scook

All of the plug-ins installed with 64bit SONAR work in CbB. At least the ones bundled with the 64bit SONAR X1 and newer. My guess is all of the plug-ins going back to the first 64bit SONAR release will work as well as they did in SONAR. Plug-ins bundled with 32bit SONAR but not installed with 64bit SONAR are a different matter. AFAIK, these are all 32 DX plug-ins that were not ported to 64bit. These are 32bit host specific and will not load in any 64bit host. There is no bridge software for DX format plug-ins. There used to be a VST wrapper floating around the internet but bridging VST wrapped plug-ins is not a good idea and VST wrapped plug-ins are not recognized as replacements for the original DX plug-ins in old projects.

I must admit that all this about overlays and whatnot is baffling. Agreed and the recommendation in @Colin Nicholls's post is essentially the same info the OP received when 2021.04 was released Yes, copy and paste is the easiest for me too. I have only used export once to send specific elements to another user. Image changes have been more frequent with CbB than SONAR. I suspect this and the impact on functionality prompted the theme check at startup added in 2021.04.

I usually leave the hardware discussion for others but will say this. An M.2 SSD is overkill for a system drive. It is an excellent choice for the libraries used by streaming sampler plug-ins. A 500GB SATA SSD is plenty for a system drive. A secondary drive for DAW projects is a good idea. Because of SSDs, less for performance but for keeping backups manageable. If you are not using a lot of sample-based plug-ins, 64GB of RAM may be excessive. DAW projects consisting mostly of recorded audio require little RAM. Samplers that don't stream from disk are the chief users of RAM. Whether one needs 16, 32GB or more RAM depends on their use of plug-ins and sample libraries. When it comes to installing legacy SONAR see

Forget about the web store. Open the plug-in, click on the store tab, locate the module and "buy" it there.

Given users have no control over what must be changed to stay current, the "overlay" system would need to be maintained just like the themes or the current import/export system. I think we will see a new CbB UI before there are changes to the Theme Editor.

The mechanics of customization is easy. Creating new artwork can be a challenge. Doing a thorough is very tedious

Blindly importing user theme on top of another user theme seems like a bad idea. It is easy enough to see what elements are changed in a theme using the Theme Editor View tab and the modified filter. And it is easy enough to copy between themes by opening multiple instances of the theme editor.

That document is linked to the theme editor help button.

Yes, all the original values in the theme editor always refer to the resource files (aka Mercury).

Failed to mention, the TH3 plug-in bundled with CbB includes an autowah and crybaby style FX or automate one of the EQ for a similar effect.

The Sonitus WahWah does not add any noise, The "swooshing background noise" is the filter being applied to noise in the signal the plug-in is receiving. This will happen with any filter plug-in when it is moving through frequencies containing a significant amount of noise. Don't like the noise, send the plug-in a cleaner signal, do not use the Auto Wah mode or try adjusting the frequencies swept by the plug-in.

There are a few issues with this setup though 1) Do not have nested paths in the scan path. The image shows both "C:\program files (x86)\vstplugins" and "C:\program files (x86)\vstplugins\eventide" The second path is unnecessary as any path under "C:\program files (x86)\vstplugins" will be scanned. Having redundant paths causes unnecessary work for the scanner and has caused scan errors in the past. 2) Do not leave the "Rescan Failed Plug-ins" and "Rescan All Plug-ins" enabled. By default, these options are off and are meant to stay off most of the time. They cause extra work for the scanner which can lead to scan failures. These are intended to be used to resolve specific one-off scanning problems. Once a scan is run with these options, they should be turned off. Running both options at the same time is functionally the same as a VST Reset. 3) Enable Scan in sandbox. By default, this is enabled. This was added to improve the safety and reliability of the scanner.

