KVR Audio

Ben [Camel Audio] · Post by **Ben [Camel Audio]** » Fri Jan 18, 2008 10:04 pm

Please let me know what you think!

Sounds interesting - thanks very much for your thoughts!

In cases where parameters moved around a lot, the C implementation would need to be really complex, but for a static plugin..

I like the idea, and think I roughly understand how it could work for the case where you're dealing with parameters which are just float values.

Unfortunately, I'm in the situation of having a plugin which has a lot parameters and a lot of data. I apologise in advance if I'm completely misunderstanding things here - I'm not at all familiar with the model-view-controller pattern and haven't done any AU wrapping myself. Presumably under the new VST3 model-view-controller pattern, the model (our data) belongs with the DSP code. I can conceive of replacing my GUIs reference to the Preset data with a reference to a PresetController which converts the calls into messages which get passed to the model. However, if you want to load a WAV file, for example, you will need to send a message with the path to the file via the controller, which is then picked up by our DSP code. If this is right, then doesn't the DSP code have to then have responsiblity for loading the WAV file, since it owns the model? If that is the case, wouldn't this require lots of CPU in the processing thread, which is not what you want. Clearly, I must be misunderstanding something, since products such as Halion work find under this new system - but I'd be interested to understand how a WAV loading case should work under model-view-controller pattern.

Ben

ericj23 · Post by **ericj23** » Fri Jan 18, 2008 10:05 pm

Angus_FX wrote: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!

what I suspect your unaware of, but that I know ttoz defintely is is that vst 2.4 automation is kind of not working properly in cubase 4 - vst 3 automation works very well

all cubase users should want your plugs as vst 3

what percentage of your user base is that ??

Angus_FX · Post by **Angus_FX** » Fri Jan 18, 2008 10:46 pm

I was not aware of that - what is not working properly, automation-wise?

Presumably that means, automation isn't working properly for any but the built-in Steinberg plugins? Isn't that kind of a huge bug, given that there's no real good technical reason for it to be broken (besides, well, a bug)?

We've not had any concrete requests for VST3 yet. I don't know what percentage of our users use Cubase - somewhat less than a few years ago, but plenty enough that it needs to be taken seriously. I'd say on the same scale as Live and Sonar, quite a way behind Logic and PT.

ericj23 · Post by **ericj23** » Fri Jan 18, 2008 11:11 pm

automation is recorded properly - but editing it afterwards is limited to only 100 steps and no fractions there of

ttoz has been quite sensibly rallying about this on cubase.net for months - but something tells me this may never get fixed, probably the fact that this problem is not getting acknowledged by the mods tells me there trying to sweep this under the carpet

doesnt really affect my way of recording things - but I can imagine it really annoys many

keyman_sam · Post by **keyman_sam** » Fri Jan 18, 2008 11:29 pm

**non-coder warning**
One of those VST3 features is creating/copy/pasting tracks/clips/whatever...i.e. app level control.

This can be REALLY cool for plugins such as Energy-XT VST which employ sequencers. I dont know how though....

anyways, whatever VST standard it is, i hope it runs in Reaper and Energy-XT. The rest, I could care less.

VitaminD · Post by **VitaminD** » Fri Jan 18, 2008 11:32 pm

I am getting ready to give up on VST3 and go back to 2.4 as at least I could compile properly in that..

one thing I like about the new 3 SDK is the examples have a lot more comments in their code.. which makes it a bit more easier to understand whats occurring..

hmm.. I wish there was a newbie VST SDK troubleshooting zone.. I have a ton of questions to ask and would feel lousy for asking them all here (at kvr)

Angus_FX · Post by **Angus_FX** » Fri Jan 18, 2008 11:43 pm

VitaminD - there is the VST-Plugins developer mailing list that Steinberg runs. That's a good place to ask.

Urs · Post by **Urs** » Sat Jan 19, 2008 12:15 am

Angus_FX wrote:VitaminD - there is the VST-Plugins developer mailing list that Steinberg runs. That's a good place to ask.

I've subscribed to it yesterday before the "bang", but it seems the news hasn't arrived there yet... or maybe everybody is speechless...?

