Project related news (was: Gathering interested people)

[falkTX]

Leave a comment if you want to help.
This does not do anything yet besides building VCV sources, I need to do some experiments for it first to see what is the best approach.
Seems that we only need to create a variant of https://github.com/VCVRack/Rack/blob/v2/adapters/standalone.cpp for plugins, and then add in some hardcoded module for IO (audio, midi and transport sync)

[falkTX]

Update: the makefile builds now.
You get a black screen if you try to run it, as there is no real code on the plugin side yet.

[unfa]

Being able to use VCV Rack as an LV2 plug-in would put it on my map. I could actually start using it in my work.
It'd be something very unique, especially if it'd allow putting external audio in.

[unfa]

Also: "CVC" = "Control Voltage Craze"? ;)

[trummerschlunk]

highly interested ;)
thanks for your work!

[falkTX]

CVCRack reads as "CV Crack", for those addicts on CV. Hopefully everyone finds it funny and not problematic 😅

One initial question is knowing which plugin IO variants are useful, because not all hosts are alike and allow placing FX on sequence tracks or synths on the mixer.
So I am thinking:

1. base synth version - no audio ins, MIDI input, 2 audio outs
2. base FX version - 2 audio ins, 2 audio outs, midi input and output
3. CV port version (only possible in LV2 and VST3, not in VST2) maybe with like 8 cv ins and outs, opinions welcome
4. ???

At least for FL Studio and Renoise we need a basic synth and fx versions.
The CV version wont work on most hosts, but useful for placing it on Carla and other modular things. I dont think JUCE hosting supports CV, so no support for Bespoke :/

[unfa]

CV Crack Rack takes the cake for me :D

I think the variants listed make perfect sense. If there's someeon who'll need an insane thig like 32x32 audio ports then it's probably not a huge deal todo it. I doubt anyone will want it though.

[x42]

The VCV Rack code to run as plugin in sync with a host is not public.

Even in v2, there is only code available for the GUI version that renders async, not rt-safe (using locks) and uses modules for I/O:

https://github.com/VCVRack/Rack/blob/042a9ce026d253700ea14e340182900162ab4653/src/engine/Engine.cpp#L404
https://github.com/VCVRack/Rack/blob/042a9ce026d253700ea14e340182900162ab4653/src/engine/Engine.cpp#L578

A plugin version processing must run in sync (with the host). This is a major task and will require a complete engine rewrite... Which is what Andrew has been busy with over the last years.

So you will have to re-implement the engine in a rt-safe way (without locks and globals), notably Engine_stepFrame: process all cables, then all modules. and every N samples check if connections or modules have changed, and swap the lists in a rt-safe way. GUI synchronization will be another task.

[x42]

Tech issues aside, have you considered that upstream might not like this, and stop releasing any GPL code in the future?

[falkTX]

Yeah, this has always been the case.
I wonder if the closed plugin has custom code for this or just reuses the engine as-is. we will never know perhaps.

But anyway, getting this to build correctly is a good first challenge already 😂
VCV is very peculiar in wanting specific versions of libraries.
One step at a time.

[falkTX]

Tech issues aside, have you considered that upstream might not like this, and stop releasing any GPL code in the future?

That is a good question... But also, it sucks that if for that reason we cannot try to make a plugin version ourselves..
IIUC they only plan to release a VST2 version at first.

[x42]

PS. check out VeeSeeVSTRack. That has a vst2-process-callback:
https://github.com/bsp2/VeeSeeVSTRack/blob/81e054be2dcc0c5d93d2f38288257cc6564ad878/src/engine.cpp#L498

as well as VST2 and VSTi wrappers. It is not entirely rt-safe, but a lot better than upstream, based on Rack 0.6 though.

[Be-ing]

One initial question is knowing which plugin IO variants are useful

Mixxx would need just a stereo input and stereo output. This would be good motivation to implement LV2 GUI support in Mixxx.

This is a major task and will require a complete engine rewrite... Which is what Andrew has been busy with over the last years.

My understanding was that Andrew was going to publish the code of that complete engine rewrite. I see the v2 branch in the VCV Rack repository which has recent commits but no 2.0 version has been released as far as I can tell. It may be wise to wait for Andrew to release 2.0 before doing much work on this. I have not been following VCV Rack closely and have no idea how far that branch is from a release.

