I want in the new version!!!
THNX!!!
VST3 is not really anything special. Supporting VST3 would not magically add any new plugin features to Renoise. In fact, it would be quite a pain in the ass for us to implement it, for very little pay-off.
VST2 (2.4) is still going to be alive and kicking for a long, long time.
Do you actually have some VST3 plugins you want to use, which are not also available as VST2?
2 Likes
As I said before, simply adding VST3 support would not automatically add this extra routing ability to Renoise. It’s up to the host sequencer to support this feature, and at the moment we don’t fully support it in Renoise, so it really wouldn’t make a difference if it’s a VST2 or VST3 plugin.
Improved audio routing is of course something that has been talked about here many times. If we do eventually add this to Renoise, then it would work just fine with VST2 plugins. It’s not really a special feature that only works exclusively in VST3.
1 Like
Ok Thnx ))
dblue what do you mean by that renoise doesn’t fully support VST 3?, does it work but without the added routing capabilities?, or not at all?
1 Like
No he said Renoise doesn’t fully support routing capabilities, these are VST 2 properties. Whatever VST 3 is supporting above VST 2 does not include audio or midi routing.
There is some minor midi routing support in the sense of that you can send midi notes to Effect plugins by creating an effect alias in the instrument list, so that involves the “partial” routing support in Renoise.
Ahh ok, I think had interpeted that wrong. Thank you for the clarification.
vst3 is a joke. and not a funny joke either, vst3 is a terrible joke. I would read dblues words very carefully because im going to right now recommend that you to trust him when he says vst 2.4 will be around for a very long long time
What Steinberg themselves explain about VST3 regarding the additional things:
Renoise has a function called “auto_suspend”, in which it will ask the plugin to shutdown if no audio signal is detected.
So this feature doesn’t really add anything fancy upon how Renoise solves it. Besides, not all plugins respond properly when the auto-suspend is active. In Renoise:You can disable this auto-suspend, but can you in Vst3?
Renoise allows you to customize routing the busses by yourself, a lot of DAWs support dynamic routing of busses. The only extra hassle with VST 2.4 standard is that you need to predefine how many busses are available if they offer the setting. Some plugins allow you to adjust the figure to what you need and only require an unload and reload of the plugin. Lots of plugins simply set the limit for you. Frankly for me, the above mentioned feature where adding or removing busses on-the-fly from within the plugin without having to restart it only sounds like a little extra comfort, but doesn’t really lift my socks. It would perhaps make plugin developers motivate to allow a user to set a maximum audio-bus limit rather than estimate what an average computer can handle and set this fixed limit themselves but that is a sheer comfort knowing that developers are free to program this feature or leave it fixed as usual.
VST 2.4 also can have audio inputs (Used Senderella as an example), i don’t see anything particular specific with this feature besides if the DAW perhaps does not facilitate audio routing through plugins. With Renoise this is not a problem for effect plugins and would perhaps also not be a problem if the devs add support for VST instruments if they support audio input.
The only real extra here is that there is no limitation on how many inputs and outputs can be defined in VSt3, the same counts for Midi I/O. It does make it easier in the sense that you don’t need more instances of the same plugin to overcome these limitations. But would it in practical sense make a real difference?
Then there is this one-liner where the page is using 64-bit processing as an argument which is utter bullshit. There are plenty VST 2.4 plugins that are doing fine on 64-bit processing. And no, 32-bit plugins won’t be capable of doing 64-bit processing because their compiled environment simply doesn’t allow to handle such large figures
I can’t find much more info on what VST 3 supposed to support in contrast what 2.4 should lack, Robot² is completely right:VST3 is a complete joke. At least for Renoise, you really don’t need it. How other DAW’s optimize VST cpu consumption is not our debate.
1 Like
wow, thank you for making that clear! nice post!
1 Like
Vst3 actually has two of really big improvements over vst2 - more accurate parameter automation (no more restricted to 7bit) and ability to have more per note automation (more than aftertouch and velocity).
Not saying that we need support for Vst3 yet, if ever. No need to hurry until it’s bigger than vst2, if that day ever comes 
Yes these sounds nice, though i don’t particularly understand the “no more restricted to 7 bit” when this is about automation since i never had the idea in Renoise that controlling the vst plugins’parameters are being done using a 7 bit figure (this seems a pure midi only limitation).
For per note automation, this also requires a big change in the pattern editor or automation editor to allow for this kind of support.
We would then need multiple automation frames for the same parameter but then tied to each note-column to allow the high precision of automation.
UI changes wouldn’t be that big just more columns in pattern editor, since we already have per note parameters (velocity/aftertouch, delay column and panning) and ability to automate those columns (which would be awesome feature in it’s own even with just vel/at and delay).
Don’t know how challenging this would technically be, doesn’t really sound that hard to do since everything else somewhat exists besides per note column automation lines.
pls name me a automaticable VSTi effect which needs more than 127 values ? and would this really be a difference between a good and a bad song?
i think the dev’s should spend her time in usefull functions, there are enough open things left.
for me it sounds a versionsjunky need always the newest ( which is ofcourse the best of all times) and can’t live and or work with the “old” one.
Filter cut-off? Finer attack-decay envelope controls?
in general, RM and FM or any frequency adjustment.
or mass (phys. -modelled), or reverb decays, or ‘you name it’.
it depends on the plugin, i think.
but hey, who is really automating the s.hit out of a plugin inside renoise?!
and no, i dont mean lfo/random-modulation “every second” parameter.
you can’t argument that you hear a difference between 128 or 256 filter cutoff steps or attack decay evenelopes.
together with
i still think its useless. pls record a proof of concept vst3 filter cutoff with more than 128 steps vs renoise with 128 steps, if that really sounds better, I’m sure the dev team will ofcourse support that.
on the other hand i’m not sure if renoise automation curve raster is fine enough for that 
however, it would not change a song from bad to good.
Trust me, you don’t want that,certainly not when you need the “over 7 bit precision” automation.
The effect columns are nice for fast exact values, but imho are a legacy feature and should not be expanded the way they are used now.
Calling effect columns a legacy feature is a brave thing to do, thats for sure 
I don’t see the reason to expand them though. If filter slides are not smooth enough, just use some inertia, at least it’s what I would do.