Noel Borthwick

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

On 9/19/2024 at 2:07 AM, Starship Krupa said:

Installers that just go ahead and overwrite the MS redistributables without checking to see if a newer version is already installed should be categorized as malware for all the damage they do.

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.

On 9/12/2024 at 2:23 PM, Xoo said:

This makes sense then: the bus needs to be active for the sidechain to work, so soloing the guitar track doesn't mute the bus.  I reckon you could do something clever with pre fades and multiple busses but I'm not sure what right now 🙂

 

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. 

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

31 minutes ago, Milton Sica said:

Could you explain how the "ROBUST SUPPORT THAT SONAR GIVES TO WASAPI" works?

I believe this would be important to dispel many of the doubts we have about the use of this or that driver.

Thank you!

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.

10 hours ago, Starship Krupa said:

Similar then to the wrapper that I use when I need a wrapper, ASIO2WASAPI.

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.

On 9/6/2024 at 4:57 PM, Steve Moddelmog said:

I agree.  The clips were so small I didn't notice them, and they are 7 years old...

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

11 hours ago, John T said:

The thing that puts me off the subscription is that I use a DAW to make a living, every day. And given how erratic what I make a living at is, cash flow problems do happen. So if my main work software is going to lock up and stop me working abruptly because of a missed payment, that's not good. May seem a fringe case, and it is, but these things do happen.

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.

16 hours ago, norfolkmastering said:

I know this is a well worn topic but …

It looks like the original  ‘get advance access to Sonar in Beta form’ has been replaced by ‘get access to Sonar’ via the monthly or annual payment options.

So I guess I have three questions:

Is Sonar now officially released or is it still officially in Beta testing?

If I start a monthly subscription then at some point stop, are all my Sonar projects trapped?

Is there any hope of getting a statement from Bandlab about future pricing intentions or do folks think the current ‘rental’ option is likely to be it for the foreseeable future (I’m not a fan of renting software)

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.

3 hours ago, Terry Kelley said:

I have to load CbB beyond rational thought with VSts before it even flinches. If someone notices a difference between CbB and Sonar with a few instruments, something else is amiss. CbB can handle A LOT.

Excluding Arturia Augmented "Anything" ... And no, it doesn't get any better in Sonar. 

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.

24 minutes ago, noynekker said:

In my humble comparisons  between CbB and NuSonar, the new audio engine optimizations are just marginally better . . . I'll take it . . . especially for my well aged I7-3770 CPU, and wonder if many here just want their iZotope Ozone plugins to keep up with the times, without $$ upgrading CPU's and Cores. When I first read about this new feature of optimization, I kind of thought it was geared towards the newer computer systems, a few tweaks here and there to the startup INI file . . . poof !

I really like the improvement, but for me only a minimal improvement, until I do an upgrade I'm thinking . . .

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.

10 hours ago, Johnbee58 said:

I've renewed my membership.  Now, how do I access the Exclusive Creation Tools like the Voice Cleaner, mastering tools, etc?  Are they accessible in Sonar?

Thanks🙂

John B

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

What your see when zoomed in is the raw audio not the preview audio. Preview audio is computed from averaged out windows and stored in the Wov files.

If you don't see it when zoomed in then it's not there and I wouldn't worry about it.

Cakewalk Next is much deeper than project 5 ever was.

The licensing is per user and we allow a for generous number of machines, more than most users would need. The actual count is not specified today but if the system is abused it may result in activation being revoked.

This is raw engine performance optimizations so it won't magically solve bugs in plugins unfortunately 😉

Thanks for your feedback. The last update is possibly the most important performance update we’ve done in more than 15 years actually. 

The work started with trying to resolve some somewhat unrelated timing discrepancies with VST’s and also to solve some severe problems dealing with huge synth projects. However, as part of profiling the app to find the root cause of these, as a happy accident I discovered a major bottleneck that was preventing the multiprocessing engine from efficiently load balancing. The reason this was not discovered earlier, is that the problem was obfuscated in some completely unrelated transport functionality and it never showed up as a problem earlier. Imagine searching for a needle in a haystack… The net effect was that the engine would be unable to independently process tracks as efficiently as possible. This had a knock on effect to all processing including our plugin load balancing technique. Once this issue was resolved many longstanding issues magically disappeared. We also fine tuned a lot of the VST processing code so now it has the minimum overhead, allowing for much better low latency throughput.

It doesn’t stop there. For the next update we have been working on improving MIDI editing performance, better support for large scale projects, and resolving some longstanding MIDI rendering issues. Already multi-track PRV editing performance has been massively improved. We’re talking hundreds of times faster to perform certain operations!
 

But are you willing to take the turing test? 😜

Re more friendly surface support yes we have lots room for improvement and I’m sure azslow himself would attest to that, but there is a lot that can be done today albeit differently from other DAW’s.

It was likely the driver rather than the hardware but it's great that a simpler solution worked better.

If you reported the issue to them its likely they fixed it. You can contact them and ask.