Tez

I learned something so, checked boogex out, you're right! The Cabinet Sim/Convolver is mono, guess that means it's a mono plug and on a stereo track it's only left sensitive, I wonder if that's typical for mono plugs?

Thanks again, I am aware of Launchpad, and appreciate your generosity in providing useful tools, it was the compatibility check that was a news update that I'm glad to know, and in general I've never rolled back, my interest is a comparison between current and previous for some feature at best, if at all ?

That's good to know, thank you, and I assume for automation you're referring to CW130Auto.dll, and of the 4 dlls that have gotten updated this release, that CW130auto is the pertinent dll as I think Splat also uses 3 of the updated dlls plus CW120Auto.dll. The others in shared utilities appear to be no later than 2019. So, going forward keeping a copy of the current CW130auto along with the "Cakewalk Core" might be an idea if desperate to run a prior version of CbB, unless the compatibility check some how prevents it?

This has to be so, because I assume by that, changes can occur to folders other than "Cakewalk Core" but FWIW I keep all versions of the "Core" backed up and I was able to run "Cakewalk.exe - 2021.01 bld 098 (Update 1)" from a renamed "Core" folder, and this version has the prior tempo features operable, maybe that's all Sam Stalos requires? This time running a prior version to the latest currently installed, I saw that there was no notice that a newer version was available, and following that on a startup of the current CbB there was a refreshing activation notice?

Ditto

I think you misunderstand, no offense, the shell loads 3 distinct 64 bit plugins which only get scanned once when the "shell plugin" was first installed and the vsts are registered, after that it's just the shell that gets scanned each time CbB starts up, the shell is just the front end for each plugin which the shell extracts, in my case, from a "WavesLib1.14_12.7_Win64.dll" file, there is no individual vst plugin dlls or vst3 files except the shell which for the vst3 is "WaveShell1-VST3 12.7_x64.vst3". Now I'm assuming that the shell maybe generic, capable of loading vsts from other libs if and when a new lib is installed and then the vsts that get loaded would be scanned when first registered. Again, no 32 bit plugins are involved and plugins loaded by the shell are scanned when first registered, and appear in the plug-in manager. It's possible the shell gets scanned every time to see if a new lib was installed, that's my conjecture. As for AAS the old installers splattered vsts all over the place, I know all the locations, but the only ones I'd delete were in the Cakewalk\VstPlugins folder the only location on my CbB's and Splat's vst path I didn't specify. The new installer is cleaned up putting the 3s in the default location and the 2s where you tell it, yahoo! I believe I saw this in one of your prior posts, that was what I implied by "a vst3 may not be suitable for all cases" and FWIW I also seem to remember that some vst2s were needed to take advantage of NKS support despite an available vst3.

Yes, it's a matter of choice keeping both vst2 & vst3 versions of a plugin, a vst3 may not be suitable for all cases depending on the plugin and it's intended use. In this case the shell loads all 3 plugin flavors so only the shell needs to be on the CbB's vst path, and it seems that the plugs the shell loads get scanned once on the first time loaded, but the shell gets scanned each CbB startup, this behavior, albeit normal for a shell, was something new too me hence the OP. Regardless the shell scan is lightning fast. The plug-in manager lists all plugins loaded by the shell with unique VST IDs, but all have the same filename which is the shell's and there are no individual .dlls or .vst3s for these VSTs which I think are embedded in a lib .dll file ?...

I think basically you're right which is good to know & now to be expected thank you very much. This plugin loads in 3 flavors and on an initial 1st time scan I'm sure I saw multiple scans resulting in 3 new plugins per vst2/3, but on subsequent startups it's seems only the shell for each vst gets a token scan which is really fast and not significantly adding to the startup time, if at all. So, right now an auto scan is just fine.

My scan option is set to Automatic Background Scan, and typically on a CbB startup when there’s no new plugins the scan popup will show either searching for plugins and/or the Scan Complete no new plugins found list and no plugin scan notice, but since adding a Waves Audio plugin this shows up as being scanned, albeit very swiftly, prior to no new plugins found list each time on a CbB startup. The WA plugin is an indirect Shell to the actual plugin, is this why the scan occurs or, in general, a quirk of Waves Audio, or something else?

I second the question, maybe you'll get a reply, I didn't see my post It's the same issue but as a reply in a different topic. good luck...

I guess you're right, I know they overhauled the GUI code for O9, which it seems is little more resource intensive and has a couple of minor glitches, and in their thrust to push out new products they just might skimp on regression testing! Their collaboration with Exponential Audio only has iLok plugins, no CBA, maybe it's gonna be the trend?

