Apple M1+Rosetta2 came to mind. that’s why I struck it.
Well yes but I am sure I would not be the only one to love to be able to have a customizable mini FX unit or sequencer or synth for live use with other hardware, which very likely would be possible with an rpi4, don’t you think ? It being ready to download on the VCV page is an other question entirely, I get that it is less user friendly and would worsen the feedback on the software itself and it would be totally unfair, but a third party providing binaries or (clear for the noobs) instructions would be absolutely awesome and useful to a lot of people. IMO.
3 Likes
Sure, the more the merrier.
But it can only be successfull if it complies with the terms of the licenses that follow VCV rack. = sourcecode + no branding copyright violations (my non-lawyer opinion)
2 Likes
Aah. Because this is an app not a plugin, there are resource files involved/to be installed, so the project needs a deb package generator action.
But if there is anything wrong with a straight clone, recursive submodule init, make PREFIX=/usr SYSDEPS=true, make PREFIX=/usr SYSDEPS=true install (going by the Arch PKGBUILD), create an issue.
falkTX is looking to make a standalone Linux app artefact possible;
Waiting for test builds and ironing out the details to get it right atm…
1 Like
Hey all, first post on the forum, glad I came across this thread! I understand that the topic has been solved, and please direct me to a different topic if a better one exists or I’m happy to create a new one if that’s the right thing for this post.
I recently got the great @hexdump’s VCV Rack 1.x ARM build running on the 2020 firmware of my Percussa SSP. I wanna say it was a recent rack.armv7l-v1.tar.gz from Releases · hexdump0815/vcvrack-dockerbuild-v1 · GitHub but I can’t recall exactly which one. It was really just a proof of concept for myself and I wasn’t intending to really dig in until recently learning more about the significant limitations of the SSP’s native interface and its core developers’ future outlook which, to say the least, is not my cup of tea.
So now that I’m confident I can get at least VCV Rack 1.x running on the SSP (including being able to address its built-in ALSA based I/O and such from within a patch) and I’m more than ready to jump ship on Percussa’s native interface I’ve decided it’s time to look around to see if there’s any hope of a VCV Rack 2.x port that might work.
Well, low & behold here I am. Even if it’s obnoxiously overpriced for simply serving as a computing vessel (with lots of DC-coupled I/O though) to run the software I hope that the SSP could be a hardware platform that complements VCV Rack 2.x in ways a boilerplate RPi form factor lacks in modular-relevant hardware capability. I’m not a kernel dev or hardware guru so I’ll be giving this a totally noob-ish go, therefore I’m reaching out to see if there is anywhere more recent relating to ARM builds of 2.x and especially somewhere I could get patches that would allow me to try and cross compile using Buildroot etc. (I don’t even know if that’s applicable in this situation because I’m so inexperienced in these areas but who knows, maybe I’m onto something?) that would be a fantastic help!
Thanks in advance for humoring my total incompetence here and hope everyone is doing well 
1 Like
@tapemachine - i have given up to provide arm builds for download since v2 due to the restrictive licensing of vcv (some of the core module front plate designs seem to have a non redistributable license) but i’m building it myself for myself from time to time and the build framework and patches are available here: GitHub - hexdump0815/rack-dockerbuild-v2: docker based build based on the vcvrack v2 sources on armv7l and aarch64 on ubuntu 18.04 and raspbian bullseye and i’m trying to keep it up to date from time to time
good luck and best wishes - hexdump
2 Likes
Do you have instructions for building this and getting up and running on an RPi4?
1 Like
Very interested here too ! 
some basic instructions for building it are given in the readme of the repo - i would suggest you to use the 64bit version of raspberry os as 64bit arm has much better cpu instructions, so that vcvrack uses around 20% less cpu for the same patch on the same hardware (vs. 32bit) - another advantage of the 64bit os is that it essentially is nearly a normal 64bit arm debian, so everything should work fine … i by myself am not using raspberry os and not really the rpi, so cannot really help otherwise
good luck and best wishes - hexdump
Thanks again for sharing all this! Great to have a version of your docker setup for Rack v2!
I’m using Linux so I chose to adapt your work into a cross compilation setup on my Debian laptop, it was fairly easy but a little hacky. I can confirm that it works!
I’m using a Lepotato by Libre Computer (Amlogic S905X) I remember you mostly use TV boxes, did you spot some cheap yet powerful arm64 boxes? I’d be super interested!
@pgatt Have you had the occasion to try this by yourself? I don’t have an RPi to test it on but I guess my build will run on it.
Before sharing precompiled distributions of Rack for arm64 I want to make sure it won’t infringe any redistribution clauses. For that I think we should aim at only distributing the binaries that can be swapped in place in the official release and plugins.
i stopped distributing binaries as the licensing got too complicated and unclear for me … the best hardware i can recommend right now for cheap linux on arm are mediatek mt8183 based chromebooks (kukui) - they are faster than an rpi4, have no thermal problems, there are plenty different versions of them available and you get a keyboard and display with them for free … with a bit of luck it should be possible to find a used (or even new) one for around 100 $/euro - some more info can be found here: imagebuilder/systems/chromebook_kukui at main · hexdump0815/imagebuilder · GitHub
best wishes - hexdump
I still have a raspi 4 lying here, waiting for something-VCV with a step-by-step-setup for dummys. I would love to use it as a pure sequencing-tool to add euclidian rhythms, random melodies, arpeggios etc. to my outboard gear without using a PC or Mac… If anybody has something working, that not requires a linux-brain, that would be awesome!
1 Like
I’m no expert, but a lot of VCV modules seem to have a GPL license, sometimes with a different license for the graphics. At a bare minimum, GPL seems to require that any re-distribution requires attribution so that end users know what they have. It must be possible/easy to get from what you re-distribute back to your source code. I have seen many ppl put up a dropbox folder with compiled binaries and nothing else. That may be allowed by some licenses, but I think it is not allowed by GPL-3. but I’m no expert…
Every Rack plugin comes bundled with the plugin.json containing attribution, so I don’t think it’s an issue.
1 Like
Good point! I think what you mean - in more detail is:
If a plugin in GPL-3 licensed:
- make sure the panel and other graphics do not have a different licenses (not gpl). If they do, make sure to follow those if possible. If not possible, make new graphics.
- fork the original plugin.
- make the fork publicly available.
- modify the make file, the plugin.json, and anything else that needs to be modified, commit that back to your fork. 3b) Make sure to change the attribution, author email, etc in the plugin.json to point to you and your modified plugin.
- It’s probably not necessary to add explicit attribution pointing back to the original author, as a sophisticated users can see from the fork what the source is. (gpl-3 does require some sort of attribution, in any case).
- now the compiled binary may (probably) be distributed.
Did I get that right, more or less? (caveat - I’m not an IP lawyer, don’t rely on my advice for this stuff).
1 Like
I sorta think so, but I’m no license expert either, so I would call on people like @dreamer and @falkTX to correct us here.
-
Follow all licenses, yes. Where I’m still in doubt is about the term “derivative” in those ND graphics. Does “derivative” mean: A) You changed the graphics, or B) You changed any sourcefile (including the manifest?) in the codebase where the ND graphics is located? I sincerely hope it’s not (B).
-
Yes, if copyleft (GPL*) the source just needs to be available somewhere. It can even be by postage.
-
Same as (1)
-
Yes. I think mostly the Makefile wouldn’t need to be modified for a simple fork.
-
I don’t think copyleft licenses require any attribution back to where your fork originated, only that you can provide the sourcecode of the fork. The other thing I think is strictly a courtesey/informational. At any rate, in GitHub forks you get it automatically.
-
If you followed the above, sure, no problem.
I’m certainly not a lawyer either, and I kinda despise the whole open source lawyering thing, but sometimes you can’t really get around it.
Sounds right. I think the reason this open sourcing get so complicated is that the vcv use case makes one want to “copy” hundreds or thousands of products, and then redistribute them in binary form. I know aspects of this are not unprecedented, but it’s a lot more difficult and complicated than the “normal” case, which to me is taking some open source code and combining it with your own source code to make something new and clearly legal.
I will say that for even that simple case I’ve nagged people to attribute my source code correctly when they use it in otherwise perfectly legal ways.
I actually think the other way around is mostly true. Distributing simple modifications to simple codebases should usually be trivial, but combining sourcecode trees from different projects, where the license deviates even a tiny bit, can be a complete license nightmare or impossible. The different GPL versions aren’t even compatible amongst each other in many cases. Looking up a matrix of what licenses can be combined with what licenses makes anyone wish they weren’t born at all.
1 Like