Jan

Thanks. In case this is easier/more convenient you can just send me the .exe or .dlls instead of the full installer and I can replace them myself.

Since you said CbB was running fine you might want to try replacing Sonar's AUD.INI file (located in %APPDATA%\Cakewalk\Sonar folder) with CbB's AUD.INI file (located in "%APPDATA%\Cakewalk\Cakewalk Core" folder). Obviously do that when Sonar is NOT running. You can get to those folders by pressing WIN+R and then pasting the name of the folder from above. Make sure to leave the quotation marks intact in the second one.

@Noel Borthwick ok, I think I managed to get something for you. Here's a simple project containing a bunch of empty tracks, a bunch of copies of the metronome track (to give Sonar something to do) and a prerecorded sine wave track. I'm also attaching a recording (via MRecorder plugin) of me clicking on various tracks (32 sample buffer - see next paragraph) with the sine track soloed. Since this project is not very CPU-demanding the issue is somewhaat reproducible under my usual 128 or 256 samples buffer although not very easily. Going up to 1024 on this sample project makes it completely unreproducible. However, I managed to get a 100% repro rate by setting the buffer to 32 samples. I also tested it under CbB 2019.09 and it can't be reproduced even on the smallest (16 samples) buffer possible. So clearly there's some CbB -> Sonar regression and given that it's project complexity/buffer size dependent it looks to be a CPU load issue related to the initializing/rendering of the mini-ProChannel view. BTW on this project when NOT playing CbB 2019.09 shows 19% audio processing when under 32 samples. Sonar 2025.07 shows 23%. One interesting discovery - in this case (mini-ProChannel view unchecked, but ProChannel displayed in its normal view) the issue does NOT occur. But if you enable the mini-ProChannel view and still keep ProChannel displayed in its normal view the issue DOES return. So it must have something to do with rendering/initializing the mini-ProChannel view underneath. I hope you'll find my root cause investigation useful. glitch-project.zip glitch-2025_07_12 11_18_08.7z

@Noel Borthwick as I said I wasn't particularly successful reproducing this in a blank project. I'll see if I can find one of mine that is "simple" (although I'm not entirely sure what would constitute a "simple" project?). Otherwise I suppose I can share the one where I first noticed that issue. see post below

I think I might have found the likely culprit - when the ProChannel is unchecked the glitch does NOT seem to occur. This would explain why it wasn't happening on MIDI tracks and when in "MIDI" view of Instrument track (they have no ProChannel to display). So I guess this is potentially a temporary fix for me, although that's still a bug and regression from 2019.09...

No prob, I don't think you should expect anything less from a fellow software engineer, I guess I'm just golden-ruling it

And one more which might limit the number of potential root causes: The glitch does NOT happen when Track Inspector is minimized. So it definitely has to do with querying/displaying audio properties of audio track/aux track/instrument track. I thought maybe it was the spectrum analyzer (which the 2019.09 doesn't have) but turning it off did not help.

Another interesting piece of information: The glitch does NOT happen on INSTRUMENT tracks when "MIDI" properties view is on. So it looks like the glitches only occur when a Track Inspector is attempting to display AUDIO-related information when one switches from one track to another (as it happens when switch between 1) audio tracks, 2) aux tracks and 3) instrument tracks when "Audio" view is enabled) The glitch also happens when clicking "show/hide pro-channel", "show/hide track properties", "show/hide tempo inspector", "show/hide arranger inspector", "show/hide clip properties" (but only in the cases listed above, so on 1) audio tracks, 2) aux tracks and 3) instrument tracks when "Audio" view is enabled, does not happen on "Midi" view)

I'm using the exact same project folders as in CbB. There's no AV running. I tested this multiple times - CbB plays fine, Sonar glitches. And this happens only when clicking on a track, when I don't touch anything everything plays fine. There are no visible CPU spikes or anything.

Some additional info - ThreadSchedulingMode was set to 1, changing to 2 or 3 - no difference. The AUD.INI files from CbB and Sonar 2025.07 are almost identical except DefaultAudSnapOfflineStretchMethod (was 12, is 11, obviously, because Elastique) WaveInID (was 2, is 0) LatencyMsec (was 5, is 2.902494 - that's an odd one, but as I said changing the buffer size even to 512 samples doesn't fix this) TransDetectorModel (was 1, is 2) AutomationDecimationMsec (was 50, is 5) and a bunch of new entries in Sonar's file TransDetectorUpgraded=1 CoreSelectionMethod=1 ExcludeEfficiencyCores=0 PluginLoadBalancingThreadCount=0 EnableMMCSSforASIO=0 MaskDropoutDetection=0 RestartEngineAfterDropout=1 StopEngineOnASIOPanelOpen=1

