Well this is a kick in the nuts: VST2 plug-ins

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

Post

EvilDragon wrote: Tue Apr 20, 2021 11:16 am I would hope not! NKS itself should stay as is, and I suppose it'd only be a matter of adding the same vendor-specific opcodes that were in VST2 to VST3 too. I'll ask around :)
As long as Maschine etc. doesn't suddenly expect NKS to tie to the VST3 protocol, I'm fine. I just don't really want to spend more months on platform issues this year.

Maybe NI could adopt LV2 instead or something open source to prevent any of this from happening again.

Or, they simply could contribute an open source plug-in SDK that is compatible to VST2... ;) ;)

Post

Wish I could actually call shots at NI. :D

Post

I didn't understand is Steinberg a good or not now, but let me promote opensourse frameworks again:

A small DPF framework https://github.com/DISTRHO/DPF which is quite nice (yes, vestige for VST2)

https://github.com/AuburnSounds/Dplug/ you need to learn D, the author: memberlist.php?mode=viewprofile&u=366815

Post

Vestige headers are legally in the gray, AFAICT.

Post

Urs wrote: Tue Apr 20, 2021 10:29 am (e.g. VST3 is designed on the premises that MIDI would somehow "go away", but obviously MIDI hasn't died, to the contrary, MPE and MIDI 2 have come about)
This is so wrong Urs. The VST3 design frees you as a plug-in developer from the hardware protocol.
If at some day a plug-in format supports MIDI 2 you will see how much headache it will make you to support it. Just lookup how many different possibilities MIDI 2 provides you to tune a voice. This will give you a funny time to code this.

Post

There's some truth there at least, VST3 already basically has MIDI 2.0 support, and pretty much the onus is on host developers to convert MIDI 2.0 messages to appropriate VST3 messages. Plugin devs don't need to do anything (well, support the VST3 messages needed to support those particular MIDI 2.0 features, i.e. note expression support would be a must then).
Last edited by EvilDragon on Tue Apr 20, 2021 3:27 pm, edited 1 time in total.

Post

A transition period again!!. I don't understand. We signed a VST2 agreement during a (last chance) grace period and we were told that we can continue publishing VST2 if we did.
www.solostuff.net
Advice is heavy. So don’t send it like a mountain.

Post

arne wrote: Tue Apr 20, 2021 2:26 pm
Urs wrote: Tue Apr 20, 2021 10:29 am (e.g. VST3 is designed on the premises that MIDI would somehow "go away", but obviously MIDI hasn't died, to the contrary, MPE and MIDI 2 have come about)
This is so wrong Urs. The VST3 design frees you as a plug-in developer from the hardware protocol.
If at some day a plug-in format supports MIDI 2 you will see how much headache it will make you to support it. Just lookup how many different possibilities MIDI 2 provides you to tune a voice. This will give you a funny time to code this.
Sure, I don't really want to mess with this. But there are other issues.

One example: The headaches of MIDI Learn for instance were real. Your developer support has advised not to register a pool of 2048 MIDI CCs, but to use the built-in CC-to-parameter mapping instead. This made MIDI learn impossible even though Steinberg's own VST3 plug-ins have this. We then co-financed a working proposal to add MIDI learn to VST3, which you then rejected. Which then made us pool 2048 MIDI CCs in order to make it work. In other words: We tried, but our problems were ignored.

Generally though, if the plug-in format handles things by itself, that's all nice and probably meant to be helpful. But we support multiple plug-in formats. So instead of doing it 1x for MIDI for all formats, we have to support all such features for each individual format. That is more work for us even though a standard exists that could be used.

Post

S0lo wrote: Tue Apr 20, 2021 3:16 pm A transition period again!!. I don't understand. We signed a VST2 agreement during a (last chance) grace period and we were told that we can continue publishing VST2 if we did.
The trick is to not sign the latests VST3 license agreement.

It's a bit of a showdown between the two formats. If people want to continue VST2 development, VST3 adoption will slow down. If people jump on the VST3 bandwaggon, VST2 dies and pressure will arise to seek for alternatives, particularly for people who do not have the funds to work out how the SDK works.

(anyhow, I think that mounting pressure that way is a horrible move, especially for the hundreds if not thousands of small developers who are left dangling in thin air)

Post

Urs wrote: Tue Apr 20, 2021 3:27 pm
S0lo wrote: Tue Apr 20, 2021 3:16 pm A transition period again!!. I don't understand. We signed a VST2 agreement during a (last chance) grace period and we were told that we can continue publishing VST2 if we did.
The trick is to not sign the latests VST3 license agreement.

It's a bit of a showdown between the two formats. If people want to continue VST2 development, VST3 adoption will slow down. If people jump on the VST3 bandwaggon, VST2 dies and pressure will arise to seek for alternatives, particularly for people who do not have the funds to work out how the SDK works.
I see :). At least it seams from this that the plugin community still has some cards to play with.
Urs wrote: Tue Apr 20, 2021 3:27 pm (anyhow, I think that mounting pressure that way is a horrible move, especially for the hundreds if not thousands of small developers who are left dangling in thin air)
I totally agree.
www.solostuff.net
Advice is heavy. So don’t send it like a mountain.

Post

I don't really understand what Steinberg might gain here. Plugin developers who support VST2 will only be more reluctant to update their VST3 SDK. The only leverage that I see might be support for stuff like ARM Macs (if this is a problem with previous VST3 SDKs) or maybe if using frameworks like JUCE with an older VST3 SDK becomes too cumbersome.
But other than that it will rather hurt Steinberg hosts as new VST3 features will more likely not be implemented in plugins from VST2 developers.

Post

Having a glance at the VST3.6.10 license agreement, Steinberg can terminate the license if a new agreement is available.
VST3 License Agreement § 9 TERM AND TERMINATION wrote: c) Steinberg is entitled to terminate this agreement with a 6 months written notice if Steinberg offers
a new, e.g. amended, VST 3 Plug-In SDK Licensing Agreement. For the validity of the
termination it shall be sufficient that Steinberg sends the termination to the last known email
address of the Licensee.
This certainly is some kind of leverage.