I recall an old GitHub Issue on the VCV Rack repo several years ago discussing this which @falkTX participated in as well. Unfortunately VCV Rack no longer has a public bug tracker and archive.org did not archive that issue. My understanding from that conversation was that @AndrewBelt planned to do a major rewrite to support running VCV Rack as a plugin with the core code published with a GPL license but the VST part would be proprietary. He said he was not interested enough to work on LV2 support himself and would not accept a pull request for that but we could implement LV2 support in a fork.

[AndrewBelt]

We haven't gotten many requests for an LV2 version of VCV Rack Studio Edition, but I can add it to our feature request list!

[Be-ing]

Thanks for chiming in @AndrewBelt. Could you clarify if that LV2 support would be published with the GPL source code? If not, I don't know if it would satisfy anyone who has shown interest here (speaking for myself, I wouldn't use it). As long as the GPL source code doesn't require a major rewrite, I think there's sufficient interest here to maintain a fork for a GPL LV2 plugin version. AFAIK there is only one proprietary DAW that supports LV2 (Reaper) so I don't think the availability of a free GPL LV2 plugin would have much if any of an impact on sales of the proprietary VST (and AU? not sure if you're planning to support that plugin format) version.

[falkTX]

My understanding was that Andrew was going to publish the code of that complete engine rewrite. I see the v2 branch in the VCV Rack repository which has recent commits but no 2.0 version has been released as far as I can tell

The v2 code is already public, but no release is official yet.
This was the motivation behind the initial work here, checking if the new code can work for a plugin or not, going with the assumption that yes since there is one announced.

We haven't gotten many requests for an LV2 version of VCV Rack Studio Edition, but I can add it to our feature request list!

As great as that sounds, my main issue is that such a plugin is not going to be open-source.
Did I understood this wrong?

For one, VCV still only officially supports 1 single architecture on Linux.
For ARM builds we need to build it ourselves, and there is no access to the online store since it also only has the more typical intel/amd 64bit binaries.
If the official VCV plugin is not opensource, we cannot use it on linux ARM devices.

And not just ARM, RISC-V is slowly rising in popularity. I would love to have this working on HaikuOS too at some point. This is just not possible without it being open-source in the first place..

Perhaps a special license deal could be possible to those who buy a commercial license, so we get access to code for personal use but under very limited conditions or something..?

[AndrewBelt]

We've gotten many feature requests for ARM on Mac/Windows/Linux, so it is definitely on our feature request list. If you have other questions/requests, our most reliable channel is https://vcvrack.com/support.

[Be-ing]

The v2 code is already public, but no release is official yet.
This was the motivation behind the initial work here, checking if the new code can work for a plugin or not, going with the assumption that yes since there is one announced.

@AndrewBelt can you clarify what is the state of the v2 branch and what your plans are for it? I see now that you published a promotional teaser video a few weeks ago but I didn't see any indication how close the v2 branch is to completion. Is there still a lot of work you plan to do before is usable for a plugin? Or is the current state of the v2 branch close to release ready?

[falkTX]

First test: can we get the VCV window embed into the host?
Answer is no, not easily anyway. VCV relies on GLFW for all its window and event handling, which does not yet support such a feature.
That said, we can replace it by Overriding the Window.cpp file with a custom one, driven by DPF and its pugl backend. The DPF stuff needs to be converted to GLFW (mouse presses, keyboard, etc) so that VCV understands them (that is, without a whole event system rewrite on the part of VCV)
The alternative would be to allow to keep VCV as external window while the embed view is a dummy/minified one.

Which one is better?
IMO the embed view is better. With VST2 the hosts could not resize the plugin UI (not without custom extensions), but this has been added officially in VST3 and LV2 supports this too. So we don't have to deal with fixed size plugin UIs anymore.

I am testing high-dpi on macOS to make sure that is possible to work well too.
You can see below how it looks:

The background is missing, but that is my fault quickly hacking around the code just to get this to build so I could test the embed approach.

So, still ask anyway... embed or external?

[falkTX]

Checking VeeSeeVSTRack it uses https://github.com/bsp2/lglw, which allows to embed its window into the host and follows the same API as glfw.
Seems to be custom code by the same author. There is no support for macOS though. Not sure how good/bad the state of that project is, but seems kinda abandoned at the moment.
Sticking with DPF/pugl might be best if going the embed way, it is more nicely integrated anyway.

[falkTX]

For the sake of transparency, I am quoting contents of an email I just received from Andrew:

