Hide related VST2 plugins does not seem to work

[Jim Hurley]

I have 'Hide related VST2 plugins' set, and I have   MeldaProduction  VST2 and VST3 plugins installed.

Cakewalk 2019.03 shows both plugins in the plugin list. Is there something else needed to hide them?

 

[scook]

For VST3 migration options to work, the plug-in manufacturer needs to add the appropriate code to their plug-ins

Here are a couple of blog posts about the feature

http://www.noelborthwick.com/2013/09/28/developer-notes-sonar-x3-vst-enhancements/

http://www.noelborthwick.com/2014/01/22/developer-notes-sonar-x3-vst3-internals/

[Jim Hurley]

Thanks

[Starship Krupa]

Regarding Meldaproduction plug-ins, I asked Vojtech about this, and he said that for whatever reason, he had neglected to do this from the start with his plug-ins, which made it impossible to go back and fix it, so it's a feature that will apparently forever be missing in Melda-Land.

Since I have 38 of his plug-ins (I upgraded the Free Bundle), it kind of makes it a pain in the ***** when both versions pop up in the Cakewalk pick-lists. What I do is use the Plug-In Manager to manually disable the VST2 versions of all Meldaproduction and any other plug-ins that don't implement the feature.

[abacab]

20 hours ago, Starship Krupa said:

What I do is use the Plug-In Manager to manually disable the VST2 versions of all Meldaproduction and any other plug-ins that don't implement the feature.

Yep, that's a good solution!

[mettelus]

Melda's installer does allow the option to install VST3 only (so you can re-install them and check only the "VST3" option); but I am in a weird situation that Adobe Audtion 4 only uses 32-bit VST2s.

To that end, I just submitted a Feature Request to Melda to add a 32-bit/64-bit option to their installer. For me, this would allow installing 32-bit VST2s (CbB would not see them since they are outside the scan path), and 64-bit VST3s.

From CbB's perspective, similar could be achieved with a Feature Request to exclude select VST paths (i.e., subfolders), since Melda installs them by default to a subfolder at the VST2 path location(s).

Edited May 19, 2019 by mettelus

[scook]

Or let Melda install the VST2 plug-ins into paths not scanned by CbB.

From there it is easy to either leave them on disk or delete the unwanted files.

This is how I handle manufacturers who supply decent VST3 plug-ins but still want the VST2 plug-ins for hosts that either do not support VST3 or are 32bit.

[abacab]

It is surprising that there are still any current hosts that only support VST2. I have a couple of them.

[Starship Krupa]

15 hours ago, mettelus said:

I just submitted a Feature Request to Melda to add a 32-bit/64-bit option to their installer.

Oh, thank you. Just because I don't like installers that install 32-bit plug-ins on my 64-bit system so I then need to go find them and remove them so that some over-eager host program doesn't find them during a scan.

12 hours ago, abacab said:

It is surprising that there are still any current hosts that only support VST2. I have a couple of them.

How about hosts that claim to support both, but I only trust the VST2 support? Mixcraft likes to fall down and go boom if I load VST3's up.

So far I have yet to notice any of the supposed benefits the VST3 spec allows for or even see a plug-in or host developer (other than Steinberg) claim that they are taking advantage of it.

There are even those who say that the introduction of the VST3 spec was mostly a boondoggle on the part of Steinberg to get plug-in manufacturers to make up for Cubase and Nuendo's inability to make audio routing between plug-ins work. Also GUI resizing on the Windows versions, which was not a problem for anyone else.

[abacab]

2 hours ago, Starship Krupa said:

How about hosts that claim to support both, but I only trust the VST2 support? Mixcraft likes to fall down and go boom if I load VST3's up.

So far I have yet to notice any of the supposed benefits the VST3 spec allows for or even see a plug-in or host developer (other than Steinberg) claim that they are taking advantage of it.

There are even those who say that the introduction of the VST3 spec was mostly a boondoggle on the part of Steinberg to get plug-in manufacturers to make up for Cubase and Nuendo's inability to make audio routing between plug-ins work. Also GUI resizing on the Windows versions, which was not a problem for anyone else.

The real problem will be in the future when new plugins are developed in VST3 only, and if some hosts are not yet fully capable of supporting them.

