I know this has come up a few times, but I have instructions! I spent a week getting things to build and working out errors, and I set up a github that contains a small patch and build instructions to have Rack working on your Raspberry Pi. I am still compiling (pun intended) a list of plugins that build out of the box, but the ones I have checked are listed in the documents in the repository. The picture below is Rack running on a Pi 4 with 8GB of RAM, though it doesn’t need that much as it barely touches it. At the time, it was powered by a 20,000 mAh battery pack, which lasted about 9 hours with USB speakers, a touch screen, an additional monitor, and a keyboard plugged in.
My repo is at GitHub - DragonForgedTheArtist/VCVRack-rpi: VCV Rack build instructions and patch for Raspberry Pi if you want to check it out. I could use help testing the existing open-source modules if anyone wants to pitch in. Right now, I’m just checking to make sure they build without errors and show up in the module browser. Actual testing comes after. The patch just adjusts a few of the makefiles to fix some architecture detection issues.
The hassle of an unofficial VCVRack build that is never going to be supported plus needing to manually build all plugins, some needing fixing too… isn’t it a better idea to have something that builds it all in 1 go?
VCV cannot legally take pull requests or code patches so keeping a custom fork/patching is always needed, that also means most projects have no incentive to support a Linux ARM build either.
And you cannot do a proper alternative build without quite some effort, as we cannot use the VCV name or logo in unofficial products (this means replacing all Core and Fundamental panel designs)
Speaking as someone who tried this at first, it just becomes unmanageable at some point.
Yes. I looked at Cardinal first. The inability to add additional plugins makes it a bad fit for me. As does it being a monolithic build and the inability to select which midi/audio interface you want to use. If I must soldier on alone, so be the way of the world. However, chewing me out for stepping foot in the darkness wasn’t necessary.
It is an honest question, I would have joined efforts for something similar if it existed.
Previous attempts at something similar seem to have died and due to forum rules we cannot talk about them here.
I have no bad intentions, just hoping to see more efforts being put into the same pool rather than everyone doing it their own way.
The monolithic build is a side-effect from focusing on a plugin version, wanting to do it proper and avoid function/symbol conflicts with system libraries. Plus helps a lot on the porting process to new platforms, that is why the web/wasm builds and BSD work “out of the box”, recently RISC-V too and I have heard of people using it with PowerPC machines too.
Each porting effort needs to deal with the same things, in my opinion it is best to consolidate this in a single place so any other/new porting is easier to do. I still have hopes to see Cardinal running under HaikuOS, already verified that everything builds it is just the GUI part that needs a bit of custom code (similar to the situation with web/wasm builds)
I see bacon and air win are on your list as not loading.
The reason for this is because the 2.3.0 SDK names -arm64 plugins as plugin-arm64.dylib or .so so most likely we built the wrong target
The 2.4.0 SDK reverts this behavior and i just pushed both these packages to head to restore them
I also see surge doesn’t build. we build it for arm all the time so happy to look at an error message. My guess is you are using a relative dir for RACK_DIR and the simde path is blowing up - like you get a simde include error from globals.h. If this is the problem replace RACK_DIR=…/foo/bar with RACK_DIR=/this/that/foo/bar
i fixed surge at head for the relative-rack-dir problem. if you build the 2.1.7.0 tag (which is the production tag) you will still need to absolute it yourself. lemme know if they work for you now.
@baconpaul Thank you! I was just about to start tackling the “not building” list and I will start with those. My goal is to get things working as close to out of the box as possible. Right now the not loading list is what I couldn’t get working on the first pass and hadn’t had a chance to run diags on.
I was able to get Airwindows and Bacon Music moved off the not building list, but with Surge XT, I’m getting the following error whether I use the standard plugin build instructions or the instructions in the github.
That got us a little further. Makes sense. OSX is basically linux with apple’s sugar on top. Still getting stuck about half way through. Thanks again for the help!
[ 42%] Built target tinyxml
Scanning dependencies of target surge-common
[ 43%] Building CXX object surge/src/common/CMakeFiles/surge-common.dir/DebugHelpers.cpp.o
c++: error: unrecognized command-line option ‘-faligned-allocation’; did you mean ‘-fsized-deallocation’?
make[2]: *** [surge/src/common/CMakeFiles/surge-common.dir/build.make:82: surge/src/common/CMakeFiles/surge-common.dir/DebugHelpers.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:966: surge/src/common/CMakeFiles/surge-common.dir/all] Error 2
make: *** [Makefile:171: all] Error 2
It’s actually bsd with nextstep sugar on top but I get your point
At this point it’s a matter of find the condition that triggers the offending flag in the cmake and condition it away. Just hunt and comment and rebuild.
Surge builds fine in an rpi - quite a few of us build it regularly as a vst - so all the problems are make system mismatches between what Linux arm needs and how the rack make sets things for arm, since the vst understands non mac arm but rack does not
If you have some consistent make flag you set (Arch Linux arm) you can use that to pass a different flag to the subordinate cmake. I would be happy to merge changes so conditioned to surge even if I didn’t exercise them myself
you may get 2 PRs from me. Right now I’m trying to build surge standalone to see what kind of information it will give me. I expect it to fail due to a know issue, but I have this…
#!/bin/sh
PIFILE=/sys/firmware/devicetree/base/model
if [ -f $PIFILE ]; then
PITEST=`cat $PIFILE`
if echo "$PITEST" | grep -q "^Raspberry Pi"; then
PI=$PITEST
fi
fi
echo $PI
yeah so i more meant : you are going to maintain a fork of the rack build system for a while to build on pi. That for is going to set something like ARCH_LINUX and ARCH_ARM or some such for the rpi
right now the surge makefile has branches for ARCH_MAC and ARCH_ARM or not. But not for ARCH_LINUX
so if you modify the surge makefile for (whatever flags your modified arch sets), as long as it doesn’t break the mainline library builds I’m happy to do a merge.
my guess is you would, somewhere in the Makefile, do something like
then you can just write normal cmake conditions based on that as you go and not have to set the OSX architecture.
See what I mean?
surge vst already has all of this done internally if you build on raspbian64 with a recent enough gcc and cmake. but we have to change some of that for rack, hence the CMakeLists and RackSDK.cmake in the surge project.
That took three days and was painful. I got a build, but it was not at all intuitive. Had to disable the window oscillator because of an error I couldn’t track down and didn’t get an vcvplugin package. Will probably get it’s own .md file.
