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