Steinberg: No more VST2 Development

DSP, Plugin and Host development discussion.
Post Reply New Topic
RELATED
PRODUCTS

Post

looking forward to VST4, its gonna be awesome!

Post

briandc wrote:LV2 and LADSPA work just fine on my machines.
The licenses of LADSPA (which doesn't support GUIs) and LV2 don't permit non-open source licenses (or you need to link dynamically to the LADSPA/LV2 parts which is plain stupid for plugins). Most plugin developers don't release their sources, so they don't have any interest in releasing LV2 or LADSPA versions and thus the "there is no usable plugin format" still stands.
briandc wrote:The Wine wrapper is simply to port all the stuff made with Windows
I don't know of any other DAWs than Reaper that work with Wine so it doesn't port "all the stuff made with Windows". Also you can't use Windows plugins in Linux DAWs with Wine.

Using Linux for audio is fine if one want's to, but it's no option for 98% of the users.

Post

FWIW, my VSTHost works on WINE. Not that it makes a "real" DAW, and of course the problem remains that any used Windows PlugIn also has to work within the constraints of this setup - doomed to fail for all that require hardware protection support and/or fancy graphics support and/or more arcane Windows functions.

WINE only gives you a rather basic Windows functionality, with a limited set of DLLs. That's not meant to belittle it - it's absolutely up to the task when it comes, for example, to standard office applications - but it's definitely not ideal as a base for cross-platform audio PlugIn development.
"Until you spread your wings, you'll have no idea how far you can walk." Image

Post

Receptor is a Linux/WINE based "solution", isn't it?

Are they even still selling those things? Haven't seen an ad for one, even on here, in quite some time.

And it would seem after a quick google that Receptor doesn't support VST 3 either! (Correct me if I'm wrong, please.)

Post

I dont think Muse own KvR anymore...

Post

AdmiralQuality wrote:Receptor is a Linux/WINE based "solution", isn't it?

Are they even still selling those things? Haven't seen an ad for one, even on here, in quite some time.
Yes in both cases - see http://www.museresearch.com for details.
But that...
a) is a heavily customized WINE setup (and they don't disclose the sources, or at least not in a form that I can see - he, Brian, how does that look, hmmm?)
b) has its problems in the areas I've mentioned, too, but they seem to have the marketing muscle that allows them to work with PlugIn developers to create "special" versions of problematic PlugIns that work on the Receptor.
AdmiralQuality wrote:And it would seem after a quick google that Receptor doesn't support VST 3 either! (Correct me if I'm wrong, please.)
Given your often stated attitude towards VST3, this is presumably a joke, right?
Anyway, seems to be so. Go seach for "vst3" on www.plugorama.com :-) ... well, it's not THAT easy to support it, and if their users don't cry for it (and why should they? Cubase doesn't run on the Receptor), there's no pressing need to support it anyway.
"Until you spread your wings, you'll have no idea how far you can walk." Image

Post

arakula wrote:
AdmiralQuality wrote:Receptor is a Linux/WINE based "solution", isn't it?

Are they even still selling those things? Haven't seen an ad for one, even on here, in quite some time.
Yes in both cases - see http://www.museresearch.com for details.
But that...
a) is a heavily customized WINE setup (and they don't disclose the sources, or at least not in a form that I can see - he, Brian, how does that look, hmmm?)
b) has its problems in the areas I've mentioned, too, but they seem to have the marketing muscle that allows them to work with PlugIn developers to create "special" versions of problematic PlugIns that work on the Receptor.
I'm one of them. (Though it was a helpful Receptor dealer, not Muse themselves who helped me by remotely testing for me. A VERY difficult way to debug a plug-in! But we've never had a single sale to a Receptor user so those weeks of trial and error debugging were for nothing.)

Is WINE not open source? If so, how can they have a modified version and not release the code? I think it's just their host software that is proprietary. Unless I'm misunderstanding something, they would be obligated to share any code changes made to existing open source code.
AdmiralQuality wrote:And it would seem after a quick google that Receptor doesn't support VST 3 either! (Correct me if I'm wrong, please.)
Given your often stated attitude towards VST3, this is presumably a joke, right?
Anyway, seems to be so. Go seach for "vst3" on www.plugorama.com :-) ... well, it's not THAT easy to support it, and if their users don't cry for it (and why should they? Cubase doesn't run on the Receptor), there's no pressing need to support it anyway.
I think you're misinterpreting my statement. I'm pointing out that here's yet another company with a platform that doesn't support VST 3.x, just like everybody shouldn't. One more application where VST 3 is completely useless.

Post

edit: removed

Post

AdmiralQuality wrote:One more application where VST 3 is completely useless.
From a user's point of view (and that's all most users are interested in) VST3 has two advantages over VST2:
- usable sidechain in Cubase/Nuendo
- readable parameter automaten, e.g. 20 Hz to 20 kHz instead of 0 to 1 if automation is drawn instead of recorded (Cockos has an VST2 extension for this but I don't know how commonly implemented it is in plugins and other hosts)

So there's not much reason to support VST3 for a host as all VST3 plugins (don't know for Steinberg, so at least all non-Steinberg) are also available as VST2. There doesn't seem to be that many complaints regarding the automation range. Also for almost all instruments there is not much need for VST3.

