Controlling multiple channels through single window of plugin

Hi, I am looking to start developing a plugin that should do the following (in which way this will be accomplished exactly doesn’t matter I need advice on is it even possible to do in JUCE first :smiley: ):

  1. Assign a plugin to channel/s
  2. When opening any plugin window from channels applied on I should be able to control panning and some other stuff for every channel where the plugin is applied (either on every channels plugin window or on a single master window where I will see all the channels the plugin is applied on)

It should look something like this if I will have a master window + one window for every channel where the plugin is applied: Whats-App-Image-2022-02-10-at-2-15-19-PM — ImgBB

Or something like this if there is no master window; For opening a plugin on each channel where it is applied I can as well control (panning for example) for all the channels it is applied on

If I confused you perhaps, one example of similar plugin is HOFA 4U+ blind test, I am attaching a video as well: Plugin example JUCE Forum on Vimeo

So the main question is architecture wise here, is something like this doable in Projucer?

Thank you and please let me know if someone needs further explanations.

Independently from JUCE it is a can of worms, but doable. You will need a plugin in each track you want to control which is then remote controlled from the master plugin. The plugin API doesn’t help you as all plugin instances are independent.
You need to establish some kind of communication, either through static variables, which doesn’t work moving forward because hosts start moving every plugin into it’s own process.
An alternative is IPP - InterProcessCommunication. JUCE has even a class for that, and I used it for a very similar plugin to yours.

The main problem is, that this communication is not synchronised with the audio thread, so it will only work in realtime, not in an offline bounce, and might have a jitter of one or two processBlock() calls, as you cannot know in which order the plugins are processed.

TL;DR: something along those lines is possible, if it satisfies your needs though is unclear.

I’m not so sure how much of an issue this is as I (also) thought it was. For instance, the default mode in Bitwig is all plugins in one process (separate to the application). I’m aware that Reaper can also run plugins in a separate process, but again I don’t think this is default behaviour.

I would start with a SharedResourcePointer or statics and then consider the IPC approach only if it becomes an actual problem.

The new Logic makes it a problem now, as it is now default and I am not aware that it can be turned off.
It appeared at the same time when Big Sur / Silicon came out, but I couldn’t find a reference which exact logic version this was.

But I agree to start simple.

1 Like

Ah OK that puts a spanner in the works then! I’m working on something similar and was under the impression that I might not need IPC… Thanks for clarifying.

@jimc this might be of interest

1 Like

Is Logic actually loading the same plugin DLL into a separate process?

I might be wrong, but last time I tested most hosts only spawn a separate process if it’s a whole new plugin that isn’t in the session already, and not a new instance of an existing one.

1 Like

Thanks @eyalamir I will check this out, sounds promising. If this is the case it would still be an issue if you have separate “master” and “client” plugins but fine if all plugins are the same.