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)

[Be-ing]

Awesome work!

[falkTX]

What is the most common place people usually post patches in? My knowledge of CV is limited, and want to start giving this proper testing, plus to understand what modules people are using more so they can be added in.

[falkTX]

By patches I mean VCV patches/projects. We need to start doing some real testing.

[zezic]

https://patchstorage.com/ probably.

[zezic]

Regarding modules popularity: https://colab.research.google.com/drive/1Rniemjz4xDzxaTrTEXdFjwhVLhptxloD#scrollTo=413f0952&line=1&uniqifier=1

[falkTX]

Regarding modules popularity: https://colab.research.google.com/drive/1Rniemjz4xDzxaTrTEXdFjwhVLhptxloD#scrollTo=413f0952&line=1&uniqifier=1

That is super useful, thanks!

[zezic]

@falkTX Thanks for the update, the black offset problem on HiDPI is solved, but now the mouse coordinates are wrong: https://youtu.be/LFACL-FIkto They were fine before the fix.

[falkTX]

Right, I know why! I was testing some things and forgot to add back the scale factor divider. Should be fixed now again, though I didnt test this yet.

btw, to all listening here, I began to create tickets for stuff to be done. see https://github.com/DISTRHO/Cardinal/issues You should already be able to clone (dont forget --recursive, there are a LOT of submodules!) and run it from the source dir. Don't move the source code around, that is used for now as the place to find resources.

If you spot anything that is Cardinal/plugin related (not an issue with VCV) please create tickets.

I never did a VCV module myself before, so help would be much appreciated to setup something for host tempo -> cv signal, plus mapping plugin parameters (around 20 are enough?) into cv signals too. If you want to tackle this, open a ticket saying so.

[zezic]

Right, I know why! I was testing some things and forgot to add back the scale factor divider. Should be fixed now again, though I didnt test this yet.

Thanks, I just tested it and it works correctly now!

[falkTX]

I have been adding a new more plugins/modules. With Core + 10 collections we are at 287 total modules, release/optimized binary size at 14.5Mb.

I think we are going to need LTO soon...

[unfa]

Whoa!

[fpesari]

I suppose this is not affected by the nonfree CC BY-NC-(ND) licenses VCVRack uses for the graphics, but what about the plugins?

[falkTX]

I suppose this is not affected by the nonfree CC BY-NC-(ND) licenses VCVRack uses for the graphics, but what about the plugins?

VCV modules/plugins are built as part of the cardinal plugin, and only opensource ones are used, so that part is quite fine.

On the CC-ND (non-derivatives) we are not changing the files, so not sure how that would even apply.

Both VCVRack and the plugins are used as-is, you can see that by checking the code and where the submodules point to - they point to the original projects. There is no DISTRHO Rack fork, not at this point anyway.

Some code is overridden to better work in plugin/embed scenarios, but that is very very small changes. And no changes to the artwork have been made so far.

[fpesari]

On the CC-ND (non-derivatives) we are not changing the files, so not sure how that would even apply.

I was more worried about packagers not being able to be include Cardinal in distros which do not allow nonfree stuff (VCV Rack has the same problem).

[falkTX]

On the CC-ND (non-derivatives) we are not changing the files, so not sure how that would even apply.

I was more worried about packagers not being able to be include Cardinal in distros which do not allow nonfree stuff (VCV Rack has the same problem).

What part of VCV is non-free? CC-ND is a completely valid license for packaging.

[fpesari]

What part of VCV is non-free? CC-ND is a completely valid license for packaging.

Not in all distros. For example, this is what the openSUSE packaging guidelines say:

Content still has to be reviewed for inclusion. It must have an open source compatible license and must not be legally questionable. [...]

As much as I like and support Creative Commons licenses, non-commercial licenses are most certainly not open source-compatible!

[falkTX]

Ok yeah for the Non-Commercial clause the situation is a bit more tricky..

[Be-ing]

Could you make a build option to exclude CC-NC content so distros could package this who can't include it?

[falkTX]

The best would be to just redo the artwork as needed, if they are core modules. Otherwise skip them entirely.

Dealing with different versions of the same plugin will be a pain for sharing plugin presets.

[falkTX]

Sadly the "core" components include the grid too. This is how things look without the CC-NC ComponentLibrary

[falkTX]

