Repos, Plugin Bundles, and the Community Library

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?

Thanks as always!

I would simply add the new XT modules to the existing surge plugin

1 Like

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…

1 Like

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.


shared code.

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

Make a new Plugin. Old patches still work & users can unsub the old Plugin if they’re ready to to convert to Xt.

Personally I’ll keep both


“most work for you, more free benefit for me” ™

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.


I think this is what Paul would prefer to do - it’s just a matter of what is the best way to go about it while maintaining the common codebase.

1 Like

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).

Thanks for the input all!


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.