But if you have a plugin that has a sidechain input and you don't want unhappy Cubase customers you are in the unfortunate postition of needing a VST3 plugin.

Post

lkjb wrote:
AdmiralQuality wrote:One more application where VST 3 is completely useless.
From a user's point of view (and that's all most users are interested in) VST3 has two advantages over VST2:
- usable sidechain in Cubase/Nuendo
If you think sidechaining wasn't "useable" in VST 2.4 you're either incompetent or were using a sub-standard host.
- readable parameter automaten, e.g. 20 Hz to 20 kHz instead of 0 to 1 if automation is drawn instead of recorded (Cockos has an VST2 extension for this but I don't know how commonly implemented it is in plugins and other hosts)
Now you're really demonstrating that don't know what you're talking about. VST 2.4 has ALWAYS asked the plug-in for the text strings to describe the parameters values. If you saw it any other way, again, that was your host's fault. Nothing at all to do with the VST 2.3 spec.

EDIT: Oh, I see now you say "drawn instead of recorded". The host could still change the parameters on the plug-in to get the correct strings, if it wanted, then return them to the current state after your envelope editing was done. Nothing about the spec would need to be changed for this.

Post

AdmiralQuality wrote:If you think sidechaining wasn't "useable" in VST 2.4 you're either incompetent or were using a sub-standard host.
I'm aware that all other hosts than Cubase (that I know) have sidechaining support. But in Cubase not using VST3 is a PITA (and I'm not sure if even possible in Cubase Artist and the like) and Cubase users will complain if only VST2 is available for plugins with a sidechain input.
AdmiralQuality wrote:The host could still change the parameters on the plug-in to get the correct strings, if it wanted, then return them to the current state after your envelope editing was done.
To quote you, "Now you're really demonstrating that [sic] don't know what you're talking about.".
Changing a parameter changes the plugin's state and this way the host could completely mess up the plugin. And still you couldn't set an automation point to "653 Hz".

As I said, there are some VST2 extensions available that are used in Reaper but I don't know how much they are supported on the plugin and/or host side.

Post

lkjb wrote:
AdmiralQuality wrote:If you think sidechaining wasn't "useable" in VST 2.4 you're either incompetent or were using a sub-standard host.
I'm aware that all other hosts than Cubase (that I know) have sidechaining support. But in Cubase not using VST3 is a PITA (and I'm not sure if even possible in Cubase Artist and the like) and Cubase users will complain if only VST2 is available for plugins with a sidechain input.
Cubase USED to allow this (you just route your side channel to 2 channels of a 4 channel track). Maybe they've taken that out in recent versions (I'm not sure, I'm not going to pay money to LOSE capability) in another attempt to strong-arm you into adopting VST3.
AdmiralQuality wrote:The host could still change the parameters on the plug-in to get the correct strings, if it wanted, then return them to the current state after your envelope editing was done.
To quote you, "Now you're really demonstrating that [sic] don't know what you're talking about.".
Changing a parameter changes the plugin's state and this way the host could completely mess up the plugin. And still you couldn't set an automation point to "653 Hz".

As I said, there are some VST2 extensions available that are used in Reaper but I don't know how much they are supported on the plugin and/or host side.
Nope, trust me, it's you who's demonstrating your ignorance. There is no "mess up" a plug-in, there are only parameters which the host is entirely free to change as it sees fit and when it sees fit. As long as it returns the parameters to what they were before (and possibly calls resume()) all should be fine with the plug-in.

And no Reaper extensions required.

Post

Maybe if you're drawing envelopes while the transport is running and your plug-in is processing, that technique might not work. (Well, actually, as long as it did it between process calls and put it back to what it was before the next process call, it should be fine in most cases.) But that's a fairly rare case, isn't it?

Post

And it would of course have been trivial to add a function for this in a VST 2.5. getParameterDisplayFor(index, value), say.

Post

And what about the case where a control changes its meaning according to the value of another control? (Or does VST 3.x prevent you from doing that? "Less is more!")

Post Reply

Return to “DSP and Plugin Development”