cache search/probe results in a file to speed up subsequent searches
VSTPluginController: ‘set’ and ‘get’ now also accept parameter names instead of indices.
VSTPlugin.ar now accepts an ‘info’ argument, which allows ‘params’ to contain parameter names instead of indices. You can also ommit the name/path argument in VSTPluginController.open.
*Msg versions for all relevant methods to enable NRT synthesis and bundling.
You don’t have to wait anymore between creating a Synth and calling ‘open’, e.g.: VSTPluginController(Synth(\vst)).open("myPlugin");
changes
deprecated ‘parameterNames’ and ‘parameterLabels’ in plugin info. The info has now a member called ‘parameters’ which is an Array of parameter info Events (with ‘name’ and ‘label’ being the only members so far).
bug fixes
fixed possible crasher bugs when the UGen is freed while asynchronous commands are still running
internal changes
use .ini like syntax for plugin info
hard-bypass prefers the plugin’s bypass method
single event loop shared by all plugins
many changes to the OSC interface, UGen arguments and plugin info file structure
Is this expected behavior? When I set the parameter of a VSTPlugin to something inside the synth, whether a single value or an LFO, this does not get ‘set’ until I send the .set message after the synth is playing, which then sets the value to whatever was in the synth. For example,
(
SynthDef('noise', {
Out.ar(0, PinkNoise.ar(0.8.dup) * Decay.ar(Impulse.ar(3)))
}).add;
SynthDef(\insert, { arg bus;
var lfo = SinOsc.ar(0.2).range(0, 1);
ReplaceOut.ar(bus, VSTPlugin.ar(In.ar(bus, 2), 2, params: [0, lfo]));
}).add;
)
~noise = Synth('noise')
// search of available VST plugins in the default VST search paths
VSTPlugin.search;
// create the synth:
~synth = Synth(\insert, [\bus, 0], 1, 'addToTail');
// get a handle to the VSTPlugin:
~fx = VSTPluginController(~synth);
// open a plugin by name/key (might require VSTPlugin.search!)
~fx.open("ValhallaShimmer", info: true);
// alternatively, you can open a plugin by its file path
// (this only works if the file contains a single plugin, like most VST2.x plugins)
// ~fx.open("/path/to/plugin", info: true);
~fx.get(0, {arg f; f.postln}) // still 0.5
~fx.set(0, 0) // start the lfo for some reason
// show the GUI:
~fx.gui;
// etc.
Sure. Usually, it’s best to get the raw plugin state as Int8Array (~fx.getProgramData / ~fx.setProgramData) because it’s more compact and plugins might contain additional state beyond their parameter values.
If you really want to obtain the individual parameter values, you can use ~fx.getn. The values are passed as an array to action and you can optionally specifiy start index and number of parameters. ~fx.get(action: { |v| v.postln }); will simply get and print all parameters. Note that if a plugin has lots of parameters, you might have to use several calls to get with appropriate offset and count because OSC messages have a size limit. On the other hand, getProgramData transfers the data via a temp file, so it’s always reliable.
I am working mostly in NRT and I have noticed that I am able to run plugins without booting the server and without evaluating VSTPlugins.search as the plguins will read from the plugins.ini file. However, in the language, VSTPlugins.plugins still evaluates to nil so I cannot get information about the plugins, mainly the parameter list. Is there any way to search without booting the server?
great to hear the NRT features are actually being used
I have noticed that I am able to run plugins without booting the server and without evaluating VSTPlugins.search as the plguins will read from the plugins.ini file.
To clarify: this is only true if you have done VSTPlugins.search at least once, so the plugins.ini file really exists. But even without the cache file you can open plugins by referring to their absolute or relative filename - which is not necessarily the same as the plugin name! This only works if the file contains a single plugin, so it doesn’t work for VST2 shell plugins or VST3 modules containing several plugins.
However, in the language, VSTPlugins.plugins still evaluates to nil
Yes, because VSTPlugin.search also asks the Server to transmit the search results to the Client, otherwise the dictionary is empty. Note that each Server has it’s own plugin dictionary because
a) it might require a specific set of plugins (e.g. by providing a directory argument to VSTPlugin.search)
b) it might run on a different computer with different plugins installed.
Is there any way to search without booting the server?
Unfortunately, this is not possible, because the language client doesn’t know the exact location of the UGen and its accompanying files, so I can’t call the probe executable. If you really want to search for plugins, you need to open a Server instance. What I could provide is a class method like VSTPlugin.readPlugins which just parses the local plugins.ini and returns a dictionary instance which the user can store in some variable. (I can’t store it in VSTPlugin.plugins because it doesn’t belong to a specific Server instance.) You would still need to call VSTPlugin.search at least once, because otherwise you don’t have plugins.ini, but then you can get the plugin info without booting a Server. Would this make sense?
And yes everything is working really great. You have no idea the headache this saves me from trying to run 3rd order ambisonics with 20+ channels into stereo or even mono VSTs.
@Daniel_PetersonVSTPlugin.readPlugins is now available on latest develop! It returns a dictionary containing the locally cached plugin info. You can pass the plugin info to VSTPlugin.ar; this allows you to use parameter names instead of indices in the params argument and you can also omit the path argument in VSTPluginController.openMsg. These features have been already available for RT synthesis, but now they also work with NRT synthesis.
I am having so much fun with this and I am immensely grateful that this exists.
I have run VSTPlugin.search and, I am aware that this is most likely for my own safety but I still need to ask this I’m sorry:
Any way I can get around certain plugins being black-listed?
Maybe if I understood more about why they’ve been put on this black list I could deal with it better.
Might it have something to do with how certain plugins introduce tons of latency? I would be ok with that.
