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?
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.
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).
And yeah, choosing GCC on windows is certainly the most unorthodox choice rack makes among the world of audio software. But we are working around it.
There will be some features which we can’t expose to rack with XT (the patch player will have to go and a couple of FX will not show up) but that’s OK. The majority of the stuff should work. One more change and I think cshol and i will have it down.
Well that’s because it’s not building on Windows is it
Cross-compiling for windows using gcc (and usually mingw) is very common. Ardour also does this I believe so within audio software it’s not that uncommon.
yes i understand that rack chooses to cross compile. but even on windows proper it still uses gcc. I think that is a relative rarity other than rack and ardour. certainly none of the other projects i’ve got commits on seem to do that.
But that’s ok we got it working just with some limitations! So all good. There will be some features where if you want the full fledged experience just go buy host and use surge itself but i bet a lot of the good stuff we can get into rack modules now we have this working.
(It’s also not just that it uses gcc; it is that it uses gcc in a limited environment off the native OS. We were able to build all of surge for rack in a GitHub actions environment on the target OS but that is different than the cross compile environment. Which is OK! Just we turned off those features.)
Yeah good point I could just hand cschol binaries off the back of our github actions rather than use his compile toolchain. I wonder if thst is a better approach? @cschol do any oss plugins do that? It means I could lift those restrictions we placed and it’s no problem for me to make binaries in automated way.
I changed CI builds for windows and linux to use the official Rack toolchain in Docker. It is based on GitHub - qno/rack-plugin-toolchain. As I mentioned in my post this is what I was already trying to do at first but it was not easy to get it working, but with your latest simplification it was possible. I still need to figure something for the windows build and I need to discuss this with @cschol at the Github pull request.
The CMAKE update is actually an issue in the Rack SDK in dep.mk. The current implementation only works in an actual native MSYS shell and not in our cross-compilation environment. No other plugins have used cmake to build their dependencies so it has gone unnoticed until in the past two days TWO plugins have tried and run into the same issue. dep.mk will be updated in the next Rack SDK release to handle this issue correctly.
@qno Updated the Github issue with additional information on the failing macOS build.
