Steinberg: No more VST2 Development

[aciddose]

Exactly yes, that was why the

[JonHodgson]

The "looseFocus" in VSTGUI is definitely something that falls in the "backward compatibility" range. Although, if I was one of them, I'd have changed it in VSTGUI4, where they broke compatibility to older versions anyway.

But "loose" is pretty much correct in this context.. "release" would perhaps be better though.

You're not losing the focus, any more than you "find" it, the opposite method is "takeFocus", not "findFocus".

But, I will say that mispelling of "lose" as "loose" is RIFE on the internet.

[Caco]

I think it is really disappointing that it has been removed all together as the barrier to VST development has just been raised significantly.

It was VST2.3 that inspired me to learn C++ as it was pretty easy to get a VST2 up and running. From there I could then tweak and learn the C++ language. VST3 certainly wouldn't do that, if I didn't already know C++ or was particularly experienced at programming I'd probably have struggled or maybe not even bothered.

There is going to be a lot less people who go out and create their own VST3 plugins than there was VST2 plugins and for me it is a shame that has happened. Sure, it's not going to affect the pros or Steiny's revenue but there has been a lot of fun, quirky plugins created over the years because it was relatively quick and easy to do and that is a loss to the VST-using community.

[cnt]

Admiral you are out of order in the way you are replying to mn. He has a valid point and if you don't agree just argue your case no need for the insults.

Personally I am going to be learning the VST3 SDK next and hope it has improved from first release. It certainly has promise and really the 2.4 API is very poor its just we know its workarounds now If 3 can produce 2.4 versions easily it will be great but I need to investigate it.

No he DOESN'T have a valid point. And if he can come into the DSP forum and tell us how to do our jobs, I can tell him what I think of it.

The insults are the ones HE'S making at the entire plug-in industry. I haven't insulted anybody.

Your "facts" are completely wrong. Saying VST 2.4 is "poor" doesn't make it so. Yes, you DO need to investigate it. Come back when your VST 3 is working and show us exactly how it's better than a VST 2.4.

And 3.x CAN'T produce VST 2.4 versions "easier" (or at all, from the continuing struggles I'm still seeing on the VST list after 7 f**king years of this nonsense!) You're drinking the Steinberg marketing Kool-Aid too and have NO IDEA what you're talking about. Speaking of insulting!

Come on dude, I'm an engineer myself and I sometimes hate new standards as well (just say the word Bonjour/Airplay........). The users loves what it brings - so we have to make it work - the users don't care about HOW we do it or if we say that we can do the same thing with other technologies that are better! The users just want it to work. Sometimes new standards aren't technically better according to everybody. That's how it is.

How come all but two developers I use software from has VST3 compatible versions of all their plugins already!? Since over a year?? It can't be THAT hard to re-write parts of the code for VST3.5+.

You haven't made a new product for many many years according to your website. You have like ONE product to think about and still other developers already did the VST3 versions.

VST 3.6 has things to offer that VST 2.4 doesn't. Heard of VST Expression and Note Expression for instance?

All hosts will continue to support VST 2.4 for a couple of years to come. So you have a lot of time to LEARN how to make your plugins in VST 3.6... or drop it and goto AAX or whatever.

It's bad business to go on how much you hate a new standard. The users don't care what is under the hood. They just want the "new" features.

[Angus_FX]

Aciddose, I'm having a lawyer look in to the copyright status of APIs with a view to releasing a clean header that'll build code compatible with VST2.4. I already have such a header, but it's a question of whether it's possible to place it legally in the public domain, and what other changes I might have to make for that to happen.

[Angus_FX]

cnt, my biggest beef with VST3 is the design philosophy.. it tries to be a template for the entire architecture of a plug-in, instead of a simple, dumb interconnect. All the XML stuff is way over the top for a plug-in API.. the simpler the better.

[whyterabbyt]

How come all but two developers I use software from has VST3 compatible versions of all their plugins already!?

You were lucky? Or you only buy from larger developers who have the resources to spend on reimplementing something they already have instead of actually making new products they can sell?

It can't be THAT hard to re-write parts of the code for VST3.5+.

Says who?

http://www.kvraudio.com/forum/viewtopic ... 11#5586111

Or try reading the VST developer list some time. Its pretty clear that its not plain sailing.