The VST2 license agreement on the other hand doesn't have a similar passage or at least I didn't find anything in this regard. So maybe this will actually lead to less VST3 plugins if Steinberg terminates all old VST3 licenses and some developers decide to go back to VST2 only. :D

Post

lkjb wrote: Tue Apr 20, 2021 7:10 pm Having a glance at the VST3.6.10 license agreement, Steinberg can terminate the license if a new agreement is available.
VST3 License Agreement § 9 TERM AND TERMINATION wrote: c) Steinberg is entitled to terminate this agreement with a 6 months written notice if Steinberg offers
a new, e.g. amended, VST 3 Plug-In SDK Licensing Agreement. For the validity of the
termination it shall be sufficient that Steinberg sends the termination to the last known email
address of the Licensee.
This certainly is some kind of leverage.
So basically not only are they trying to legally bully you out of VST2 development, they also reserve the right to kill any of your future products on 6 months notice at will? Exactly WHO would sign this non-sense?

ps. Let me guess, the version 3.6.11 license agreement is going to demand 35% of your gross revenue for notarization purposes? Then 3.6.12 is going to require that all VST plugins authorize with Steinberg servers, right?

Post

Urs wrote: Tue Apr 20, 2021 10:29 am (e.g. VST3 is designed on the premises that MIDI would somehow "go away", but obviously MIDI hasn't died, to the contrary, MPE and MIDI 2 have come about)
Exactly. That is a major design-flaw.

Further design-flaw: It has been designed to run GUI and Audio on separate computers. This is completely senseless, doesn't work well for more complex plugins and wastes performance. It is an unnecessary limitation that complicates programming a lot and opens a can full of worms.

It also has a bad documentation, doesn't come with proper examples, has lots of bugs and is very messy. A massive number of sourcecodes are scattered all over the place.

As Urs said: Steinberg continuously ignores the problems.

My impression is that the responsible programmers are lazy and do not care about it at all - since Steinberg depends on them and they get their money
Last edited by Markus Krause on Wed Apr 21, 2021 9:04 am, edited 1 time in total.

Post

EvilDragon wrote: Tue Apr 20, 2021 10:42 am
chk071 wrote: Tue Apr 20, 2021 10:08 amUnless Steinberg really decides one day that they want to discontinue VST2 support in their DAW's, which I just can't see in the next few years, especially when big players like NI don't have VST3 versions of all their plugins.
That is definitely happening sooner than you think (no VST2 in Cubase). And NI is working hard on VST3 across the whole portfolio too. :)
I do not think that this will happen.
This would be a really stupid move since it would be a kick in the nuts for all their customers. Many people have invested lost of money into plugins which they wouldn't be able to use any longer. Old Cubase Projects would not longer load. Their customers would completely freak out. A part of them would use a bridge to load VST2 plugins. The rest of the customers will move to competing products or stick with an older Cubase version.

Post Reply

Return to “DSP and Plugin Development”