KVR Audio

Dewdman42 · Post by **Dewdman42** » Wed Jun 19, 2019 5:13 pm

AU plugins do not have to be coded in Objective-C.

The main reason to make AU plugins is for LogicPro, which doesn't support VST. Could be other advantages I suppose, but mostly I don't think anyone is taking advantage of AU specific features, most people are making cross platform plugins that need to run on both Mac and Windows, as both VST and AU.

AU3 is also infant stage. LogicPro, the main reason for needing AU instead of VST, is still basically in beta stage in terms of supporting AU3 completely. It will all get there and AU3 will be the future, but I'd say VST3 is much further along then AU3 right now in 2019.

ictools · Post by **ictools** » Wed Jun 19, 2019 5:19 pm

MYTH: VST3 isn’t that different from VST 2.4. It’s just hype; there are no real improvements.

VST3 is a ground-up redo of VST 2.4 and is essentially a new platform.

Sample accurate automation. The manufacturer has to implement this, but it’s a significant change compared to VST 2.4.

Hierarchical plug-in and automation parameter categorization. Some consider plug-in categorization (fig. 3) a drawback, because they can’t organize plug-ins the way they like (although most hosts provide some kind of plug-in manager, in which case it doesn’t matter). But when you want to automate parameters, VST3 plug-ins can make life a whole lot easier if the manufacturer took advantage of the parameter categorization options. Grouping all filter automation parameters under a “Filter” category is waaaay better than a huge list of automation parameters with a seemingly random arrangement.

Figure 3: Cubase 9.5 has a sophisticated VST plug-in manager. Note how in the Category, some plug-ins have been categorized as to the type of effect (e.g., Dynamics, Modulation). Highlighting a plug-in shows information about sidechaining, type of I/O, file path, and more.

Dynamic I/O allocation. VST 2.4 plug-ins used to have a fixed number of inputs and outputs, but that’s no longer the case — VST3 plug-ins have the potential to adapt to the channel configuration into which they’re inserted. Put the plug-in on a stereo bus, and it’s stereo. Insert it in a surround bus, and it’s surround. You can also create audio buses, which makes cross-modulation and vocoder applications easy to do. But again, it’s up to the manufacturer to implement these features.

Instrument output bus cleanup. In a related development, instruments with multiple outputs can take up a lot of unneeded mixer channels. With VST3, you can disable unused outputs yet re-enable them later if needed.

