I didn’t know that you could not set it to private.
I guess you have to only clone the original to your own storage then - and make a new github repository for your patches ?
I’m sure you can figure something out to be compliant with the written wishes of the copyright holders.
And I agree - it’s a minor issue - very minor.
It’s whether the repo is publically visible or not; any repo where you’re not the owner or a contributor is read-only irrespective of visibility.
Yes and then make the new repo Private under Visibility settings. Although this would only be useful for local testing. You can’t make PRs across repo’s only forks.
Never been an issue, and for the reasons stated in a post of mine above, it never will be.
If the owner/holder doesn’t want PRs they can close them as they come in, and post a message to the end of the PR for the forker to delete the fork.
hopefully not. Certainly it won’t be for you, because it’s pretty clear you are doing exactly what you say - mainly submitting PRs for bug fixes. Nice!
But there are real issues here. Just for a little history, it used to be VCV’s official policy that if an owner of a repo went “MIA” for a month that anyone cloud clone their repo and submit it to the VCV library, where it would be accepted. This policy created several flame posts from a developer, and was pretty visible.
At some point this policy was rescinded. I think it was when someone pointed out that it was in direct conflict with other VCV policies.
Now there are several (many?) cases of developers who have not (yet?) updated their modules to VCV 2. So some people are porting these to V2 and letting others knows that the enhanced versions can be found on the forked repos.
I believe that in some of these cases the original developers have no intention of ever releasing these ports. If there are cases like that, unlike your case(s), these people may be inadvertently violating both the wording of the license and the wishes of the original developers.
I don’t have that issue. When I decided to get out of the VCV module rat-race I announced it early, and explicitly gave a dev permission to port the modules, and even submit them back to the library.
For other devs who choose not to update, I can’t really say what their reasons may be.
In the case of this particular plugin, I guess we are waiting for @stoermelder to let us know what his plans are for his modules.
Just jumping in on this, not that I’m an expert on GPLv3. The ideal outcome here would be a word from @stoermelder, because we’re in a friendly and functional community that we all value and we all want to respect each other’s intentions and boundaries. But I think the choice of GPLv3 license expressly permits what @Steve_Russell is doing, doesn’t it? The only question I can see is with section 5(a), which @Squinky quoted, and I have a suggestion about that.
For anyone who wasn’t around, the issue that @Squinky is rightly raising to had to do with admission to the VCV Library, because Andrew (not @-ing him because I am sure he’s pretty busy right now) has implemented additional “do not clone” Ethics Guidelines, which I think is a very good thing, and which, now that the “takeover” rule has been removed, would also apply to @stoermelder’s work (absent permission from him). But, as the manual notes, those guidelines may go beyond the legal requirements, and in this case they do. As I understand it: inside the library, cloning is forbidden and plugin and module slugs are centrally maintained; outside, only existing law governs, and for GPLv3 plugins, there are very few restrictions. There’s no attempt here to resubmit the modified plugins to the library under the same slugs (or different slugs).
That said, forking is pretty definitely “conveyance” so section 5(a), which @Squinky quoted above, would probably apply when the code is modified:
The work must carry prominent notices stating that you modified it, and giving a relevant date.
The commits and repo change that @Jens.Peter.Nielsen mentioned above might be enough, but I’d mildly suggest that anyone who is doing this (extremely valuable and community-minded) work should consider adding to the top of the original README something like:
This is a fork of {ORIG_AUTHOR}'s original plugin made on {YYYY}-{MM}-{DD} intended to help the original author with migration to Rack V2, and any modifications will be submitted as a pull request once they are tested. If {ORIG_AUTHOR} would rather these modifications not be made public, they should contact me and I will delete this repo immediately.
This seems to me as though it would satisfy the GPLv3 while being courteous to the original author and clarifying for anyone who runs across the fork, especially if they get there without context. And (as I suspect will almost always be the case) when the original author comes back from vacation/day-job/whatever, they can easily accept the pull request except for the modified README and thank @Steve_Russell or whoever’s doing something similar for all the help!
Yeah, I agree. I’ve seen quite a few ports where the readme has been clearly changed to show the history. Some are super classy, like the stuff @netboy3 has done. Of course those must have been done with explicit permission, since they are in the library.
found this while searching the forum. seems like he does have plans to update.
there is also a v2 branch in his repo.
while i don’t feel like its appropriate for me to speak on his behalf, i do believe its appropriate to assume that he hasn’t abandoned the modules he has made, and that we all love.
Could be. The last change in the repo is from two months ago, isn’t it?
Believe me, I can be patient, and I will keep using Rack 1.1.6 for projects expressly because of @stoermelder modules. I’ll really miss Blamsoft as well, & hope they take the time to update to Rack2.
The fact is, Stoermelder stuff - 8Face Mk2 specifically - completely inspired a new way to compose music for me.
Being able to snapshot a whole set of modules, including quantizers & sequencers means that it’s easy to do what’s actually the hardest part of working with a modular synth - changing. With a hardware modular, you pretty much have to record, repatch, record, and then edit a performance together. You can’t make a unified performance where you change things in the moment.
Paradoxically being able to do that combines two things: spontaneity and pre-planning. And because of how 8face works, you can also swap in a whole new ‘scene’ and then tweak and mutate it live, without losing your original work. And save the transformed scene to a new slot, so that the next performance can improve by using some of the moments of improvisation from the last.
I lied, I’m very impatient. 
You lasted a whole 3 minutes! 
Is Stoermelder no longer active? Did I miss something?
Is Ben ok?
In the absense of any word I have to assume @stoermelder is fine. If you’re maintaining a complex open source Rack plugin, sometimes real life has to take precedence.
I know @Steve_Russell forked Stoermelder PackOne and got it building for Rack2. But it’s not fully functional.
This makes so much sense. If I understand you correctly, you use 8 face as a way to save “sketches” of a patch, or module settings. And then once you have a couple, switch between them to see what works best? I’ve got to try that. BTW, I really enjoy your compositions.
Think of it like presets - but presets for groups of modules, not just one. Sequencers, quantisers, voices etc. So when you change presets, the sequence, scale, timbre of the voice etc can all change at the same time. You can then jam on a preset and either save it as a new preset if you like the results or return to the original preset to get back to how it sounded originally
You can then sequence those preset changes… it’s very powerful and versatile. You can build entire arrangements this way and then re-arrange by just editing the one simple sequence controlling the order the presets play in.
I just saw Omri’s new video with Bitwig and VCV VST and in his library, oh yes…Stoermelder!! That just made my day.
Seems @stoermelder is working hard behind the scenes to port everything properly.
This community is the best.
I don’t want to spoil the excitement, but that is probably just an older beta version from the Github PR that is waiting for follow-up.
The older beta version seems to works “fine” in VCV Rack 2 release, i have it here, i can load all modules, no crash.
However, there is a very big reason we have not heard from Ben yet, as he clearly stated that he wanted to wait until VCV 2 was done. The Stoermelder plugin was based on a lot of tricks and “exploits” if i may call it that, to do super cool stuff that wasn’t available in VCV 1.
But a lot of those tricks, will need re-evaluation. As some newly introduced features of VCV 2 (as module copy, group etc).
Will not work with some of the modules of Stoermelder (yet).
To put it simple, we will have to wait and for Ben, until he responds.
And mostly important, i hope he is well!!
Exactly right. Some deep hacks were involved in earlier releases. And likewise, let’s hope Ben is doing well.
Cheers.
That’s so cool. I’ve always just done a “save as”. But this will definitely open a lot of possibilities.
Ben has made, what looks like for now, an initial commit wip v2 - api fixes and more · stoermelder/vcvrack-packone@05de804 · GitHub that has a fix for 8FaceMk2, which I don’t use so I never picked up on the need for that change.
If you combine his commit with the rest of my PR, you’ll have, for the time being, a more complete build.