Would it be possible to write a modular synth host (as an audio plug-in) where modules (also made with Juce) are offered as standalone dll’s that can be dragged into the host? I would like to enable an open architecture where anyone can add & share their own modules. Similar to what’s already out there, but simpler.
Is there a reason the modules couldn’t just be regular VST3/AU plugins?
If you really would want a custom plugin format for the modules, it’s certainly doable but you’d need to design the system very carefully. I would for example avoid what VCV Rack did with their module plugin format, where they are using a C++ ABI, I would instead choose to do a C ABI.
one problem with hosting VST and AU child plugins in a modular system is that they try to do ‘too much’ themselves. Do you really want your user to deal with 10 different preset management systems? or is it better to have a single layer of presets, that applies to all child plugins?
Also, you run into the problem of redistributing the patch, because users will inevitably make a patch that contains commercial, copy-protected child plugins. How do you share that with other people? (who might not own a license for the child plugins)
Also, how do you handle polyphony. If a user loads say a filter plugin to use polyphonically, are they going to have to deal with say 8 copies of the GUI being open?
You may want to investigate GMPI plugins, which integrate very smoothly with modular systems because they allow the DAW to manage the presets on behalf of the plugins, and they also support polyphonic parameters and instantiating multiple copies of a plugin while retaining only one (shared) instance of the GUI (that controls all the instances).
1 Like
At first glance, constructing a modular system may seem deceptively simple. From my experience, here are some things that can turn out to become massive challenges:
- Most of the performance comes from the efficiency of your routing/eval graph. At some point you’ll have to optimize on a very low level (compiler explorer is your friend)
- Complexity increases by orders of magnitude if you want to compensate module latency, especially if you not only want to delay audio, but also control events like MID, DAW transport sync, resets. Prepare for staring down sketches of routing graphs
- Complexity also increases if you allow cycles (feedback loops in your graph). Being able to do that got me into hardware modulars, so it’s nice to make this work.
- If you want to reap the benefits a modular system can offer, like audio rate modulation, normal plugin interfaces/designs are not great for that. Instead of processing rather large blocks, you may find yourself requiring to evaluate the graph per sample.
While I haven’t played with it, the AudioProcessorGraph that JUCE brings out of the box looks suitable for experimenting with the concept in general.
2 Likes
You’ve basically described VCVRack, which is open source by the way:
… and yes, VCVRacks modular plugin format is very much as you describe - simple shared objects which get managed (quite nicely I must say) by VCVRacks Plugin Library Manager - which directly accesses the Plugin marketplace that VCVRack has built for the purpose.
Meaning there is an extremely viable and flourishing open/free market for VCVRack module developers to promote their work.
Could do something like this for JUCE - or maybe someone simply wants to write a VCVRack Module Loader Class for JUCE … would be a nice challenge and of mutual benefit to both projects, imho…
VCV Rack is very cool, but they seem to have tied themselves to a particular C++ ABI (Binary Interface). This is not so portable, and is likely to become obsolete at some point in the future.
Most other plugin APIs use a ‘C’ interface, which is stable and portable across all C++ compilers, plus also compatible with upcoming languages like RUST.
This might have the disadvantage of locking you into one specific compiler and toolchain. i.e. it may be difficult to build a module with Microsoft C++, or many other laguages.