Noel Borthwick

Zoom makes good interfaces. Not many audio interfaces support 32 or 64 bit inputs. The only one I came across many years ago was from Rane and that was a DJ mixer. It made sense to output in 32 bit since it was mixing internally. I’m sure you are aware but besides the advantage of flexible gainstaging (low or high input gain isnt a problem in float) there is no sonic advantage to 32 bit inputs since all ADC converters are up to 24 bit. Its clever that they have two inputs and choose the best level. Not sure how they handle that dynamically without levels jumping around but it seems plausible. However in this case you should note that the 32 bit inputs themselves are not giving you better dynamic range of the audio, since the convertors are still sampling 20-24 bit audio at the end of the day. My guess is that they are likely applying some gainstaging for whatever algorithm they use to combine data from two inputs and its more convenient to do losslessly in 32 bit. Still its a nice innovation. In Sonar there is actually an advantage to having 32 bit inputs from the audio interface. Since the engine is all floating point, all hardware inputs get upconverted to 32/64 bit depending on the engine bit depth. If the audio inputs are already 32 bit no conversion is necessary so this actually saves a bit of CPU.

It does save the state per project.

@Bassfaceus Your dump file is for a hang and isn't from the latest release of Sonar. Also it contains no info that shows Sonar code hanging. I suggest updating to the latest Sonar release and retesting this there.

Can you send the crash dump so we can check if it's a plug-in crash?

@Scott C. Stahl I'm not sure what you mean by changing the version number.

@Scott C. Stahl you sure that saving is slower in this build? I can send the last release if you want to compare and report back. Note that GPU is only used in the piano roll view currently and only if it is enabled in preferences. If you can send me a video of any drawing issues we can look into it.

Sonar processes audio and MIDI independently and as a result each can be processed at different buffer sizes. While it is more efficient to process larger buffers than tiny buffers in general, a larger MIDI buffer size means the engine has to prebuffer more MIDI data when you press play. This translates into a small lag before playback starts and depending on the project size and amount of tracks it can take a second or more. Running at a smaller size means there is less work to do before playback starts. Note that unlike audio, running MIDI at a larger buffer size doesn’t mean that “just in time” live MIDI will be delayed. JIT MIDI is always processed immediately and not subject to the MIDI buffer size.

Hopefully you can confirm this is fixed in the latest Sonar version…

This isn't totally accurate. In this case the malware is the old Microsoft redists themselves lol. Installers don't overwrite redists themselves. App installers just install the Microsoft redist installers. The problem is that old versions of the MS installers cause problems. Recently Microsoft started shipping universal redist installers but many companies don't seem to have caught on to this and are still using the old installers. This is the main source of the problem.

This. When you solo the track it figures out all the dependencies for the track and conceptually solos them as well. In this case the bus is a dependency for the track because you are sending to a side chain plug-in input in that track. So the circuit for that bus gets activated. This is the only way you can hear the side chain. If you don't want to hear that bus you can set it's output gain to silence.

You should be able to work with smaller buffer sizes than that. Sonar adaptively scales it only when needed. It should apply for export as well. I can run most normal projects at 20ms without any issues. If it needs more it should post a message informing you. Please report your findings.

The 2024.09 feedback thread is where you should post anything you think is specific to the new release, not in random threads.

Wasapi isnt a driver. Its the windows API to access all audio hardware drivers. Its the same API that windows itself uses. As long as a device exposes wdm drivers they should be available via WASAPI. WASAPI shared mode in particular goes through the windows audio engine, which is how it is able to handle multiclient use of a single audio devices. As a result it has a 10 ms latency. WASAPI exclusive doesn't have that limitation. Its not that WASAPI is perfect, but its the Microsoft recommended API for consumer audio devices. ASIO4All and some other similar products try and duplicate some of that functionality but introduce other problems because they wrap all other audio devices on the system and when Sonar starts up sample rates can get messed up with other devices among other problems.

I don't see any point in using a WASAPI to ASIO wrapper when Sonar already has robust WASAPI support. You are inviting more problems and bugs by doing that. If you have a problem that is related to our WASAPI support report it as a bug and we'll investigate it in time. A WASAPI to ASIO driver couldnt get any better latency than Sonar already gets from WASAPI. Its typically limited to 10 ms for USB audio devices in shared mode, and can go lower depending on the manufactures support for WASAPI. Unfortunately a few manufacturers don't support great latency in WASAPI and if so the only recourse is to use ASIO.

There is a new feature coming in the next release that would help with this very issue.

Yes the problem was related to the loop construction view preview bus. I've fixed the issue for the next release.

There is forwards compatibility to the extent that older versions skip data for unknown features. That is essentially the definition of forwards compatibility since older versions cannot have code for features that don’t exist obviously. My point was that this has never blocked anyone in the past from sharing project with others using older or different versions of Sonar.

This is in the latest version of Sonar? If you pm me the original project file I can take a look.

I can open a Sonar project in a Cakewalk version from 2009. I don't think there is a likelihood of it preventing anyone from working.

Read these official links. Sonar projects are always backwards compatible with prior versions. We've supported backwards compatible from day one.

A secondary advantage with those is that if a plug-in takes the system down it won't crash the host.

Can you send the source wave file that exhibits this? Perhaps it may shed some light on why it happens, assuming its reproducible.

Even with a modest project using virtual instruments at low latency, the performance gains with Sonar are very significant. Sonar will allow you to run at 64 or even 32 samples with instruments that were impossible in CbB. Of course if all you do is run at 1024 or higher then you aren't going to notice the low latency performance. Even besides realtime performance we've additionally been focusing on improving speed when performing common editing operations. Those are certainly gains that any user will see on any hardware. Its anything but a marginal improvement - depending on the workload you throw at it. Imagine a project with 128 instances of Kontakt - Try doing that with Cbb and run at low latency. Not that most users are going to do that, but the fact that the engine now has the headroom to handle this allows more modest projects to run at far greater stability, especially at low latency.

Correct this was changed because 99% of the time a user doesn't need every single parameter exposed and consuming resources. Adding them on demand is the way to go. You can also create track templates if you need them often.

Those are BandLab specific tools so you can accesss them via BandLab studio. They aren't accessible in Cakewalk apps today. If you want them in Sonar or Next, send a feature request to BandLab support...