VitaminD · Post by **VitaminD** » Sat Jan 19, 2008 1:03 am

Angus_FX wrote:VitaminD - there is the VST-Plugins developer mailing list that Steinberg runs. That's a good place to ask.

Thanks.. I'll look into that..

in other news.. I *was* compiling and getting the plugin, the problem was its labeled as a *.vst3 so I didn't realize what it was

It was also on an entirely different drive than the one with my SDK on it..

in other other news.... I just realized that my host of choice (orion) doesn't recognize vst3 plugins nor when they're relabeled as DLLs... so all of this was pointless to me

jouni · Post by **jouni** » Sat Jan 19, 2008 1:29 am

VitaminD wrote: in other news.. I *was* compiling and getting the plugin, the problem was its labeled as a *.vst3 so I didn't realize what it was It was also on an entirely different drive than the one with my SDK on it..

in other other news.... I just realized that my host of choice (orion) doesn't recognize vst3 plugins nor when they're relabeled as DLLs... so all of this was pointless to me

The path is set in the project to the global VST3 path the SDK mentions. Silly place, and puzzles me why user path is omitted officially under Windows when it's "supported" in Mac. Especially now that Vista may have limitations on installings stuff to global paths.

But you're right no VST3 under Orion, quite obvious that the SDK was released just hours ago.

Cyrosis · Post by **Cyrosis** » Sat Jan 19, 2008 1:32 am

I would kill for Gigapulse to be updated to VST3, have all your tracks routed into it and routed to their own convolution space within the environment.

Wallander · Post by **Wallander** » Sat Jan 19, 2008 1:38 am

Is there a technical reason why they don't run the GUI on the slave as well and just export the window graphics and mouse/key events? Feels like this would be the reasonable way to do multi-computer processing, and any host should be able to do this today for all its plugins, regardless of plugin standard.

I can't imagine this being less effective than forcing the plugins to communicate with their GUIs via host messages.

gravehill · Post by **gravehill** » Sat Jan 19, 2008 1:46 am

ericj23 wrote: what I suspect your unaware of, but that I know ttoz defintely is is that vst 2.4 automation is kind of not working properly in cubase 4 - vst 3 automation works very well

all cubase users should want your plugs as vst 3

what percentage of your user base is that ??

Hmm, at least on the current version of Cubase there are issues with lots of VST3 plugs and their silence detection. You'll end up getting clicks and pops unless you deactivate it. So much for that idea...

mystran · Post by **mystran** » Sat Jan 19, 2008 2:40 am

Urs wrote: I've subscribed to it yesterday before the "bang", but it seems the news hasn't arrived there yet... or maybe everybody is speechless...?

I think ygrabit said something "it's going to be released January" a month or so ago, and back then there was talk about what SHOULD be in the SDK and whether VST is the right standard and all that standard crap all the way to the point where you could call it flood..

So I guess everyone's now looking into the SDK to see if it contains whatever it was that they hoped for... or everyone's afraid to be the first to say they don't like it.. or whatever..

Anyway, personally I'm not going to even download the thing before I have my current project brought to a point where it can be either released or abandoned, and unfortunately it's getting towards the point of release, so might take a while.

Tonmann · Post by **Tonmann** » Sat Jan 19, 2008 4:42 am

Angus_FX wrote:Presumably that means, automation isn't working properly for any but the built-in Steinberg plugins? Isn't that kind of a huge bug, given that there's no real good technical reason for it to be broken (besides, well, a bug)?

Well...there could be another reason: To outpace the competitors! Look, the VST3 SDK looks quite unfinished, MIDI-stuff needed for instruments is still not documented fully. But how can that be, if Steinberg already uses this standard for their stuff since nearly a year now? How did they build their plugins and how comes, that their VST2.4 stuff does not fail from automation...
If there was a bug in Cubase 4 that leads to this, why are only 3rd party plugins affected?
This combined with the unfinished API-docs of VST3 and the incompatibility to VST2.4 looks like a really dirty trick to me. But I wouldn't be surprised if this will cause a backfire this time.

cheers,
Chris

Don't know if anyone noticed... VST3