Noel Borthwick

I was referring to the File name field not the new dialog itself. Sorry we don't plan on having two different dialogs in place. Its not practical.

Nothing forces you to use this. Change the file name to what you want it to be. It defaults to a tag thats all. Please read the release notes or follow the video tutorial posted in this thread to understand how to use the new features.

@Ty Ener-Chi please post in the main feedback thread and provide a project that has a repro. Its impossible to diagnose without knowing exactly what you are doing. Have you tried rolling back to the prior release to check if its a new issue or not?

Performance is mentioned primarily to explain that using double precision doesn’t mean you will get half the CPU performance because there are secondary optimizations in modern processors. The main benefit is the higher precision. Compare these two formats: 32 bit float https://en.m.wikipedia.org/wiki/Single-precision_floating-point_format Sign bit: 1 bit Exponent width: 8 bits Significand precision: 24 bits (23 explicitly stored) And 64 bit: https://en.m.wikipedia.org/wiki/Double-precision_floating-point_format Sign bit: 1 bit Exponent: 11 bits Significand precision: 53 bits (52 explicitly stored) In practical terms, the second has much more than 24 bit resolution so you could literally go through a huge number of gainstages, bounces or mixes and the noise floor would be inaudible. With modern CPU’s why not use the best resolution.

That is not a net performance gain in general. It Is talking about specific mix operations in the engine. And the avx thing is talking about gains with avx processing rather than double precision vs single precision. The only reason I quoted that paper was because modern processors have abilities to handle 64 bit operations more efficiently. Processing twice the amount of data for streaming is always going to have a cost.

I don't think we ever claimed a net performance gain. It's about precision and noise.

The 64 bit engine can be turned on in preferences or in exporr. The first is applied while playing the second while rendering. They both affect the engine by telling out to use 64 bit float when mixing and streaming. Bit depth only affects the file capture at the end of the signal chain when exporting or bouncing.

Modern as in circa 2005 lol. This is not new technology - we led with it a long time ago. I’m surprised this thread is even being discussed in 2021, Using 64 bit however requires twice the buffer size so it has a higher memory hit and takes a bit more cpu to handle the extra data being streamed. Also even today there are a few plugins that don’t handle it properly so there are a few downsides. An example of 64 bit gains is discussed in another white paper that we published with Intel several years ago. http://www.noelborthwick.com/2011/07/14/utilizing-intel-avx-with-cakewalk-sonar-x1/

These links should help. http://forum.cakewalk.com/64bit-Audio-engine-vs-double-precision-engine-and-a-dithering-question-Noel-please-m3804976.aspx https://www.cakewalk.com/Press/Release/1047/White-Paper-Benifits-of-x64-for-Audio-Workstations Essentially the 64 bit engine uses double precision floating point numbers from end to end assuming that plugins support it. The main advantage of 64 bit computing is that its very tolerant of errors that build up over thousands or millions of computations and has a massive dynamic range. You can literally do multiple mixing gainstages that clip > 0dB or go to very low levels and then scale back up with no audible errors creeping in. In fact the original white paper had a test project that did something like that. Not only is it advantageous for mixing, it is actually more efficient for modern CPUs to process. As far as the export settings go, its simply a way to control whether you want the export to use the 64 bit engine processing or not. I.e you can have it disabled in preferences and enabled in the export or vice versa, (If its disabled in export it will NOT use 64 bit processing even if it’s ON in preferences) The delivery file format is independent of the engine precision. You can choose to export to 16, 24, 32 or 64 bits. Obviously 64 bits will retain the full resolution and integer formats will be dithered down. There are still advantages to mixing in 64 bit even if rendering to 16 bit because the conversion happens at the last stage. Whether you will hear a difference with 64 bit really depends on the processing in the project. In simpler projects without a ton of buses and processing its unlikely that it would be audible.

@Adam can you elaborate further what specifically is broken? If you can attach a simple test project or give a step by step recipe it would help reproduce the issue here. I’m sure it is something minor to fix if its broken. Preferably please post any bugs or regressions to the main 2021.09 feedback thread since we’re tracking that more closely.

It's not. Most encoders write audio directly without first being written to wav. Only the external encoder does that

I'm thinking of adding a parallel export to wav for other encoders

I can repro it with your file! I'll investigate it thanks.

Yes you can create two tasks and they will render the wav and mp3. Its not rendered at the same time however it will do two bounces.

@rocstudio I'm not seeing any cases where audio disappears when you do a bounce to clip with buffer size set to 350. If you can reproduce this can you share a zip of your project folder so we can look at it?

Yes the that buffer size is global so is used by bounce to clip as well. That part is not new to this release. Perhaps we should ignore that setting for bounce to clips since it has no UI.

Fast bounce is not related to the buffer size option directly. All it means is that Cakewalk exports as fast as it can and is not gated by realtime playback. The custom buffer size itself only applies when Realtime playback is unchecked in the 2021.09. The only change in 09 is that fast bounce is now renamed to "Render in real-time". So to do the equivalent of a fast bounce make sure render in real-time is unchecked.

Are the dropouts actually impacting your work or is the message and audio stopping bothering you? If so you can turn off the dropout detection here:

For activation please read this FAQ on Activation, especially the section on in-app activation.

Some discussion of optimizations in win11 https://www.tomshardware.com/news/microsoft-details-how-it-made-windows-11-faster-than-windows-10

Oh God no, the cookie is only used to remember the users identity so that it doesn't have to prompt you to log in everytime we want to access something from Bandlab. The mystery of the overloud plugins activation is most likely because we install the original overloud TH3 installer which may be resetting the activation to what it used with SONAR. So this is probably why you see the custom code getting clobbered. Why it worked this time is when you updated you got our "thin installer" which only installed the program and anything that changed. This is another reason to update frequently since the updater will only get the differences rather than the full program installer No legal issues with Gibson, but your original FX chains referenced a lot of SONAR exclusive plugins which we don't ship with BL. So it did not make sense to include those chains out of the box since they would reference missing plugins for most users.

Correct. Also every time the activation is refreshed you get a new lease. You can also do it manually via refresh activation for the obsessive compulsives

Being "logged into BandLab" from Cakewalk simply means we save a cookie that allow you to reach user specific BandLab services such as the BandLab library view to download from BandLab, and of course activation itself. Cakewalk doesn't actually send any data to BandLab based on being logged in, so there is really zero need to log out unless multiple people use the system and you don't want them looking at your songs Regarding updating frequently if you don't use the program often that's really your call. Activation will still work automatically (if necessary) the next time you launch the program even if it's after a long time. I've never heard of overloud plugins losing activation as a result of updating Cakewalk. There is no correlation. Maybe you are confusing it with command center.

If you have logged into your BandLab account from within Cakewalk (and stay logged in), you should never need to manually reactivate even if you go past 6 months. As long as the PC is online it will automatically restore its activation whenever needed. Additionally if you ever install a new CbB update within a 6 month window it automatically restores activation. People complaining about this have been using an old version of CbB that didn't have these improvements. This was done back in April. Current CbB users will never see this message. The bottom line is issues like this is why we want people to keep up to date. Otherwise they complain about things that have been fixed ages ago.

Do you see the audio data in BandLab's mix editor when you edit the project there?