Hello,
The name you've chosen for your fork is very close to our trademark "VCV" (USPTO 87714461) which may lead to confusion. VCV Rack's own 250k+ users are extremely brutal/demanding for tech support, and the last thing I need is for a similar-looking product with a similar name creating more support due to confused users. I already get hundreds of complaints per year about other forks of VCV Rack (having much more different names than "CVC") and have to send them an automated template response explaining that we don't make that product and to contact who they obtained their version from. This makes many people angry toward VCV for not offering them the free support they think they deserve!

VCV releases open-source software so people can review and modify how the software works. We don't release software because we like providing support for free. I hope you can understand this and change the name of your fork to something that will cause fewer problems. Perhaps "falk Rack" would be better, as it suggests who users will assume is responsible for support?

And my reply:

Hi Andrew, that makes sense, sure.

Though you could have said the same thing on the github ticket where conversation is on-going, I dislike to keep such matters private.

It is only a research project at the moment, if anything comes of it I will rename it (likely even before that).

[falkTX]

A few more details, seem that passing events from DPF to VCV works well.
Have a hacky way to pass-through mouse clicks, motion/hover and scroll.
With a little resize handler at the bottom right the UI can become resizable even in VST2 format.
Seeing in action as below: (Renoise and VST2 version)

The SVGs are not loading somehow, dont know why yet.

The way VCV manages the "active context" is a bit weird for plugin usage, but should still be doable.
oui-blendish kinda works the same way and my testing for the one-knob series tells me it is not an issue as long as host GUI is single-threaded (which so far is always the case)

Since VeeSeeVSTRack had a working audio plugin engine, I assume this part is doable too.
We can likely copy its plugin modules to serve as a base.

The hard part is going to be dealing with VCV plugins, VeeSeeVSTRack went a bit overboard with its approach even though long-term it is/was the more stable one. Audio plugins should be self-contained, in theory, but in practice VCV already fails due to its heavy use of global state. So perhaps not worth bothering too too much on this side of things...?

Oh and yes this needs a new name. I am often bad at those, so suggestions welcome.

[x42]

Oh and yes this needs a new name. I am often bad at those, so suggestions welcome.

How about "Cardinal"?

[falkTX]

Oh and yes this needs a new name. I am often bad at those, so suggestions welcome.

How about "Cardinal"?

I am quite neutral about this one, what is the reason for it?
Starts with a "C"...?

[x42]

Thinking about "Rack", I associated Monty Python's Spanish Inquisition: "Cardinal, [bring forth] the Rack",
and yes it starts with a C, like all your other projects.

[falkTX]

I dont see why not, thanks. It actually sounds cool but still generic and simple enough.
We just got to see if there are no other plugins or big projects already with the same name

And not all projects start with C, you know DISTRHO itself is already an exception right? 😉

[falkTX]

The embed view works on Linux/X11, and tested win32 builds via wine as well.

If we can figure out why svgs dont load correctly, I think then a cleanup for a proper UI can begin.
The DSP I am assuming can just work, just a matter of setting up the engine properly.
I was more doubtful of the UI because of GLFW, still am a bit because when using stock Window.cpp that uses GLFW, the svgs then load correctly:

My guess would be at some OpenGL setup/state not being quite as needed when using DPF/pugl

[falkTX]

Success! Embed view and SVG loading, UI interaction seems to work fine from what I can tell.
I was looking all over the place, but turns out the culprit was this little piece of code on VCV Svg class:

	// It's more important to not lag the frame than to draw the framebuffer
	if (dirty && APP->window->getFrameDurationRemaining() > 0.0) {
		render(scale, offsetF, args.clipBox);
	}

My custom Window class didnt have a lot of things that GLFW provides, such as frame duration information.. for now putting some dummy values makes the check pass and SVGs are finally drawn on screen 🎉

[falkTX]

Multiple instance seems to work, at least for UI stuff.
Some barebones keyboard input too, still need to handle special keys so we can do stuff like backspace for deleting characters.

This is showing how great it is to build good infrastructure.
Most of the work is just glueing stuff together, tying the DPF things into what VCV expects. It goes rather smoothly, so fingers crossed...

The next big item I guess is getting the engine to do something, likely I will need help on this.
But for that the build needs to work cleanly, so others can start to run it too and not just me.
Since we have CI tests already in place from other DPF plugins it should be clear when the build and plugin runtime is working well enough. This might take some time now though...

[Be-ing]

Is or will there be a means for an LV2 host to tell the plugin to load a particular patch separate from other instances? My hope is that I can save patches and create effect chain presets in Mixxx which load specific patches, then manipulate them with a single knob on my controller:

Are modules' knobs exposed as LV2 parameters? IIUC LV2 plugins can't dynamically add and remove parameters, so I suppose it would need a hack similar to audio I/O with a fixed number of LV2 parameters which could bind to modules' knobs within the plugin.

[falkTX]

Is or will there be a means for an LV2 host to tell the plugin to load a particular patch separate from other instances?

Yes of course, each instance of Cardinal is supposed to be self-contained in its own engine, patch and gui.
And state should be preserved in the host as long as the host saves it and restores it the usual way.
For LV2 and Mixxx just make sure to support the LV2 state extension,

Are modules' knobs exposed as LV2 parameters?

This is up to discussion.

IIUC LV2 plugins can't dynamically add and remove parameters, so I suppose it would need a hack similar to audio I/O with a fixed number of LV2 parameters which could bind to modules' knobs within the plugin.

That is correct. Though VST3 supports this dynamic parameter stuff, it is not something I am interested on adding to DPF.
The complexity around it is too much for very little gain, and almost no plugins need this in practice.

Hosts dont typically support CV as a form of automation, so we will need some special parameter mapping.
What I have done in Carla (and zynaddsubfx for example does something similar) is to expose a static 100 parameters to the host. In Carla these will be auto-assigned to the first plugins loaded in the rack, in zynaddsubfx you can map as you wish through a dedicated dialog.
For VCV as plugin I think the static parameters are the best choice. We can have a dedicated module to convert from plugin parameters to VCV internal CV, probably with some options to control its behaviour (sudden changes vs smooth interpolation, threshold for smoothness etc)

Nothing about this is done yet, so for now it is just discussion.
Opinions always welcome, specially before any real implementation begins.

[falkTX]

FYI Just did some changes regarding cable values behaviour.

I was not aware before, for not having yet dig deep enough into the code, but every cable introduces 1 sample of latency in Rack because of how the engine works.
The engine runs on every frame, but ports with connections require the next cycle for the target port to see new values.
The cables basically accumulate and slowly add in bits of latency everywhere..
This is quite annoying, to be quite honest I expected there to be no latency on straight connections like A->B->C, disappointed that it is not the case...

But wait! Now it is!
Or at least it starts so. I made it so that (output) ports store their current connections/cables. Every time a module port calls setVoltage the other (input port) side gets its value updated at that very moment, no need to wait for the next cycle.
This makes the A->B->C case have zero latency!

Now this is great but there is still more to do. For example Carla and Ildaeil (plugin hosts) have their own buffering because running regular audio plugins at 1 frame is just unfeasible. I am thinking of making them have the same exact buffer size as Cardinal in the DAW, so in theory they would run in sync with everything else and also have 0 latency, but need to do some tests to make sure of that.

Another issue still remaining is the lack of a "graph" context in Rack. Rack's engine simply goes through all modules one by one in the order they were created. So if we add say A, B, C modules and connect C->B->A the zero-latency cable stuff doesnt help at all. In order to have reduced latency the modules would need to be processed in order of their connections, which is what a "graph" entails. Everytime a new connection is made the graph would be rechecked for the most optimal path of processing. Basically how any modular host/patchbay works.
I am not familiar on creating such graphs so won't do this myself, I only know they are quite complex to code, so it is understandable that Rack doesnt have one yet.

In other news, AudioFile and Ildaeil panels got a little reorganized.
Slightly related, I updated the imgui stuff and made it recreate the GL stuff on zoom level changes so it always looks crisp.

Also started playing with expanders. The stuff from Ildaeil was split off to create the midi-to-host modules expander.
Wanted to make sure to signal that the connection was active, so when close to a module it works with, the expander will expand its port background.

The background color is wrong though, on Cardinal the white layer is supposed to be for outputs, so I will still change it before release.

And speaking of releases, it is just 8 days away now :)

[zezic]

@falkTX That's all nice, but how do you plan to handle the circular feedback loops? It will need some type of graph clustering to be able to process the A->B->C chains if they have a C->A connection.

Ability to extract the non-feedbacking chains and run them with 0 cable latency is good to have, but how to make the patch perform consistently when rack operator makes changes is a problem.

Maybe it would help to access the archive of the Rack GitHub issues and also to search the community forum for related discussions, it can fire some light on the question.

[falkTX]

@falkTX That's all nice, but how do you plan to handle the circular feedback loops? It will need some type of graph clustering to be able to process the A->B->C chains if they have a C->A connection.