Window resizing. This is certainly welcome, given that monitors have a wider variety of resolutions than when VST was introduced back in 1996 (and for perspective, “Macarena” was the #1 song of the year. Just sayin’).

With virtual instruments, there’s support for multiple MIDI ports you can switch on the fly. And who doesn’t like multiple MIDI ports?

It’s a lot easier to do a search and find your plug-ins. VST3 plug-ins have the .vst3 suffix instead of a generic suffix.

Plug-ins can have a dedicated “event bus.” Although at present this is designed for MIDI control input, there’s no reason why it couldn’t accommodate some future standard that’s not MIDI-based.

VSTXML for remote controllers. No, a cat didn’t walk across my keyboard. VSTXML is a protocol that simplifies creating remote controllers for audio and MIDI software application. It can even display non-editable parameters, like metering.

Multilingual design. All user-facing character strings are in Unicode format, which allows displaying characters in any language (включая русский — which means, “including Russian”) to facilitate localization.

Better handling of MIDI events. This assists upcoming expansions to the MIDI spec. As one example, a particular note could be associated with bend so only that note reacts to pitch bend — think MIDI pedal steel. An instrument can also have more than one MIDI input and/or output.

The VST3 SDK is free technology that is available to any developer. Thanks, Steinberg/Yamaha. Enough said.

https://www.sweetwater.com/insync/vst-2 ... es-you-do/

NAD · Post by **NAD** » Thu Jun 20, 2019 9:46 am

https://www.steinberg.net/en/company/te ... /vst3.html

Multiple dynamic I/Os is nice in some plugins, for example not having separate versions for mono/stereo/surround.

Sample-accurate automation would be nice if it actually worked. I have yet to see this properly implemented, or else I'm doing something wrong.

Audio inputs for VST instruments - I kinda thought this was already possible with 2.4, no?

Xenakios · Post by **Xenakios** » Thu Jun 20, 2019 12:49 pm

NAD wrote: ↑Thu Jun 20, 2019 9:46 am Sample-accurate automation would be nice if it actually worked. I have yet to see this properly implemented, or else I'm doing something wrong.

Many plugins are developed with things like JUCE or IPlug, which don't properly implement the sample accurate automation for VST3. They just use one of the provided automation points from the host per processing buffer, and that parameter automation value will be used by the plugin for the whole buffer. (So, it end ups working like VST2 automation worked and maybe even a bit worse, since the host has no control over what automation point the plugin actually ends up using...)

Interestingly, even Steinberg's own VST3 example plugin skips implementing the sample accurate automation...

Functional · Post by **Functional** » Thu Jun 20, 2019 3:28 pm

NAD wrote: ↑Thu Jun 20, 2019 9:46 am Audio inputs for VST instruments - I kinda thought this was already possible with 2.4, no?

Maybe it means multiple audio inputs, because I can't recall a single VST2 (or... sigh, VST3...) plugin that accepts multiple auxiliary audio input sources. Although I'm not entirely sure how would that feature even really be useful in the end. Maybe for plugin containers or something, but otherwise? eh

pdxindy · Post by **pdxindy** » Thu Jun 20, 2019 3:31 pm

Plugin standards should not be in the control of a single company.

mike_the_ranger · Post by **mike_the_ranger** » Thu Jun 20, 2019 3:35 pm

"we have 99 standards"
"time to create one that's available to all and not in control of a single company"
"oh look we have 100 standards"

Functional · Post by **Functional** » Thu Jun 20, 2019 3:44 pm

I was actually thinking about the same thing. Having open standard would be rad but realistically speaking it just means one more standard for devs. It would only work if major DAW developers would promise to adopt it. Then only Cubase and Pro Tools would remain to not support it and devs could just ignore both. Most do ignore AAX already, don't they?

Forgotten · Post by **Forgotten** » Thu Jun 20, 2019 3:48 pm

mike_the_ranger wrote: ↑Thu Jun 20, 2019 3:35 pm "we have 99 standards"

It's a bitch that we don't have one...

vurt · Post by **vurt** » Thu Jun 20, 2019 3:52 pm

hit me!

Xenakios · Post by **Xenakios** » Thu Jun 20, 2019 3:54 pm

Functional wrote: ↑Thu Jun 20, 2019 3:44 pm Most do ignore AAX already, don't they?

That's probably because of the extremely complicated procedures to develop and particularly release the plugins. If those were simpler, I bet there would be a lot more AAX plugins. But Avid actually doesn't want it to be simpler, to keep the ProTools/AAX platform more exclusive.

Functional · Post by **Functional** » Thu Jun 20, 2019 4:37 pm

Yeah honestly I can't really comprehend the rationale behind what Avid does. I mean, they have to have at least one guy in their huge ass company that has to have figured "Hey, these days actually other DAW's are viable in studio as well, maybe we shouldn't anymore bank on being the only industry standard" but lo & behold, they keep going like it was the 2000's.

Tj Shredder · Post by **Tj Shredder** » Thu Jun 20, 2019 4:43 pm

pdxindy wrote: ↑Thu Jun 20, 2019 3:31 pm Plugin standards should not be in the control of a single company.

As vst3 is open source, there is no problem using that as the standard. It even has advantages if the project is lead by a huge company like Yamaha...
Anybody could take over control under the terms of GPL... But that would be bad news for devs who want to keep their plug-in sources closed...

BlueprintInc · Post by **BlueprintInc** » Thu Jun 20, 2019 4:50 pm

Xenakios wrote: ↑Thu Jun 20, 2019 3:54 pm
Functional wrote: ↑Thu Jun 20, 2019 3:44 pm Most do ignore AAX already, don't they?
That's probably because of the extremely complicated procedures to develop and particularly release the plugins. If those were simpler, I bet there would be a lot more AAX plugins. But Avid actually doesn't want it to be simpler, to keep the ProTools/AAX platform more exclusive.

I don't know which major devs don't support AAX meanwhile. Developing it actually isn't hard and doesn't cost any additional money besides a dev certificate (if at all). The interface is pretty clear and straight forward compared to others. Yes it is exclusive to Avid, but given the features ProTools support, the DSP cards or the console hardware that's used with it, a totally general plugin interface wouldn't make much sense.

The only real thing that seems to annoy some devs is the code-signing part. I on the other hand think this is a quite good thing to verify it's your unmodified version of the plugin.

BlueprintInc · Post by **BlueprintInc** » Thu Jun 20, 2019 4:54 pm

Dewdman42 wrote: ↑Wed Jun 19, 2019 5:13 pmAU plugins do not have to be coded in Objective-C.

You're right. If you only code 1 plugin with hard coded class-names and can afford the auval warnings as well as the possible resulting errors, you can go without ObjC. Or if you don't support the most basic Cocoa UI classes

Is VST3 worth it?