Would Any Rack Plugin Devs Like To Join The Surge Team?

Huh how do you build? We use an ubuntu 20 action to build in GitHub actions and it builds fine

And no all these dependencies are new. We rebuild surge with juce and I think will be the first plugins in rack to use juce

Also, obviously, Steve etc let’s hold off on investing anything in these plugins until we know if the rack build environment will build surge or not. We’ve built it in every other place we’ve tried so far but you never know maybe some rack choice excludes the project.

All plugins must be build-able with this toolchain:

Github actions usually introduce additional packages and things that make it look like it is working, but it will still fail on the official toolchain build.

Any adjustments necessary to the toolchain can be discussed.

OK thank you.

Lemme see what I can do, if anything. I did have one idea which means we could expose almost all of surge to rack without the juce dep perhaps.

I would suggest installing the official toolchain, at least for Linux. It’s not too time consuming. I installed it for all three so I could make builds for ppl. Anyway, without knowing more, it’s not clear to me why your deps can’t install this stuff.

Also, @cschol might make small mods to the build process to accommodate you. If the changes are small and reasonable. (just a guess).

you mean I can do an apt-get in my deps stage?

rack really is a foreign environment compared to where we build surge (which is on basically every environment we found but using the native toolchain). But I’m trying to make it so you can at least build a subset of it without the juce dependency, and it will just make a few modules impossible.

(it also doesn’t help that my primary dev environment is a M1Max mbp with clion which works pretty poorly with the rack dev so its all a bit clumsy but will see what i can do).

oh, probably not. that leaves modifying the build process… But I guess if you can get around it…

yeah right so surge ships with all of its deps. It just requires git, MSVC and CMake on windows, Xcode and CMake on mac, and gcc and cmake and the juce apt dependencies on linux. (We can also build with clang on linux and some people have tried mingw on windows but its very slow) We’ve built on ARM, X86, most linux variations, win 32 and 64, and more.

Rack provides an environment which is nothing like that though. Hence the problem.

And the fact that GitHub actions aren’t a reliable predictor of success really really makes it hard. Has anyone set up actions which use the docker image instead of the native stuff? @qno - thoughts?

No. Ubuntu and apt are only providing a small baseline for the cross-compilation environment. You cannot assume to have access to any package manager during the build process.

Again, Rack’s plugin build environment has different goals and therefore is different. Ultimately, you are likely doing three native builds for three platforms and you assume to have all of the tools of the native environments at your disposal during the build process (e.g. apt). Rack only has a minimum baseline available for all three platforms to provide one cross-compilation environment.

All build dependencies must to be provided in a cross-platform fashion, e.g. compiling libsamplerate from source for all three platforms during the build process instead of relying on a (platform-specific) package manager to provide it. Special cases like platform-specific tools are generally avoided.

Building the Docker image for all platforms requires a macOS SDK, which in turn requires you to adhere to the macOS SDK licensing. Therefore, we cannot provide a turn-key Docker image for all platforms to be used for CI/CD pipelines. The Rack toolchain source is available, so developers can build their own version and use that to test their build process.

Also, you can build a Github Action-based CI/CD pipeline that very closely matches the rack-plugin-toolchain and will give you correct feedback. You just have to understand the goals of the build environment (one cross-compilation environment) and adhere to its rules, e.g. do not rely on the convenience of a package manager, because it is very likely not cross-platform. See the rack-plugin-toolchain repo for the Makefile that sets up the build environment for cross-compilation. It is separate from the execution environment, e.g. in Docker or, in this case, a Github action. The macOS SDK consideration still applies, though.

@pgatt has successfully built the toolchain with an M1 Macbook Pro.

Im curious why rack made this choice. Surge deploys to a similarly sized audience and we just do automated builds on mac, win, and lin using the baseline tools. But that really doesn’t matter I guess; you have decided that and so either we adapt to it or don’t upgrade surge.

But anyway I’ve removed the juce dependency (which will limit some of the new stuff from being exposed to rack) and that should eliminate most of the pkg-config calls. I’ll get it pushed today and maybe someone with the docker environment could give it another run.

And I built it in an Ubuntu VM running on my windows computer. “borrowed” the Mac SDK from my wife’s mac. Never tried the docker. don’t know how to dock on windows.

Personally I prefer a clear computer interface AND a clear hardware interface and I get frustrated with both if there’s a learning curve where there’s no need for one.

Making VCVRack more skeumorphic doesn’t serve either people coming from the hardware world and people coming from the ‘I saw a cool thing on the internet,’ For hardware geeks, it can never be analog enough, and for n00bs, they don’t care about what its emulating, they just want their computer-user skills to apply to Rack as well as it does other programs.

I tend to agree with you. But there are people who like mystical panels with mystery symbols on them. And I think a majority really like the skeuomorphic UI’s.

I was never happy when ppl would say “I never use your modules, they are too boring looking”. While no excuse for my bad art skills, to some extent they were boring on purpose. Legible text, easy to understand controls (and instruction manual!). Well, it’s a big world out there, with lots of different ppl.

1 Like

Given the number of Rack users - and I don’t think @vortico or anyone else has said how many people have gotten as far as downloading Rack and starting an account on VCVRack.com.

But I think it’s a fair guess that the majority of Rack users have never been in the same room with a hardware modular synth, much less used one and gotten hooked on ‘knobiness.’

Given that I’m not sure if the majority of users are attached to skeumorphic interfaces.

And the worst of both world is when a module/VST/whatever duplicates a hardware interface to a ‘classic’ synth, complete with all the compromises the synth maker made to make an affordable front panel interface. Looking at you, Arturia!

How many people on earth have used a Prophet V clone VST, versus the 6000 Prophet 5s that were actually built?

I’m definitely not a developer, but I am a graphic designer. I’d be happy to help with designing new module panels.

Because it is less complexity for Rack’s use case once it is set up (which it is now). I can do integrations on one machine (Ubuntu), and within 2 minutes usually have a good idea if there are integration issues. Same for official builds. A much simplified build pipeline on Andrew’s build system, which produces the releases plugin builds.

Sounds good. I am happy to test and work with you to get this to work. I really like Surge in general (I use the VST mostly) and want to see this continued to be available in Rack.

4 Likes

Yeah I didn’t mean to complain. You build how you build you know! It’s just really really really far away from how we build!

Anyway I just did a push which removes the juce dependency. Like I said this means we can’t provide a couple of FX and there may be one or two edges which don’t work in the wavetable oscillator right now (but I can fix). But it would be great if you could give it a whirl again.

You will need to re-pull main then do a submodule update then remove the directory surge/ignore completely, then remake deps and plugs. (And is there a way a module can add custom content to the clean rule? I can’t figure that out).

Thanks so much!

1 Like