Noel Borthwick

@Norave can you send us a zip of a project file that exhibits this?

The bounce to clips issue was reported and fixed two days ago. You can download the fix below. Also in the next release we have optimized this even further. The delay was because of effects flushing which we're now doing for bounce.

@Milton Sica We are unable to reproduce any difference in load times. Please send a project file that exhibits this.

@stevebell001 Its unlikely that this is related to this release but coincidental. However, if its crashing please attach the dump file that is saved when the application crashes and we can investigate. The crash dialog lists the dump file.

@Matthew Simon Fletcher it seems unlikely to be related to this release since there aren't specific changes I know of that would impact synths, Can you send a pared down version of the project with steps so we can try and reproduce it?

Apparently you have run into an untrappable exception lol @Mark MoreThan-ShawHave you tried looking in the windows event log as well?

Opening a project is slow? Have you tried to rollback to verify if its really due to the new release?

TBH I'd be surprised if any DAW did this specific thing. I'll continue to investigate it in case I can think of a better way.

Hm you added it to Cakewalk initialization section right? it should show up in preferences | initialization file. I've not seen crashes not show up with the highest level since this also catches heap corruption.

@rocstudio uad can't handle multiple plugins in the same session set to the same sample rate. Issues like this can be project specific so if you have a recipe save a simple project file with audio and send me a link.

I've implemented some multiprocessing optimizations that should make it much faster to flush plugin tails now. Thanks for your help testing this.

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.