This post is obviously inspired by the current pandemic where I can’t see my bandmates on a regular basis to record stuff, and I just hate it. So what I’m looking for is a solution to record someone who is not in the same house like me. Doing so asynchronously & sharing the files afterwards has its benefits, but it’s not for everyone.
There exists at least one commercial application by the name VST Connect, but neither am I keen to spend 200 bucks for a software not designed to work with my preferred environment, nor have I ever made VSTs work in Ardour at all.
There also is Studio Link, but it aims at podcasting where timing is not as as big an issue as in music.
Maybe my Google-magic does not suffice or something like VST Connect simply does not exist in the Open Source space.
But maybe one could use & combine existing tools to do the job?
I’m aware that, in theory, you could hook up a remote computer to the local network via VPN & patch it into Ardour with netJACK, but that is not an operation to be performed by non-IT-professionals (not mentioning the potential rigidity of the approach because you’d be awfully dependent on your network’s latency).
While hypothetically, remote recording doesn’t even need perfect global synchronicity: As long as the audio output from the recording DAW is in sync with the audio input at the remote location and the returning audio stream is automatically aligned with the rest of the tracks in the DAW again, the latency doesn’t have to be specifically low, but we could rather buffer pretty much as long as we want. This would have a number of benefits:
more reliable process in general
enables recording even through poor internet connections (empowerment for less rich/developed regions of the world as a side effect)
lowers the requirements to programming & environment (you might even hack this together in python or Lua)
no need to settle for a specific codec, WAV would work just as well as Opus
one could wrap it in a nice & easy to use GUI or a web interface, especially on the client side
maybe even embed a Jitsi-call or something along the way for communication
After all, I think if what I sketched out doesn’t exist, it definitely should in the future!
So what do you think: Can this be done with existing tools? If not: How hard would it be to implement, do you even see the use case?
P.S.: Sorry If I used the wrong category for this posting, it kind of falls into more than one place.
So I taught a mixing class last semester on Mixbus during COVID distancing, so it had to be done virtually. I tested several options, at the time sonobus either wasn’t one or I missed it in testing, but I will say it would be my first stop for this use now as it seems to be aimed for the need.
Jamulus was what I ended up using, but quickly left. It was ‘ok’ but not quite reliable enough. I ended up using Zoom which released some original audio improvements halfway through the semester to at least let me hear mixes and present mixes in a somewhat decent way.
The other one I used that had promise was Jacktrip, but this is technically more challenging to set up and at the time wasn’t quite there for longer latency in tradeoff for latency that is more appropriate, but some work has been done in this area so if you are more technically minded, it could be worth a look.
There were others I checked as well, but as as soon as Jesse told me about Sonobus that made my list for trying next semester.
Giso Grimm described this on the Linux Audio Users mailing list last May:
Uses zita-njbridge running on a dedicated embedded computer with an attached USB audio interface. I think the reason for using a dedicated computing device is because they wanted to send identical setups to several different musicians to use, without worrying that those musicians were also capable of creating and maintaining a low latency operating system configuration. Nothing was proprietary, so if you are already configuring your OS for low latency DAW usage I don’t think there would be any hindrance to creating the same software setup on your machine. The github page in fact mentions using the configuration on a desktop computer.
As you can probably tell, SonoBus is still a little wonky on Linux… getting it playing nicer with JACK is still on the list… it’s JUCE underwear is showing and they clearly don’t understand how JACK clients are supposed to work… I need to get in there and fix the whole ins/outs model.
The VST3 plugin version is probably a better fit for using in Ardour, I’ve just installed Ardour 6.6 on Ubuntu (20.04) and it does recognize and load the SonoBus plugin, but the plugin UI is super sluggish (not an issue when running the standalone) to the point of being unusable. Any ideas? Also, the latest SonoBus plugin supports up to 8 additional in and out buses (on develop branch of SB), but Ardour seems to only be able to reach one of them… the pins editor seems like the place to do it, but almost all the buttons there seem disabled.
Lots of work to do to make SB more Linux friendly! It’s good to be (sort of) back!
For VST3 plugins Arodur currently only supports a single main bus, and one aux-bus which is treated as side-chain.
This is mainly due to a conceptual disconnect between VST3 variable I/O and Ardour’s internal abstraction which is largely based on Apple’s AU. We’ll have to address this at some point in the not too distant future.
