Vst::kDistributable - remote processing

Hello,

In the vst3sdk docs it is mentioned that the Vst::kDistributable flag allows for separation of processor and edit controller.
And also: “It can even run them on different computers”.
Another vst3sdk code comment, behind kDistributable: “Component can be run on remote computer”.

So i’m wondering if this VST3 feature is being applied like this in the field. Are there any hosts that allow a plugin to run the VST3 processor on another (slave) computer, while keeping the GUI on the master computer? (I couldn’t find any examples of this so far)
Or did I interpret these comments plain wrong?

If anyone has some more information about this, that would be great.

Thanks,
Jeroen

Hi Jeroen,
there’s currently no host I know of using this. I once (10 years ago) had a prototype on macOS working, but at that time all non Steinberg VST3 plugins were not able to do this (because they implemented IEditController and IAudioProcessor in the same object, or much worse communicated a pointer address to the other part and used that directly). But with the few plug-ins with a clean separation between controller and processor it worked.

Cheers,
Arne

Based on this, isn’t it fair to say that this feature should simply be deprecated? Clearly nobody has implemented it (on the host side) and I am not really expecting it to be implemented: I fail to see the use case frankly.

Related to this, the communication between the UI and the RT via the Messaging system is certainly very clean (for decoupling purposes) and is clearly a requirement for the “remote processing” to be able to work. But if “remote processing” is not being used, having to use the Messaging system is overkill. If you think about it, what you do when you communicate is serialize/deserialize the data (via the IStreamer interface) which is very heavy and requires memory allocation and data conversion when in fact you could just be exchanging memory pointers…

Thanks to shed some light on this!

The use case i had in mind was offloading of processing to another computer. A common complaint i see is that mix engineers/producers run out of cpu resources when they run plugin-heavy sessions. There are some options out there that let you run vst’s on different devices, but that is still an additional layer of software. So when i saw this flag i got curious whether this could be a solution.
Of course, if no hosts support this, then it won’t fly. A chicken/egg problem, i guess.

Keeping the general idea of separating UI and processing completely does seem right. For example, with the recent announcement of SOUL, it could become more common to run processing elsewhere. But there again the same goes: sufficient market adoption will be needed.

I’ve seen enough people excited about REAPER’s ReaMote tool (similar goals) that I think there’s a market for it, when a host does implement it properly.

I also hope that at some point, this will work well with the ELK support which was announced a few months ago. Being able to (for example) control a VST running inside a guitar pedal, using a GUI on your computer sounds pretty neat to me.

I think it can be interesting to load the UI in a different process, that would isolate some bugs and also smaller code size in the audio engine.

This is very cool feature - separate controller from host. We at Screenberry implemented it fully, because our media server is always controlled by remote panel, it does not have any keyboard/mouse connected and no service video output for user.
And we meet some problems: no plugins support this. I’ve found only one major plugins suite that fully utilize Messages and its IControl works perfectly with IProcessor, even from different OS and CPU arch.
For the rest of plugins, we use getState/setState for communication, triggered by parameters changes. It is less responsive, and, if called frequently caused some plugins to crash. Also, there are no feedback from processor, like volume meters.
So, I think that this feature must not be deprecated, and more plugins developer should implement it, because using of plugins in live media servers, or cluster systems is difficult without it.

3 Likes