I believe this is an iZtope issue as this has occurred with other DAWS and doesn't apply to all iZotope plugins. The versions of Ozone for example, prior to Ozone 9 loaded just fine without iLok and other iZotope plugins also load swiftly without iLok, so it would seem Cakewalk's off the hook on this one ?

@msmcleod Not sure if this is a bug but, in the Tempo inspector if there's just the initial tempo node (M.B.T 1:01:000) and a later node is added for the same tempo value, just that single node appears, but if the tempo value is different 2 nodes appear 1 at the desired M.B.T. and 1 at the end of the project. This seems like odd behavior?

There's a known issue with Ozone 9 Advanced modules loading slowly if they were computer authorized, which all my iZotope plugins are. The solution is to install the iLok software even though iLok authorization is NOT being used, and this enables normal fast load times. I verified this issue with iZotope support a while ago. If you don't have iLok installed, this solution might help ...

The website BandLab Assistant Setup file version is 7.0.0.3045 not the latest. This next update for which you see the notice, I believe, will be the 5th update since the beginning of March and the last couple of times I've made the request to update the website link which has not been in sync with latest update. So, BandLab support is aware, but I guess they're just taking a while to fix it... Ho Hum...

When the number of tracks in the PRV is large enough to require scrolling, the scroll bar will gain focus but a “right mouse button press and drag” does nothing. The mouse wheel will scroll as does the UP & DOWN arrow buttons... Other scroll-able panes, so far, seem just fine. A minor irritation, but still...

The website file version is now 6.5.0.3026 the latest version, as of 03/22/21...

If I have a stereo track, either an audio or VSTi associated, and set the output to a new Aux track, the generated Aux: Aux 1 is also stereo, the Aux input is “Aux 1: Stereo”. If the Aux input is set to “Aux 1: Right (mono)”, the Aux track still appears to function in stereo, that is the stereo meter shows independent Left/Right activity. Is this to be expected and because the Aux track is basically a stereo audio track with a patch point input? Any insight would be appreciated...

Thank you John, One Drive worked a treat... ?

Indeed, and that was the only reference to PRV note colour I could find... It seems like another INI option might do the trick ?

https://bandlab.github.io/cakewalk/docs/Cakewalk Reference Guide.pdf pg 746 By default, note events in the Piano Roll are colorized based on velocity. Darker shades of the basic track color indicate higher velocities. Lighter shades of the basic track color indicate lower velocities.This behavior can be bypassed by adding the following INI variable to the WinCake section of Cakewalk.ini (see “Cakewalk.ini”on page 1346): PRVColorizeVelocity=0

On a dell audio dropouts can be caused by the “Dell SupportAssist Remediation” service, if you haven't already tried this, try disabling the service... That's what us dell users have had to do.

Hey @Glenn Stanton, the stereo bus with the output & sends defined for the hardware outs works fine except when soloed, as mentioned. There's a known issue with routing with patch point/aux tracks in Track Templates, that I previously ran into, which in my case involved hardware outs, and this was just more glitchy routing behavior I wanted to draw attention to. The actual bus I use Ive dubbed "Audio" the real master sends to this as the final output so, I don't need to solo it. The same thing occurs if it's an aux track instead of a bus, set up the same way with an out & 2 sends and is soloed. A workaround is simple, 3 buses - Master, M1 & M2 as follows: Master: output 1/2, 1 send M1 and 1 send M2, M1: output3/4, and M2: output 5/6 and simply group the solo buttons... Voilà But as I said I don't need it, and a surround bus definitely doesn't serve my purpose, not to mention the additional resources it could potentially consume.

Well for me it doesn't... I configured and checked out the surround bus as a master. A track or a bus targeting the master gets a surround panner, and that's flaky, the speaker mute and LFE solo don't work. The panner algorithms for distributing surround channel signals might be fine if you're designing a surround mix, but this is in contrast to the hardware out levels in the console view which can also be adjusted. I'm only interested in a stereo render, and a stereo master with output & sends defined for the hardware outs is a better fit sound-wise, for the stereo bounce I'm after. It's a whole lot less fiddling around and more precise just managing the basic output levels in the console. Yes it's possible to route everything to a pre-master bus or Aux track that targets a surround bus, eliminate the solo issue and only have a single panner to deal with, but the sound is not ideal...

Frankly I dunno... I'll take a look & see if it makes a difference, but FYI 1/2 = Front L & R, 3/4 = Center (L) & Sub woofer (R) and 5/6 = Rear L & R. So, console view allows specific control of each speaker...