Cardinal (VCV Rack) plugin

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…

1 Like

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…

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).

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.git
  • cd 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 .lv2 variants under /bin into /zynthian/zynthian-plugins/lv2/ for the time being.
  • Starting the standalone bin/Cardinal starts 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?

3 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 :slight_smile:

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

4 Likes