After some checking and testing I think the everything-together-in-one plugin issue is solved. I was afraid that building so many similar things together would lead to problems, and without being careful it does, but we can automate finding these issues to mitigate them.

LTO (link-time optimization) comes to the rescue, as it nicely reports to us during the link stage if there are definitions that mismatch. So if 2 different modules define "VCA" we can just use compiler macros on one of them to convert that to "AS_VCA". Same with e.g. more than one using freeverb, on slightly different versions. More compiler macros to convert "allpass", "comb" and "revmodel" fixes this one. It is tedious because LTO takes quite some time for linking, but the output information is very valuable.

Dont know how to deal with this for C libraries yet, and we already have the issue of 2 plugins using different versions of dr_wav. For now I copy files from the plugin folder to override them, will deal with this properly later.

We have 405 modules so far. Binary size sits at 18Mb optimized without LTO. With LTO we can reduce 2-3Mb.

[falkTX]

With plugins, we are typically supposed to save state in the current session/host instead of files in the user dir. So, with trying to preserve state in the plugin I am placing a few VCV related things as plugin parameters, then we can save&restore their values through the plugin host.

What ends up happening is sorta amazing, exposing the "room brightness" as a parameter means the host can automate it...

What a show :joy:

https://user-images.githubusercontent.com/1334853/138003203-54230d24-84f4-4448-8e13-b102708adcc7.mp4

It is a little bit weird to setup, since this is a global variable. But with some local caching + set&restore on each window event handling means we can have separate settings per window. (we really do not, not really, but it acts like we do)

We will be able to save the typical user settings with this.

[falkTX]

Plugin state save/restore is in, as well as 24 host-exposed parameters. The (added by default) "host parameters" module will map between host parameters and the VCV world. Some little filtering to reduce stepping and it produces nice results.

I was able to get Carla playing a MIDI file where the notes are converted into parameter changes that automate Cardinal's parameters. The result is (sorta) playing the chocobo song purely out of plugin parameter automation. :tada:

https://user-images.githubusercontent.com/1334853/138166313-9757f351-abb9-4993-94d9-e34082fc5f47.mp4

[falkTX]

Bringing more news.

The resources are now put in place that allows the binaries to be redistributable. The source code dir is used only as fallback. Automated builds can be downloaded from GitHub Actions, https://github.com/DISTRHO/Cardinal/actions/workflows/build.yml These builds have LTO enabled, around 14Mb for the binary.

MIDI input and output has been added. Sadly but unsurprisingly VCV handles MIDI separate from the audio, they are not on the same thread. This is typical for desktop applications, not so much on plugins. I see queues here and there inside VCV MIDI handling that we we want to avoid for a plugin version. So likely that part needs to be reworked so we do all directly on the audio/processing thread. What is already in place now for Cardinal + MIDI should work though, just not as precise or jitter and latency free as we are used to in plugins. (plus these different threads for MIDI handling are a mess/pain to handle properly, specially if trying multiple instances)

So at this point testing and feedback would be much appreciated. Finally we have something that we can see if it really works or not. Maybe the effort is pointless if the open-source application engine cannot handle being a plugin properly, or maybe what we have is already enough... We should find out soon.

[falkTX]

btw for those using Arch, @redtide was very helpful in providing cardinal-git as AUR package, should simplify things a bit. https://aur.archlinux.org/packages/cardinal-git/

[falkTX]

The menu bar is now adapted/custom for cardinal. I tried to do it by keeping the old menu bar from VCV, but there is no way to reach some elements, so the whole thing needs to be overridden.

The file->quit menu is hidden if running as plugin (as otherwise would do nothing) and file->open now uses dpf file browser stuff. So at least this action should not block the even loop (making the plugin unusable).

[falkTX]

Anyone with experience setting up compiler cache in GitHub actions? The automated builds are taking a seriously long time at the moment, due to them needing to build the deps, plugins, vcv and plugin wrapper in full every time.

[Be-ing]

I have experience with compiler caching on GitHub Actions with Mixxx and Tenacity. It's really easy to setup ccache with CMake, but you're using a handwritten Makefile. In this case I think you'd have to use the hack of replacing the compiler commands with symlinks to ccache and add a step like this to the workflow. The GitHub Actions run number in the cache key is important to create a new cache on every run. Otherwise the cache key will match exactly so GitHub Actions won't upload new contents in the cache after subsequent builds.

