Noel Borthwick

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.

@Gavin Davies thanks for your interest. There is no way to contribute to actual development other than being a developer because Cakewalk isn't open source. Matrix cells store a copy of data and there is no linkage with tracks so it cannot be edited in realtime unlike the step sequencer which has native cel data. The cel data can be copied out of a cel into the TV via drag and drop and edited there and copied back but there is no direct way to do that in real time today. We have update to the matrix in our backlog but it won't be in the immediate future. Recording and direct editing were considered in the original spec for the Matrix but did not make it in.

@JamPro Which version of Cakewalk are you running and what version of Windows?

AFIK The track and clip tokens only apply when exporting with source category track or clip respectively. If you are exporting the entire project it wont pick those up since the export isn’t per clip.

Not sure what current filename refers to. The token “projectname” will expand to the actual project name. If you save as a new project then your exports can inherit that name automatically.

In 30 years of Cakewalk I have never seen this issue Glad you figured it out. I can assure you that it has nothing to do with any recent update. If you find out that markers are being created without user intervention please let us know.

Please read the docs on using the tags. You can parameterize the file names. If you use fixed file names and want to change them then of course you need to create new tasks for them. The program can't guess what you want to do.

Elastique Pro is pretty much the standard these days. Primarily because it operates in realtime unlike Radius but it also sounds great. Radius was good but they discontinued support many years ago. BandLab also has its own propretary real time stretching called AudioStretch which is very good. I may integrate it as another choice in the future. You can check it out in BandLab or in Android/IOS there is an AudioStretch app.

Actully if you selected entire project for the task it should adapt to the duration changing.

The dest track is based on the current track. If your set that before opening the dialog then it should default to it.

Not easily because there could also be more than one track as a source.

Entire project refers to the selection time range in the project. However if you add new tracks to the project later they won't be included in that task. IOW tasks are very specific to the project state at the time the tasks were created. If you change the project later you have to make a new task or update it. Tasks are not intended to be valid for the lifetime of a project if you make changes to it. It's cheap to make new tasks so just delete the old ones and create new tasks.

Thanks for the feedback. We don’t really have control with how Radius handles its stretching since it was developed by iZotope and its no longer maintained by them. IIRC radius internally uses its own transients rather than ours so I don’t expect a major change there even though our detection is improved. Do you see better behavior with the elastique stretching? Elastique is more advanced than Radius and is still maintained by zPlane.

@AlexHomeStudio We’ll need a bit more information to solve this. Please list the specific steps you are doing and if you can reproduce this in any project. Also please attach the dump file for the crash to help us investigate the cause. Not seeing any problems here bouncing to clips.