Noel Borthwick

To clarify - this is not a bug per se. Its an unfortunate side effect of backwards compatibility of projects when dealing with 8.3 file names in the case of VST2 only.

Yes this is the unfortunate effect of 8.3 names with VST2. We have code to handle loading plugins irrespective of mismatches and we synthesize a better UUID that doesnt rely on short names for that. However for automation it still uses the old format for compatibility reasons. I'll think about it some more and see if there is a way to auto detect this and prevent envelopes getting orphaned in such scenarios but its not going to be easy.

This would be rare. We replace VST2 to VST3 based on rules provided by the VST3 spec. If a plugin vendor marks the plugin as being convertable then its unlkely they will change parameters because that would be silly.

It is not linked to the plugin dll and certainly not the install path. However there are some caveats with VST2 plugins. see below. Plugins are assigned a 128 bit UUID when scanned which is used for all operations including loading plugins as well as automation. For VST2 plugins the UUID is derived from the manufacturer assigned plugin ID as well as the plugin name (because ID's are not guaranteed to be unique). This is the legacy method used only for VST2. VST3 plugins already have unique UUID's . For automation envelopes for VST2 plugins for legacy reasons the UUID utilizes the 8.3 plugin name. If you are loading a project on two machines and the 8.3 file name differs for the plugin you can run into orphaned envelopes. The most common reason for this is because the new machine has disabled 8.3 file names on the hard drive. This is a bad idea. You can check if there are different 8.3 file names on the two machines for the same plugin dll by running this from a dos box and replacing <plugin.dll> with the actual dll name. If the dll has an 8.3 file name it will be listed. BOTH machines must have identical 8.3 names or automation will get orphaned potentially. dir /X <plugin.dll> Do this test and see if you find a difference with the plugins that are having orphaned envelopes. If there is no 8.3 name then you need to reenable support for it in the OS and re-install or copy the plugins again to let the OS generate them. This is not something we can change for VST2 without breaking compatibility with millions of projects. This is a good reason to not use VST2 plugins when possible.

That error is displayed when no presets were imported for a selected category or something failed while loading a specific preset. However if you see the presets imported OK looks like you are all set.

The latest Cakewalk update should prevent this error.

If I remember you can select all the plugins and then import and it should import to the relevant ones.

Was the bundle created in the latest. 11 release? Send me a link and I can check

Are you sure about this? If there are no soloed tracks or buses it has no bearing on previous versions. If you are seeing something attach a project that has the issue.

Undo history isn't saved so no way to know easily what went wrong. Its likely one of the operations with instrument track commands is my best guess. And don't worry you aren't doing anything "wrong" there is no right or wrong approach as a user. No two users will use the app the same way. You just ran into a problem that we haven't discovered yet.

Are you are referring to plugin PRESETS as opposed to plugin layouts? If you have saved actual presets for plugins from within Cakewalk, you can export them all using the export feature in plugin manager. Select all the plugins (you can multi select) and then click Export to export to a preset library file. Then on the new machine assuming you have the same plugins, import it .

There are major changes to the solo logic in 2021.11 so its not surprising that older versions may have issues with solo. The solution is not to use new projects with soloed tracks with older versions. There are bugs in the old versions that didn't handle solo properly. @Michael Reynolds which version of Cakewalk are you seeing this problem in?

Using more advanced features are certainly not simple so don't feel bad. And it does look like you uncovered a bug that we need to find so please let me know if you discover what caused the corruption.

Thanks, maybe there is something in that series of steps that exposes a bug in the code. I don't think this is related to Play itself but how you are going about setting up the tracks that led to this. If you get some time please try and recreate the problem in a fresh project and keep opening console view to check. If you find something please let us know.

Was the project created in the 2021.11 release? It would be useful if you can retrace what operation first lead to that issue. Did you save versions of that project and do you remember what operations were performed, undo/redo etc? There is definitely a bug that is leading to this inconsistent state. The bad tracks are instrument tracks that have lost their linkage to the synth track apparently. This confuses the UI and it doesn't load the strips properly in the console. Even right clicking the strips can cause it to crash.

It looks like your project is in a corrupted state where the UI is referencing tracks that have been deleted somehow. You can recover by deleting tracks 4 and 12 and deleting the associated synth. Then add it back later. I'm not sure what operation could have caused this. Did the project originate in an older version of SONAR perhaps?

Can you send us the project file? Something is likely failing when loading the UI resulting in the strip being partially initialized. Also which build of CbB are you running? Have you checked if this happens in the prior release (09) as well?

Interesting article on win11 performance with alder lake CPUs https://ph.news.yahoo.com/intel-12th-gen-alder-lake-cpu-windows-10-11-streamers-multitasking-045701919.html

Tip for using it live. Turn off dropout detection. This will let the app keep running even if it runs into a potential dropout condition. Much better than stopping playback! Set this to TRUE in preferences | configuration file.

This is how to set it up. After a bounce I get this As you can see it respected the track lengths. As mark said "Tracks through entire mix" does not respect the track length. We'll try and make that work the same way as well.

Yes its hard to find since it depended on the order in which the sends from the patch point were created. The bug has been there since the creation of aux tracks so its good to get this fixed.

@Maxim Vasilyev thanks for sending the project that exhibited the problem. I was able to track down the cause and fix it for the next release. The main issue was that the internal patchpoint bus associated with the aux track was somehow sending twice to the aux track. As a result the gain was boosted. I'm not sure what led to the sends being duplicated but I've made the code that handles this more robust and it wont allow that to happen now. Also at load time it automatically gets fixed so that it routes only once to the aux. Did these projects originate in an earlier release of SONAR by any chance?

We looked at TDR Nova and couldn’t quite figure out how that plugin works. You may want to contact the developer if there is an issue.

You could always do this. Select source category tracks. Make sure that you have nothing selected and export the full project. It should automatically size the export of the tracks based on their length. Fully described in the release notes as well. A note about selection and the Tracks export category: When the source category is Tracks, the project selection has a special meaning: Having a project selection means there is also a time selection. So if you have tracks selected in your project selection, then all the tracks chosen in your audio source will be exported at exactly the length of the selection. In other words, the length of each tracks’ audio file will be the same. If you have nothing selected in your project, then no specific export time range has been set, and the length of each tracks’ audio file will be the length of each individual track.

Glad you could figure it out. All the scanner is doing when not actually scanning a plugin is enumerating files on the system and checking timestamps and reading from the registry. That should be very fast unless something external blocks those accesses (as AV's typically do with any executable files and the registry). When scanning plugins the plugin is loaded and queried for various parameters. This can also be blocked and made very slow if the AV needs to check for viruses. This is the main reason we don't recommend running AV's on DAW's. That said I've never had issues with Windows defender slowing down the DAW. Your mileage may vary with other AV's since some are very aggressive.