that is unsolvable unless there is specific dedicated APIs for those.
JACK has a similar problem where you can use feedback loops. IMO it is acceptable to have 1 sample latency for those.
The audio graph as implemented in JUCE doesnt even support feedback loops at all, and mutes the output if one is detected.

Maybe it would help to access the archive of the Rack GitHub issues and also to search the community forum for related discussions, it can fire some light on the question.

There is no archive anywhere that I could find, if you know of a platform that has a copy please tell.
Joining the forums is something I am undecided about. It could be seen as trying to promote an unofficial product and generate drama/anger/etc.. And anyway discourse forums are not the place for such talks. The Rack GitHub issues should have never been closed in the first place! I dont feel comfortable starting a discussion around something where we already have precedence of community being silenced. The same way the GH issues were closed, other topics can be closed just as well.

[falkTX]

MIDI output expander is implemented, so plugins loaded in Carla or Ildaeil that generate MIDI out will now be able to be part of the project too.
Did an experiment with Carla's internal midi file player, which gets converted to CV, back to MIDI for an instance of zynaddsubfx. Works fine 🎉

[zezic]

IMO it is acceptable to have 1 sample latency for those.

I mean, sure, that's absolutely acceptable, but for me it feels that it will be a pretty complex algorithm to find 0-sample-latency segments, cluster them and decide where to use the 1-sample-delay cables.

There is no archive anywhere that I could find, if you know of a platform that has a copy please tell.

Sadly, I can't find it either.

Joining the forums is something I am undecided about.

Ah, I mean, you can use them read-only. However, after quick search I can't find any discussions about cable delays and graphs which would be productive enough. But it's an interesting topic.

[falkTX]

IMO it is acceptable to have 1 sample latency for those.

I mean, sure, that's absolutely acceptable, but for me it feels that it will be a pretty complex algorithm to find 0-sample-latency segments, cluster them and decide where to use the 1-sample-delay cables.

It is not that complex, there are even several known algorithms for it.
JACK basically works this way, when you make new connections the entire graph is checked for the optimal processing path. If a new path is found a graph reorder callback is triggered.

Maybe with Rack things are a bit harder because the amount of connections will be bigger, but still doable.
I have seen people with setups with a big amount of connections while using JACK, and it still behaves as you expect, e.g. https://kx.studio/screenshots/news/carla-2.2_usage.png

Joining the forums is something I am undecided about.

Ah, I mean, you can use them read-only. However, after quick search I can't find any discussions about cable delays and graphs which would be productive enough. But it's an interesting topic.

Thanks for looking! And sure, I already do see the topics there from time to time.
But serious dev talk doesnt seem to happen much on their forums.

[falkTX]

It is release day!
Wrote a few details about Cardinal on my KXStudio page https://kx.studio/News/?action=view&url=cardinal-2202-is-now-released

The releases page https://github.com/DISTRHO/Cardinal/releases has the usual builds attached, they should be downloadable by anyone, even those without a github account.

[falkTX]

The very first piece of media after the tagged release,
From our dear unfa 😎
https://www.youtube.com/watch?v=HapldC7rROc

[unfa]

Thanks, @falkTX ! I hope I got all the facts right! This is a wonderful tool, and something I've been waiting to see before I dive into modular synthesis again! The last time I've done any serious work was with ALSA Modular Synth in 2012 or something...

[falkTX]

I didnt hear anything incorrect.
The crash was weird, maybe Cardinal inside Cardinal, but I have tested that to work fine before.

Thanks for the quick video!

[unfa]

You're welcome! I was hoping maybe I can manage to do this yesterday, but I wouldn't have the demo song to show, and I think it was worth the delay.

Are there any debugging tips? Maybe I could collect some logs or coredumps after such crashes to help fix the issues?

[falkTX]

Are there any debugging tips? Maybe I could collect some logs or coredumps after such crashes to help fix the issues?

The release binaries are quite useless for debugging, as everything is optimized and stripped for the best performance.
There are debug builds on the "nightly" github actions though, which run quite poorly but allow for full backtrace and debugging.

But I think the best for helping to fix issues is just to get a nice set of reproducible steps more than anything else.

[falkTX]

To keep you all updated on what is going on. Quite a few modules were added thanks to @dromer, with me just helping along the way. We finally have Befaco 🚀
For now it is best to not add any more, focus goes on stabilizing the ones we have right now.