And of course, the unnecessary introduction of a new plugin standard that both hosts and plugins are required to use isnt going to introduce new bugs or issues anywhere, is it? <cough>

VST 3.6 has things to offer that VST 2.4 doesn't. Heard of VST Expression and Note Expression for instance?

Heard that there's only one host that actually uses them?

It's bad business to go on how much you hate a new standard. The users don't care what is under the hood. They just want the "new" features.

No, some users do care.

[HrastProgrammer]

Well, yes and no. One can use parameters for MIDI instead.

We add 2048 VST3 parameters to cover CCs 0-127 for all 16 channels

Not sure if we found a way to receive MIDI Program Changes.

Excuse my ignorance, because I really didn't look at VST3 at all ... Does it mean that in VST3 you don't have ProcessEvents where you can process incoming MIDI events?!?

[arakula]

That's correct. One part of it that I'm entirely content with is that all events are now (optionally) passed to the process() call. That's better than the separation between processEvents and process(Replacing) in VST2. All nice and tidy in one package, all nicely timestamped.

BUT they ripped standard MIDI processing apart; some parts of the carcass can be used in the form of special "events" (Note On / Note Off / Polyphonic Aftertouch / SysEx), while others aren't available at all (Program Change, all realtime messages), and Continuous Controllers / Channel Pressure / Pitch Bend are only available as parameter changes using a complex translation mechanism. A daft one at that; it doesn't allow for relative CCs, 14-bit CCs, (N)RPNs, and the like. Plus, events and parameter changes are passed to the PlugIn in separate lists, making it a really funny business to get a unified, sorted list of events for the current frame.

[JCJR]

Having paid little attention to this issue, a dummies question. Are vst 2.x ALL 32 bit, and vst 3.x ALL 64 bit? IOW are all 64bit built vst necessarily 3.x and all 2.x guaranteed to be 32 bit builds?

No, you can have vst2 x32 and/or x64. You can have vst3 x32 and/or x64.

Thanks. Are there a lot of x64 vst 2.x plugins? Is bridging software necessary to use x64 vst 2.x in a 32 bit host? It has been a few years since I read the vst 2.x docs, and I've never read the vst 3 docs. Do more recent versions of vst 2.x docs explain how a host would detect the diff between x32 and x64 2.x plugs?

[Angus_FX]

9 second summary of VST3...

http://www.youtube.com/watch?v=oAKG-kbKeIo

[SJ_Digriz]

9 second summary of VST3...

[whyterabbyt]

Thanks. Are there a lot of x64 vst 2.x plugins?

well, except for SynthEdit, I'd guess probably about 90% of anything VST2 still being actively supported is available in an x64 version.

Is bridging software necessary to use x64 vst 2.x in a 32 bit host?

yes, but you'll only be able to do so on a 64-bit OS

Do more recent versions of vst 2.x docs explain how a host would detect the diff between x32 and x64 2.x plugs?

Same way as any application would determine if it can load a dynamically-loaded library, I'd assume.

http://stackoverflow.com/questions/4952 ... t-or-64bit

[arakula]

Is bridging software necessary to use x64 vst 2.x in a 32 bit host? It has been a few years since I read the vst 2.x docs, and I've never read the vst 3 docs. Do more recent versions of vst 2.x docs explain how a host would detect the diff between x32 and x64 2.x plugs?

Depends on what you want to do on which system.

• Mac OSX :
  • PlugIns are normally distributed as "fat binaries" containing both 32-bit and 64-bit code. From a user's perspective, it's a quite transparent business - a 64bit host loads the 64bit code, a 32bit host loads the 32bit code.
  • 64bit PlugIns can't be loaded on a 32bit kernel (older machines, like mac mini 1,1).
  NB: I'm not the biggest expert on the Mac side, so correct me if I'm wrong.
• Windows :
  • you can't load 64bit PlugIns on a 32bit Windows, bridging or not. Only a 64bit Windows can be used to load 64bit PlugIns
  • if you're mixing 32bit hosts with 64bit PlugIns or the other way round, bridging is ALWAYS necessary, since a program can load only DLLs with the same "bitness".

BTW, there's no difference between VST2 and VST3 in this respect.

[JCJR]

Thanks whyterabbyt and arakula for the explanations and pointers.