NOTE: Many method names and parameters have changed, so old examples probably won’t work.
I’ve updated the documentation and added some examples (could be more, of course).
I think it would be also good to have a short Tutorial/Guide.
class methods for searching a Server for plugins (in the platform specific default paths and/or user provided paths).
the plugin info is cached on the Client side, so you can access it without actually creating plugin instances
each searched plugin is stored under a key which is generated from plugin name + subfolder (e.g. ‘GVST/GChorus’). those keys can be used in -open.
-open now also accepts relative paths (which are resolved to the currently executing file).
easier to use VST instruments: the -midi method returns an instance of VstPluginMIDIProxy which basically has the same interface as MIDIOut and can be used as such (e.g. as the MIDI target for \midi Pbinds). all other MIDI messages have been removed from VstPluginController (except for raw MIDI).
-showGui is gone; instead there’s -editor to show the VST editor (Windows and Linux only) and -gui for the Qt GUI.
you can use the Qt GUI and VST editor simultaneously (but you have to -open with ‘editor: true’)
-gui now follows the SC conventions and can be either opened as a new Window or embedded in existing views!
it’s possible to change models, so you can use a single view and switch between different VstPluginController instances
parameter displays are now text fields, where you can type the value as a string (not supported by all plugins)
VstPluginGui also has a pop-up menu for changing programs, panels for reading/writing program/bank files and a dialog for searching, browsing and opening plugins.
various customization points on class and instance level
several optimizations for local Servers (most data is now transferred via temp files)
more reliable OSC communication with remote Servers
proper MVC via object dependency. you can add objects as dependants and they will receive all necessary updates. (needs to be documented.)
I’m afraid that this won’t be possible without changing some internals in SuperCollider. I have to discuss this with the devs and maybe we can work on a solution together. But first I need to integrate VST3 support, finish the release and get it into the SC3 plugins. Only then it makes sense to even approach this problem.
Definitely! I’ve been in touch with Christof during the last weeks and did some testing with patterns. I used simple vst instruments, but had enourmous fun with pattern control of basic params (via midi and/or VstPlugin setting, both can be handled with comfortable event types, one possibility was shown by @Geoffroy). Together wíth LFO controls and vst fxs this is an overwhelming extension of SC’s possibilities. GUIs are fine and a nice way to explore, but IMO the real power lies in the combination of the myriad of existing vstis/vstfxs with SC’s control and processing options. Myself I’m currently a rare vst user but I don’t know if this will change in future, thank you so much for this, Christof!
@droptableuser that can happen if you have some nasty plugins in your path. if you do the following: VstPlugin.search(verbose: true)
you will see which plugin causes the crash. maybe I should make verbose: true the default…
would be interesting if you could give me the console output (maybe in a PM).
EDIT: I’m actually thinking about probing plugins in a seperate process to avoid any crashes of the Server. it’s probably worth the hassle.
always use VstPlugin.search(verbose: true) to find out which plugin crashes.
only buggy plugins should crash the Server in the search because I’m doing nothing but opening them, getting some info and closing them. this works with every decent plugin I’ve tested… but I’m working to make the search safe in a way that it never crashes the Server.
for the mercurial VST it seems like it’s printing repeatedly to stdout which floods the console.
Many times until the IDE crashes.
how many? I might need to deactivate stdout during the search… anyway, thanks for reporting!
Daniel(or anyone), can you post an example of controlling parameters with patterns? On my machine (macOS 10.14.3) vsts aren’t showing up as MIDIClient destinations and I can’t figure out what to name the midi port.
‘Waves Mercury’ provides VST2 and VST3 as well as AU under macOS.
Usually, plug-ins provide individual VST files in the VST2 folder. However, Waves plug-ins provide only one file: “WaveShell1-VST” in VST2 folder (“WaveShell1-VST3” in VST3 folder and “WaveShell1-VST” in AU folder).
This WaveShell1 then links all plugins in the Waves plug-in folder. This is very unique. Could they be detectable in SC?
@prko I see, it’s a shell plugin. I’ve only read about those. is there a chance you can send me the plugin bundle? I don’t need the license, I just want to see the bundle structure and investigate the binaries to figure out how to deal with them.