it would be nice to have a possibility to script ardour.
The best solution would a dbus interface or a small integrated makro language like in vim.
Why i think that this could be useful ?
I’m using ardour 0.99.x since 6 month for small demo/rehearsal room recordings. But when i started to make 8-Track drum recordings, the (“adminstrative”) overhead grew… You have to create 8 or 16 new busses for every new sessions which are named after a repeated pattern, like snare1,kick1,…,snare2,kick2.
And sometimes you want to connect new busses automatically to a certain input, but with your own rules. For example if you create a new bassdrum bus, connect it with input3 of your first soundcard.
I suppose a hook-based script system whould be great for this tasks. Example: Let’s think off a new-session-hook, which gets called on session creation:
#example script
i=0
ardour.addGroup("drumtake1")
ardour.addGroup("drumtake2")
for name in (bassdrum,snare,overhead)
while i < 2:
busname=name+i
bus=ardour.createBus(busname)
bus.setGroup("drumtake"+i)
i++
Explanation: create 2 groups and 6 busses for 2 drumset takes. Put bassdrum1,snare1,overhead1 in Group drumtake1
and so on…
Another task would be export to ogg or something an session-quit.
an ardour session is just an XML file. you can use any language you want to generate that file once you understand its format. people have already done some experiments with algorithmic composition via ardour, generating session files with audio samples arranged along a timeline.
once you create (or modify) the XML file, just run ardour (or even reload the session).
its not as cool as adding lua/python/ruby support to Ardour, but its actually considerably more flexible in the long term.
In my opinion, a nice IPC-based solution like dbus would be perfect for ardour. My first idea, a (makro) language seems to stable and complicated. XML-files are fine, but you couldn’t affect runtime related things like fader positions.
But with IPC, you can offer all common ardour-functions (everything from “create a session” to “lower fader X”) to other programs. I think that would be a very unique feature (for a DAW) and not easy to implement, but i suppose its worth a lot because the user has more “freedom” in working with ardour. But i accept that this is a lot of work and more like a vision
an ardour session is just an XML file. you can use any language you want to generate that file once you understand its format.
That sounds like a good choice for whole sessions, but could it be made to work for more dynamic control of individual parameters? Reloading the session does sound like a rather coarse level of control.
If this worked for single-parameter control (maybe it does!), and if Ardour provided an XML listener attached to a port, then everyone could use their favourite scripting language in a separate process to control Ardour very dynamically through XML commands sent to that port.
PS. If the elements described in XML are mapped automatically into a DOM-style tree, setting parameters becomes as human-friendly as the OP’s example commands. Combine that with the listener port above and you can offer a 1-line command window almost for free.
i think this important. whilst editing the xml can help in building templates and offline structuring, a live scripting language or interface opens up many new possibilities. think of it as an extension to midi automating - sure without realtime automation you can draw curves etc for parameter changes, but it certainly isn’t as intuitive as using a midi control box for realtime work. the scripting/dbus/etc interface can extend this to a much more flexible system. how about a script that re-routes the ‘room A monitor mix’ to ‘room B’ and changes the reverb parameters and so forth to accommodate the changes in room dimensions. sure it can be done manually, but that isn’t the point. a daw is all about a more efficient way of recording over more manual methods. another example is a more experimental ‘art installation’ setup. i had an idea to control the volume, filter settings and panning etc of many different layers of sounds depending on various inputs and conditions. some involve touch inputs (easily done with midi), some involve algorithmically processing inputs from video cameras (more messy to convert input>midi>ardour than direct) and all sorts of other weird ways of inputting information. this would be far more efficient if ardour had a back end scripting or dbus-like interface (i’d prefer scripting, as long as it was realtime capable).
Sounds like fun… reminds me of Script-Fu (scheme-based) and websites like flamingtext.com which have GIMP running as an image-generation backend, but now with a realtime aspect… Interestingly enough, the GIMP on my machine here has MIDI listed among the input devices. Not sure why yet… sysex for GIMP? What could you do with note events in a gfx app? (And given Script-Fu’s completeness, what couldn’t you do?)
the control that script-fu gives you over just about every function gimp offers is more than amazing. you can automate/replace the mouse completely - if i had my way, all creative software should be like that.
especially a daw in such a nerd-friendly environment as linux/osx
This would make ardour the most awesome DAW ever. People would be able to write plugins for it, and post them here. I’m willing to bet the features for ardour would explode in number.
after wasting some time with guile integration, sockets programming and even a custom mini-language
…i wonder if
OSC
could do the job.
osc is great for sending messages to and from running applications.
there are easy-to-use osc libraries for c, java, scheme, python, ruby…
so everybody can write batch-scripts in their preferred language.
within the script, you send ardour “commands” like
/track14 “mute”
or ask ardour for information like
/ardour “getMutedTracks”
which causes ardour to send you an array of integers as an osc message.
of course, all the “scriptable” functions are also accessible from pd, max, supercollider, all of which also support osc.
so my strong hope is that extending ardour’s osc-functionality would please the realtime-people as well as the scripting people.
or can anyone imagine an example that would go beyond the abilities of osc?
