The mod software stack should be a product

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 :smiley:

2 Likes

A VM could be a nice idea.

1 Like

O like the Line 6 Helix Native?
Mmmmmmmm… maybe

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.

Big question, just hypothesizing…

which one is better:

  • generic PC application (standalone executable)
  • generic arm/arm64 device support (so MOD OS can be installed on arm boards)
  • LV2/VST plugin

Ideally, a MOD virtual machine. I don’t know how well ARM emulators work on PCs though

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 :smiley:

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!

Any that can make pedalboard exchanging with a real mod device possible.

Other than that, i’d say, the easier to install, the better. It should be something that requires no compilation and minimal configuration.

If targeted to linux users, adding a repository to your package manager or installing a Snap should be within grasp of most people.

But a VST plugin could open the mod world to many more musicians, be they Linux, Windows or apple users, and be a great marketing return for mod.

1 Like

I see your point … It could be easily that all are called for.
Yet, the last one is what I’d like to have most; a VST wrapped version of MOD OS. This of course means x86 builds of everything, which could very well payoff in a number of ways.

Meanwhile, the ARM builds are for granted right now. Albeit non-generic–which is fine, as there’s nothing I’d rather want in place of the MOD devices in terms of ARM.

That said, a standalone PC application I don’t see much value in. Someone already mentioned Carla which could easily act as such for standalone purposes.

What I really need though, is a VST version of MOD OS, so I can use my DUO presets in a DAW, for recording purposes. I’d buy that for sure, no doubt.
Also, the development of such a thing now could be very timely, as it’s obvious what troubles for hardware are now present with the situation in China.

I don’t see the value of a MOD LV2/VST plugin. The market is big and already saturated with all kind of plugins which are better than the ones in the MOD ecosystem.

I’m also not sure about the value of a standalone PC application. When I look at VCV rack I see that there’s a very high demand of a plugin version. AFAIK the VCV guys were against a plugin version for a long time but they changed their mind. But again, VCV rack provides a unique feature while MOD is basically just a audio routing system with a lot of plugins.

On the other side, it might be good for the growth of the MOD ecosystem to provide an easy way for plugin developers to test their software without actually owning a MOD device.

That said, I see the most chances in MOD OS for embedded systems. This is an actual market gap which is likely to be filled by MOD devices.

I have done this and the stack now runs chroot-ed to the amd64 build target in a Ubuntu 18.04.4 VM. :slight_smile:
The build was done with a lot of time, changes and lucky guessing.
I only did basic testing because of latency problems. Redirected USB Midi input and sound output works.

The fasted jack settings I can get is -p 1024 -n 4. The output signal goes like this: (VM: jack -> virtual_sound_card) -> (Host -> PulseAudioJackSink -> Jack -> usb_sound_device). This adds more latency and makes it a real problem. :worried:
I tried to redirect the USB sound device to the VM: While I can start jackd with hw:USB in the VM, it does not work in the chroot (Unknown driver “hw:USB”).
I have also tried using jack over the network with “jackd -R -d net” inside the chroot, but only got some high pitched noise on the host.
Are there any ideas how to get sound with low latency from inside the chroot, inside the VM?

Another possibility could be to build the plugins statically and then use them on the host. But I don’t know if this would work and which setting in the build env have to be changed.

You cannot use VM audio, that is always going to be killer in terms of latency.

I think one possible solution is to register a USB Audio device as gadget inside the linux VM.
The tricky part is exposing this virtual USB device to the host.
But something like https://blog.elastocloud.org/2016/06/linux-usb-gadget-application-testing.html could work…

Maybe a docker image could work? On linux we have a loopback ALSA device, which can be exposed to docker internals so it can run audio.

The amount of changes needed to make this work makes it very impractical.
Not to mention commercial plugins would then just be impossible.

I currently opt for netjack.
Screenshot would be here, but I get: “Sorry, you can’t put images in a post”

The chroot image runs now on the host and latency seems ok.
Looks like a docker image could get real.

Screenshots of saved pedalboard do not work. I’m using a bunch of variables inside the image, but I don’t know their meaning and correct setting:
export MOD_DEV_ENVIRONMENT=0
export MOD_LIVE_ISO=0
export MOD_APP=1
export MOD_DEVICE_WEBSERVER_PORT=8080
export MOD_LOG=1
export MOD_SYSTEM_OUTPUT=1
export MOD_SCREENSHOT_JS=/usr/share/mod/screenshot.js
export LV2_PEDALBOARDS_DIR=/root/.pedalboards

What do I have to set?

Another thing I would like to do is to rename the browser window to make it clear it’s not the official version from MOD. Something like “MOD - MODED unofficial MOD Emulator Desktop”.

env looks ok, but MOD_APP=1 is not needed, should be 0
MOD_SCREENSHOT_JS is no longer used

Not being able to save screenshots might be missing python dependencies.
Try this inside the chroot, which will manually run a pedalboard screenshot:

python3 -m modtools.pedalboard take_screenshot /root/.pedalboards/default.pedalboard/ /usr/share/mod/html/ /root/data/.cache/

True.
Caused by referencing and older mod-ui version in mod-plugin-builder.
Fixed.

MOD_APP=0 makes “banks” visible, but also results in 100% CPU usage.

I’d really like to build the software stack as a yocto layer, I’d be happy to get involved with that project if it meant there was a chance of Yocto being the main build system for mod devices.

Out of interest have you looked at replacing Jack with pipewire? It should be a drop in replacement. If more mainline linux distros look at using pipewire to replace pulseaudio and jack then it should be easier to port the mod software stack I guess?

In my case a x64 image that can be used on a Linux PC.

Something like this (here running in a chroot):

That would be great! :wink: