Plug-in capabilities and limits in general

Hello, everyone.
I’m starting to get along with JUCE, seeing how it’s supposed to work, and looking forward to making things.
Am I able to include just about anything a standalone program does in a plug-in? I see, for example, that IRCAM made a VST plug-in that simply routes parameter automation to OSC. What I’m especially interested in would be to load an instrument plug-in within an instrument plug-in. The goal would be to clone the normal plug-in internally and route data selectively to all or some of the clones, sum their output, and present the user with just one version of its GUI. All for the purpose of microtonal music. There are some plug-ins that allow very simple microtuning, I know, but I’d like to make any plug-in available to microtonal musicians.
I see that VST3 plug-ins can change numbers of inputs and outputs, and deactivate ones that are not needed, but I don’t just want to target VST3, so I think I will need to provide several versions with different numbers of inputs and outputs.
But, first of all, is it going to be possible to include the necessary hosting code within a plug-in and load other plug-ins in it? I’m just not very clear on what a plug-in can and can’t do aside from its interaction with the host. Is the sky indeed the limit (as it would seem to be if a VST plug-in can send to OSC)? Could one, for example, make a VST plug-in that… sends an email? runs Python? Could you actually write an OS in an audio plug-in? (For some reason, the VST SDK documentation doesn’t have an example of this.)

Thank you!

Yes that’s technically possible, there are various commercial plugins out there doing exactly this.

You can do a lot of stuff from within a plugin. Basically nothing stops you from implementing features in a plugin processor that could also be implemented in a standalone application (e.g. creating threads and starting child processes, using whatever IO resources your system has…). However, you should be aware that the plugin host manages the lifetime of your processor, it is perfectly possible that it will create an instance and destroy it quickly afterwards to check some features of the plugin, there was also a thread recently about Ableton Live creating two instances of the processor at the same time for a short moment if some settings are changed at runtime, etc… So this kind of behaviour could possibly conflict with some more sophisticated features.

Yes, you can do all those things within a plugin, nothing is enforced about what the plugins can do with their code with plugin formats like VST.(*) What you will be facing is the limits of what you can do with the host application. The plugin<->host interactions are pretty limited, and even more limited when doing plugins with Juce, as that has to support so many plugin formats.

(*) As a counter example, a plugin format that has strict limits on what the plugins can do is the Propellerhead Rack Extensions. Juce does not support doing those, though.

I was also wondering about that, but for this particular project, all I really want to do is to route messages between a host and several instances of a plug-in. Anything the host sends should be sent either to all plug-in instances or routed to individual ones; all audio created by the plugins should be summed and send to the host; and, along the way, I’d have to deal with switching processing on and off for individual plug-ins, creating and destroying instances, and such. I haven’t considered how to make presets work, but again, that’s obviously well-supported by all of the standards I intend to use, including JUCE.

Needing to know how many inputs, outputs and parameters are required before loading the plugin seems the most difficult part to get around.
NB I noticed how host<->plug-in interactions are limited, but also that plug-ins can have some level of autonomy, while trying to customize another microtonal trick, wherein some plug-ins can use a tuning table loaded from disk. None of the ones I found had exposed this feature to the host; all of them required using the mouse to open a file. The only way I could automate it was to rewrite the file in question on disk and activate/deactivate the track, which caused it to be reloaded. None of the plug-ins had an external parameter for that tuning table. But, then, I understand that my plug-in’s parameters could include the paths to plug-ins it loads and arrays of instances of them that would not be touched by the host.

Good to know!