Stoermelder for Rack 2?

I have tried out Rack2, and it’s super rad and cool. BUT…

A big part of how I compose with Rack is using the 8Face to save snapshots of modules.

Earlier in the beta process, I was able to build the v2-dev branch of Stoermelder-PackOne but the 8Face didn’t seem to work at all with Rack2. Now, it doesn’t even compile. @stoermelder’s last commit was in October.

I know that Ben’s work on this is a labor of love and he’s doing things that exploit the Rack API in ways no one else has considered. Just curious and feeling impatient.

If you’re still using V1 as a primary tool, give 8Face Mk2 a try, too. It is amazing to be able to change up sequences/quantizers/voice parameters with one click, AND to sequence them as well. It’s a new way to organize and sequence compositions!


As a temporary measure, Steve Russel has made a fork of Stoermelder that compiles and works fine in the latest betas 1 & 2 (he’s also sent Ben a Pull Request and I should add I haven’t tested 8face specifically)

1 Like

@chaircrusher What OS are you on?


I looked at that fork you mention. And I looked at the license for the original modules, which states:

  5. Conveying Modified Source Versions.

  You may convey a work based on the Program, or the modifications to
produce it from the Program, in the form of source code under the
terms of section 4, provided that you also meet all of these conditions:

    a) The work must carry prominent notices stating that you modified
    it, and giving a relevant date.

I think this is a modified version of the original, but it doesn’t carry any notices at all that I can see. In fact the readme seems to be unmodified and uses the word “I”.

I’m certainly no expert. Do others think that making a fork like this with no modification notes is compatible with GPLv3?

I think he’s using a github fork to try and get things working properly, and as he stated he has a pull request outstanding.

1 Like

I got the Steve Russell fork, checked out v2-dev, built it (using a locally built Rack version instead of the plugin developer kit) and installed it.

Same issue. At least in the case of my test patch, it isn’t updating @jeremy’s NoteSeqFu after saving a couple of presets.

Here’s my test patch:

2021-11-29.vcv (7.5 KB)

Sure. Are you saying “and therefore it’s legal to do in a public GitHub”, or “and therefore the time duration will be so short that the license doesn’t apply”?

I’m saying that there’s a difference between having a public fork on github, and having a fork to improve/fix bugs, via pull request.

In the second case, it’s not like the forkers are releasing a derivative work. They’re trying to fix/enhance a plugin, and submit pull requests.

By me checking the forked repo out and build it, I’m helping the forker (Steve Russell) test his code. No one is doing anything that would violate the terms and spirit of the license. No one is ‘conveying a work’ – they’re working on modifications to be merged via pull request into the actual official plugin.

Or am I missing something?

You may be right. I interpreted publishing a public fork is “conveying” it. Of course I know that everyone has honorable intentions. I just don’t know if they are legal.

1 Like

I don’t think the license is supposed to account for intention. Like if you can’t convey it for a “bad” reason you also can’t convey it for a “good” reason. Very few laws that I know of take intention into account, and then ones that do are a mess.

Again, I admit I don’t know the answer, but If you aren’t allowed to fork a repo, modify it, and make it publicly available, then you aren’t allowed to do it. Even if your reason is "I’m only going to modify it, test it, submit it back as a PR, then un-publish it.

In summary, I don’t think there is a meaningful difference between two things you mentioned. At least not meaningful to IP laws.

True, sort of. It seems what this person has done is make a public fork on github. As Bruce points out, the licenses doesn’t really care why, so in this form the licenses is likely violated.

The improve/fix bugs/pull request workflow shouldn’t require forking. Anyone can clone the original repo locally, create a branch, work on it, push the branch back to the original repo and create a pull request based on the branch. This would be allowed by the license as the 3rd party dev is not publishing their own version/fork.

That sounds right to me. One could also give some people access to a private fork to support this kind of testing.

Unfortunately I think a lot of people are doing this right now - making a public fork of GPLv3 code without crossing all the T’s.

I dunno, Didn’t read it all, but these are prominent enough for me:

so your interpretation of “prominent notice” is a github commit without a comment, leaving in place the readme that suggests the opposite? well, like I said, I don’t know for sure. So maybe?

the readme for the audible instruments fork has Andrew saying:

" The panel graphics in the res/ directory are copyright © Emilie Gillet and are used and distributed with permission."

I think a quick reader might think this implied that steverussel33 got permission from Emile Gillet to re-distribute those images, but I’m guessing that actually Andrew Belt got that permission. But it could be that the permission was “anyone, anywhere can use these graphics”, I guess.

I see your point - @Steve_Russell probably should have kept the forked source private, and only published patches.

1 Like

Let me nip this one in the bud.

A fork of a public repo cannot be made private for security reasons. So what you’re suggesting is impossible.

Forks of public repos for PR purposes are made all the time. Policing the enforcement of licenses is going to be a problem. Most of these “PR use only” forks are deleted once the PR is merged or rejected. This is the approach I and many others use.

The only time lawyers are going to turn up is if there’s a complaint from the original repo owner/copyright holder. How’s that going to work out? It won’t, because all the forker has to do is get the original owner to merge the PR (if done so, there’s no case) or the owner/holder rejects the PR and tells the forker to delete the forked repo used for the PR = there’s no case.

Tech note: even if a forked repo (along with any branches, obviously) is deleted and/or the PR is rejected, the code remains part of the closed PR on the orignal repo. So it’s not like someone cannot come along look at the modded code and fork a repo themselves and add the PR code manually. You can even add closed PRs as new branches at the command line to a fork.

That sounds sensible. How many years do these PR’s stay open for usually? In your experience, that is. Proposed fixes for Tides envelope modes bug & Warps algorithm LED colours by SteveRussell33 · Pull Request #87 · VCVRack/AudibleInstruments · GitHub

AFAIK they stay open for as long as the repo that the PR was posted to exists. Delete the repo, everything gets deleted along with it. Forking a repo that has PRs doesn’t copy those PRs over to the fork, for an obvious reason.