[Ardour-Dev] ardour as audio backend

[Robin Gareus]

Hi Evan,

On 07/24/2010 10:37 PM, Evan Laforge wrote:
> Hi!  Sorry in advance about the huge first message.  I could stop by the irc
> channel but I think something with this level of detail would just swamp
> people.
> 
> For the last couple of years I've been working on a music sequencer.  It's
> only concerned with writing music, and so it has no ability to deal with sound
> at all.  It simply transforms a user written high level score into a lower
> level format, which currently means MIDI.

Excuse my bluntness, but how does it distinguish itself from similar
existing projects?  fi. rosegarden, qtractor, seq24, shaketracker, lmms,
muse,... ardour3 ..or since you say "concerned with writing music":
musescore, canorus, nted, denemo,..

> Not supporting audio simplifies things, but it means I'm missing some features
> I'd like to have.  Since my program is purely focused on writing music and MIDI
> and ardour is mostly focused on recording and editing audio, they seem nicely
> complementary.  Cooperation with ardour seems like the most practical way to
> get these audio oriented features implemented.  I think ardour's existing OSC
> and MTC support can get me part of the way, but it may require some additional
> features to get the integration nice, hence this email.  Of course I'm willing
> to do the work myself, but it would be nice to have someone who understood the
> code say something like "this seems practical, here's the code you should be
> looking at, come back when you have more specific questions or some patches for
> review" or maybe "this would be a lot of work and we're iffy about accepting
> giant patches that do things we're not too interested in" or "you're confused,
> here's what you should really be doing" or whatever.  I know that features to
> turn ardour into the audio backend for an as-yet unreleased sequencer are
> probably not a core design goal for ardour (but... in my personal opinion I
> think it's probably a better idea than trying to make ardour into a sequencer
> by putting in a whole bunch of MIDI features, though I guess I can understand
> why people would want that).

If you only need an audio-backend maybe http://eca.cx/ecasound/ is an
option. it's a versatile console/command-line only multitrack audio
processor and can be scripted (integrated into other apps) quite easily.

If you want to go for ardour, your time is probably spent better working
on ardour3-MIDI (which is already quite usable) than on an external app
remote-controlling ardour.

> Anyway, what I'd like to achieve can be broken into three features:
> 
> The first and most complicated is a software synthesizer host.  I currently use
> plogue bidule for this, which is not convenient because once I release this
> thing as free software it's not very nice to tell people "oh but if you want to
> use software synths you have to buy this commercial program or come up with
> some solution on your own, have fun!".  And bidule is not convenient because as
> far as I know it can't be controlled from another program.  For this I would
> need the ability to list plugins, load and unload them, configure them, and
> configure their position in the audio graph.  And I'd need to get MIDI to them
> somehow, which probably means configuring a MIDI graph as well, though that can
> be as simple as "make an OS-level virtual MIDI port or 3 for every plugin".
> 
> From poking around a bit, ardour2 doesn't seem to support synth plugins, but it
> looks like ardour3 does.  Presumably ardour already has an internal notion of
> an audio graph, so ideally I'd just need to make sure there are (say) OSC
> commands to manipulate it in the ways I want.  I don't think OSC really
> supports bidirectional communication so maybe I really want a real RPC
> mechanism... or perhaps ardour can just open up an OSC port coming back.  Or if
> necessary all these commands could be made unidirectioral by just displaying
> output on the ardour UI.  Or write it to a log file, whatever is simplest.  So
> something like:
> 
>     plugins - list available plugins
>     load "name" - instantiate a new plugin, return a plugin ID
>     unload ID - unload plugin, disconnecting everything from it
>     ls audio/{in,out} midi/{in,out} - list port IDs for global ports
>     make_midi_input "name" - make a new midi input port, return port ID
>     ls plugin/ - list loaded plugin IDs
>     ls ID/audio/{in,out} ID/midi/{in,out} - list port IDs for relevant input or
>         output available on a given plugin
>     connect port_id port_id - connect two audio ports or two midi ports
>     disconnect port_id port_id
>     get_state ID - return state of plugin with ID, as an opaque chunk of bytes
>     set_sate ID state - restore state, given previous chunk of bytes
>     edit ID - bring up editor window for plugin
> 
>         I gather plugins have additional control inputs that might be nicer
>         than crummy old low res midi control messages:
>     ls ID/auto - list automation targets on some loaded plugin
>     automate ID/auto/auto_id signal - feed automation signal to automation
>         parameter.  I suppose this would be best sent as chunks of (Time, Val)
>         pairs.
> 
> 
> The second is just the ability to record audio and do the normal DAW things.
> The main feature for this is synchronizing play position as well as play and
> stop times.  I think MTC and existing OSC support may already get me there.
> I just need to set the cursor to n seconds into the session, possibly receive
> a message saying ardour wants to set the cursor at X, and send a message saying
> to start plaing at some time and n seconds into the session.  Then if both
> ardour and my sequencer are using the same underlying time source (presumably
> the one used by the OS's midi scheduler), I can tell ardour "start at xyz"
> and send midi data to the OS tagged starting at xyz and they should start in
> sync.  And as long as the clock ardour uses for audio and the clock the OS uses
> to schedule MIDI don't wander with respect to each other, they should stay in
> sync.  I'm kind of a dummy about synchronization though so it might not be so
> simple?  I know jack also deals with synchronization, but I gather it's
> concerned with synchronizing the creation of audio streams, which is not really
> the case here.  My program doesn't understand audio, it doesn't even have a
> scheduler.

You'll want JACK-transport:
http://jackaudio.org/files/docs/html/group__TransportControl.html

The time-position includes both: audio-sample-time and bar/beat info:
http://jackaudio.org/files/docs/html/structjack__position__t.html

JACK-MIDI allows to schedule events, as does the ALSA sequencer
interface. "RAW-ALSA-MIDI" allows you to implement your own scheduler.

Synchronization always requires some diligence (fi. compensate
latencies) but it's pretty much straight-forward using JACK.

> The third is just a combination of the first two, I'd like to be able to bounce
> tracks from synthesizer output (either a plugin synth or external hardware
> one), aka "track freezing".  I think I just need to be able to tell ardour "arm
> the track associated with this synth and overwrite anything already there".
> The former is presumably part of the audio graph, and the latter is presumably
> what ardour calls "tape mode".
> 
> 
> I inteded to try out ardour3 to see what the current situation is wrt synth
> plugins, but it seems like the OS X building process is even more tricky than
> usual because the GTK patch doesn't apply cleanly to current libgtk 2.20.1 (not
> surprising if it's really 2 years old), and that it still hasn't been applied
> upstream (!? really?).  I might be able to muddle through but it looks
> different enough to be somewhat painful and maybe there's an updated patch, or
> maybe it's no longer necessary?  Or maybe the OS X build process has bitrotted
> for ardour3?  If a working build is a prerequisite for doing any mac hacking
> then I suppose I could try to help out with that too.  I've been poking around
> in libardour's ardour/plugin.h and whatnot trying to figure out what ardour's
> concept of an audio graph is like and how it's configured, but it's always
> easier to actually have a running binary to prod and inspect.
> 
> 
> thanks for making it this far!

Cheers!
robin

> _______________________________________________
> ardour-dev mailing list
> ardour-dev at lists.ardour.org
> http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org