This is not significantly different from the current process The base theme is Mercury User themes are the overlay files. They are all changes relative to Mercury. Tungsten is a special case. It is a factory theme. The only differences between Tungsten and a user theme are the location of the theme the file extension In all other respects, Tungsten works the same as a user theme. Currently one can import and export Theme Editor elements. These elements may be image files or color settings. If there were an additional overlay layer, who is going to maintain that? What is it going to contain, another collection of color settings and images? Isn't going to require at least the same amount of work to create and maintain as the original user theme? By that I mean some one has to create the original theme. Then there are items added, removed and modified by some additional document or process. The bottom line is, if one wants to use a custom theme then they need to Use one that is actively maintained by some one else or Maintain it themselves. When a theme is no longer actively maintained by a 3rd party the user is left with a decision Learn how to maintain the theme Change to a theme that is actively maintained Maintaining a theme is not that hard but does require learning a little bit about image editors and the theme editor. It can be time consuming if the images are significantly different from the images currently available. If one does not have the time or is unwilling to make the investment in learning, the best course of action is use themes provided by the manufacturer, be prepared to change themes occasionally or do update the DAW.

There is a better chance this type of issue will be seen by the devs when posted in the appropriate place. When a production release is announced a thread is created for it. In this case, the thread for 2021.04 is When an early access release is announced a thread is created for it. In this case the thread for 2021.06 Early Access is

VST path issues are usually pretty easy to resolve. The OP's issue with Studio Instruments did not seem to be a path problem when it was brought up before

Cakewalk DX plug-ins are registered during install and have nothing to do with VST paths or the VST scanner.

I have the 64bit version of GrooveSynth DXi that came with SONAR Platinum installed. It loads OK in CbB but I have not used the plug-in in a very long time. The "C:\Program Files\Cakewalk\Shared DXi\P5antom\P5antom.dll" shows the product version is 1.1. 0.3 last modified 30 Dec 2011 8:54 PM on its ptoperties details tab. I am running CbB 2021.06 build 32, Win10 Pro 20H2 build 19042.1052. Maybe the one bundled with 64bit SONAR 5 needs to run as administrator, IDK, I recall a previous conversation about Studio Instruments left with a recommendation to contact support. What did they say?

To insert a new event

New release of CbB, Windows or ? There is an early access release of CbB 201.06 and a dedicated thread for any issues with it. The current production release of CbB is 2021.04 also has a dedicated thread for issues with it. BSOD are usually hardware/driver related.

When using an external encoder, to export different mp3 bitrates requires setting up a definition for each bitrate.

Now that plug-in only users may want to access the "Instrument and Note Names" dialog how about removing the need to have a MIDI output device enabled to click on the Define button in Preferences > MIDI > Instruments?

No need to mess with channel assignments preferences. That screen is designed for hardware. The only part plug-in users need is the Define button to access the Instrument and Note Names dialog in order to import/edit plug-in note names. Once the note names are set up in preferences, in the PRV when the instrument/MIDI track is displayed: right-click on the keyboard to the left of the Notes pane to bring up the Note Names dialog click the "Use these note names instead" radio button and select the appropriate entry from the drop down The AD2.ins above shows in the drop down as "AD2 Standard" Alternate note names is a per-track setting. Note: if the Define button is disabled on Preferences > MIDI > Instruments it is probably because no MIDI output device is enabled in Preferences > MIDI > Devices. Currently, to add/edit instrument definitions an output device must be enabled. For those who run CbB without a MIDI output device, temporarily add one (make sure to click apply after selecting the device) to enable the Define button.

The data needed to display note names in the Label pane next to the Note pane in the PRV. I used the Addictive Drums keymap pdf and CC data from the Addictive Drums 2 manual AD2,ins in on my google page or use this direct link to download. If you need info about adding this to CbB or creating your own custom note names entries, feel free to ask in this thread.

FYI the new persistent Note Names feature uses entries from the master.ins file. To take advantage of this feature I created an instrument definition file for Addictive Drum 2. Even if you do not have Addictive Drums, it may be useful to see what the format looks like in order to create your own custom note names. Instrument definitions are text files.

Export defaults to the Render Bit Depth in preferences but I am pretty sure this can be overridden using an export preset and IIRC, that setting is persistent. Starting with SONAR 4 it has been possible to chain creating a wav and another format as long as there was a command line encoder available for the other format. Many used this feature instead of purchasing the mp3 license from Cakewalk. I believe Cakewalk even supplied external encoder definitions for lame and a few other encoders at one time. The command line options are limited though.