David Baay

It's the control at the upper right corner of the Track View that currently says "Off", so that's probably not the cause, and might actully be the solution. If you enable Ripple Edit - All, closing the gap on any clip/track will automatically close the others, keeping all automation, tempo changes, etc in sync with the move. But do it on a copy of the project as suggested, and be sure to disable it after the project is fixed so you don't get in more trouble!

MIDI buffering issues generally manifest simply as dropped or stuck notes (more often the former) which shouldn't really affect how a plugin behaves unless maybe you're automating synth parameters via MIDI controllers or key switches. It would be really nice to at least know what specific plugins are implicated. I understand the OP doesn't have time to investigate thoroughly but we're not likely to get to any diagnosis without more detail.

Zero is the default that tells Sonar to use the real-time buffer size for Fast Bounce. After encountering problems with rendering of some synths at very low buffer sizes I long ago raised it to 20ms and have had very few Fast Bounce issues since. Would be interesting to see a project with one particular track and FX that reproduces the issue. Are you seeing this with any super-common plugins?

I would try: - Set Workspaces to None if it isn't already. - Make sure any screenset in use isn't locked. - Drag the tracks pane completely closed and back open to force a redraw. - If that doesn't get it, remove each group of problematic tracks from its folder and move them back in with or without re-creating the folder depending on whether the problem persists. If that fixes one project but others continue to have a problem, I would suggest you abandon any old templates you may be using and re-create them from scratch, starting with a Basic or Empty one. In the past, I've had templates that continued to have issues around new features that didn't exist when they were created.

I agree this is likely system-specific, maybe related to the interaction of the display driver with a specific combination of Windows and Sonar scaling. Is Windows at a standard scaling increment and Sonar at 100%? I have encountered one specific, reproducible case where I get blank space to the right of the Prochannel tab in the Inspector with a custom Windows scaling setting. Otherwise I haven't really ever seen blank space anywhere in the UI except when the app was in a bad/hung state.

Bounce or Freeze? If freezing, getting tails rendered properly is just a matter of enabling it and setting the time in Freeze options. When bouncing, you have to deliberately select a longer time range to include the tail. The quality issue may be due to particular plugins not playing nice with Fast Bounce or in combination with a low ASIO buffer size which is the default for offline rendering. Try setting BounceBuffSizeMsec in Config File to 20 (milliseconds).

I don't recall that feature, and maybe I'm missing something in the workflow, but... why enable looping at all if you only want a single pass? Just enable "On Stop Rewind to Now Marker" in Track View options, and start recording (and performing) as many bars before th punch point as needed to get in sync. When you hit Spacebar to stop, the transport will return to wherever it was started. If your really want to use a loop marker to define that start point, you can just put the end of it further out in the timeline to give yourself time to hit spacebar after the punch out before it loops back.

More likely just an issue with the that particular project's internal referencing of the plugin, but for good measure you might want to re-register the dll which is the usual solution for this error: - Open a command prompt and cd to C:\Program Files\Cakewalk\Shared Dxi - Type regsvr32 GroovePlayer.dll and Enter.

Inquiring minds want to know... what the heck kind of presumably-unrelated update caused that regression?

Maybe share a copy of the project with just that one track in it.

Each send creates a duplicate of the original signal that is going be merged with the track output at some point on bus or at the hardware outputs. If the tracks and the aux go directly to the same bus with no FX on it, you should see a 6dB increase wherever they merge, but if the sends aren't at 0dB or there are FX anywhere in the chain, you might see more or less than a 6dB increase.

Hmmm, yeah, pretty obvious. 🙄😜 Ye olde "picture is thousand words".

They cannot be deleted, only "Disabled", but that's effectively the same. And you can "Promote" their disabled stated to keep them from being re-enabled by lowering the Threshold.

I was going to suggest the same after testing with all 24 (!) OUTs enabled on my main DAW but only one used in the project, and finding the delay is in excess of 2 seconds. It's been a long time since I used more than 2-3 ports on that DAW, and my laptop has only a single OUT so hadn't noticed it. @Noel Borthwick I'm also wondeirng if it's necessary to send messages to all ports serially, or only per-port - i.e. could the same message be sent simultaneously to all ports or would some drivers still have trouble with that? It definitely seem like this needs to be defeatable for users who encounter it and have MIDI interfaces that aren't sensitive to high-speed messages.

I would think the delay must be a significantly larger fraction of a second to be noticeable much less bothersome. 50ms is on the order of the fastest double-click the most agile mouse handlers can achieve.

Unfortunately I don't have those plugins. A comparable project that I think everyone should have access to is Tim Lord's CbB demo, Time to Fly.

Load distribution across cores appears much more even in Sonar - both in the app and in Windows resource monitor - and some individual cores are being pegged with Cbb which is usually more of a problem than a high average.

Not the typical experience of course. You should submit a crash dump to Support.

Even though Sonar seems to be suffering more than CbB, you definitely need to do this, starting with disabling Speedstep and C-States in BIOS. and setting High/Best Performance power mode.

~30% average engine load with peaks over 100% indicates DPC Latency spiking issues. I'm not sure why Sonar would be more sensitive to that than CbB on your system, but both of them are showing it and suffering for it. So check your DPC Latency and figure out what's causing it. https://www.resplendence.com/latencymon Common offenders are onboard WiFi and Bluetooth which can be disabled in BIOS if necessary. Some laptops will also suffer from issues with power management either because CPU is being throttled or just due to the activity of ACPI.SYS causing DPC spikes.

... or you're not using tempo-synced FX or arps, which is my excuse for not picking it up. Almost all my projects use fractional tempos because they're set from recordings made without a click, but I haven't used any tempo-synced FX recently. I'll have to add that to my regression watch list. ;^) Noel, does this mean there might still be subtle sync errors if the tempo is changing frequently by small amounts? I sometimes snap the timeline to every beat of a freely-recorded piece but leave all or most of the variability intact. If the piece lends itself to using tempo-synced FX, that variation is likely to get flattened to a fixed tempo, but not always. Just curious whether your caching approach would accomodate that.

Check that your Playback I/O [disk] Buffer is the same in Sonar as in CbB. And do remove the Realtek ASIO entry from the registry; probably of no consequence, but it's not compliant and Sonar won't work with it anyway so it might as well be invisible. If you ever have a need to use the Realtek interface, change Sonar to WASAPI mode. The "Configuration File" is AUD.INI; in the past we would rename it manually to have a new default one would be created automatically on launch. The Reset function just makes it easier, automatically backing up the existing file and replacing it with the default. Doing this after removing Realtek ASIO from the registry will ensure that AUD.INI contains no reference to it. You might also try unchecking that 'Low Latency mode' box in the QuadCapture's ASIO panel. That reduces the interface's internal firmware buffer at the cost of some dropout-resistance.

File > Export > Audio and Export [module] > Advanced... should open the same UI by the same underlying method. If there's a difference in the result, it's probably down to some interoperability issue with Win10 as Noel suggested. But possibly that info can lead to an easy fix.

I can't repro this, and not sure what might cause it other than some mutually exclusive state like having an ARA FX applied.

Preview bus is now set by right-clicking the desired bus and selecting 'Set as Preview Bus'.