I think this is a question for @cschol but I will just push it out there to everyone
A few of us are embarking on re-building the surge rack modules and we just had a kick off today. Some really great ideas, but just like with Surge XT which was a different plugin than Surge, I don’t think the new modules will be the same names, modules, behaviors, ports etc… as the current surge ones. So we would like to make a new module collection and keep the old Surge ones around just for compatibility on patches. That leads to a question
1: Any concerns there generally beyond the one below?
2: Even though the modules are separate, there’s code continuity for many parts. So Ideally I would use the current surge-rack repo and just modify plugin.json and the makefile with a commit. That means the surge module would be surge-rack at commit abc and surge-xt would be surge-rack at commit def. Any concerns or do I need a separate repo for the community process to work?
Pretty sure that won’t work. To build XT in the rack environment we had to turn off some of the XT features which means a couple of the existing surge 1.7 modules don’t make sense any more. It’s a different module set because XT is such a different synth than Surge 1.7.
But if you’ve looked at the code and build and see a way around that we would welcome contributions! Maybe we missed something.
that’s clever, if a little offbeat. The build system just cares about the SHA number, so it sounds like it would work. using a common submodule and two different repos might be a more “normal” way to do it. That said, your way sounds way easier.
Building two “things” from the same repo in VCV seems much harder than it “should” be…
Disclaimer: I’m a novice VCV Rack developer, but a multi-decade experienced developer in general. My gut feeling is it would be far cleaner in the long run to fork to another repo or start another repo from scratch. Avoid entanglements and murder irrelevant old code without mercy.
Yeah that’s not a bad instinct generally but the continuity in the dsp is very very high. With surge we kept a linear repo and I think we can here also. If we made a new repo tbe first version would just be head of the current version to avoid typing in all that code again
I might add a new repo anyway by the way it really depends on the community library process! But if I did that repo would have git continuity back to epoch so it sort of seems like a choice I don’t have to make barring the library
LOL. I just answered the man’s question. I was agreeing with him.
If it was me I’d use branches based on the common code base. If you need to update the common code, fix it in the common ancestor branch, then rebase the two versions on the that common branch. Submodules get you there too but I haven’t learned anything about them because never had a reason to.
But I’m good with them just sticking them in the same plugins under different name. Or whatever.
Yes it will be a new plugin for sure. Probably later today!
The question is do I need a new repo?
If a repo called abc builds plugin Foo at one hash and bar at a second hash does thst work for the library build? Or is plugin : repo a one to one
If you check out the surge repo at tag release_19 it builds a plugin called surge. If you check it out at release_xt_1.1.1 it builds surge xt. Can I do the same in rack and have the community build work?
Anyway I realized the answer doesn’t actually matter that much. if the library does need a separate repo I can just do a fork/clone on every release to a repo. The code can stay continuous and we can work there. Appreciate all the input (also the head of surge-rack now builds surge xt rack modules and that co-loads with the surge 1.7 ones in the library without problem, but the new ones basically aren’t working now).
The library consists of git submodules whose SHA points to a SHA in the plugin repository. So all we need is a plugin repository reference to add the submodule and a SHA within that repository. There is precedent of multiple plugins being built out of one repository.
so sometime in the next few months i’ll open a new library issue for the new plugin then, and it will just be a different sha on the same repo that builds the old plugin. Great.