Noel Borthwick

@Tez we’ll need more information about this. If its crashing its most likely plugin related. You can try turning on the higher exception handling levels to capture a dump file for the crash. Also can you try the latest early access release that has a lot of improvements to export and bounce?

Yes a matrix cell has a full copy of the underlying data stream. While the base data type is similar, clips in tracks are more complex than data in matrix cel’s, hence its not trivial to share data directly across tracks. Editing operations are different etc.

Yeah the toast message has a max limit so that will happen. Best to use shorter messages there.

It is a sticky notification by design so it will not follow timeout. All you can do is disable notification is you don't want them. Note: This will disable ALL toast notifications (including update notifications) except for important warnings.

Im not sure what you are expecting. It works exactly like all toast notifications in Cakewalk. If you turn off show toast notifications in preferences you won't see a toast notification on export. That is the only change. This is in build 114 and I've tested it works.

Build 114 has been uploaded Bug fixes Fixed a regression with exporting task queues when the task was created with no selection made, leading to an empty exported file. Export toast notification now respects the setting in Preferences | Customization | Display | Show Toast Notification

Yeah that's not great. It is explained in the tooltip however. We'll try and set the text to show something descriptive other than zero.

Yes there is a regression with export tasks caused by some of the selection changes. We’ll post an updated build so that you can resume testing.

The reason why we don't do this behind the scenes is because like audio latency, there are cases where it can affect sound so we don't want to second guess the user. Some plugins will render differently and then users will complain that their bounce sounds different. The higher buffer size doesn't play such a big role in memory consumption, but it plays a huge role in speed and CPU load. While it may not be very noticeable in small projects, with 400 or 500 tracks and lots of clips for example, it can be the difference of whether you can export in real-time or not. >>Those folks do not need understand why some buffer setting is faster and other is slower. Shall I rename the field to something esoteric like export acceleration? :) Re memory consumption the main change in 09 is that when you export the entire mix with all tracks it no longer duplicates the project in memory which uses a lot of memory and setup time. In large projects this will make a big difference because it now exports directly from the main project loaded in memory.

Got it. That would be a task better suited to scripting as mentioned.

You export multiple projects on a daily basis? Export queues are designed to be per project. We don't plan to build multi project export as a function. That said, in the future it may be possible to do scripting operations to achieve something similar.

First world problems? The toast is displayed so that people who walk away can see it. Close it if you are done with it. It's one click.

There is a tooltip already if you compare a 2 msec buffer to a 200msec buffer you will save more than 2x the time in my experience. It depends on the plugins and data in the project

As mentioned before aux tracks and buses are not exactly the same thing. A source category for them is not the solution. There are some further steps to potentially improve this behind the scenes without adding unnecessary and confusing user options. What was fixed was a fundamental issue with source category tracks that was preventing rendering of outputs to aux tracks and sidechains. This was the root problem.

You should be able to test with any export buffer size now and not get timing problems or lost MIDI. The numbers there are just dividing the range of values to give you some convenient multiples to pick. You should be able to manually enter any in range value for the buffer size if you wish. Note that VST2 plugins and some VST3 plugins do not support intra-buffer automation so if you have plugin envelopes you may notice aliasing at higher buffer sizes.

A new build has been posted today Sept 4 2021 which addresses a serious issue. We recommend updating to this build to avoid unexpected crashes with realtime bounce. Bugs Fixed: Bouncing or exporting audio in real time could cause a crash or unexpected behavior in some projects due to a race condition.

@JoseC It is intentional that it defaults to a new track because that is the 99% use case for most people because when you bounce you don't want to accidentally overwrite data on another track or the same track. If you are bouncing to save CPU you can use freeze.

Not in general because a single task can generate multiple files depending on the source category.

@Max ArwoodPlease try this in todays build.

A new EA build has been posted that includes fixes for several reported issues and numerous improvements. Please check it out and report back if you encounter any problems. In particular please look at the new export folder source category and the improved handling of aux tracks and sidechains when exporting or soloing tracks. Anyone who had issues with soft synths or tempo changes not rendering properly please check out this build. @Terry Kelley hopefully your problems with the last beta should be resolved. @Promidi @chimkin2 does the folder export and improved sidechain handling cover your requirements? Happy labor day weekend!

you are running an old version and many such issues have been fixed since then. Update to the latest using this installer Also Win 7 is not supported as stated in the install message. It is not tested anymore by us and you use it at your own risk,

I assume you meant 250 and not -250? Also confirm that you were doing a fast bounce and not realtime bounce.

Yes in the new export dialog there is a way to set the export buffer size independently. Try with that set to 0 which uses the same buffer size as playback. I suspect the issue is related.

@Terry Kelley Rolling back without providing any info is not going to help us solve the issue you are running into before we release. Can you provide like to a small project that has this issue? By any chance are you using the export buffer size higher than your audio device buffer size. There is an issue we're investigating there.

If you import a wav onto a NEW track that did not exist before this will not work because the tasks will not know about it. However if you import data onto pre existing tracks it should work.