VSTPlugin NRT: setting Effect Type


I’m having difficulty setting an effect type VSTPlugin via NRT:

While using the (VST3) Plugin in real time i can browse through 12 available reverb types by setting the correspondent parameter 1 (in the usual range 0-1), the same doesn’t work in NRT mode. While the Plugin is otherwise clearly working in NRT and other parameters do react, that specific one won’t work, staying locked to the default effect/reverb type. Is there anything I might be overseeing?

Thanks for any help!


to illustrate.

works in realtime:

SynthDef.new(\vst, {
	Out.ar(0, VSTPlugin.ar( Saw.ar(30), 1,0,[0,1,1,MouseX.kr(1,12)/12])); //browse through 12 effect types

~fx1 = VSTPluginController(Synth(\vst));

doesn’t work in NRT:

				SynthDef(\test, {|dur|
						VSTPlugin.ar(Saw.ar(30),1,0, [0,SinOsc.kr(1).abs,1,LFSaw.kr(0.1).range(1,12)/12])); //while parameter 0 (dry/wet) works, parameter 1 not changing the effect type
		p= (Pbind(
			\instrument, \test,
		~vpc= VSTPluginController(~sy) ;
		p.add([0.0, VSTPlugin.searchMsg("/Library/Audio/Plug-Ins/VST/BigSky.vst3")]);
		p.add([0.0, ~sy.newMsg]);
		p.add([0.0, ~vpc.openMsg("BigSky.vst3")]);

Hey, I cannot spot any errors in your code samples. What happens if you use the \test SynthDef in realtime mode? Does it work as expected?

thanks for chiming in! Yes, realtime works as expected, both parameters react. In NRT, parameter 1 (effect type) stays fixed no matter what the input, while parameter 0 (dry/wet) reacts…

The only thing that comes to my mind is that the plugin might need to be notified about offline mode.

Try this:

p.add([0.0, VSTPlugin.searchMsg("/Library/Audio/Plug-Ins/VST/BigSky.vst3")]);
p.add([0.0, ~sy.newMsg]);
p.add([0.0, ~vpc.openMsg("BigSky.vst3")]);
p.add([0.0, ~vpc.setOfflineMsg(true)]);

I tried this but unfortunately that doesn’t make a difference. Also it’s clear the plugin is generally working in NRT as dry/wet + the specific parameters of the default effect type (such as decay time etc) are responding.
The effect type itself though, maybe because its a sort of “meta-parameter” is unresponsive, which is weird as in real time it works perfectly.

Consider a 2x2 matrix:

. Real-time Non-real-time
SC Ok Not ok
DAW Presumed ok? Unknown (untested)

So let’s assume that SC and VSTPlugin’s reliability is unknown (pretty good based on experience, but lacking professional grade QE), and also assume that a DAW’s reliability should be very high.

Then one way to gain insight into the problem is to test the plugin against a DAW: Set up a track with the plugin and automate the fx type parameter continuously. Then export NRT style.

If the fx type automation works in the DAW, then we know that the DAW is doing something that SC isn’t. This doesn’t guarantee a fix but it would identify where the difference is.

If the fx type automation fails in both environments, then it is a plugin problem, not a SuperCollider problem.

I’m not a betting type, but I’d put an espresso on the second possibility.


1 Like

Hi James,
I followed your experiment and tested it within a DAW. The funny thing is that to automate the fx type in the daw is basically unusable in real time as it pushes cpu to extremes (but it works/ parameter responsive). The rendering in the daw is extremely slow but the results are clean and as expected, the parameter can be automated and it browses through the fx typed…
Ironically seems to be the opposite to SC, where real time usage is flawless and not as demanding cpu-wise but NRT won’t give the expected result.

Interesting. Since there is no easy fix, I would suggest to open a ticket at Pure Data libraries / vstplugin · GitLab. I can look into it more closely when I have more time.

Ok, just did, thank you!

1 Like

I take your DAW results to mean that the effect type parameter is not safe to modulate. It “worked” with DAW NRT (and ground RT to a near-halt) but if it dramatically slowed down rendering, that suggests it isn’t quite a best practice.

You got lucky with SC real-time, and this set a high expectation for you, which did not translate into other scenarios. It isn’t always true that “it worked for A” implies “it should work for B, C and D.”

FWIW I’m not sure I’d like it if SC’s behavior matched the DAW here (“you can drive real-time into the ground by supplying a kr signal for certain parameters” for me would increase risk). So it would be nice to be able to choose the desired behavior.


I take your DAW results to mean that the effect type parameter is not safe to modulate.

It depends. Usually, VST plugin parameters are automatable, but not all are meant to automated at a high rate. I think the actual problem is that @mousaique modulates the parameter with a saw tooth wave, so that the value changes every 64 samples. Typically, discrete parameters should be automated in steps, otherwise this can lead to excessive CPU usage (if the plugin does not employ proper checks).

I would be interesting to know what @mousaique means exactly with “pushes cpu to extreme”. In my understanding, audio playback is working fine and it is rather the UI that is overloaded. This would also explain why it seems to work flawlessly in SuperCollider: the IDE and sclang are in a different process; if the event loop on the server side is overloaded, you typically don’t notice - unless you try to use other plugin UIs.

Now here’s a wild guess on what’s happening: if you automate the “effect type” parameter in BigSky, it sends a command to the UI thread to do the actual work, to avoid blocking the audio thread. If you do this for every control period, you might overload the UI thread. Also, it would explain why NRT synthesis does not work: if you run scsynth or supernova in NRT mode on macOS, there is no event loop! You could easily test this hypothesis by running the same code on a Windows machine. (Needless to say, a VST plugin should also work without an event loop.)

Regarding the DAW usage, the audio was choppy with cpu going up to about 400%.
Also just to be clear the fx type parameter in NRT does not respond to any input, including (non modulating) numbers. It stays locked to its preset no matter what i do.

I guess it’s a semantic distinction…? Referring to this specific case, taking a 2x2 matrix of host vs render rate, you have 1 OK and 3 not OK (of those, in one case, the parameter value is ignored; in one, the choppy audio is unusable; in the last, rendering time is severely impacted).

That is, the assumption seemed to be “if I can modulate other parameters at any rate I choose, then something is wrong [with SC / VSTPlugin] if this parameter doesn’t behave well.” I think we agree that this is not a valid assumption.

That would match spacechild’s event-loop hypothesis (no event loop, no handling of that specific parameter, but only that one).