Don't know if anyone noticed... VST3

[VitaminD]

I still have yet to compile a poopin' VST3 plugin.. I have a directory full of object files.. but no stinkin' dll..

at first I was getting errors that I discovered were due to it not finding headers needed for Mac plugins.. of course I don't have those files.. I'm in the win directory trying to compile the win example.. on a windows box

[Urs]

yet hardly any dev has ever implemented it

That's what I tried to say: Standard or not, it's still up to the plugin developer to implement it. That's the utter marketing crap. Only because they say it's "in there" doesn't mean that it isn't up to the dev.

[griels]

All other technical concerns aside, the SKI interface looks interesting - perhaps this could be used to resurrect a Rocket Network-alike system whereby you can share an arrangement and audio over the Internet.

I wonder if other host developers will be able to implement the SKI interface - this would allow something (cross-host support) that Rocket never supported.

[Aleksey Vaneev]

cpu saving features are what is of interest to me as an end user.

CPU saving is of no interest if your tracks were recorded live (there's no digital silence in such projects). And generally there's little need in it: if your computer can't handle project parts with most instruments on, CPU saving like that won't help you: you will be saving CPU time on parts that do not choke your CPU in any case.

While this 'CPU saving' creates problems mentioned here already (e.g. long delay lines that will be processed incorrectly).

Track freezing was 'invented' to resolve CPU problem gracefully. VST could theoretically support plugin-to-host call to update freezed track so that user does not have to press freeze/unfreeze. Track could also auto-freeze after a minute of no activity. It all can be done - not just through the 'fifth point' of our body.

[Fred e]

The most exciting new feature to me is the SKI, I can see a future of new "workflow plugins", that can well be the future of DAWs, provided this feature is going to be supported by others than steinberg.

Remember the VST Module Architecture SDK?

yeah, sadly... are there any hosts that support midi plugs except the Steinberg ones? It might be different this time though, since if a host dev is to claim to "fully support VST3", they probably are forced to implement support for the SKI. The midi plug support was more "optional" i guess since it is not part of the VST 2.4 spec. Further, making midi plugs is possible without using the MIDI SDK, so all devs of course choose using the VSTi way instead, plugs like chordspace etc loads as VSTis.

[whyterabbyt]

but they're not. and they won't be.

they would be more likely to be if the other host developers decided not to go with VST3.

and since steinberg seem to wield VST as a technical stick with which to beat their competition, that becomes more of a possibility too.

fact is, i'll bet now 80% of devs will move to vst3 come years end.

i dont. if you were a developer would you really spend all your R&D resources running to stay in the same place when you could be developing new stuff. there are already a lot of devs fed up with how much extra work Apple have created for them, this is possibly the last straw for some of them.

[Oliver.Lucas]

*** Beware - customer with no coding experience speaking ***

I've been followig this (without understanding a part of it, I have to admit)
. Anyways, here are my two cents.

Aleksey, the the CPU save IS a really cool feature imho. (It is in the Steinberg reverb)I come from the audio post side of things where sessions can be over an hours length. It is really nice to have an effect reverb as an insert on a track for the guy who is speaking a couple of lines from the bathroom next door. I used to render these things but being able to use and tweak them in the session is GREAT! Maybe it was possible in VST 2.4, but since it's on the table now people will start to actually use it I guess.

VST Plugs being able to create tracks is something I always wished my sampler (Kontakt) could do. As a user I absolutely hate the message about wrong output assignments.

Ollie

[VitaminD]

give me the DLL!!!#$!#@#@#####!@ Don't tell me you compiled successfully without giving me the file!!!!!!







I'm not quite there ^^^ yet but I'm getting there...

[Aleksey Vaneev]

It is really nice to have an effect reverb as an insert on a track for the guy who is speaking a couple of lines from the bathroom next door.

Understood, but in that case you could put the reverb on insert and freeze the track. Not to mention that hosts could freeze sends as well (I don't know if they do it already).

[DaveSonalksis]

I'm about to head to NAMM for the day.

I've a proposition to make though - a serious one.
I spent this morning reading the VST3 SDK source.

I'm going to ramble about some technical stuff, and then get to the point... so be warned.

The worst thing about VST3 is the MVC architecture. That's the biggest issue for a 2.4 codebase. Now, on the other hand, AU is MVC, and it's not so terrible. Why? Because the Controller is a generic object that draws its construction from the Model, and requires no code implementation. AU simply enforces some (hackable) "lane discipline" regarding the M-V link. That said, AU wrappers often use SetProperty to pass pointers around, to wrap a generic 2.4. Truth be told, we ought to be a little more lane disciplined - and there is a fairly easy way to facade that in.

So, to the point. I believe what we need is a shim. And VST2.5.

The general architecture that I naively see here (and people far smarter than me can correct this) is a VST3 plugin that hosts a VST2.4 plugin linked into it.

Now, obviously, because of the strict MVC architecture, this is, in general, impossible.
However, enter VST2.5 - a very slight refactorisation of 2.4 which creates an intermediate (facade) object to manage all communication to/from the editor, and we have factored in a middle-man which allows us to create the M-V separation with these facades either side of the split (and a downwards pipe to the underlying communication mechanism through the C for both). With some care, this oughtn't represent too many pages of code.
The resulting edit to your code would be that you'd change your "editor = new MyEditor(this);" line to "another_variable=new MyEditor(this);", and we'd shove the mediating facade into "editor" post construction. Most likely we'd need a factory function of the form "AEffGUIEditor *CreateEditor() { return new MyEditor(); }", which would be used by the V implementation, but I'm hopeful that that would really be it.

In cases where parameters moved around a lot, the C implementation would need to be really complex, but for a static plugin, you could interrogate and precache the construction data for a set of normalised parameters from a dummy instance of the 2.5.

Naturally, in cases (metering data) where the plug and the editor do need to converse, we'd need some change - but i'd like to think that a trivial overridable dispatcher (onto the facade) could sweep away a lot of that goop.

This then gives us working VST3 plugins, just by a few nips and tucks to the source - we'd need to be very careful that it was little more than a few edits to the source.
By precompiling and distributing the shim, we could get around ABI incompatibility problems. By making the shim open source (though not distributing any copyright code), we'd make it debuggable. By being very methodical and judicious about the VST2.5 spec, we'd effectively own our own format (which we could distribute as a patch file for the 2.4 codebase). We could then progressively add VST3 features into 2.5, at a slow and sensible (and peer-reviewed) pace, which would eventually let us forget all about the VST3 architecture! Best of all, we could build DLLs that were BOTH 2.4 and 3 simultaneously!

In summary, if we can build a neat shim, that requires minimal edits to existing source ("just" enough discipline to make it workable), we can win!

Please let me know what you think!

Dave.

[Ben [Camel Audio]]

Aleksey, the the CPU save IS a really cool feature imho.

Its perfectly possible to implement the CPU save feature in a plugin under existing standards. All you have to do is stop processing sound if the output is silent for N seconds. CamelSpace, CamelPhat and Cameleon have had this feature for at least 3 years (I forget when I implemented it exactly). There are questions over exactly how it should be implemented, and whether its a good idea - and I understand and respect the arguments against. The key point is that this is not an argument for VST3, since its perfectly possible to do this with VST2 - and even VST1!

Ben

[DaveSonalksis]

For non-coders, the perspective that us developers have might need some explanation.

The situation we have been put in is this:
You go into the studio one morning, and hear that there's a new version of your sequencer out. It costs $400 to upgrade, and none of the new features are really all that useful. Also, they've heavily redesigned it, so it'll take you a few days to relearn it all.
Now, it might be fun to do the upgrade, and show off to your friends, but it means that you can't really make any new music for a week, and you won't be able to buy any new plugins this month.

That's our situation, but multiplied by approximately 20.

Dave.

[Aleksey Vaneev]

In summary, if we can build a neat shim, that requires minimal edits to existing source ("just" enough discipline to make it workable), we can win!

Please let me know what you think!

Dave.

Looks like a good plan (actually, VST2.4 + VST3 in one package is what I want to have in a plug-in). But we ultimately need to move to a competing spec: it can also have UI and DSP parts hardly divided, but just without all those COM and GUID things: this can be implemented differently and more efficiently.

We should warn users that VST3 degrades overall performance in comparison to VST2.4: prove me I'm wrong.

[Tonmann]

Aleksey, I think it would be enough to point out and explain that VST3 does not bring any enhancements over VST2.4 that are really useful for VST plugins. I think common misconception on user-side is, that VST3 is needed for sidechaining, multiple MIDI, etc... Make clear, that this is rather a matter of implementation and not of the API.

cheers,
Chris

[Angus_FX]

ttoz:-

but they're not. and they won't be.

titanic, iceberg analogy. it's just the way it is.

fact is, i'll bet now 80% of devs will move to vst3 come years end.

Why..? Somebody correct me if I'm wrong, but it doesn't seem like VST3 is even finished yet (there's a whole bunch of stuff relating to MIDI/instrument support that seems to be missing) - considering it was announced more than a year ago, who knows when that will even be ready. And, as others have noted, it's a huge amount of work for not much enhancement (that's not to say _some_ of the enhancements are not important to _some_ people, but overall it is a small step in the right direction and a huge leap sideways, backwards and generally allovertheflippinggalaxy).

The only thing that would get people moving on to VST3 en masse would be a mandatory strong reason to support it, which basically means Steinberg has to come out with an absolutely amazing, compelling host that is VST3-only.

And to make that compelling for users, well, it'll have to do something outstanding to make up for breaking all their existing plugs.

Bear in mind that 64-bit VST has been around since 2.4 - how many companies support that yet? iZotope and East West maybe?

Dave -- a shim like that is feasible, but I don't see what it gains, at least as long as Steinberg maintains 2.4-compatibility in its hosts.
However, you can't build a VST2.5, as Steinberg owns the copyright and other IP on VST1.x and 2.x, and probably wouldn't appreciate having their intellectual property mucked about with!