Sorry if this has already been posted but a quick search has yielded nothing.
The combination of mod-ui, mod-engine and the plugin repo is a quality product in of itself, reminiscent of things like Bias FX, and it can be used without any MOD hardware so long as you’re familiar with Linux audio. It is definitely something I would pay money for (I’m thinking a good fifty bucks) if it was officially supported on regular x86 or ARM Linux computers.
Please note that the experience will be quite not the same as with the official hardware.
There is a reason why we separate the plugins in the store with “beta” ones (previously labelled “unstable”).
We also build them in very specific ways (usually involves patching and removing UI).
It is tricky… we do a lot of care to make sure everything works well together.
When a project builds our stuff plus a bunch of plugins in a generic way, it can really give a bad image.
On the MOD units, we have no graphical toolkit or library running, and this is quite intentional.
The separation of DSP/Audio and UI (web browser) is purposefully made so that the browser does not run on the same system as the audio does.
Performance will also not be quite on par too, since we run all our audio code in the same process. (We use JACK internal clients instead of external ones)
For a “proper” MOD all-in-one software product, I would personally build all plugins using the mod-plugin-builder (so they match 1:1 what is inside the MOD plugin store) and then make the core components like JACK, mod-host and mod-ui running on top of a very barebones distribution like Alpine.
Getting the stack to run on top of existing systems is tricky, since it needs JACK and all that. It is not cross-platform anyway which is a killer…
Maybe inside some minimal VM? It only needs to expose an audio device and an HTTP port
From what I’ve seen, formats like AppImage and Flatpak also support process isolation or “sandboxing” which may fully or partially meet your security requirements and also give you some additional measure of control over the execution environment as you’re targeting a runtime instead of the bazillions of permutations that might inform a Linux system. For end users it’s also a drop-in product that only needs them to have a JACK server running, which in my opinion doesn’t require advanced technical chops (or at least not more than setting up ASIO4ALL on Windows).
I’m not 100% sure as I’ve never implemented one myself but I do believe clients communicate with JACK using unix sockets, so if the MOD engine can run as an external client then you don’t even need to think about audio devices, etc. You just need (limited) access to the host and also to expose a port for the UI.
Disclaimer : I am of course mostly talking out of my ass. Linux audio, as much as I love it, is not my area of expertise.
One situation where I could really see this as a useful approach would be a virtual pedalboard plugin for music production DAWs, something like the Carla rack/patchpay plugins that would host MOD plugins from the store. If you could sync that with your MOD pedalboard (i.e. all the connections and parameters), it would allow to create a live show setup with the exact same sounds as in the studio mix.
To take it one step further, you could automate the parameters through MIDI in a DAW and in a live show connect your MOD to the DAW to take all the automation parameters.
Well, that’s what AxeFx does for example
I like the open character of the current stack. Selling it as a product might imply that it’s getting more closed in the future.
I’d rather like to see the opposite: a community which contributes to the open core which can be used for in their DIY solutions. The professional hardware of MOD devices can be used by musicians who need an appliance for their performance and professional support.
Remember that open and free software can perfectly be sold. And that closed proprietary software can be distributed for free. Many companies or fundations (RedHat, Ubuntu, Firefox etc…) make money and pay professional developers by selling open source free (as in free speech) software (their added value is with the service, the packaging etc…).
Moreover, I think that in this discussion, the term “product” refers to a well packaged, stand alone piece of software rather than something you have to pay for to get. And in that sense, I would argue that it is already somewhat the case with the mod debian packages that are distributed by KXStudio. As @falkTX mentioned, it is not exactly similar to the experience you get within the MOD, but it is quite close. And we could perfectly have a community of developers helping enhancing it.
I would really like a packaged, contained, easy to install “mod sandbox” for my PC.
Let’s say a Snap or Docked package. I’d really like a way to experiment and test plugins and pedalboards when i can not / do not want to take the duo off.
If one had the ability to sync the pedalboards to / from the duo, then you could do most of the creation work on a PC only, which would be a big plus for me. I’m experimenting with MODEP and i really like it.
Performance would not be an issue, i don’t intend the PC mod software version to actually replace the duo.
I don’t know how the plugin structure and interfacing of MOD plugins works and if it’s similar to plain LV2, but I really like using your Carla patchbay plugin within Ardour, so something similar would be great.
Hypothetical workflow would be creating pedalboards on the MOD until I have the perfect sound, export them and use them inside Ardour/Reaper/… for producing songs while having the exact same sound (ignoring preamp/interface influence) on my MOD for playing on stage.
This would mean that all the plugins will have to be compiled for x86-64 oooor (long shot) somehow run on a qemu arm64 VM interfacing as a “virtual MOD” LV2/VST plugin with probably 10sec of latency
Compared to standalone app a DAW plugin would be much more flexible and still as useful, as long as it synchronizes with the MOD hardware; compare Line6 Helix for example (this doesn’t mean you’re supposed to copy them, but people do find their approach useful ;)).
Leave the Raspberry Pi support to the Pisound guys, unless you want to target even the tiny DIY-pro-linux-audio-on-ARM community.
What’s important to add to my 2 or 3 cents above is, remember on the desktop we have many more possibilities regarding the UI and I would love to be able to have more control over, for example, parametric EQ with a spectograph view, waveshaping, compression and even modular synths that I can easily modify on my computer screen without being limited to what rotating knobs and the MOD web UI can do!