Creating a host platform to run and arrange the order of multiple VSTs/EXEs?

Hi, I’m very new to JUCE and programming in general so please bare with me.

As part of my project, I’m looking for a way to host multiple FX plugins (maybe like 10-20) on a microcontroller (I haven’t decided which one) where the user can decide the order of the plugins and choose which plugins are enabled/disabled. (This is basically a digital pedal board for guitarists).

So is there like a C++ plugin host or something I can make so that the microcontroller can load up the plugins?

Also which format is easier to work with in this case, VSTs or EXEs? I’m guessing the code will be something like:

// Check which plugins enabled and their order (Distortion, Compression, Reverb) 
// Run clean signal through Distortion
// Run distorted signal through Compression
// Run compressed signal through Reverb
// Output reverbed signal

Any help/suggestions/ideas are much appreciated!

I am not exactly sure what you are planning to do…I get the impression that you would be loading 3rd party plugins on the microcontroller? Those plugins would of course have to already exist for the platform, you couldn’t run any Windows or even Linux binary directly on some completely different architecture.

However, if I got that wrong and you are doing your DSPs yourself, I am not sure if a separate plugin system would really even be needed. You could just have your DSPs as part of the main program running on the microcontroller. (You could optionally have a plugin system to allow 3rd parties to develop for your device or to keep your own code cleaner.)

Okay, as you say that you are new to programming, I guess that you might not be aware of the fact, that a software application or plugin is always compiled specific to the processor architecture and operating system it runs on. This means that e.g.

  • A VST3 Plugin compiled for x86-64 CPU Architecture for Mac OS won’t run on a target machine with x86-64 CPU and Windows (even if both share the same CPU architecture)
  • A standalone .exe application compiled for x86-64 Architecture for Windows won’t run on Windows executed on an ARM CPU (even if both share the same operating system)

So your problem is: A typical microprocessor environment, suited for this use case is a multicore 64 Bit ARM as you find it e.g. on a Raspberry Pi running a Linux operating system. The major number of third party plugins out there are compiled for Windows or Mac OS running on x86-64 CPUs. So in order to get third party plugins working, your only realistic choice is to chose an x86 Intel or AMD CPU that runs a striped down windows.

Things look totally different if you want to create the effect plugins for your system yourself. Then something like Elk that allows you to deploy JUCE-based audio processors directly to a highly optimised ARM/Linux environment – as far as I have heard – might help you.

This doesn’t answer your question directly but may still be useful – unless you’re really looking for an excuse to solve this challenge by hand, you should look at existing systems like the Elk audio OS or Bela that address the underlying hardware part of things and let you focus on the audio part.

e.g. this dev kit is cheap and readily available: https://elk.audio/dev-kit/

“I get the impression that you would be loading 3rd party plugins on the microcontroller?”
Yes I was planning on doing that because I think that’s the simplest option but could be wrong. The main goal is to create an amplifier which has a digital component for modular effects and could be interfaced with the touchscreen (change plugin order, change plugin parameters, etc.)

“Those plugins would of course have to already exist for the platform, you couldn’t run any Windows or even Linux binary directly on some completely different architecture.”
Oh yea I completely forgot about that :frowning: I don’t suppose it’s possible to run Windows on the microcontroller and run the VSTs on it efficiently? (without too much latency for live performance).

A plain “microcontroller” isn’t going to cut it. You’d need a full single board x86-CPU based computer solution that can run Windows (or at least WINE for Linux), to get access to the existing 3rd party Windows VST plugins. (There is apparently a version of Windows that runs on ARM CPUs, but you couldn’t run existing 3rd party VST plugins on that.)

Oh yea I wasn’t really aware of that. Thanks!

Yes I do want to create the plugins myself but as an optional extra, I’d like third party VSTs to also work.

Elk seems the perfect solution for me right now (low latency, easy integration with JUCE). But the Elk Pi Hat would be a big blow to my budget. Is it possible to just use the Elk OS on the Raspberry Pi without buying the Pi Hat?

If you’re using a Pi then you could just run the Tracktion engine on it and let it take care of all the housekeeping. The Pi is powerful enough to run the full-blown Waveform with a GUI so just firing one up as a headless tracktion engine board should work fine.

Thanks for that! It seems perfect for me (low latency, works well with JUCE and VSTs). But the Elk Pi Hat would be a big blow to my budget. Is it possible to just use the Elk OS on the Raspberry Pi without buying the Pi Hat?

TBH, I’m not sure. I’ve put off snagging a dev kit myself until I have time to actually use it (looking across my office to a different SBC dev kit that’s been gathering dust for a long time…)

First of all: I never used Elk myself – however I’m sure it works without their hat which basically just gives you I/O and especially some good DACs/ADCs which you’ll need in any case. Designing such a circuit yourself will be an electrical engineering challenge on its own – I don’t know how your skills in this field are. There also might be other cheaper I/O solutions for the PI.

I’m not really sure if I gout you right, on the one hand you say you’d like third party VSTs (which are for the reasons described above neither compatible with ARM CPUs nor with a Linux based OS) and then you say that Elk (a Linux flavour) running on a Raspberry Pi (which is powered by an ARM CPU) is the perfect solution for you? So before we dig deeper, what’s your plan: Making third party VSTs run OR targeting a lightweight ARM-based platform with your own plugins or maybe some open source community driven non-VST plugins?

Ah yes sorry for the confusion!

Using third party VSTs is more of a bonus requirement so I can live without that as long as I can use my own (VST) plugins.

Although I’m a bit confused. I thought VSTs would still work on the Elk OS. Isn’t that one of it’s big selling points? I thought it’s also easily integrated with JUCE somehow which is nice because I’m creating the plugins using JUCE.

Plugins that can be compiled from source code may work on it. But this of course wouldn’t be the case with 3rd party commercial developers like Waves, Native Instruments etc.

In addition to what Xenakios already said, if you are a plugin developer, then you can easily deploy your existing VSTs to Elk – this is indeed a big selling point if you plan to convert the plugins you sell into some kind of hardware device.