I’m interested in an extremely pared-down, completely headless Ardour daemon with an API for “load session”, “play”, “stop”, “to to beginning” and maybe a few other basic commands. This version would really only need to support Audio tracks (not audio playback) with LV2 plugin support as well as MIDI tracks with FluidSynth and a single SF3 file. Everything else would be extraneous.
I sort of asked this before…
… but I’m now suggesting it’s a master daemon with interactivity, rather than just “headless autoplay”.
The ultimate vision – What I want (and I can handle this part) is to be able to talk to Alexa, tell her to play a session, and jam along with it. Eventually I want this to happen on a Raspberry Pi, but I can use a laptop in the meantime until a Pi powerful enough to handle it is made.
Clearly what I want is possible… I guess my questions are more nuanced:
Is there anything to gain, performance or stability-wise, by cutting out large sections of the code for the GUI, editing, or anything other than Audio/MIDI playback with LV2 support for the Audio tracks?
How much of a lift would it be to create such a thing? (i.e. how much $)
Who could do it?
How realistic is a web-facing REST API in the same codebase? One would be necessary to receive external commands and it would be preferable to avoid it having to run command-line processes to control Ardour. (I guess it’s preferable? Maybe it’s fine?)
No. Ardour’s engine is already separated from the UI. The only benefit of not instantiating the GUI is that you save a bit of RAM.
For all I know all the building blocks are already available. The main and most time consuming work will be to put everything together into your appliance.
There is already a basic C++ project that can load session (hardour) as well as an interactive Lua commaneline interpreter (arlua). Both can load sessions without an UI and allow to interact.
There are some plans for a websocket interface, but you really want OpenSoundControl.
There are already various apps as well as web-interfaces using that, mostly for transport-control and mixer. The problem there is that the remote-control surface setup is part of the session itself. So you can’t load different sessions using an Ardour provided remote control.
You can however do that with arlua as-is, or by customizing hardour to your needs.
The quick/dirty solution would be to simply add a small wrapper script that just starts Ardour, passing the session as argument, using a virtual framebuffer or vnc x-server. - Personally I’d use the Lua interpreter though. That can trivially act as daemon.
And just to reinforce a point that Robin made … hardour (headless Ardour) offers all the interactivity of regular Ardour, minus the GUI. That means that OSC and MIDI based control all work entirely normally (assuming you have already configured Ardour and the session, presumably using the GUI) to use them. So if you were already using a session with some MIDI or OSC control surface to drive everything, firing up hardour with the same session will work in precisely the same way.
So I’m diving into this headless stuff now… I found /usr/lib/ardour5/hardour-5.12.0 on my system. Is this the hardour you were referring to is there is a separate build?
In any case, when I run it, I got
/usr/lib/ardour5/hardour-5.12.0: error while loading shared libraries: libardour.so.3: cannot open shared object file: No such file or directory
but adding /usr/lib/ardour5 to LD_LIBRARY_PATH solved that.
Then I get:
cyrus@ok420:~$ /usr/lib/ardour5/hardour-5.12.0 /home/cyrus/Desktop/thingamagig_songs thingamagig-fountains_of_wayne-stacys_mom
ARDOUR_CONFIG_PATH not set in environment
ARDOUR_DLL_PATH not set in environment - exiting
…which I’m not sure how to handle. What should I set these to?
Inside the headless/ folder is a script called “hardev” which runs the executable from that location and sets all the required environment variables. Not sure anyone has ever run it any other way, thus far.
Jack is running in the background and I get this exact same message if it is not running as well. The session is just two audio tracks, one with gxAmplifier-x to color a guitar input signal. Session works fine when opened with the normal GUI.
Note to others: The prebuilt binaries do not contain hardev. Hey, at least I got the satisfaction of donating to this great project!
Primary question: What am I doing wrong? What does this error message mean?
Side question: When I run hardev should it autoplay the session?
Did you start Ardour before on this machine at least once with the GUI and used JACK?
hardour uses the most recently used backend that started successfully (it’s saved in ~/.config/ardour5/config under <EngineStates>.
We’ll likely add them in the future. I didn’t expect anyone would fine hardour useful as-is. I thought it’s mainly a skeleton to customize for specific needs. Before we publish it, it should at least have some method to exit cleanly without being killed (causing audio to drop out)…
Thankfully hardev comes with some debugging flags. Here is the “AudioEngine” debugging output. Appears it’s looking for a backend. I guess gtk ardour starts up a backend while running the GUI and that hardev does not or should?
cyrus@ok420:~$ /home/cyrus/Ardour-5.12.0/headless/hardev -D AudioEngine /home/cyrus/Desktop asdfasd
AudioEngine set ... debug bits now set to 00000000000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000 using 00000000000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000
DEBUG::AudioEngine: looking for backends in /home/cyrus/.config/ardour5/backends:/home/cyrus/Ardour-5.12.0/headless/../build/libs/backends:/home/cyrus/Ardour-5.12.0/headless/../build/libs/backends/jack
DEBUG::AudioEngine: Checking possible backend in /home/cyrus/Ardour-5.12.0/build/libs/backends/jack/libjack_audiobackend.so
DEBUG::AudioEngine: Found 0 backends
Cannot create Audio/MIDI engine
Pool: 'click' max: 0 / 1024