NOTE: I had to make some breaking changes to the VSTPlugin.ar and VSTPlugin.search methods. Most existing code will be unaffected; otherwise, it should be easy to update.
WARNING: because the internal UGen input/output structure had to change, you can’t use existing .scsyndef files! Please recreate them with the new version.
Changelog overview:
JITLib integration: new VSTPluginNodeProxyController class and NodeProxy roles (\vst, \vstFilter and \vstDef)
support for multiple input/output busses (VST3 only)
setOffline method for better offline processing support
VSTPlugin.search: new timeout and exclude options
moveEditor and resizeEditor methods to resize/move plugin UI (if supported)
Linux: allow to run 32-bit and 64-bit Windows plugins (via Wine)
Linux: fix VST3 editor
fix some race conditions (= better stability)
fix possible wrong channel count in VST3 speaker setup (regression introduced in v0.4)
Not to be too discouraging about sc3-plug-ins, but that really is a repo that, while still useful, isn’t one that I would encourage further contribution to. How to replace it has been on my mind for a bit, and I’m still not sure what the best way to grow external plugins should be.
Hi @josh! I didn’t know about this problem. Recently I’ve also asked @madskjeldgaard if he could merge his plugins into sc3-plugins.
As a user, the problem that I am facing with multiple plugins repositories it is because when you are remotely collaborating with instrumentalists that does not have strong computer skills it is really hard for them to install SC and plugins which are spread over many repos. Shipping a standalone would be the solution, but it is only available for MAC…
Another problem I often seen is begginers lost searching for features which have already been implemented as plugins, but are somehow hard to find because they are spread through multiple github repositories.
Yes - I agree. And I think the crux of the matter is finding a repo with plugins if high quality. My own have problems in my mind at this point … some are rad, some are “uh … I’m a better programmer now”.
I have some thoughts, but I won’t focus on them until 3.12 is out the door.
Not to be too discouraging about sc3-plug-ins, but that really is a repo that, while still useful, isn’t one that I would encourage further contribution to.
I fully agree with Josh here.
How to replace it has been on my mind for a bit, and I’m still not sure what the best way to grow external plugins should be.
IMO, the most natural solution would be to expand the Quark system to also support pre-built binaries, similar to Pd’s Deken package manager. But let’s save this discussion for another thread
