Noel Borthwick

I found the way to recreate the problem. It was the Bass track being soloed that leads to the issue. It internally soloes the sidechain bus for the sonitus compressor. Older versions don't handle this properly and think that some other track is soloed when its not, which is why they play silent even after unsoloing the bass track. There was an additional corner case I wasn't handling which is why even saving after unsoloing didn't fix it. I've solved that issue for the next release.

@Terry Kelley your issue appears to be caused due to an internal sidechain bus being left in a soloed state. I cannot reproduce anything that could cause that problem the latest release. Is it possible that you started that project in an early access release that had that issue? In any case it can be fixed by simply turning on exclusive solo and toggling solo on the master bus and resaving your project. If you or @Michael Reynolds have any way of reproducing this in a project from a fresh project created in the 2020.11 release let me know ASAP.

If you have a copy of the project with the issue send us a zip or bundle file containing the audio as well.

32 GB is plenty for most purposes. If you have an issue its unlikely to be RAM. If you are using the latest Cakewalk it will list a code if there is a dropout. That can be used to diagnose the cause.

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.

@Jacques Boileau This is data specific so we will need a zip of the project with the issue.

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.

It has always worked that way. Older versions didn't ever warn about the mp3 for external encoders. External encoders are as the name implies "external" so Cakewalk doesn't do any special handling.

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

Unhandled exception at 0x000000002B6632C2 (PGFlanger64.dll) in New Song Acoustic 5A 110521_11062021_212027.dmp: 0xC0000005: Access violation reading location 0xFFFFFFFF8B64BE04. This is a plugin bug. Please report it to the vendor (PG Music)