Thank you for coming here.
This is a presentation about Cardinal, the HIFT-3 and some tips and tricks as well.
My name is Philip, also known online as Falk DX.
I'm Alexander, also known as Dreamer.
We already got a nice demo of Cardinal just now, so that saves us some time.
Yes, is it working the remote?
Of course it isn't.
We've connected with, anyway, with the old way.
I think it works.
Yeah, yeah.
So I work at back last electronics, a finished company with a little pedal, Linux based.
I maintain DPS, I maintain Carla, Jack, a couple of other things.
Yeah, typically I'm Linux audio.
Most of the things I do have related to Linux audio and open source.
Yeah.
I work at Wased Audio, which my own company and currently I'm mailing developing the heavy compiler,
which is a pure data to see transpiler.
And I also contribute to plug data, which really nice, sort of enhanced PD version.
So before we start, we have to talk about VZV rack, which is sort of our upstream.
As you can see, you have physical modular synths, which have been around since about the 50s or something.
And in 2016, Andrew Belt released the first version of VZV rack, which is a virtual modular synthesis system.
Initially, the 0.6 branch started as a BC3 project.
And it quickly gathered a really nice size community and developers.
And it was sort of open for people to create plugins and extend the software with their own modules.
Unfortunately, because of the BC3 license, closed proprietary commercial forks started to appear,
which developers did not really appreciate.
So when the VZV rack version 1 appeared, it was released into GPL3.
And it was not open to contribution.
And we can only assume that some of this was because of legal issues for their future plans,
which is that I think was 2021, VZV 2 launched and with their rack pro as a proprietary plugin version.
Users had been requesting a plugin version for a long time.
And there were sort of some hacks to get it working as a plugin.
But they restricted the program to make it functional as a such.
But they made their pro version, closed source.
And of course, we really wanted to see an open source version of the plugin.
So later we published Cardano as an alternative to the pro.
Yeah, so I don't know.
Okay, so basically Cardano started when we knew that the pro version, the plugin version of BCB rack was coming.
We suspect for developers to be able to port their plugins early.
The source code was launched a few months before the official public release was out.
And we took that as an opportunity to just run some tests.
If we can actually run this code that was supposed to be for the standalone version that still was open source.
See if we can put it in the plugin, see how well it works, what kind of problems emerge.
And yeah, got it working fairly quickly.
Not using the same frameworks, same tools that the official plugin does.
We also didn't know about it at the time because the plugin version is never open.
So I did it on my own framework on DPS, I had just a couple of things.
It was a very nice test case to like extend DPS to support other things that a bigger plugin would need.
In a couple of months everything like we got our first release after the official rack probably.
Intentionally I even slowed down a little bit on the release because I was collecting modules to ship within the plugin.
We saw a lot of small little things that would not go well if we want to distribute the source code to be packaged by distributions.
One example that we give there regarding licenses that we have to track like some developers that push to the BCB rack platform.
They don't care where they files come from. There are some funds that we ask like where did you get this?
They just say I just found it online, whatever.
Or they copied it from their Windows machine or something like that.
Which license states that is not visible.
So we had to ask them to change and a bunch of other stuff.
If you read this document, you're going to see it's quite extensive that we try to cover.
And also because we buy it into single static binary.
All of the licenses have to be compatible.
It's one of the reasons. We don't mention in here.
But one of the reasons we keep the project as GPL 3 or later as a requirement.
Because if at some point we have GPL 4, we want to be able to have the option to upgrade to it.
If we only have GPL 3 only, there's a couple of modules that are like this.
And then we get stuck forever.
About the name, it came as a little joke.
Like Robin X42 from the Linux all the community.
And the idea based on the multi-pitan sketch that the guy just says Cardinal, the rack.
And it just became the name of the program.
And they use it as a torture device which also modular synthesis can be very useful for that.
Yeah, yeah, yeah.
So what is Cardinal?
It is a modular urx software emulator based on vis-vrack.
It can load modules, it can connect cables, you can excount.
Right now, it's a latest release that we did yesterday.
It contains almost 1,400 modules from 84 different vendors.
It's free and open source.
It's available as pretty much all of the plugin formats.
And soon it also have a shared library so you can integrate it into other software.
And there is some standalone, which you also saw on the previous demo,
which are kind of more for testing.
They're not as featureful as you would expect from standalone.
And there is a web version because we have a web assembly built
so you can run it in the browser.
It's cost platform.
We have built for people using it for freebies, the Linux, MacOS, and Windows.
And it's multi-architecture.
So we have 32 bits, Intel, 64 bits, ARM, 32 bits, 64 bits.
And we have risk-5 builds.
We don't have any risk-5 boards, so we don't know if it actually works.
So if anyone is willing to test this or give us a board to test,
this of course appreciated.
Yeah.
Now I'm going to begin to do the technical details of this,
because people always compare it against the rack pro,
the proprietary version of from vis-vrack.
So I'm going to list the main differences,
but also explain the project a bit in the meantime.
So the biggest biggest difference is that it's completely fully self-contained.
So the plugin does not load external modules.
The official rack version is based on standalone,
where there's a marketplace of plugins you log in.
You can install stuff from there.
Some are free, some are proprietary, some are open,
or not.
We baked everything into a single program.
The binary gets quite large, yes.
But if you install the plugin, you have it ready to go.
You don't have to go fetch like other modules,
and all this nonsense.
Just have it running, ready to go.
It helps a lot in building.
We're going to show the web version soon,
where we don't have to build things one by one,
if everything is separate, some projects try to like,
if you want to have rack the official version for like a Raspberry Pi,
for example, you have to build everything from scratch,
one by one, every single module,
because the official rack does not support arm on Linux.
So you have to build it yourself,
but managing building all these things, it's a whole mess.
With Cardinal, you just build it in one go,
that's what we do for the web version as well, everything is there.
We build failures, we know right away.
This also means the projects are portable.
If you make a patch, you share with someone else,
they don't have to go on the store,
and you know, fetch the actual plugin they're missing,
it just works.
Like, completely look like.
With some limitations, like if you're loading sample files,
or we also have some plugin hosting that's bit more tricky,
but it's standard patch it should work.
Yeah.
If you don't load external files, then the project's are compatible.
The other big change, because we want to run as a plugin,
we want to integrate nicely in the host,
is that it's single threaded audio processing.
In the official rack, there's ways to multi-trad the processing of the audio,
which we didn't like so much to do,
that's a lot of complications,
and because the focus is to run as a plugin,
if you put it, for example, in Ardor,
each track gets its own instance,
and you can do the multi-tradting for you.
Every instance gets its own audio thread.
So we don't have to worry so much for this as a plugin.
Yeah.
The things also run in order,
but it's not something I can do.
It's a little level.
Yeah.
One big change is also the host modules
that we have there that do the integration.
There run as always on the start of the audio chain,
or at the end of the audio chain,
to minimize jitter,
so that if you have like a MIDI controller or something,
the MIDI controller runs before it gets the same,
the signals being sent to anything else,
which is nice not the case for the official rack,
the MIDI modules run randomly.
So we try to improve this a little bit.
Something that's not everyone likes,
but we did it this way,
if that UI is tied to the host event loop,
if the host decides to run your idle cycle
of the plugin at 15 FPS,
your UI runs at 15 FPS.
That's it.
Which, yeah.
I know it's not the best,
but comparatively to what I see,
some plugins doing,
where they try to draw as fast as possible,
the plugin can make the host go sluggish,
because it's really trying to replace things to fast.
If we are nice to the host,
I develop my own host,
I know that it's a pain to deal with this.
I want to be nice to the host.
Wherever the host can provide,
we apply it and that's it.
And we run the dialogs as asynchronous,
so it doesn't block the main thread,
but it only to know just,
if you open a dialog,
it's not going to blank out the entire host,
it's going to keep running fine.
It's just a small difference when you're never,
you open dialogs that you're going to see.
Which means you have to patch some of the other modules
and send them upstream,
so that they can differentiate their builds
between VCVRack and for Cardinal,
because VCV has this synchronous dialogs,
which block the UI thread, which can be a bit ugly.
Yeah.
So we have a bunch of custom host integration modules,
because the regular VCVRack integration works completely differently.
So when you want to use Cardinal,
you should particularly pay attention to these modules,
so we see the stereo host audio,
the dark sockets are basically outputs,
and the light sockets are inputs,
or depends on how you look at it,
but if you want to send audio to the host,
you put it into the dark sockets,
and if you want to take audio from,
let's say, it's an audio effect,
you take it from the light sockets.
Then there's the standard stereo,
we have 8 audio,
and there's also 10 CVIO,
that will show later.
We take this distinction between audio and CV,
because there's some nice tricks in Jack and OV2
that you can use to differentiate between the two.
Then there's host parameters,
so these are 24 parameters that are accessible to the host,
for automation or for control,
and then you can also map these parameters to specific knobs
inside of the patch.
The host time audio is really nice,
so when you're playing the timeline of your DAW,
you can synchronize that with the plugin,
so you can get all this time information,
or whether or not the host is playing.
We recently added the last one,
which is a BPM sync.
There's some module support this,
where it uses sort of a vaults per...
No, it's not a vault per BPM,
but there's sort of a standard that they developed
for synchronizing plugins with sort of a voltage range.
Then of course there's MIDI,
so you can both receive and send MIDI,
with multiple channels.
You can map those to different parameters as well,
and there's this sort of gate, host MIDI gate,
which is quite handy for controlling drum machines or things like that.
Then there's a bunch of other plugins,
which modules for hosting other plugins,
which is a vendor version of the Carla plugin host.
So the top two modules you see here,
the left one is LDO, which is sort of a one-to-one plugin.
It can host one single plugin,
and then there's the full Carla plugin switch.
If you click on the right module,
it will actually open the full Carla UI.
You can have a full Carla patch bay
and run a whole rack of plugins if you want.
And then there's these extension modules you can see on the side.
So when you connect this extended module,
you can either send MIDI, convert CV into MIDI signals
for the plugin or receive MIDI signals from a MIDI generator plugin
and convert those to control voltage
and run those inside of your patch.
Then there's some nice convenience modules,
like an audio file player, an audio to CV pitch tracker.
So you can, if you have an audio signal
that you want to convert to a pitching gate,
and then we can also load IdaX neural models.
So that's some nice additions.
Then let's see if I can demo Jack and LV2 CV ports.
It's a video, but I'll see if I can get this down to that.
So this is a very basic plugin that I created on the right,
in UC Carla hosting this plugin.
And then there's a Cardinal standalone.
And you can clearly see the difference between the audio ports
and the CV ports.
So we have a sequencer running inside of Cardinal,
but it's sending CV signals.
And you can have these CV plugins that respond to that.
So this one is receiving pitch and gate.
And very basic demo.
But I think it's through the points.
Then we can also do advanced.
Yeah. The next name is the OEC remote control.
Like the previous talk we're watching,
that we can have, like,
system-wide, we can enable something in the engine menu
to receive OEC messages.
There's the protocol specified on the website,
so that you can control individual modules.
So you change the parameter in the visual module.
Or you can use, like, maybe on the next slide.
Just to show.
I can present.
Like, you can, in this case, we're showing off using touch OEC.
It's not an open source application, but it's just to demonstrate that.
You send some knob value and remotely over the network,
the host, CV, then just to receive the value,
and then you can send it to whatever signal you want to control.
Can you click?
Yeah.
This allows not just to control the parameters,
but also send the entire patch.
And then this, the example,
hard to exactly see.
But you can have a,
carve-in-all being a client,
one being the server.
And it's only one way.
It's not by directional communication,
because React didn't support this from the beginning.
So we're shooting in the future in a certain way.
But you can have things in sync.
So you have one instance that's,
you know, it's playing the audio and another instance
that is sending whatever patch you're working on to it,
and things that are being kept in sync.
There's some little caveats,
but if you'd run into issues,
there's like F7 key that stems the full patch again,
and then it receives.
Which is very useful for the embedded case.
Imagine you have a device that you want to run car in a loan.
The device might not be very powerful.
So we can have embedded builds that's three-pout
audio GUI components.
So it only does the audio part.
And then you connect with a real car in a,
and you send the actual patch over.
And this way you can have like a laptop or something
that has more power doing all the things.
And embedded device you prepare a patch,
you check the performance and all these other things,
and you can have a remote device being like a car in a loan.
That's being like a car in a patch player, in a way.
Which is neat.
Also, that we did because we have car in a running on the web browser.
This might be a bit tricky to explain,
but on my previous job, in something I still maintain,
we have a web GUI that's kind of like a pedal board,
that you can have little pedals and you connect cables
and all these things.
Some people here might know it.
We kind of have car in a running as a plugin
inside this platform.
Basically, all these little blocks pedals
are like visual representations of the DSP.
But because we have car in on this, working on the web browser
and because we have this remote communication,
we can load the full car in all UI on this platform.
And whenever you make some changes,
it sends over the full patch to the remote instance
to the device that is running at the embedded device.
And that allows to have the full plugin running
on the platform like this.
In better device, that allows communication
over like a web portal.
And you can run the full.
It's just one example.
Things that are possible to do.
One cool thing that not many people know about.
So two things we got in the web version.
You can use the patch URL parameter
and then just in there, you just post whatever
file you have a car in all patch.
So imagine you create a nice patch.
It needs to be like in JSON format.
You need to unpack the file.
But it's possible to, for example, get to a paste pin.
Paste there your patch file.
Save it.
Get to raw URL.
So you can have the raw file and patches of the parameter
to the web version.
And whenever you give, for example, to someone.
Like check out my patch.
They load the thing and it will also pass.
Which is quite neat.
And we also have the mini version because it loads faster.
Yeah.
On the website, if you go to carinal.kx.studio,
the second little button there, the trial life,
basically runs the entire thing in the browser.
And the browser catches it.
So this is now a lot faster.
But this is basically a full version of,
oh, this is a mini car now we call it.
So it has less modules.
But this is now running as web assembly in the browser.
Yeah.
Which is, can be quite useful for, like,
I'm seeing some people that want to demonstrate and to have
use carinal as a teaching tool for some synthesis.
You just, like, open this web page.
There's a scope in there as well.
That it can investigate whatever the sound waves are doing.
It's very nice for control controlling of how to make a sound.
Yeah.
Okay.
So how can you help?
We could use more demo patches.
So we include about a dozen patches right now.
That sort of showcase a nice base template or
showing off a specific functionality.
You can help adding more modules.
Although, like I said, we already have, like almost
1400 modules.
It's getting a little bit tight in terms of both the binary
sizes and our CI, which is running all of these different
fields.
It's getting a little bit heavy.
So it's sort of within limits.
And right now, we really prefer quality over quantity.
Yeah.
I mean, I can say that right now, the thing is taking so long.
Like, I don't like using GitHub so far, but they provide
all these things for free.
We, six hours is not enough to build a thing from scratch.
Because on Mac OS, especially, we want to have a static build
that has the dependencies altogether.
And it's unified build.
So it's both into an arm.
Yes.
Universal build.
We have a lot of extra caching in the build.
So that's why they are pretty fast.
Once the cache is filled, but otherwise.
Yeah.
So we have to divide the CI in two steps.
First, they build the dependencies.
Then after the dependencies is done, as a separate build,
then it builds the actual continual.
And that can take like three hours.
The builders are not the fastest.
But yeah, it's getting a bit heavy.
But so if there's like a good proposal, and especially
if it's coming from module developers, we're very open to
then contributing and then also maintaining sort of
the updates.
So there's, because we have so many modules,
some are still being developed.
And they get updates, but we're not always aware of that.
So people can help with updating modules or patching
them with some of the cardinal specific features.
Some community guidance.
Like, there's quite some people using it and
posting it.
We've been, like, some people wanted us to expect us to have
like a discord server.
We, of course, don't want that.
We have an IRC server, but it's hard for people.
So we don't know if we should have like a dedicated form for this,
etc.
So if there's people in the community that feel that there
should be better ways for users to sort of come together.
It's much appreciated to help organize that.
So of course, thanks to VCV and direct depth community,
because we are just downstream from all of them.
And yeah, we're just an integrator mostly.
And users are posting on patchstorage.com.
So there is like a dedicated cardinal section where you can find patches
that work.
And we'll thank you for listening, and there's a project page.
So any questions?
Thank you very much.
A great talk.
Before we ask, before questions,
it's merely in the next speaker in the room.
Not yet.
So I mean, as soon as he hopefully will get in here soon,
because he is the next one in turn.
Speaking about is there any question for Alexander and Philippe?
No question at all.
They were so clear, so.
There's one.
Okay.
Big walking together.
We'll show the website.
Maybe we'll show the website again.
Where are you, sir?
The license list.
I have this.
Keep scrolling.
Just a quick question.
It's about plotting.
What are the dependencies required to port to an open watering system?
Depolences.
Sorry, I don't hear.
People say it be quiet, please.
What are the dependencies required to port cardinal?
The penalty is the port cardinal.
As you shoot, a lot of stuff is already supported.
So the main issue is not exactly cardinal.
It's third party modules that assume where we're in Linux.
That's the issue.
Like the raccoon supports Mac Windows Linux.
Not even Linux ARM.
So a lot of modules have their expectation.
It's possible to support PSD because we can fetch a couple of things.
Out say anything that is politics and can do Excel 11 is easy enough to port.
But I at some point have I call ICO as built as well.
Not without the UI, but this is just the engine.
It was interesting.
It's just in the ICO.
Yeah.
The ICO is possible.
The issue is we don't have the UI stuff ready on the DPM site.
If you don't care about the UI side, you can run it.
We will take a look.
Thank you.
Okay.
Thank you.
Yeah.
Oh, that's one more.
I think it's getting a bit too noisy for questions.
But let's give them a round of applause, please.
Thank you.
And the beer round.
So feel free to catch them outside if you want to make any question.