For perspective, 20 minute builds aren't terrible. Mixxx takes a bit under 20 minutes to build on Windows with 100% cache hits with sccache. I'm sure you could get much faster build times for Cardinal with ccache though.

[Be-ing]

What ends up happening is sorta amazing, exposing the "room brightness" as a parameter means the host can automate it...

Now can you hook it up to a brightness sensor? :laughing:

[falkTX]

using a handwritten Makefile

this should be fine. the makefiles honor the usual CC, CXX and other env vars.

[CarloCattano]

Running quite smooth on arm64. Vst3 here inside bespoke ( cant see the macros tho ) , lv2 runs well also inside Carla and can see the params

[vcvrackideas]

works almost smoothly on windows in Ableton, otherwise I described issues in separate topics the proof - https://youtu.be/mEZ7G7vWKZ8

[Torinbob]

On the CC-ND (non-derivatives) we are not changing the files, so not sure how that would even apply.

@falkTX Here's the problem as I see it....

From the Rack Licence: "The VCV logo and icon are copyright © 2017 VCV and may not be used in derivative works."

Cardinal is a derivative work. You therefore can't use the Fundamental modules without removing the VCV logo from the panels.

But by removing the logo, you are changing the panel files, and therefore falling foul of the CC-ND (non-derivatives) clause for the panel graphics.

It's a (quite deliberate I presume) Catch-22.

[falkTX]

From the Rack Licence: "The VCV logo and icon are copyright © 2017 VCV and may not be used in derivative works."

A derivative work of the logo, not VCV itself. That is the subject of the sentence here.

We do not need to make derivatives of the logo, a brand new one is fine. Or no logo at all really.

[Torinbob]

A derivative work of the logo, not VCV itself. That is the subject of the sentence here.

I think you are misinterpreting that. You are suggesting it means "The logo may not be used in derivative works of the logo" - which doesn't make much sense.

"The logo may not be used in derivative works of the VCV software" - makes a lot more sense.

Regardless of interpretation, the logo is copyright and has no license applied to it which means it can't be used - at all. It would therefore need to be removed from the panels and you then run into the CC-ND panel problem.

[falkTX]

"The logo may not be used in derivative works of the VCV software" - makes a lot more sense.

ok with that I agree.

Regardless of interpretation, the logo is copyright and has no license applied to it which means it can't be used - at all. It would therefore would need to be removed from the panels and you then run into the CC-ND panel problem.

That is an interesting situation. But all can be easily solvable by just contacting the author. I am sure a resolution is possible.

As I see it, the main deal with VCV CC usage is to prevent commercially-sold clones with VCV or ComponentLibrary on them. We get side-effects from this in linux distributions because these can be sold for money.

This is a serious but also completely un-fun problem to tackle. I would say to let Rack v2 be released first, so we don't bother Andrew with this at all, and then come back to try to find a resolution.

[Torinbob]

But all can be easily solvable by just contacting the author. I am sure a resolution is possible.

