u-he

Urs · Post by **Urs** » Mon Mar 13, 2017 4:19 pm

Diva /w latest VST3 support is almost ready for public testing. We're addressing a few more little niggles before we'll post it.

e@rs · Post by **e@rs** » Mon Mar 13, 2017 5:20 pm

^Cool.

Any benefits to switch from VST2 to VST3 for instruments?
For effects I know there are a few...

EvilDragon · Post by **EvilDragon** » Mon Mar 13, 2017 7:09 pm

For instruments, I bet there's absolutely no benefits to VST3, apart from Steinberg probably dropping VST2 altogether in Cubase 10, which isn't unlikely to happen.

fourthmanfire · Post by **fourthmanfire** » Mon Mar 13, 2017 10:50 pm

EvilDragon wrote:For instruments, I bet there's absolutely no benefits to VST3, apart from Steinberg probably dropping VST2 altogether in Cubase 10, which isn't unlikely to happen.

VST3 noob here. What are the benefits for VST3 effects vs. VST2?

SJ_Digriz · Post by **SJ_Digriz** » Mon Mar 13, 2017 11:07 pm

EvilDragon wrote:For instruments, I bet there's absolutely no benefits to VST3, apart from Steinberg probably dropping VST2 altogether in Cubase 10, which isn't unlikely to happen.

well, note expression ... instrument sidechain ... disable when not in use and stuff like that are pretty good things. But, won't go into the crappy negatives associated with how VST3 has been received.

karrikuh · Post by **karrikuh** » Tue Mar 14, 2017 6:44 am

fourthmanfire wrote:VST3 noob here. What are the benefits for VST3 effects vs. VST2?

Sample accurate automation! Not sure though whether U-He plugins support it.

Urs · Post by **Urs** » Tue Mar 14, 2017 7:23 am

karrikuh wrote:
fourthmanfire wrote:VST3 noob here. What are the benefits for VST3 effects vs. VST2?
Sample accurate automation! Not sure though whether U-He plugins support it.

Nope, we lowpass automation with slew rate limiters. Otherwise we'd get bad reviews about "steppy parameters".

If a host sent automation data per sample, everyone would diss it for being "badly optimized". Hence no host does that. The only example that comes to mind is Fruity Loops which does it with VST2 by chopping up the process into parts that automation ramps through.

EvilDragon · Post by **EvilDragon** » Tue Mar 14, 2017 8:43 am

Err... Cubase and Reaper (from what I know) can (and WILL) do sample-accurate automation (not different block sizes like FL Studio) for VST3 (and Reaper for its JS FX) and PT for AAX as well.

I think you should perhaps add an option to disable those automation slew rate limiters in Preferences, for people who want to use this accuracy (and also to fully comply to VST3/AAX, no?), with the default being how it is currently.

EvilDragon · Post by **EvilDragon** » Tue Mar 14, 2017 8:48 am

SJ_Digriz wrote:well, note expression ... instrument sidechain ... disable when not in use and stuff like that are pretty good things.

And two of those are already possible with VST2 in almost all hosts that are not Cubase, ehehe.

So I guess note expression is the only merit.

Urs · Post by **Urs** » Tue Mar 14, 2017 9:33 am

EvilDragon wrote:Err... Cubase and Reaper (from what I know) can (and WILL) do sample-accurate automation (not different block sizes like FL Studio) for VST3 (and Reaper for its JS FX) and PT for AAX as well.

I think you should perhaps add an option to disable those automation slew rate limiters in Preferences, for people who want to use this accuracy (and also to fully comply to VST3/AAX, no?), with the default being how it is currently.

Well, thing is, if they don't split processing, we have to. It'll definitely cost more CPU.

Also, sudden parameter changes can blow up filters and stuff. I think it's generally a good idea to do some slew rate limiting like we do, if even just for 64 samples or something.

Urs · Post by **Urs** » Tue Mar 14, 2017 9:34 am

EvilDragon wrote:So I guess note expression is the only merit.

Hehehe, I think our multichannel MIDI support with individual controllers per channel elegantly allows for Note Expressions in AAX/AU/VST2 as well

EvilDragon · Post by **EvilDragon** » Tue Mar 14, 2017 9:40 am

Urs wrote:Well, thing is, if they don't split processing, we have to. It'll definitely cost more CPU.

Also, sudden parameter changes can blow up filters and stuff. I think it's generally a good idea to do some slew rate limiting like we do, if even just for 64 samples or something.

If additional CPU would happen only with the slew rate filters disabled, I say go for it. Regarding blowing filters up, might be a good idea to then add a note on the Preferences pane just like you have for Base Latency parameter?

Urs · Post by **Urs** » Fri Mar 17, 2017 10:30 am

Update...

We have a bit of a problem left: While projects with our old VST3 versions open fine with the new ones in Cubase for all we know, they don't assign parameter automation data correctly in many others. I don't know if it's an oversight or just not well documented enough, but due to our rewrite this is going to be the one big issue left. I just hope it's not going to be too much of a hassle to reassign the automation and I also guess not many people have used our VST3 versions in those hosts anyway.

zvenx · Post by **zvenx** » Fri Mar 17, 2017 11:01 am

@ ED, for me one of the biggies it allows one to have more than 16 midi channels per plugin. Whilst one may argue that for Kontakt it may be better to have several instances rather than fewer instances with many midi channels and ports, for Maschine it would be a godsend.
rsp

EvilDragon · Post by **EvilDragon** » Fri Mar 17, 2017 1:16 pm

For Kontakt it's actually better to balance things out. Use several instruments per instance rather than a single instrument per instance. In this regard, multiple ports aren't really needed, since there's a tipping point after which a single Kontakt instance would fall over a CPU core.

But yeah, multiple MIDI ports is great in VST3. Just not something very applicable to u-he plugins, since they're monotimbral. All they need is 16 channels for MPE, that's all

u-he

KVR Audio

VST3 - known issues (Updated Jan 2019)