I noticed a macOS issue where the disabling of "update rate limit" breaks a few hosts. Situation is a little weird/unusual.
Some hosts always repaint the plugin UIs even if it has nothing new to draw, that makes Cardinal use a lot of CPU wastefully - this includes Ableton Live, Carla and REAPER; some other hosts only repaint as necessary - including FLStudio and Renoise.
The way original Rack handles this is just to do a small sleep if it detects repaints happening too often. I dont think this is a good option, specially in a plugin, as it will slow down other things the daw does.
So the "update rate limit" option is there for macOS now, but note it doesn't work on all hosts.

Current plan is to fix up issues related to the new added modules, then a couple of other ones reported, and also do a windows installer. As much as I think copying some folders around is okay, seems not everyone agrees... :/
The individual plugin bundles will remain as release binaries, but we will have a windows installer option too.

There is no specific date set, but target is to do a 22.03 release this month with the newly added stuff and fixes.

PS: unfa is doing a livestream using Cardinal very soon, in about 10mins from posting this message! https://www.youtube.com/watch?v=Tpd_vZJwGNQ1 🚀 🚀 🚀

[falkTX]

On something maybe expected, maybe unexpected, I have been testing leveraging JUCE as a way to get a few more plugin formats working. Basically bridging between DPF and JUCE, giving a few more options to DPF plugins.
It is not something that belongs in DPF, because licenses, but can be quite useful in selected cases which Cardinal is one of them.

An obvious target is to quickly get an AU plugin without having to do the full implementation on DPF side, as a few DAWs like ProTools only support AU. I dont have a ProTools license, but do have GarageBand that is in a similar situation only support AUs.
Does it work? ..yes :)

Got audio, transport information and UI working. Parameters, MIDI and state save/load not yet. But first was just checking if this was doable anyway.
I am not sure if this will be part of 22.03 release, since it is very new and I am still doing tests, but it is great to have as an option.

[falkTX]

Some news!
So the AU stuff was finalized, at least for the use I wanted to make of it. I do not use it myself, but gave it some testing to ensure all required functionality is present.
Only issue I saw was resizing being a bit jerky, have some ideas for how to make it better, will try them later.
Testing is welcome.
(on the technical side, this is pretty much just leveraging JUCE as a middle layer between DPF and AU. Initial testing and development was done on Linux with VST3 and Standalone formats, and then double-check on macOS with AU. Since it is all JUCE stuff, I suspect it works fine).

On the Windows side, happy times, we got an installer now!
The resources are stored on a single place, reducing wasted space. And yeah it puts the plugin files on the correct places, no manual copying necessary.
The situation with Carla (the plugin host) has been solved on Windows too. Now Cardinal builds the whole GUI toolchain needed (Qt, Python and PyQt) and makes it an option during install.

Carla is running! 🚀

And speaking of Windows, most of the issues present on the 32bit build were fixed. Some still remain, but way less than before. This will be an on-going effort, as VCV Rack never supported a 32bit OS so we are on our own for this.

These changes and the added modules already make it worth to have a new release.
I have set the date for that to be 21st of March, the start of Spring season. Will do a few more fixes as possible until then.

[falkTX]

Spring is here, and so is a new release.
Details at https://kx.studio/News/?action=view&url=cardinal-2203-released

Time to party 🎉

[wpostma]

I'm a Visual C++ dev not much MSYS2 experience but I have a high dpi Windows DAW workstation and would be willing to help with the current high dpi issues on various windows vst hosts (bitwig, reaper, ardour) with cardinal . Stuck at MSYS2 installed, make reports OpenGL not installed.

Have read BUILDING.md but it isn't highly detailed for MSYS2 users. a

pacman -S list-of-all-the-things-one-wants

[falkTX]

I dont use msys2, that is why :)
The windows builds are cross-compiled from linux, it has been many years since I actually used windows as an OS.

That said, https://github.com/lv2/pugl is the underlying layer used by DPF (in turn used by Cardinal). So a first step would be to try to reproduce the issue with it.

[falkTX]

Just tagged 22.04 🎉
https://github.com/DISTRHO/Cardinal/releases/tag/22.04

Note: I will stop writing updates here.
Cardinal is more or less an established project now, and known to work well for quite a few people.
If there are issues, you know where to report them.
Some are still unfixed, which likely will be fixed in due time. Not everything is perfect but this is a fully free plugin in the end. Help is always appreciated for those that can provide it, be as it source code fixes or other means.

PS: builds still going, binaries will be up soon.