Possibly, but please tell me, why do you think the author would want to help you?. He has been working on Rack v2 for over 2 years now. The only difference between the free Community Edition and the commercial Studio Edition is that the SE runs as a plugin (and has professional support but I doubt that's really what anyone is paying for here)

By forking the free CE and adding plugin capability to it, I imagine all you are doing, from the authors point of view, is directly taking sales away from his Studio Edition - before it is even released. Why would he help you do that? What possible motivation could he have?

As I see it, the main deal with VCV CC usage is to prevent commercially-sold clones with VCV or ComponentLibrary on them. We get side-effects from this in linux distributions because these can be sold for money.

Perhaps - but I also notice you are asking for GitHub Sponsors, so you are looking to benefit financially from your work on this.

This is a serious but also completely un-fun problem to tackle.

Yes it is.

[zezic]

What ends up happening is sorta amazing, exposing the "room brightness" as a parameter means the host can automate it...

Now can you hook it up to a brightness sensor? laughing

Haha, I actually just tried it – https://www.youtube.com/watch?v=8wu2Gt-tsf4 Sadly, the brightness sensor of my phone is too lazy and updates its value at too low freqency, so I had to add some smoothing to make it look nice.

[falkTX]

But all can be easily solvable by just contacting the author. I am sure a resolution is possible.

Possibly, but please tell me, why do you think the author would want to help you?. He has been working on Rack v2 for over 2 years now. The only difference between the free Community Edition and the commercial Studio Edition is that the SE runs as a plugin (and has professional support but I doubt that's really what anyone is paying for here)

By forking the free CE and adding plugin capability to it, I imagine all you are doing, from the authors point of view, is directly taking sales away from his Studio Edition - before it is even released. Why would he help you do that? What possible motivation could he have?

From the few interactions I had so far with the author, everything leads me to think this is quite fine. Cardinal is a related product, but not really the same. There are no commercial plugins for one, or access to the plugin library or anything that involves login. Say some day VCV has integration with patchwork, Cardinal will not have that (per my stance of not wanting anything related to network on the plugin)

I see it as 2 things that eventually will just coexist. People that are running on configurations not yet supported by VCV (for example Raspberry Pi, RISC-V systems, BSD, Haiku) can use Cardinal and it should work reasonably well, eventually. For most common folks though they will want to use official VCV plugin not just for the library and commercial plugins, but also official support.

The CE/SE split is just one way Andrew is attempting to turn some profit with VCV. Perhaps the regular plugin store does not return the investment put in, I dont know.

We should be for Rack v2 being successful, so we can have Cardinal as a plugin as well. Without Rack v2, Cardinal won't exist, so it is 100% within our interests that VCV succeeds and keeps growing.

[AriaSalvatrice]

Hi! I wish I had been made aware of this great project sooner.

Having stopped module development last year due to VCV's attitude towards developers, problems regarding inclusion, and disallowing discussion of these issues via its code of conduct, I am very excited to see the community starting to exercise the rights the GPL grants it, and move away from this company towards being a free software community.

I have a lot to catch up on, but seeing that people consider this fork contentious in this thread, I wanted to quickly signal my support for it and interest in contributing..... Once I actually get a chance to actually try it and look at the code, haha.

[falkTX]

What ends up happening is sorta amazing, exposing the "room brightness" as a parameter means the host can automate it...

Now can you hook it up to a brightness sensor? laughing

Haha, I actually just tried it – https://www.youtube.com/watch?v=8wu2Gt-tsf4 Sadly, the brightness sensor of my phone is too lazy and updates its value at too low freqency, so I had to add some smoothing to make it look nice.

Wow, that is really cool to see! Mind if I share this around?

[zezic]

Wow, that is really cool to see! Mind if I share this around?

Sure, do whatever you want.

[falkTX]

Hi! I wish I had been made aware of this great project sooner.

Hi and welcome I guess..

I am purposefully keeping the project not too exciting, because there are a lot of quirks to sort out and until a few days ago I was just researching if this was even possible to begin with. The "project" is not even 1 month old!

The only announcement I made for it so far was gathering interested people to work on the idea. Not having facebook, or insta, or twitter or errr what else is out there, means my "announcements" dont go far..

So I ask to not spread this project around too much. Let's only keep the deeply interested people around for now, otherwise it easily generates a lot of unwanted noise.

[jaffasplaffa]

Hello :)

Very interesting project :)

I just tried running the Cardinal version on my Macbook M1, using Logic 10.7(In rosetta/Intel mode) and tried loading it by using DDMF Meta plugin. Logic doesn't use VSTs, so I had to use the Meta plugin, which can load VSTs, to be able to load a VST in Logic.

But I get instant crash of Logic when trying to load Cardinal inside Meta plug in.

Is there any chance for an audio unit version at some point, so we don't have to go through several conversion steps(Rosetta/Meta), where things can go wrong? Also would be really nice with M1 native version.

Thanks in advance.

[falkTX]

The binary is already M1 native, I use it on my own system. For AU version, small chance maybe next year, there seems to be very little interest on bringing AU support into DPF (the project Cardinal relies on for the plugin format support).

From my testing the binary can indeed crash on init on macOS, but when I try it from the command-line everything is fine... Which makes it super difficult to debug. So for trying this out on macOS, open a terminal and run your application (Logic or something else) from there. If you do get a crash, please post here the output of the application as printed in the terminal.

[falkTX]

Just did some tests on macOS again, all when running from terminal.

• FLStudio (beta arm/M1 version) hangs when Cardinal file->open is used (maybe related to how it changes CWD?)
• Renoise (x64 version, they dont have ARM yet) also hangs when using file->open
• Ardour also hangs the same way
• REAPER (ARM version) seems fine, can load the pre-included Celebration.vcv from this repo

