Noel Borthwick

There is more documentation on Freeze here.

Its been there since 2016 ? Select the tracks you want to freeze and then hold down CTRL and press the freeze icon.

Thanks for the extra information. When Cakewalk starts up it goes through a small validation process for all drivers on the system to build the list of available devices. As part of this process it sets the sample rate of each driver to the SAME sample rate that the driver reports to us. i.e. one of the profiling steps is: ASIOGetSampleRate ASIOSetSampleRate (same value) The only way I can see this process setting the sample rate of the driver to something else is: 1. You have another driver that references the same PreSonus ASIO device that is internally reporting 96K and setting the presonus indirectly to 96K. Do you have the Steinberg generic audio driver or something else like that installed? If so that could be the cause. 2. The presonus driver itself is reporting its sample rate as 96K to Cakewalk even though its not set to 96K. That would cause us to call ASIOSetSampleRate to 96K. I would consider this to be a bug in the presonus driver. I don't have this device to test so I can only speculate to the cause. We can contact presonus if you are unable to get any information from their support on this matter.

Things to check: Are you running Cakewalk in ASIO mode? Are you loading Cakewalk with a custom template? Also check what the "Default Settings for New Projects" shows in preferences | Audio | Driver Settings. That value is used to set up the driver when a new project is opened.

There is an API for the XBox controller so someone could write a control surface extension to allow it to control Cakewalk.

It is. very soon.

@Gswitz in your one track test with lots of plugins you will see much higher CPU loading and thereby faster speed if you turn on plug-in load balancing. That is our patented load balancing designed to handle cases with tracks containing many plugins by parallelizing the load on the track. However even that gives me about a 3X boost but not full CPU loading. There are several complex factors involved in balancing loads when bouncing including plugins throttling as well as disk load bottlenecks. I spent a lot of time experimenting with optimizations in this area some months ago and got some benefits. However I ran into plug-in compatibility issues so decided to shelve it. The engine is designed more for streaming real time audio rather than processing offline audio so there are some bottlenecks that are imposed because of that. There is definitely still room for improvement.

Like others mentioned, if all you need is starting and stopping the transport or recording a simple wireless keyboard is all you need. I use this all the time from about 15 feet away across the room to start and stop recording. In fact many keyboards have dedicated multimedia media controls on them and CbB will respond to them as well. Here is one example of a keyboard with media controls.

Fixed it. Its related to hidden buses. The hidden preview bus was confusing the waveform drawing.

Can you upload a small project file with the issue?

Have you been following the release notes? There is a Click behavior option to "Set time during playback" that allows you choose whether clicks in the clips view sets time or not. Clicking on clips always set the time - that's not new behavior. If you prefer to click exclusively in the time ruler then turn off that option. I'm not seeing your problem with bus preview. There were several fixes to bus preview in this release. Can you be more specific about the conditions under which it doesnt work? If I start playback I see bus preview drawing fine without clicking anywhere.

Yes we can repro the issue where ghosted data prevents it being moved. This is not new. One one hand it could be argued that invisible data shouldn't move. However it seems to negate the select envelopes with clips option so it can be unexpected. We'll consider changing it.

Oddly enough we were just looking at this and fixed a different bug that could lead to this same issue. (Preexisting issue not in 09) We'll also look at the ghosting issue thanks.

The driver has disconnected from the system or you have a faulty USB connection causing it. This is not caused by the DAW.

If you can reproduce the crash please send the dump file. Regarding the fx chain, try dragging it to the track fx bin and then splitting it into it's components. It may reveal which plugin is going silent.

Does it happen if you try and load the same project again? If so please send me a link to the project file that causes it. That warning was put in to help diagnose cases where plugin settings might not be restored properly.

@Helene Kolpakova thanks for posting your use cases. This change was made to align the behavior with the way most modern DAW's work as well as to cater better to the "always playing" workflow. As you have already noticed most other DAW's do not stop in response to transport actions (other than stop itself). Prior to this change, there was no way to jump to the loop start dynamically without stopping playback, which IMO is a major omission. This can be important while mixing where you want to repeatedly audition a segment without stopping playback. Or even when playing or practicing a part before recording. Also the behavior was very inconsistent since some operations like "W" would stop playback but yet others like go to previous measure would not stop. Its inconsistencies like this that make the application not intuitive to new users, so sometimes we need to make hard decisions to change behaviors even though it may impact some users. In the future we plan on adding more accessible transport control operations as well so unifying the behavior was a first step in this direction. However I acknowledge the opposing workflow requirement to "seek with stop" in order to make an edit and then proceed post edit. So to accommodate this but in a more consistent way, we're considering adding a new preference. "Transport Seeking Stops Playback". When this is enabled any seek operation to change the transport position while playing (or hotkeys like W) will first stop playback before seeking to that position. I believe this should address your two cases "Case1: Often, I need to Stop at a particular moment that I want to edit." and "Case2: Equally often, I need to Stop to get back to the beginning, because the part I need to edit is around where I started" We will default to the new behavior but you will be able to turn on the stop behavior through the TV options menu. Sound OK?

Hi guys, I've fixed this now. It will be in a hotfix soon. There were some massive changes to time management this release and I missed the count in case when reporting time to plugins. It's not exactly related to starting playback. It's just the time reporting itself that was not accounting for the count in.

Thanks for the report. Indeed the time reporting with a metronome count in is not properly accounted for. I'll investigate it.

If you are going to be in New York Oct 15-18 please come see us @ AES! If you don't have a pass you can get a free pass from us here. Jesse Jost, Mike Balzarini, and myself along with Amon Wong from BandLab are at the show and we're showing CbB as well as BandLab. Here are some pix of the booth.

The only reason it happens is because you press W multiple times quickly Now that it doesn't stop playback it exposes the issue. You can repro in any version of Cakewalk by just seeking on the timeline faster than a second with your project.

@eli0s thanks for sending your files. I loaded up your project with the video and set up a loop and repeatedly pressed the W key to rewind but everything works as expected. There were no hangs at all. Do you have any synths in your original project or something else that could be causing a stall? If you could send the hang dump via wetransfer or google drive etc it might show where specifically its hanging. I suspect its some video codec on your system leading to the issue. Does it hang if you seek time by clicking on the transport? All the W key is doing is setting the transport position so the hang should occur there as well if there is an issue. Edit: I was able to reproduce it finally. I had to have the video running fullscreen before it happened for some reason. It appears to be a deadlock with the MF video engine. I'll investigate further and let you know but I don't believe this issue is actually new to 09, just exposed because of the seeking while playing. EDIT2: Confirmed. I can repro the same hang by rapidly pressing CTRL PgUp or PgDn to seek through the video while its playing. In fact that hang even happens in SONAR. Will investigate a potential fix EDIT3: I've fixed it for our hotfix This was an ancient issue that could cause a hang with some video's if seeking on the timeline quickly.

The aux track related drop out was fixed for the main release. That would have a error code 12 and not 1. If you are seeing a project specific dropout with aux tracks that is reproducible try and pare it down and send me the project file to look at.

Thanks for the follow-up @guitfnky. I've already implemented a workaround for a hotfix, but it would be best if they fix the issue in the plugin since Im just ignoring the error.

@eli0s if you can upload a version of the project and the video file we can take a look.