After upgrading from CbB 2019.09 to Sonar 2025.07 I sadly noticed that when the project plays merely clicking on an AUDIO or INSTRUMENT track (not resizing it or anything) produces an audible glitch to the point where some of my MeldaProduction tempo-synced effects go out of sync or some MIDI notes get canceled (in this particular case it was a Sylenth1 arp). By "clicking on a track" I mean clicking on the track strip in the track list (empty area or its number on the left). Clicking on CLIPS (first in one track, then in another) does not produce this effect AFAIK. Clicking on MIDI tracks does not seem to produce this effect. The project has approx 60 tracks and as far as VSTs go it uses multiple (approx. 20) instances of Shortcircuit (light-weight sampler, 32-bit, running on JBridge, switching to default 32-bit bridge does not change anything) for drums, 2 Sylenth1 instances, one Spire and one Dune. FX: mostly MeldaProduction MTremolo/MTremoloMB for pumping effects, MRhythmizer (hi-hat stutters), MEqualizer, also MWaveShaper. A couple of busses, 1 or 2 Aux tracks. Nothing too fancy. No dynamics processing, no limiter, etc. The CPU does not look taxed very much. The same issue occurs on other similarly sized projects (I haven't been able to reproduce this on a blank project with just a couple of tracks - perhaps the number of tracks/plugins makes Sonar behave like this) Attached files: rec1 - audio output of the project with me clicking. The glitches might not be super audible, but they are there. You can hear at around 14 second mark the arp stops playing completely (probably missed a note-on event), and you can later hear how the pumping effect goes out of sync. sine - I put an additional track with a simple A440 sine, soloed it and started clicking on tracks while the project was playing. The glitches are pretty audible. One glitch = one click (at times I clicked quite rapidly) Scarlett 6i6 2nd Gen, firmware 1583, driver 4.124.3 (newest, freshly updated to see if it makes any change - it doesn't) i7-8700, 32GB RAM, Windows 10 driver mode: ASIO, Use multiprocessing engine: on, plugin load-balacing: on, use MMCSS: on, enable MMCSS on ASIO: off (flipping LB/MMCSS/MMCSS on ASIO doesn't change anything) This has never *) been an issue with CbB, which is running fine on a 128 samples buffer. Increasing the buffer size to even 512 samples (way beyond my comfort zone) doesn't seem to change anything. CbB has just started displaying "activation required within 11 days". Not great *) well, at least not when simply clicking on tracks. It would however produce similar effect when clicking Mute/Solo while playing - temporary glitch, MTremolo going out of sync until playback is restarted. I just figured out "that's just the way it is" and learned to live with that. However having this happen when simply clicking on a track (to change eq, whatever) is a dealbreaker. P.S. Just noticed - while writing this - that when I came back to Sonar and hit "Play" the window would update only once per second (a slideshow essentially). Not sure what caused it. Maybe related? rec1.mp3 sine.mp3

@Noel Borthwick I confirmed with both my original and test projects that the issue is no longer reproducible in the new build. Thanks a lot for fixing it so promptly! Just as I suspected the bug has been lingering there for a while, but went unnoticed - not necessarily because of people using integer tempos (although quite possibly), but even if you are using a fractional tempo you might not notice it if you retrigger your arp often (chord changes or sth) - I have another project with a 122.52 BPM tempo, but since I retrigger the arp every bar it was not noticeable. In that 139.77 project I don't retrigger the arp at all.

Until this is fixed I can't use Sonar

Yes, and that "any time" depends on when you last reactivated which is what I'm trying to find out. If your last activation refresh was mid-February, then it will work until mid-August. If the refresh was yesterday it will be good until January 4th, 2026. I don't have a date there sadly, perhaps it was introduced later. I'm on an ancient 2019.09 version.

Well, I did just that and turns out that my projects are not identical (some odd tempo sync bug with VSTs that's not present in my old copy of CbB (2019.09)), so I can't use Sonar Free until this is fixed and thus I'd really love to know how much time I have left on my copy of CbB...