• Carla (native ARM) also works fine

the file open is weird, working on some but breaking others, and it is just normal NSOpenPanel methods... need to investigate this..

[fpesari]

Possibly, but please tell me, why do you think the author would want to help you?. He has been working on Rack v2 for over 2 years now. The only difference between the free Community Edition and the commercial Studio Edition is that the SE runs as a plugin (and has professional support but I doubt that's really what anyone is paying for here)

I agree with you and I think this is the problem of FLOSS business models based on proprietary parts (code, as in "open core", or assets): they really are not FLOSS business models, they are traditional business models which sell licenses. Which is a problem only for the community, not for the authors if they can make a living off it, and in the meantime provide some code which can in any case useful to other projects. They are not evil: they help their developers earn a living and right now, as a community, we are not offering enough alternatives.

I think this case has no solution that can be good for everyone, unfortunately. I think the real change should be cultural: we should encourage FLOSS users to donate more (at least as much as they consider a fair price for that program) and more often. We should encourage FLOSS developers to join forces and start Foundations. Projects should not be only about code but also about finance (fundraising), marketing and design. But this takes a lot of time, as all cultural changes do.

We are already seeing people burned out by the current FLOSS business models - people who release their projects under libre licenses and are offended when somebody, often a SaaS vendor, makes money off them. Of course, that should be expected, especially when licenses different than the (A)GPLv3 are involved, but one thing is theory one thing is living it! The backlash is such that nonfree licenses such as the SSPL and ACSL and other "ethical source" or "public source" licenses are springing up left and right. If we don't want FLOSS to turn into a politicized minefield in which collaboration is impossible, IMHO we should go back to its altruistic roots (as enunciated by the FSF in the four freedoms) and stress the fact that donating to a project you use often (if you can) is a (IMHO moral) duty.

[falkTX]

I agree with you and I think this is the problem of FLOSS business models based on proprietary parts

While this is quite a good topic to talk about, and I generally share the sentiment around all this, it is off-topic on this specific ticket. If you want to keep pursuing the topic please use the discussions page.

Now to be back on the original topic, on the worst case that we simply cannot use the resources from ComponentLibrary in any way, we will just have to remake them in a compatible manner. The units/metrics for VCV panels are well defined so it is this is not a big long-lasting task. And in this scenario the core components looking different from the original would also give Cardinal its own distinctive look.

[AriaSalvatrice]

It's worth noting that the component library is not just comprised of SVG files, but also Rack/include/componentlibrary.hpp, which mostly loads SVG files, but also draws a few primitive shapes directly. However, those shape are so simple they cannot be argued to be a meaningful part of the trade dress. But the license says that "The Component Library graphics" (emphasis mine) are CC-BY-NC, so it seems reasonable to regard the code as GPL.

I have experience with the subset of SVG supported by VCV, and made from scratch for my modules some panels unencumbered by component library restrictions, so I could take care of this. The main challenge here would be to end up with a look that's generic enough to do justice to any module using the library, while also being distinctive enough it can't be argued to be a rip-off.

[falkTX]

It's worth noting that the component library is not just comprised of SVG files, but also Rack/include/componentlibrary.hpp, which mostly loads SVG files, but also draws a few primitive shapes directly. However, those shape are so simple they cannot be argued to be a meaningful part of the trade dress. But the license says that "The Component Library graphics" (emphasis mine) are CC-BY-NC, so it seems reasonable to regard the code as GPL.

Yeah I understand it the same way, the code is still all GPL (these kinda restrictions are not really compatible with GPL anyway, it would make it a separate license that is not GPL or open-source)

The main challenge here would be to end up with a look that's generic enough to do justice to any module using the library, while also being distinctive enough it can't be argued to be a rip-off.

If the design is made from scratch and not copied over, this should not be a problem right? As far as I understood, the issue is due to "non-derivative" clause.

Since we are in control of which plugins end up in the final build, any weird oddities can be taken care of. Cardinal is not meant to load external plugins, so there is no issue of something unexpected not working right (like lack of contrast). The plugin set included in the current builds is mostly random. I just imported stuff with names that sounded cool, and then went to the most common/famous ones too. Nothing is set in stone, we can easily add and remove modules.