VSTPlugin v0.4 released!

Resources Libraries and Quarks
#1

NOTE: Please upgrade to v0.4.1!

This is a new release of VSTPlugin - a UGen to load VST plugins in Supercollider on Windows, macOS and Linux.

Binaries can be downloaded here: https://git.iem.at/pd/vstplugin/-/releases

If possible, please report any issues at https://git.iem.at/pd/vstplugin/issues, otherwise leave a comment here.

Changelog

Features

  • automatic bit bridging (load 32-bit plugins on a 64-bit Server and vice versa).

  • VSTPluginController.open: mode argument for sandboxing (\sandbox) or bridging (\bridge). Both options allow plugins to crash safely without taking down the Server. This can be handy for buggy/unstable plugins (especially during live shows :slight_smile: ).

  • VSTPluginController.open: multiThreading argument for multithreading (process the plugin in a seperate worker thread to utilize more CPU cores)

  • VSTPlugin.ar: blockSize argument for reblocking. Some plugins might run more efficiently at higher block sizes.

  • VSTPlugin.ar: info argument can now be a symbol (get the plugin from the default Server)

  • VSTPluginController.collect method to get controllers for all VSTPlugin instances in a given SynthDef

  • VSTPluginController.latency to query current latency or VSTPluginController.latencyChanged callback function for latency change

  • VSTPluginController.pluginCrashed callback function for plugin crash (only sandboxed/bridged plugins)

  • VSTPluginController preset methods now also accept preset Events

  • VSTPluginController.preset method returns current preset

Improvements/Bug Fixes

  • VSTPlugin.ar now stores info and id arguments in SynthDef metadata, so they can be serialized to/from disk (e.g. in SynthDef.store )

  • fix VSTPlugin.searchMsg

  • improve general error handling: throw Errors/MethodErrors whenever possible/practical

Changes

  • you can only omit the id argument in VSTPlugin.ar if the SynthDef contains a single VSTPlugin instance

  • VSTPluginController preset methods are now async by default

  • VSTPluginDesc: deprecate isSynth and hasEditor in favor of synth and editor

4 Likes
#2

I have just released VSTPlugin v0.4.1 which fixes a critical bug. Please upgrade!

1 Like
#3

Hi @Spacechild1, I tried to update to VSTPlugin 0.4.1 from 0.2.0 but am getting ā€œexception in GraphDef_Recv: UGen ā€˜VSTPluginā€™ not installed.ā€ I just swapped in the new vstplugin-master folder into the same Extensions folder where the old one was and recompiled. The help files do show up in the help window, though. Iā€™m on SC 3.11.0 using macOS 10.14.6. Any obvious reason why this would be happening?
Thanks,
Boris

#4

Any obvious reason why this would be happening?

Yes, it seems like you downloaded the source code and dropped it into the extension folder. You have to download the binaries instead (see the link on the top).

1 Like
#5

Hi @Spacechild1,

Love this! Thank you! Is there a way that I can get at the ranges of the parameters that show up in .gui? For example if I wanted to make my own slider with those ranges?

Thank you!

Ted

#6

Is there a way that I can get at the ranges of the parameters that show up in .gui ?

@tedmoore VST plugin parameters are always normalized to 0.0 - 1.0.

#8

AFAICS parameters are all normalized 0 to 1, so thereā€™s no need to set the sliderā€™s range. (Edit: Christofā€™s message appeared while I was writingā€¦)

It might be nice to get the range as a display courtesy for a number box next to the sliderā€¦ I have no idea if VSTs publish that information to hosts though.

hjh

#9

It might be nice to get the range as a display courtesy for a number box next to the sliderā€¦ I have no idea if VSTs publish that information to hosts though.

Itā€™s tricky and the situation is different for VST2 and VST3.

VST2: you can set the parameter either as a normalized float or as a string representation (the latter is not supported by all plugins). You canā€™t directly set the parameters as ā€œplainā€ values, e.g. -60 for -60 dB or 90 for 90% Dry/Wet Mix, but you can obtain a VstParameterProperties struct, which tells you the min/max
values. You could use this info to map the plain values to/from the normalized range. However, from my experience, not all plugins support VstParameterProperties.

VST3: you can set the parameter only as a normalized float, but there are methods to convert normalized values to/from ā€œplainā€ values or string representations. You can get a ParameterInfo struct to check for the number of steps and step count (in case of a discrete parameter). But these steps do not necessarily correspond to ā€œplainā€ values, because the latter might use a different range and scale (e.g. logarithmic). This means you canā€™t naively calculate ā€œplainā€ values from normalized values and vice versa, you have to use the relevant editor interface methods. From my understanding, the step count is mostly relevant to automation curves in a DAW (so they can snap to discrete steps in the case of discrete parameters).

The only things that work consistently and unambiguously are normalized float values and strings, so I restricted myself to that. Parameter automation via UGen inputs and Busses always has to use normalized floats because I canā€™t distinguish between ā€œplainā€ and normalized values (both are just numbers). Regarding the set and get methods, I could add something like a set_plain and get_plain method to set/get plain parameter values, but Iā€™m not sure it would be worth the effortā€¦

However, I could add the number of steps and step count to the parameter infos (see VSTPluginDesc.parameters) and provide helper methods to convert between normalized values and discrete steps.

#10

In the generic GUI editor, I have a text field next to each slider which shows the actual parameter value. Note that this text field is not only a display - you can also enter values! (However, this doesnā€™t work with all VST2 plugins)

#11

Thanks @jamshark70, that is the question I was trying to ask!

And thank you @Spacechild1 for the detailed response! For what I was thinking, a get_plain and set_plane wouldnā€™t be necessary. I actually went and checked in the VSTPluginDesc.parameters because I thought I would find some control spec type of info there. Adding what you can might be really useful if anyone is trying to control the VST via something other than the .gui or .editor. That way they could also display scaled values.

Currently, Iā€™m going to go forward just using 0 to 1. Itā€™ll serve my purposes. Thanks!

#12

That way they could also display scaled values.

Not really, the additional parameter info would only help with discrete parameters (e.g. a ā€œmodeā€ parameter with 5 modes). You canā€™t easily calculate ā€œplainā€ values from normalized values, because you donā€™t know the range and scaling. Thatā€™s why VST3 plugins have a special method for converting between ā€œplainā€ and normalized parameter values.

1 Like
#13

Amazing plugin that I am excited to use. But VSTPlugin.search is showing me nothing (windows 10). Is there a way to manually configure or something? My VSTs are in the usual place ā€œ/CommonFiles/VST3ā€¦ā€

Help!

#14

oh the server has to be running for the search to work! My bad. Iā€™ll leave the post up in case anyone runs into another issue and stumbles across this thread. Feel free to delete if you think thatā€™s appropriate.

2 Likes