Vst::kDistributable - remote processing

SDK for VST 3 audio plug-in and host development.
Post Reply
Posts: 2
Joined: Wed Nov 28, 2018 11:15 pm

Vst::kDistributable - remote processing

Post by jeroen » Thu Nov 29, 2018 5:02 pm


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.


Arne Scheffler
Posts: 254
Joined: Mon Jun 20, 2016 7:53 am

Re: Vst::kDistributable - remote processing

Post by Arne Scheffler » Fri Nov 30, 2018 8:48 am

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.


User avatar
Posts: 68
Joined: Sun Mar 11, 2018 5:57 pm
Location: Las Vegas, USA

Re: Vst::kDistributable - remote processing

Post by pongasoft » Fri Nov 30, 2018 2:08 pm

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...

Posts: 2
Joined: Wed Nov 28, 2018 11:15 pm

Re: Vst::kDistributable - remote processing

Post by jeroen » Fri Nov 30, 2018 3:12 pm

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.

Posts: 2
Joined: Tue Dec 11, 2018 10:19 am

Re: Vst::kDistributable - remote processing

Post by signalsmith » Thu Jan 10, 2019 4:12 pm

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.

Posts: 38
Joined: Tue Jun 21, 2016 12:43 pm

Re: Vst::kDistributable - remote processing

Post by abique » Fri Jan 11, 2019 10:01 am

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.

Post Reply