Noel Borthwick

Hi @Andres Medina what you are doing isn't unusual or wrong, but it would be quite complex for us to make soloing a track smart enough to discover the entire downstream signal chain going to buses and automatically activate any other tracks that are feeds for sidechains in buses. The changes I made earlier were specific to discovery of interrelated signal flow exclusively within tracks (and aux tracks to some extent). It won't handle a track that outputs to a bus that indirectly relies on a different tracks output, unfortunately. So yes what we have is a major step to improve some common sidechaining requirements but not every imaginable scenario. I think the only solution for these is to manually render them for now.

@rocstudio thanks for doing these tests. I appreciate it. Based on my findings it appears that UAD plugins don't really process much faster than realtime so this might be a known limitation. I'm trying another optimization to parallel process this which may help. I will PM you directly to try something soon. BTW did you try bouncing at your playback buffer size instead of using 350? I wonder if UAD plugins don't like large buffer sizes and that causes an issue.

@rocstudio A quicker test may be to start out with all FX bypassed from the global FX bypass on the toolbar. Then go to each individual bin one by one and unbypass, retesting the bounce each time. When the delay comes back you have the plugin causing it.

@Andres Medina I tried your project. I think you are mistaken about this. Soloing the Instrumental track does not automatically include the vocals sidechain because it is routing through it via a bus circuit. You can see this by looking at the meters in the vocal bus. As a result the export also fails to include the vocal sidechain.

@rocstudio Sure you ran 126? If so I'm not sure why those plugins are blocking processing for so long. I'm definitely informing the plugin about offline bounce now. Does the same issue happen even with normal exporting without a task queue? You can narrow it down by bypassing your plugins one by one till you find which ones cause the issue. My hunch is this is UAD specific. Please let me know if you confirm this.

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.

Weird. We'll check that its initializing with the same sample rate as the project.

@rocstudio can you please try this new build 126 with BounceFlushTailsMaxDurationSec set to 20. It now properly signals offline mode when bouncing. Hopefully there is no predelay with this one. Let me know...

Hard to say. @Mark Morgon-Shaw can you raise the ExceptionHandlingSeverity to 7 and retest this? That should capture a proper crash dump. Add the ExceptionHandlingSeverity variable to prefs initialization file and set it to 7 and then restart the app.

@rocstudio "much better" as in there is no pre and post delay for the bounce? I suspect I know what is going on. Your UAD plugins are processing in realtime and slowing down the export. I've made a change that should solve that issue if so. I'll send another build to try shortly. In the meantime you can verify this by bypassing all your UA plugins and exporting with BounceFlushTailsMaxDurationSec set back to 20 msec which is the default.

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

Please test this by soloing the tracks you are exporting since export goes through the same process.

I see thanks. I'll investigate this and see what's involved. As I said earlier there may still be corner cases I've not explored so far.

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?

@rocstudio So the same issue occurs with bounce to track when bouncing the full project correct? That means the delay is happening when flushing effects tails with some of your plugins. Do you have some plugins that are generating audio even with silence or very long reverb or delay tails? You can try changing this variable in the configuration file BounceFlushTailsMaxDurationSec Go to Preferences |configuration file | Edit Config File Search for BounceFlushTailsMaxDurationSec and set the value to 0 and save the file. Then close Cakewalk without changing anything else Restart Cakewalk and retry the bounce. This should perform the bounce without doing any effects tail flushing. Let me know if this solves the issue.

@Andres Medina you will have to give me a test project with exactly the routing as you set it up. I don’t know exactly what you mean by sidechaining placed on a bus. Did you mean you are sidechaining a plugin in a bus from a track send or are you sending from a bus to a side chain in a track? The ultimate test is to solo the tracks you want one by one and check if you are hearing the sidechain. If you hear it then it should render in the mix. If you don’t hear it when soloing then we can troubleshoot that further.

Please start a different thread for issues present in 06 or earlier. For looping issues you should provide a test project or clear steps to demonstrate. Very often such problems are data or plugin specific.

Here is a link to Build 124 that has an optimization for clip bounce. See if it solves this issue. @Andres Medina this also has Mark's fix for the selection problems you were having. Let me know if this resolves your issue.

@rocstudio looking at the video I can't fully see whats happening but it appears that the lag is happening before and after the actual bounce happens. i.e. before and after the progress bar runs from 0 to 100% and shows activity. Is this correct? If so this means that the actual bounce happened quickly but the startup and shutdown took time. Please confirm that this is what you saw. Also if you select the same time range for all tracks in the project and do a bounce to tracks instead of bounce to clips do you see a similar lag? Your project didn't include audio but it contains several UAD plugins. I suspect something expensive is happening there. I can send you a build to test with my optimization in case it helps. Perhaps you could upload the file "Top Snare (Bounced, 326).wav"

Upload it to any file share (include the audio data) and send a link. I found one possible inefficiency that I've fixed for next update. It would flush all plugins in the project for each clip being bounced which is unnecessary. For a project containing a large number of plugins that could have added a little overhead. Not sure if that is your issue however. In normal cases I don't see any obvious slowdown. If you post a video of what you are doing it may get more clear.

Can you provide a project that exhibits this? What does the track that contains the clip look like?

This is caused because you have an incompatible version of the roboto fonts on your system. We're working on a solution to that. If you react to fix it locally for now you can uninstall your roboto fonts in windows fonts, assuming your don't use it for something else

Well the change for that was only added on Friday so it doesn't exist in 114