Cardinal wraps Rack 1.x as a plugin as far as I know. My binaries are a standalone ARM port based on the latest VCV 2.X
If you’d look at the code you’d see that you are mistaken.
Talking about code, where is the code you used to create your binaries?
It is great that I am mistaken, need to build it and check what is the status there. Last time I checked I thought it was based on 1.x. The source is still not available, but it will become so on my github account. Need to polish it a little. Still very messy. It is basically a couple of commits on top of the latest VCV and inclusion of sse2neon with a couple of hacks there. The rest are compiler options and optimizations here and there.
“The “VCV” name is trademarked and may not be used for unofficial products.”
also see section “6. Conveying Non-Source Forms.” in the GPLv3
I’m not a lawyer, but I don’t think you should post your binaries if they’re breaking the terms of the license.
Very good note ! I will definitely have to change that ! I am not a lawyer myself and all I wanted to do is share an experiment mostly for fun. If I need to take down the binaries - please advise. I don’t mean no harm to the VCV project - just the opposite ! Maybe the only correct way to distribute this is in a source form and instructions how to patch and compile for ARM.
That would be the best way imho.
Or just mail it to firstname.lastname@example.org
OK. Just had a look at Cardinal and tried to build it on RPI 4/400. As is now it doesn’t build for Raspberry Pi 4. But with couple of small changes in the Makefiles and sse2neon I think I can build it this night. Then I can check the standalone performance and see how it compares to my binaries Thank you for reminding me about this wonderful project. Was unaware how far it has progressed !
You should just be able to run the arm64 build.
I want to compile and run it on what I have currently installed - the official Raspbian OS which is 32 bit. Actually the problem is not the OS even. I have some linker problems at the end of the build: missing -latomic somewhere, but need to understand better the project structure and the Makefiles to see where to fix it. I will leave it for another night, hehe. I had the same linker problem while compiling the regular Rack and fixed it in compile.mk and plugin.mk, but in Cardinal it doesn’t work for some reason (for now) …
Then you grab the armhf build.
At least check the GH-actions folder to see how it should be done.
There are a lot of people distributing modified gpl3 software in ways that don’t seem legal to me. I’ve asked the moderators to look into it. I may be completely wrong.
Grab ? Cardinal doesn’t seem to have binaries for download. Also the ARM build flows use cross-compiler and Ubuntu 20 as a base. Maybe I was not clear enough but I build natively on the Pi itself - I am using it as a desktop machine with the default 32 Raspbian OS. Currently building from source on Raspbian is not possible without changes in sse2neon and the Makefiles. Hopefully this will change very soon - I need some free time to get it working.
They do offer binaries
Follow this link: GitHub - DISTRHO/Cardinal: Plugin wrapper around VCV Rack to
right now, this is the latest run.
N.b. GH builds have LTO enabled, which is not default, because it takes longer.
OK. So I got the armhf build, but sadly I don’t see a standalone synth version, just the LV2,VST plugins. I need Carla (or other VST host) to be able to run this.
I have not tried it, and probably never will. Can’t help you there.
Fair enough and thanks for replying nevertheless. I am quite accustomed to getting things to work without any 3th party support. The current result is that there is no publicly available binary version of VCV 2 for Raspberry Pi 4. And we need to change that - be it Cardinal or VCV 2 that are to be used for a base.
And no vcv for amiga, atari or zx spectrum - but i don’t see it as a problem. The performance on a Pi4 is poor compared to a recent PC or Mac. Bad user experience, I can see why VCV doesn’t support the
architecture Pi 4.
Indeed the jack-standalone isn’t there, I thought that was built by default. Although it is specifically meant for testing it works quite well for most things.
Any reason you are using 32bit OS on a modern 64bit arm CPU?
No need to cross this out, they indeed do not support arm currently.
Main issue there is of course keeping the entire module library synchronized and dealing with non-optimized modules that particularly are bad for performance.