Any plans for building a VST3 wrapper in the near future?


#1

Though VST3 had some problems in the beginning, it seems by now that most companies have adopted the new standard and offer VST3 versions of their software.
So, as the subject already says, are there any plans to support VST3 in juce officially, or is it up to the juce users to implement a wrapper on their own?
I don’t hope so because I really like the way the existing wrappers are done and having a number of different VST3 wrappers designed by different users could make it pretty complicated for the juce community to communicate and to sort out bugs.

Besides the plans of Jules, I would be interested in the opinion of other juce users, what they think about the new standard and if they would release VST3 versions of their software.


#2

I haven’t looked into it yet, but suppose that if it’s starting to be used then I’ll inevitably have to think about doing it (groan…)

Can’t give a timescale within which I’m likely to do it, but if anyone tries doing it themselves, then any code you want to throw my way might get me started faster - even if I have to rewrite it, it’s always quicker to have a rough framework to start from.


#3

I personnaly do not feel any urge to switch to VST3 , and nobody has asked us to do it. And there are already so many combinations of plugin formats/hosts/platform to deal with, it’s such a pain to test (and to fix when it’s broken), I’m not eager to add a new one.

In fact, if I were to vote for a new plugin format, maybe I would even peek LV2 instead of VST3. At least it would enable juce plugins to work on a new range of hosts on Linux.


#4

Is there any exciting new functionality in VST3???

I was a little bit underwhelmed reading the release notes.


#5

I think the most important new features are a real sample accurate parameter automation for the first time and an extended speakerhandling supporting native sidechaining. There are a lot more nice features but the two mentioned above are the most important, at least for me. Probably if you ask someone else, he would have some other favourites. Just read the introduction of the docs provided with the sdk. I think they didn’t reinvent the wheel, but some things are pretty good.


#6

Bringing this thread back from hibernation. :slight_smile: Any news on this front? We ignored VST 3 support for as long as we could fend off the Marketing department with big Engineering words… but we’re going to have to add support for it sooner rather than later now. Any progress in this area? In the official JUCE code, or 3rd party?


#7

My schedule is too full right now to offer to do it any time soon, but am happy to help out as much as possible if people are trying to roll their own version…


#8

The VST3.1 SDK was released in late June. A few of the new features:

  • VST2.4 wrapper (turns your VST3.1 plugin into VST2.4, not vice-versa)
  • AU wrapper
  • MDA example plugins in VST3.1 format

I don’t know what hosts work with VST3 besides the Steinberg hosts, and I don’t know of any that currently REQUIRE VST3. Still, it’s there, and it may become a more widely adopted standard in the future.

Sean Costello


#9

Hi,

Please could someone tell me… what is the current state of VST3 with JUCE at the moment? Can JUCE build VST3 plug-ins, or is it not implemented yet?

Paul


#10

You could search the codebase for VST3 (which doesn’t seem to be there)?


#11

Yes, sorry - not yet implemented!


#12

Is it something that is planned at all, or should we assume that we’ll need to write our own wrapper if its something we require?

Paul


#13

I just don’t have time to think about it right now… If anyone came up with some working code, I’d be happy to help with it, but it’s not a big priority for me at the moment.


#14

Fair enough. Thanks for the response.


#15

I would be interested by a VST3 wrapper, given the (lots of) features it brings and that we need for our plugins…

If someone started something, I would be glad to give a contribution.


#16

I’d like to contribute too.

Cheers
Emanuele


#17

Steinberg announced that they are discontinuing vst 2 support, which means vst 3 is here and new plugins and hosts will be developed supporting vst 3. Hopefully someone will jump on this and help jules.


#18

Thanks, but don't worry, it's underway.


#19

​Hi,

I'm working on a host application and I'd like to have some visibility on the future VST3 implementation with Juce library, especially about the sample-accurate parameters automations.

The question is quite simple: How to manage the parameters' change's positions in buffers and then send them in the processing of AudioProcessor? I read that the VST3 implementation is just begining, and I imagine there are other issues to deal with before and that this isn't your main emergency, but in the future, how will this work?

- Will the setParameter//setParameterNotifyingHost methods set the positions of the events in buffers (at their exact sample position) that will be processed with a sample-accurate precision in the next block ? (Which would mean that we don't have to care about it, such a dream...)

OR

- Will the ProcessBlock method evolve to include these new buffers of parameters changes?

 

or maybe you are planning other solutions?
 

Thanks.

Florent.

-- I precise that I'd have been happy to help for this work, but I think I'm not good enough... :| --

 


#20

TBH I need to have a serious think about how best to handle this in a way that's compatible with all the plugin formats. I imagine that it'll involve some redesigning that might break people's code, but I'm yet to find the time to properly think it through.