David Baay

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'.

I agree the pointer could be improved, but I can't repro that the results are that wildly inconsistent/imprecise/unexpected in the Staff View. Can you post an example of MIDI track/file that exhibits this with some frequency?

A few more things to check/try: Uninstall Steinberg Generic Low Latency ASIO driver if present. Remove Realtek entry from HKEY_LOCAL_MACHINE\SOFTWARE\ASIO in the registry. Reset AUD.INI via Preferences > Audio > Configuration File > Reset... If it doesn't help, you can restore the backup that the process creates. If it does help you can compare the two files to see what's different. And, of course, make sure you're testing with the same project using the same audio and MIDI driver selection(s).

What's the exact scenario (i.e. what delay values, what tempo, where does the switch occur, and where are notes relative to the articulation start/end points). Maybe share a simple demo project. I once had a project that exhibited a change in note volume related to an issue with articulation delays, but I reported it, and the problemis no longer reproducible in in the current release. Possibly you've encountered another manifestation of that problem.

I guess it could depend on what else is going on in the project in the way of PDC and overall processing load but I definitely have not seen anything like that, even with a 2048-sample buffer at 48kHz.

Are you sure about the length of that delay? I think the gap that Noel is talking about is more on the order of an audio buffer or two - maybe 50-100ms if you're running a large buffer. The gap I get is like that - a small fraction of a second.

Yes, definitely 20-40% better. ;^)

The CbB screenshot is showing "X-AIR ASIO Driver" while the Sonar screenshot is not showing "ASIO". Possibly you have the drive mode set to WDM or WASAPI...?

Is CbB still giving expected results with the same project in both cases? Sonar has revised External Insert functionality that now supports using mono channels of a stero pair independently among other things, but I've not seen any issues with it except in very esoteric use cases (e.g. putting two mono external inserts in series using channels of the same stereo pair which - not entirely unexpectedly - causes PDC issues). I don't often have enough tracks in the Console view to have to do a lot of scrolling but I can't say I've ever seen that issue.

FWIW - I'm running a i7-3770 @ 3.4GHz... I've now got 32GB ram, but was running on 16GB for years. I'm typically use an ASIO buffer size of 64 Likewise here on a 10-year-old i7 6700k @ 4.0Ghz with 24GB. It continues to run great for my purposes - admittedly using a generally limited number of synths and FX plugins compared to what some users require. But running more plugins just requires raising the ASIO buffer. 8GB would already have been considered somewhat marginal even in the Sonar 8 era, but is no more limiting now than it would have been then. If it's possble to double it, that would be advisable.

The longest audio file I have handy is two hours and 15 minutes. I just opened the project over WiFi from another PC where it's saved, figuring that would be worst-case. It took some time to draw the waveform, but even before that completed paging back and forth by measures was instantaneous as expected. So unless the audio has to be a lot more than two hours to demonstrate the issue, whatever is happening seems to be peculiar to your system or Sonar configuration. You might try turning off/disabling your interface to see if it has something to do with Sonar's interaction with the audio driver.