Rack: Library version of Rack

[ncthbrt]

I'm interested in embedding Rack into a game engine like Unity to act as the sound engine. I was wondering if there is some sort of headless mode, and if not, how difficult it'd be to go about enabling such a feature.

[AndrewBelt]

Perhaps I could talk to Unity or Epic Games about funding for this feature, but my schedule is full until ~12 months from now.

[ncthbrt]

Thanks for the fast reply @AndrewBelt. It wouldn't be inconceivable that one or either of them would be willing to fund a feature like that. Completely understand in terms of time however.

[catronomix]

I'm also very interested in this! Not for games but for live performances. Imagine 8 old laptops connected to controllers in a live setup, where every patch can be switched out while the others keep playing. An arm build on raspberry pi's would be even more awesome. Rack Embedded® :D

[hexdump0815]

i'm currently having some proof of concept stuff in this direction working on armhf and aarch64 based on the rcomian multithreaded fork of 0.6.2c (plus some inspiration from mi-Rack) and i just built the current v1 dev version on aarch64 successfully, armhf will happen tomorrow. it is possible to run small to medium patches on arm with a bit of linux audio tweaking. the sse stuff is translated via the simde project. on the raspberry-pi the main problem is cooling to keep it running at full speed. i mainly work with android tv-boxes running ubuntu (rockchip rk3288 for armhf and amlogic s905w and s905x for aarch64). the headless part i'm doing by running vcvrack against a virtual xserver (Xvfb) and using xpra in case i want to access it. opengl is a problem: no support for the virtual xserver, so only cpu-bound software rendering which kills audio (so i simply iconify vcvrack on startup automatically which solves this problem) or mali plus gl4es for the non headless mode (its quite a bit of hacking to get mali working on those platforms, but doable - at least the lima and panfrost opensource mali opengl drivers are on the horizon now, so this might make things easier in the future). i'll polish all this a bit and will upload my build stuff and patches soon. i'll update here when ready. my target is as well to use all this for live setups. midi can go via usb2midi connectors or via jack in network mode.

[hexdump0815]

just in case anyone else is interested: here are some first vcvrack builds on arm 32bit and 64bit - you should be very familiar with linux on arm, mali opengl there etc. if you want to try to try it:
https://github.com/hexdump0815/vcvrack-dockerbuild-v0
https://github.com/hexdump0815/vcvrack-dockerbuild-v1
otherwise stay tuned - i hope to make this easier to use in the future ...

[hexdump0815]

there is an update on my vcvrack headless arm efforts: the sonaremin - https://github.com/hexdump0815/sonaremin

[hexdump0815]

just a little update: the sonaremin has been updated to vcvrack v1 meanwhile ...

[spacepluk]

This is not possible after the relicensing, is it?

[AndrewBelt]

I'm renaming this issue because "headless mode" is not what the OP is asking. "Headless mode" is where Rack runs as its own application but with no UI window. To embed into a game engine, Rack would need to be compilable as a library rather than an executable. This would depend somewhat on headless capabilities, but it would require more than that.

@spacepluk No, it's still possible. Either the embedding application would need to be licensed under GPLv3, or the developer would need to contact [email protected] for commercial license pricing.

If this issue is solved, there would be at least one caveat with the solution:

• Since plugins do not separate their DSP and UI code in two shared libraries, a library version of Rack would need to include all graphics/window libraries, such as GLFW, GLFW, nanovg, nanosvg, and osdialog, and their dependencies such as -lGL -lX11 or -framework Cocoa -framework OpenGL -framework IOKit -framework CoreVideo or -lopengl32 -lgdi32 -lws2_32 -lcomdlg32 -lole32.

[spacepluk]

@AndrewBelt Thanks, I totally missed the commercial licensing bits.

I see, are there any plans to separate the UI code? Linking all those libraries would probably be acceptable for desktop games but I think it might be more problematic if you're targeting mobile.

[AndrewBelt]

There are no plans, since it would singificantly break the plugin API.