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

[christof.ressi@xxxxxx]

sorry, I meant Scott of course :-)

> Gesendet: Mittwoch, 16. Januar 2019 um 14:08 Uhr
> Von: christof.ressi@xxxxxx
> An: sc-users@xxxxxxxxxxxxxxxx
> Betreff: Aw: Re: Re: Re: [sc-users] VstPlugin - new pre-release version!
>
> Hi Sam,
> 
> > I suppose I'm thinking about this a lot because the FIRST thing I'd want to do is map a VST parameter to some external control 
> > All the code in the core SuperCollider class lib and external quarks to do this by either writing control data to a bus and mapping that to a synth arg
> > or sending it directly to a synth or a parent group.
> 
> but this is already possible! just use -mapParameter to directly map a control bus to your VST parameter of choice. if you rather want to use Synth args to control VST parameters, in your SynthDef graph function just write the args to a (possibly multichannel) control bus with Out.kr and map the bus channels to the VST plugin parameters you want to control (again with -mapParameter). Please tell me if I'm missing something here!
> 
> I know that the current approach to parameters is a bit unusual but I'm just trying to keep it as flexible as possible in respect to the highly dynamic and unpredictable nature of VST plugins/synths. often you don't even know in advance which parameters you have or which you're interested in, so I think it's better to be able to map/unmap them dynamically instead of hard-coding it in the SynthDef.
> 
> The final VstPlugin class should work conveniently not only with a small Chorus plugin with 5 parameters but also with massive synths with literally thousands of parameters (I'm not exaggerating: Waldorf's "Largo" has about 2000 parameters, a user on the FB group actually tried to load it and it works - with some caveats).
> 
> 
> > I think all you'd need to make this thread safe is to make the plugin ptr atomic
> 
> It will need more than that to make it perfectly thread-safe (especially for closing the plugin) but I will look into it. actually, reading and writing program/bank files could be made realtime-safe if I read/write the file in a background thread and then use setProgramData / getProgramData. 
> unfortunately, there's no real restriction in what VST plugins can do internally, so some plugins might never be completely realtime safe for all operations. eventually, I guess it's the user's responsibility to find out what is safe and what is to be avoided in a realtime-context but I'll try to minimize possible issues as much as possible.
> 
> Christof
>  
> 
> Gesendet: Mittwoch, 16. Januar 2019 um 07:42 Uhr
> Von: scott@xxxxxxxxxxxxx
> An: sc-users@xxxxxxxxxxxxxxxx
> Betreff: Re: Re: Re: [sc-users] VstPlugin - new pre-release version!
> 
> I could totally imagine this! (actually, I had implemented VstPluginUGen like that before). I could (re)add a class method to quickly create a SynthDef for a single VST plugin with a given number of inputs/outputs:
>  
> VstPlugin.makeSynthDef(name: \vst, nin: 2, nout: 2, replacing: true).add;
> 
> this would be equivalent to your SynthDef above. if users want more complex SynthDefs with several VstPluginUGens and/or other UGens, they can create their own SynthDef.
> creating a VstPlugin then becomes:
> 
> ~synth = Synth.new(\vst, [\in, ~input, \out, ~output, \bypass, 0]);
> 
> // if there's only one VstPluginUGen we don't need an identifier:
> ~plugin = VstPlugin.new(~synth);
> 
> // otherwise it has to be something like this:
> ~plugin = VstPlugin.new(~synth, \eq);
> 
> // the SynthDef is automatically inferred with SynthDescLib.at(synth.defName) but it could be provided as an optional argument.
> 
> // the first version could be combined into a single line:
> ~plugin = VstPlugin(Synth(\vst, [\in, ~input, \out, ~output, \bypass, 0]));
> 
> this doesn't look so bad. it is not as dead-simple as the current implementation but it opens up more possibilities. creating a single VST plugin is still simple enough not to frighten beginners.
> what do you think? 
>  
> Yeah, I think that's definitely heading in the right direction. If there was a need for a more expressive syntax, you can always add something like:
>    ~synth = Synth(...);
>    ~synth.vstUgens[\eq].setParameter(\freq1, 100);
> This would allow you to keep Synth and VstPlugin as separate classes and keep their constructors clear and unambiguous, but still make accessing them very natural and easy - and you could manage the VstPlugin objects, rather than making the user keep track of all of them.
>  
>  
>  
>  > 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
> 
> when I use UGen inputs to automate parameters, how do I tell which one I want to automate? when my plugin has 100 parameters (some have 2000!) and I only want to automate a couple of them? and maybe I want to change which parameters I want to automate? I could use pairs of UGen inputs like 'parameter ID', 'parameter value'... but how do I tell that I don't want to automate a parameter anymore? setting the parameter ID to -1? honestly, mapping/unmapping parameters to control busses like in the current implementation seems like the most straightforward solution to me regarding the abstract nature of VST plugin parameters. but I have to think more about this...
>  
> I could definitely see the arguments being key value pairs, of either symbols or numbers (where the symbols are looked up from the list of parameter names once the plugin is loaded?) ... VstPluginUgen.ar(args:[\freq1, 100]). It doesn't seem very useful to allow for switching between the params being controlled, but depending on how it's implemented it would be just as easy to support this as not.
>  
> I suppose I'm thinking about this a lot because the FIRST thing I'd want to do is map a VST parameter to some external control - a pattern, a MIDI device, a slider. All the code in the core SuperCollider class lib and external quarks to do this by either writing control data to a bus and mapping that to a synth arg, or sending it directly to a synth or a parent group. All of these methods would need at least some new server interaction code to work correctly - it would be nice if it was possible to more or less use existing libraries or techniques to connect up VST's, at least in simple cases.
>  
>  
>  > 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
> 
> unfortunately, this won't be possible if you want to use the VST GUI because the GUI runs in it's own thread with a Win32 / X11 message pump and some plugin (e.g. all JUCE plugins) expect the plugin to be created and destroyed it that thread (otherwise they crash). it might be less a headache for plugins with the SuperCollider GUI. Let's leave this for later :-)
>  
> Ah, I see in your code that you're already doing initialization on a background thread in certain cases, and blocking the audio thread to wait. I think all you'd need to make this thread safe is to make the plugin ptr atomic, and then not block while waiting for the initialization thread (just have it set the plugin pointer). The plugin would have to just output 0's if the plugin pointer isn't set, which is far preferable to blocking the audio thread, which can be disastrous.
>  
>  
>  
>  > SynthDef graph generation code changes sometimes, and that can have an effect on the ordering of nodes - this can in turn affect the index.
> 
> I see! I've already changed the code to deduce the index from the SynthDef.
>  
> Awesome! Sorry to be pedantic about this - but the graph generation code is some of the most sophisticated, sensitive, and least understood in SuperCollider. It can take ages to track down issues related to this kind of thing, so it's good to have a solid base to start from!
>  
> - S
>  
> 
> _______________________________________________
> sc-users mailing list
> 
> info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
> archive: https://listarc.bham.ac.uk/marchives/sc-users/
> search: https://listarc.bham.ac.uk/lists/sc-users/search/
>

_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: https://listarc.bham.ac.uk/marchives/sc-users/
search: https://listarc.bham.ac.uk/lists/sc-users/search/