I’m wondering if it’s possible to run a headless VCV on a server somewhere and then for several users to connect to it… I guess there are two questions here:
i) connecting the peripherals (screen, mouse, keyboard etc), so that’d be like telnet or something?
ii) connecting the sound card… so each user would want to connect up to the sound endpoint on the server
Not sure how any of this would work but it might be a cool model for collaborative VCV Rack? Any prior art here?
That could enable a cool network multi-user performance collaboration environment, if it could be done. I’ve done a similar system as a world-wide distributed 3D metaverse using UDP for communications, but UDP is like TCP except packet delivery is not guaranteed. What I did was just use the network for high level communications but use the local engine for time sensitive processing. I’m not sure if that is what you have in mind. If you are imagining doing time sensitive and synchronized graphics and audio on the server, that is very similar to remote access application and desktop virtualization, which requires deep data compression and decompression.
But, I really don’t know anything about Rack headless mode, so it will be interesting to see what others say about this.
I think this is an interesting topic.
By the way, I used the UDP packet timestamps to perform “continuous” re-synchronization as UDP packets are delayed or fail to arrive. This works well for some things, but would not work well at all if you attempt to synchronize audio over the network in real-time.
I have done similar things to this before, and been thinking how it could adapt to Rack.
In my view, the best approach is a mix of TCP and UDP, not one vs the other. Keep TCP for the important packets and information that cannot be set out of order, and use UDP for streaming audio peaks, lights and other things that is okay if there is some misses here and there.
For Rack, it might be doable to plug into the history/undo implementation and send data through the server whenever something is added there, plus the current knob being turned/smoothed/moved.
Then perhaps send the state of lights and meters back from the server on a regular basis…
In theory this should work, but did not try it yet so it is all theory for now.
The big concern is how to handle modules that have custom widgets with internal data that is never stored on Rack history. It is not a huge amount of modules that do this, so perhaps we can ignore those on such model (think of it as a challenge haha).
EDIT:
For something “prior art”, I can show https://modbox.kx.studio/ which I did for work a while back.
It runs JACK, a plugin host, a webserver and other things on the server side. the frontend is exposed as web page and communicates to the server. More than 1 client can connect at a time, and what you do on one side is seen in the other.
Use “enable streaming” on the top to bring audio from the server to your PC using WebRTC, so it is kinda low-latency.
Still a bit experimental, but a nice show-case of the platform.