Noel Borthwick

By default cakewalk is streaming audio to plugins even when the transport is not running (there is a setting in preferences) VST3 has a setting for telling the plugin that its a zero buffer but its up to plugins to implement it. You can find out which plugin is consuming cpu by bypassing them one by one in the fx rack.

Lol we used to do work with them at one point. You can tell them that the bloke said that since the crash is completely within the plugin there is nothing actionable from our side until one of their developers investigates the reason for it crashing by looking at the dump. I don't have magical powers to analyze their code unfortunately

You don't even need a foot switch. Use midi shift key bindings and assign a special key to start recording.

Good to know. Were the outputs not visible in the port list earlier on? Was the issue specific to VST3 or VST2? There were quite a lot of improvements in the 06 release for multi out instruments mainly for VST3.

That is strange. apparently the resource strings got confused and displayed the wrong text. Let me know if that recurs.

2021.06 Update 2 has been released.

If I were to make a calculated guess I would think Air might be a potential cause. We've had issues in the past with some Air plugins. If you get a hang again use task manager to capture the dump and that should show the stack where the hang occurred.

Thanks for taking the time to test it, appreciated. I expect that you ran into a hang that was unrelated to the EA2. This is a relief since there isn't any code in EA2 that I can imagine would cause a hang. In fact I fixed a hang with one VST instrument. Please keep an eye out and report back if you see anything untoward.

@Base 57 Can you please provide more information? There is nothing we can go on with just a report of a hang. As far as we know there are no changes that could cause a hang so this could be an independent issue. If you can't repro the hang please capture a dump and send it asap so we can investigate. What plugins are being used here?

Two people in this thread have pointed you to an updated installer. Have you tried that? BandLab assistant as a means of installing will soon be deprecated.

Well not in general. The PPQ concept itself is still valid though its an old term - its a measure of accuracy or sub divisions of a quarter note. In the old MIDI days, the highest subdivision was 960 PPQ before computers could keep up. Since then most DAW's can handle far greater accuracy so the subdivisions are much more. Rather than get rid of the PPQ setting, concept we retained it such that the setting controls the display and editing resolution of MIDI. For example in the UI where you enter values in MBT we convert from our internal high resolution time to MBT using the display PPQ. That's one example where you will see the impact of that setting. Its also used when exporting MIDI files - i.e. internal timestamps of notes will be quantized to the display PPQ. So the PPQ also affects outgoing data. Another way to explain this is that our internal representation of MIDI uses high resolution timestamps but when its used in the UI, or in editing operations its quantized to the display PPQ. Hope I haven't confused you further Its a bit confusing I agree and could probably be documented better.

Right

Not quite. Our internal "PPQ" if you could call it that is 2 to the power of 27 (134,217,728) This is our high res subdivision of a quarter note.

PPQ is a remnant of legacy MIDI from the 90's. In CbB PPQ is really "display PPQ" internally the resolution is much higher than MIDI. We have a 48 bit resolution for MIDI which is very accurate even for very slow tempos (eg 8 bpm). We updated this in the very first SONAR version back in 2000. No. The project PPQ should only be the display PPQ as noted above. It should not affect the resolution of data recorded. You should be able to verify this by a test.

Worse would be if you had a backup of the original CWP in the folder but the audio files were missing because they got deleted. Users frequently make copies of CWP files and edit one master file. For this reason all audio is retained until the user decides its not required (typically by using clean audio)

It should make no significant difference. Internally the MIDI engine runs at a higher resolution than 960 PPQ.

@Mark Bastable I looked at the dump files you sent. The crash is consistently in the plugin on its own thread, and there is no context of interest within the Cakewalk code. The crash appears to be the plugin accessing uninitialized data. Unhandled exception at 0x00007FFA9CC9FA87 (MIDIGuitar2-64bit.dll) in ROOM_07232021_203926.dmp: 0xC0000005: Access violation reading location 0xFFFFFFFFFFFFFFFF. To resolve this you will have to follow up with the plugin vendor and forward the crashes to them.

This is exactly how it has always worked there is no change. Once the project file is saved with a referenced take it doesnt matter if you delete the take later and resave, Cakewalk will not auto delete the take files because it can lead to data loss. For example a user may have manually copied the project, or autosave could have made a backup copy of the cwp file that is still referencing the deleted take. Its working how it was designed to work. Use the clean audio command to remove unreferenced data manually.

No once you save the project the files are committed. It would be data loss if Cakewalk removed the files because the saved project is referencing them

It is an option!

@Steevthere are no changes in the 06 release related to prochannel modules. Now that you know how to rollback can you install the latest early access build that was posted and check if there are still problems?

@Mark Bastable I need the actual minidump file not the text file. Can you please send the original file (it has a .dmp extension) BTW the reason your zip file was so big was because you had audio from multiple versions of the project file in the audio folder. If I do a save as and save to a new folder it will copy only the associated audio files. After I do that The size dropped to 81 MB which is quite normal. There is no audiosnap data here as I first thought. I don't see any obvious problems with your project. I suspect your crashes are all caused by that plugin. When you send the dump file I can get better information.

@Mark Bastable were you able to capture a crash dump yet?

It would be good to get to the bottom of what is causing the crashes. Send me a PM and I can help you with the exception severity if you havent been able to set that. Most crashes should be caught immediately in that mode. Please also try the latest early access release that was posted in case that helps with your problems. PS: received your project. We'll look at the project file and try and repro.

We posted a new early access installer that includes a fix for this issue. @bitflipper @Andres Medina please try this out and let me know if this addresses the issues with I/O's getting changed unexpectedly. AFIK the problem was only localized to track inputs when loading a synth that changes its outputs. Let me know if you still see problems with this fix. I'm confused by the statement that inputs and outputs were mismatched. Are you referring to the outputs to buses from tracks? Those should have been unchanged. Anyway let me know how it works in this release.