VSTPlugin v0.1.0 is largely compatible to the last test release (VstPlugin pre-release) but the naming convention has changed from Vst to VST, e.g. VstPlugin => VSTPlugin. Better late than never .
Other important changes/additions:
plugins are now probed in a seperate process, so opening a bad plugin shouldn’t crash the Server.
searched plugins are now simply stored by their name (instead of the relative file path). Subfolders are still searched but the folder names are not prepended anymore. This means you can have “SomePlugin” anywhere in your search paths and.open("SomePlugin") will just work.
Another advantage is that the actual file name can differ across platforms and architectures because the plugin name is platform independent (e.g. “SomePlugin.vst”, “SomePlugin.so”, “SomePlugin_win32.dll” and “SomePlugin_x64.dll” can all be opened as “SomePlugin”).
In the (rather unlikely) case of nameclashes, you have to resort to opening the plugin via its file path.
Oh, this is a bug! Fixed it right now. Don’t hesitate to report if you notice any kind of odd behavior!
EDIT: the bug only manifests when trying to open two or more different plugins which are not in the plugin dictionary (yet). Plugins added with VSTPlugin.search are not affected, that’s why I haven’t noticed it :-/.
@dkmayer to avoid confusion you could change the example to use VSTPlugin.search(verbose: true); before each example and then open them simply like ~ctrls.open("ComboV");
That’s actually the preferred way to open plugins, using the full path is rarely necessary.