Steinberg has issued a retirement statement for the VST2 development kit for 2018 onward...

Quote

From October 2018 onward we are closing down the second version of VST for good. While the  VST 2 SDK has been unavailable, and so have maintenance and technical support, the subset within the VST 3 SDK will also be omitted.

https://www.steinberg.net/en/newsandevents/news/newsdetail/article/vst-2-coming-to-an-end-4727.html

[mettelus]

On 5/14/2019 at 11:23 PM, Starship Krupa said:

Regarding Meldaproduction plug-ins, I asked Vojtech about this, and he said that for whatever reason, he had neglected to do this from the start with his plug-ins, which made it impossible to go back and fix it, so it's a feature that will apparently forever be missing in Melda-Land.

Vojtech responded quickly about the feature request with "we actually removed the 32/64 option intentionally, because people generally don't understand what it actually means and it led to all sorts of confusion and needed support," which I understand. So for the OP, the available options have already been mentioned above:

1. Reinstall VST3 only.
2. Install to a path that won't be seen by the VST scan.
3. Manually delete them after installation.

If you have a DAW which may require VST2s, the only real option would be #2, which Steve mentioned previously.

[Starship Krupa]

16 hours ago, abacab said:

The real problem will be in the future when new plugins are developed in VST3 only, and if some hosts are not yet fully capable of supporting them.

I hear ya. But the hosts will have to get their game on, then, eh?

It's just disappointing that with all of Steinberg's blather about how revolutionary the new spec is, I have never, and likely will never, notice a difference from having my plug-in be written to conform to one spec or the other, except at the moment Acoustica still haven't gotten Mixcraft straightened out with VST3 support, IMO.

It's just more trouble for developers and apparently saved the Cubase/Nuendo engineers the work of implementing a couple of features that other DAW's already had.

Marketing: "Can you lads put in audio routing between plug-ins like Sonar and all these other DAW's have? The young people like to do this thing called 'side chaining.'"

Engineering: "That would be really hard and nobody wants it. Young people only use pirated Ableton Live. Please leave us alone."

Marketing: "How about resizable GUI's? Our own VST spec calls for it and everyone else is doing it already."

Engineering: "You are very annoying and should leave now."

Marketing: "How can we get these features? Aha! We control the VST spec, we can force the plug-in developers to add it themselves!"

I can think of lots of cool things to have in a plug-in spec myself, like better protection from having the plug-in crash the host, maybe some way for different instances of the same plug-in to share resources so if you have 15 tracks, each with the same compressor, they can be more efficient, specifications for how to have a plug-in use the resources of other networked computers for processing, more uniform standards for latency reporting, standards for gain staging and level matching, and so forth.

[marcL]

The VST3 specification/invention reminds me of the history of the Germanic languages. 1000 years ago the English, the Teutons, the Dutchmen and the Scandinavians could easily talk with each other, the languages were almost the same. Today there is a lot of misunderstanding! ?

No, seriously the VST3 introduction created a lot of chaos and there is almost no benefit for the plugin users! With automatic installations that are different with each plugin provider the thing got even worse! I agree with Starship Krupa that I never ever noticed an advantage of the VST3 version of a plugin, on the contrary I had some VST3 plugins that didn't support proper property/preset saving. And that is also a risky thing with automatic VST2 to VST3 replacement in projects, does the property and preset handling really match for the plugins???

IMO, in the end we have to keep control of our (numerous) plugin installations, we have to know the folder organization and the scan paths for each DAW! It really does not help with install programs, that's why I decompose the exe installers with innounp.exe and install the plugins manually (and create a zip file for backup). Well, that works great for me, had no more issues and no more needless menu and app entries in Windows!!! ?

[Starship Krupa]

On 5/21/2019 at 1:20 AM, marled said:

I never ever noticed an advantage of the VST3 version of a plugin, on the contrary I had some VST3 plugins that didn't support proper property/preset saving. And that is also a risky thing with automatic VST2 to VST3 replacement in projects, does the property and preset handling really match for the plugins???

That's a thing, back in the VST2 days it seemed like the hosts mostly knew what to do with the .fxp and .fxb files that were installed with the plug-ins. I'd go to the host's preset menu and the factory presets would already be in there. With VST3's, that's not the case.