Re: Re: [sc-users] VstPlugin - new pre-release version!

On Tue, Jan 15, 2019 at 2:28 AM <christof.ressi@xxxxxx> wrote:

Hi Scott, thanks for your detailed feedback!

> Is there a specific reason to use buses?

after I've decided that there should only be one VstPluginUGen in a Node on the Server, I chose to use busses for input and output so that the needed SynthDef would become trivial (I can create it in *initClass and it works for all plugin configurations). VstPluginUGen is rather an implementation detail and not to be used directly.

You should be able to get the same result, but with fewer UGen arguments, less resources, and more flexibility with something like this:

SynthDef(\vst, {

var inChannels = 2, outChannels = 2;

var input = \in.ar(0 ! inChannels);

ReplaceOut.ar(\out.kr,

VstPluginUgen.ar(
input,

outChannels,

\bypass.kr(0)

)

}).add

This would eliminate a couple arguments from your UGen (and the related complexity w/r/t dealing with buses directly). This might allow you to avoid a copy/fill on VstPluginUgen.cpp:288 and simply pass your audio wirebuf pointer directly in to the VST plugin (maybe the output copy also?). I believe the synth graph will handle allocation, and should even let you know whether you can call processReplacing or just process (e.g. if the input buffer == output buffer pointer).

> - Why is VstPlugin a subclass of Synth rather than a standalone class that e.g. points to a running Synth? For example, why not:

> ~node = { VstPluginUgen.ar(...) }.play;
> ~vstInstance = VstPlugin(~node);

I subclass because currently a VstPlugin instance creates and represents a Node on the Server.

But your example is interesting because I now see that I could use SynthDescLib.at(\foo).children to get the index of the plugin within the Synth. But in case there are more than one VstPluginUGen in the Synth, how would you refer to them in VstPlugin.new? maybe VstPluginUGen.ar could take an optional identifier:

~node = { Out.ar(2, [VstPluginUGen.ar(\chorus, ...), VstPluginUGen.ar(\delay, ...)]) }.play;

~chorus = VstPlugin(~node, \chorus);

~delay = VstPlugin(~node, \delay);

just thinking out loud...

I could imagine a scheme that worked like this:

SynthDef(\foo, {

var input, sig, delayTime;

input = \in.ar([0, 0]); // two channels input

delayTime = SinOsc.kr(1).range(1, 4);

// Assume 2 channel input means 2 channel output by default?

sig = VstPluginUgen.ar(\delay, input, args:['delay', delayTime]);

sig = VstPluginUgen.ar(\eq, sig);

Out.ar(\out.kr, sig);

}).add;

~node = Synth(\foo);

~node.map(\in, ~microphoneInput); // connect some input audio

// Okay, now how do have more control over my vst? Create a control object and point it to the node - you should be able to infer the SynthDef in most cases, but lets set it explicitly here

~delayCtrl = VstPluginControl(~node, SynthDescLib.at(\foo), \delay);

~delayCtrl.set(\feedback, 0.5);

~eqCtrl = VstPluginControl(~node, SynthDescLib.at(\foo), \eq);

~eqCtrl.set(\f1, 440);

You could probably store the linkage between names and UGen index in the SynthDef metadata, which is written out to a file and re-loaded as well. You can access the current SynthDef from a ugen via buildSynthDef (for e.g. storing metadata).

I could also see an initialize-first scheme enforced by the actual sclang objects - where you would do something like:

SynthDef(\vstEq, {

Out.ar(0, VstPluginUgen.ar(\vstIndex.kr, \in.ar(0));

})

VstPlugin.load("/path/to/eq.vst", doneAction:{

|vst|

~synth = Synth(\vstEq, [\in, ~inputBus.asMap, \vstIndex, vst.index])

});

All just brainstorming! VST's are a weird match for SuperCollider, but incredibly useful - I'm glad this is moving forward.

- S

> - Is it possible to support specifying VST parameters via regular UGen arguments, e.g. a syntax like:

the reasons why plugin parameters are not Synth arguments are exactly those you've mentioned. number of parameters varies *widely* between plugins (lets say 0-160).

you can modulate every parameter with either -setParameter or you can directly map it to a control bus with -mapParameter. I think this gives you lots of flexibility already, but if I rewrite the thing so that VstPluginUGen can be used freely inside a SynthDef, I see that it would be handy to set the parameters via UGen inputs. However, I don't see how this should behave together with the plugin GUI...

OTOH, inside your SynthDef you can easily write to Control Busses which the VstPlugin can read from.

Hmm - I would expect that setting a parameter via a UGen input would be exactly the same as it works now when setting it via \setParameter. In terms of UI, I would expect parameters that are being set in an automated way would work the same as params being driven by automation in a DAW (usually, the UI updates as you play?). It might be good to ignore /setParameter changes if you're driving a parameter with some kind of input, but that's straightforward to do.

> - You mention plugin open/close and bank load/save as non-realtime-safe operations. Can these be performed asynchronously, rather than in a way that blocks the audio thread as they are now?

opening/closing a plugin: very difficult; reading/saving programs: also difficult, but actually you can load your preset file in the language into an Int8Array and pass it to -setProgramData. this should be more realtime safe (but it depends really on what the plugin is doing).

I forget that UGens don't really have a non-realtime setup phase, so everything has to happen on the realtime clock. I guess my inclination would be to provide a custom plugin command that would initialize a plugin instance on a background thread, and then call back when finished (like buffer allocation) - that way you could load and unload VST's and have a firm guarantee that you won't break playback or drop audio. Not sure how possible this is - but at least from the sc side, it would need to work like:

1. Tell plugin to initialize a new foo.vst instance with id=123

2. Plugin reports back when initialization is done

3. Lang creates a Synth with a VstPluginUgen.ar(123, ...)

That should at least provide a path to create and remove VST's without dropouts. Anyone really wanting to use VST's is going to have to build this functionality anyway (e.g. init first, then use later), so it might as well be solved by the core classes?

> - The ugen index in your /u_cmd is hard-coded to 2. This definitely isn't safe

right now, VstPluginUGen is the only UGen in the SynthDef, so it will always have the same index (I think?). getting the index with SynthDef.children would be more save of course!

SynthDef graph generation code changes sometimes, and that can have an effect on the ordering of nodes - this can in turn affect the index. It's *definitely* possible that a change in core sclang code could break your plugin if you're using hardcoded indexes.

- S