Cardinal is an lv2 vcvrack host btw GitHub - DISTRHO/Cardinal: Virtual modular synthesizer plugin
2 Likes
This looks very interesting as a true open source fork of the commercial VCV Rack. There is a recent release announcement that included a comparison. The is also a Cardinal Mini version for MOD Devices pedal (dare I say Zynthian?) style devices.
The pre-compiled current release of Cardinal (22.03) depends on glibc 2.29. Zynthian based on Buster has glibc 2.28 so it won’t run. It may be possible to recompile against the earlier version of glibc but maybe (probably?) not in which case we may need to wait until we port Zynthian to Bullseye. I wonder how efficient it may be with the overhead of running a plugin within a plugin within a plugin… turtles all the way down!
[Edit] Got it running on my ChromeBook:
Screen refresh is a bit slow and I haven’t got audio running so can’t actually hear it! (Dummy audio driver in jackd.) Looks pretty cool.
[Edit] I moved this to a new topic as it seems like an interesting subject to discuss in its own right. I am compiling Cardinal on my Zynthian 4 from source. Let’s see if that works…
2 Likes
This would be extremely interesting if it could be patched to the ports/pins on a zynface.
1 Like
Yes - it would be excellent to add CV & Gate routing within Zynthian - maybe a future development.
My attempt to compile failed. The build system requires either ARMv7-A+NEON or ARMv8-A but Zynthian runs Debian Buster with kernel: Linux zynthian1 5.10.63-v7l+ #1496 SMP Wed Dec 1 15:58:56 GMT 2021 armv7l GNU/Linux, i.e. NEON disabled. There seem to be tangible benefits to migrating to Bullseye (and 64-bit whilst we are at it). This is not the first module that has failed to compile due to such constraints. Now where did I put that spare couple of months of effort…
1 Like
It is not, it’s a plugin. Based on Rack2 code.
What do you mean by that? Unless you use the Carla/Ildaeil Host modules there are no plugins involved. Cardinal is the only plugin in this story.
I mean that Cardinal is a LV2 plugin which had to be hosted, in our case by jalv.gtk. Cardinal then loads modules which one may consider plugins in that they are compiled elements written by disparate authors. I haven’t looked at the architecture so don’t know if it compiles all the modules into a single binary or loads then dynamically. If the former then there is an overhead of all that mostly unused code. If the later then it is acting as a plugin host
The modules are not plugins at all. VCV Rack uses them as plugins (separate .so files that are loaded dynamically), but in Cardinal they are compiled into the build directly (with LTO) and simply part of its runtime.
There is not much overhead other than a bit of extra disk-space and memory, but that’s quite insignificant. The main thing determining the overhead of a patch is which (and how many) modules are loaded and how they are connected.
However, Cardinal does include Carla/Ildaeil which is/are a modular plugin-host themselves. You would likely not use this inside Zynthian though (the headless MOD builds also disable Carla for obvious reasons).
1 Like
I’ve been poking around a bit with Cardinal on Zynthian. Got it to build and run (standalone and LV2), using the following:
git clone --recursive https://github.com/DISTRHO/Cardinal.gitcd Cardinal- Make using
export CFLAGS="-march=armv7-a -mfpu=neon"
export CXXFLAGS=$CFLAGS
time make HEADLESS=true WITH_LTO=false
- Using LTO makes the Raspberry Pi explode (oh, this is on RPi4)
- Drink coffee for a few hours
- Symlink the three
.lv2variants under/bininto/zynthian/zynthian-plugins/lv2/for the time being. - Starting the standalone
bin/Cardinalstarts up, and opens up UDP port 8222 (just like the “official” installation on MOD DUO does).
I see two ways to proceed from here:
A) Embed Cardinal as a “special layer” (the standalone) and code some custom direct loading of Cardinal/VcvRack scenes, including through UDP from the desktop (might require small tweaks to Cardinal desktop as well, but doable)
B) Stick to LV2 (the input controls show), and instead write a tool that embeds plain Cardinal/VcvRack scenes into proper LV2 presets, so we can use the existing preset management.
Thoughts?
4 Likes
Well, not much progress on the LV2 side. It turns out that when restoring an LV2 preset, Zynthian only sets the controller values, and not any custom state. But Cardinal stores its patch in a state:state entry in the LV2 preset.
I’ll create a ticket on Zynthian, so that part can be discussed there.
That’ll be jalv not setting state. I think the same happens with Helm.
Well, it seems that after all, the state IS loaded. I must’ve misread the output the first time. The modules of my patch are loaded, according to Cardinals stdout. There’s just no sound 
I’ll keep digging.
aaand success. Working sound! The problem is that the “Clocked” module wouldn’t start automatically. I’ve hooked it up in a different way, and now it works. Probably an edge case in Cardinal itself, or the Clocked module.
Triggering by MIDI works fine.
I’ll see it I can wrap this up into a recipe
6 Likes
I have been playing with Cardinal a bit and wonder whether we might progress this a bit? It would be good to create a deb package to allow simple installation without the need to compile from source. We would need to integrate with Zynthain (possibly as a special chain) and provide a mechanism to control it. We also need a method of editing the config. @jypma did the heavy lifting, figuring out how to compile and describing the end result but you didn’t say how the modules / patches could be edited. What is UDP port 8222 used for? I have seen that Cardinal supports some OSC control, e.g. setting parameters but that does not provide full configuration.
2 Likes
It would be really nice to be able to use zynface I/O with it too (even if it is just via midi)
I think I recall UDP port 8222 is used for the desktop version of Cardinal’s “Send to MOD” feature, that was being experimented with at the time. It would allow a patch being edited on a desktop to be sent to a different target. All of that is (was?) pretty hard-coded at the time, as far as IP and port goes.
A ticket is open to make that communication more flexible, but I’m not entirely sure what final solution falkTX has designed/is designing.
Baby steps… Let’s get it running first!
I saw a hard coded IP address for “remote” in the current source code so it looks like this hasn’t progressed. I am building on a Zynthian so maybe I might see it working later…
1 Like
Yeah, I think I actually patched my desktop Cardinal version to make it read the remote from an environment variable I think the way forward is probably less fancy, i.e. allow one to upload Cardinal-saved JSON patches into the Zynthian web UI (just like one would upload other presets).
I can’t get this to compile using your previous instructions. If you can get it to compile again, please update the instructions and I will take another look.
1 Like
With 4MS planning to release their new “Meta” VCV Rack-running module, this could be a huge ROI for the Zynthian since it can do so much more (and accessing the GUI via the web config seems like a much nicer UX than that tiny screen 4MS is using)! Has anyone made any advances in getting this up and running? I wish I could help but my Linux knowledge is basically “add sudo to stuff to see if it works” 