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.
> - 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...
> - 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.
> - 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).
> - 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!
thanks again for your ideas! I'm really thinking now about changing the design so VstPluginUGens can be connected inside SynthDefs... I could provide convenience functions for quickly creating a single plugin as a Node on the Server. please let me know!
Christof
Gesendet: Dienstag, 15. Januar 2019 um 01:53 Uhr
Von: scott@xxxxxxxxxxxxx
An: sc-users@xxxxxxxxxxxxxxxx
Betreff: Re: [sc-users] VstPlugin - new pre-release version!
This is totally awesome work - it will be a real game-changer for a lot of people. I haven't had time to do a full review, but I've been poking the code a little and have a few design questions:
- VstPluginUGen takes bus indexes plus a channel count as arguments - this is non-standard for a ugen that processes audio input -- normally you would simply allow one or more channels of audio to be passed directly in as an "in" argument. I understand that the output channel count would still have to be a parameter (this is the norm for ugens that output a variable number of channels, so that seems fine). Is there a specific reason to use buses? It should work exactly the same to read from / write to internal Synth wirebufs, no?
- 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);
Subclassing Synth could make VST plugins much less flexible vs a more loose coupling between VstPlugin objects and synths (for example, what if I want a VstPlugin that controls a Synth running via an Ndef?)
- Is it possible to support specifying VST parameters via regular UGen arguments, e.g. a syntax like:
sig = VstPluginUgen.ar(input, args:['param1': SinOsc.kr(1)]);
I understand that VST's may have too many parameters to easily support them all via Synth arguments, but it seems important to be able to at least able to have the *option* to set params as part of the normal SynthDef graph (for e.g. modulating parameters).
- 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?
- The ugen index in your /u_cmd is hard-coded to 2. This definitely isn't safe - there's no guarantee that the ugen index is always going to be 2, this is an internal implementation detail. Beyond that, it limits flexibility (since this e.g. would not allow more than one VST ugen per synth). You should be able to walk the ugens of a particular SynthDef (SynthDescLib.at(\foo).def.children), find all instances of VstPluginUgen, and find their index (I believe this should be .synthIndex, or just their position in the children array) - this should be a safe and stable way to get an index for /u_cmd.
Excited to see this evolve!
Scott