VST Processor / Editor on different machines

General JUCE discussion
1

Hello everyone!

I’m trying to do something a bit insane, but I’m curious if it is possible:

I have a JUCE app that acts as a plugin host for VST3 plugins.
I have a second JUCE app that acts as the GUI / control for this app.
I now want to be able to control my hosted vst plugins from this second app (that runs on a different machine, using the plugins native editor GUI).

I know in theory the VST3 protocol might allow something like this, but in practice no one really cares for this special case (as far as I can tell).

I tried different solutions with NSViews, getting the native window, trying to createComponentSnapshot() etc. but so far everything without success.

My main problem is, that the plugins create separate native windows, that I don’t really get access too in my JUCE app (trying getPeer(), getNativeHandle() etc.).
I also tried using OS specific capturing of windows etc, but also not much success on that front so far.

So long story short:
Does anyone have an idea on how to approach this without going insane, what might be a feasible solution or should I drop this idea? :slight_smile:

Thanks in advance

2

Use MIDI? A virtual MIDI connection can be built up between the two applications, or you could use MIDI over networking if they are on different hosts.

3

Or maybe you can use OSC? Haven’t used it myself but sounds suited to what you want to do. Not sure how outdated it is, but there’s this tutorial: JUCE: Tutorial: Implement the OSC protocol in your app

4

Thanks for your quick replies!

Maybe I made my point not clear, I want to have the Plugin Editor (so for example if I want to use FabFilter Pro-Q3 I want THAT sweet interface on my gui machine - preferably without the need to have the plugin installed on there even) and use that native plugin interface to control the processor on the other machine.

So the problem is maybe less about sending control messages to the processor, but rather how to get the GUI on my 2. machine (for example an iPad).

I tried to capture that plugin window and stream the images to the 2. machine, but without success (Can’t get the native handle on that window on MacOS 15, every image is just blank).

For now I think i checked most solutions and came to the conclusion that (atleast on MacOS with all the security stuff) its not really feasible or worth the hustle - hopefully someone will prove me wrong!)

Thanks again for the quick help though :slight_smile:

5

Have you seen any existing product that achieves that? If there are none, that’s typically an indication a thing is not possible or not worth bothering with.

6

Haha yeah that’s a good point.

I think on windows it could be possible maybe to build a hacky solution (much easier there to capture Native windows) but still, I think you are sadly right…

Maybe in the future!

7

Have you seen AudioGridder? It might be relevant to you:

8

I think what you are asking for has been tried a handful of times, the most recent attempt I’m aware of (and they seem to be doing a pretty good job) is from Fourier Audio, they did an ADC talk about it in 2023 https://www.youtube.com/watch?v=kn4aPKgHHIM

2 Likes
9

Cool thanks, will check that out ! :slight_smile:

PS: Interesting, from what I can tell they went pretty much the same route as me. Snapshotting the plugin window and sending the images to the client and injecting mouse events back - but all under Windows (Did these things before on a Windows aswell, there it felt quite easy to grab HWND contexts, inject mouse events etc. but On MacOS I fail so far, my guess was the much higher security restrictions).
Thanks for sharing, interesting company!

10

I would have thought ScreenCaptureKit would be worth looking into on macOS. We had to migrate to this in JUCE to do screenshots of a native window for JUCE 8, so you can look for an example there but I think you can capture a stream rather than individual screenshots. I recall there are quite a few WWDC videos on the subject.

2 Likes
11

What you are doing is not insane. It’s a perfectly value use case that several plugin formats support.

VST3 is one that supports running the editor “out of process”. It does this by separating the plugin into 3 main parts (Editor, Controller, Processor) and provides a messaging mechanism so that the Processor can be abstracted away to run in a different address-space than the other parts.

… but VST3 also supports a backward-compatible mode called “Single Component Effect” which lumps both the Controller and Processor parts of the plugin into a single class (like VST2 did). In this mode it’s difficult to tease apart the bits that need to run in different address spaces. This is the mode that JUCE uses at this time.

We do not know when it will be safe to run our JUCE Processors in a separate address space. We only know that day is not today.

3 Likes