[Ardour-Dev] ardour as audio backend

[Evan Laforge]

> yeah, this was way too long. i think i've extracted about the only
> question i can usefully answer out of it.

Ok, sorry, I'll try to be more specific.

> the build system for ardour3 is certainly NOT something that excludes
> OS X. but ... none of us enjoy developing on OS X and as a result,
> nobody has yet built a3 on OS X. its not impossible, and will become
> "mainstream" once 3.0-beta1 is released, which will require that at
> least i do an OS X build myself.
>
> the build instructions on the website are indeed out of date. i have
> some newer ones - the process with respect to GTK has gotten a
> *little* easier, though overall its still a pretty nightmarish one.
> i'll try to post them on the website soon.

Ok, sounds good.  If you want a proofreader, I could run through them
myself and make notes about where they worked and where I had to do
manual hacking.  Otherwise, I'll keep my eye on the website.

> as a broader comment, i think that it would be MUCH more useful to
> talk about your ideas on sequencing to see if you could usefully work
> on ardour3's MIDI capabilities.

All due respect, but I don't think ardour is ever going to get there,
nor should it.  Writing scores is outside of its mandate.  Here are
some specific things that my program currently supports but I don't
think anyone is going to reimplement in ardour: a notion of a
hierarchical series of relative times, so multiple tempo curves can be
composed (I don't think this would fit too well with a DAW's idea of a
single global real time), a language of composable ornaments that can
be reprogrammed at runtime, a notion of inherited note attributes so
that a note with say sfz and tremolo can trigger the appropriate
keyswitch, a midi multiplexer so that notes with incompatible control
or pitch curves are split into their own channels, and a whole system
of scales that can be relative to other scales, parameterized by other
pitch signals, and much more.  In short, a giant pile of features I
don't think you'll ever want to reimplement in ardour and most other
users who just want to record something will have no use for.  I could
see some of these going in in a limited way (I hear recent versions of
cubase have a notion of attributes for keyswitches), but if you start
off with the idea that the score == midi then you're basically trapped
at that low level.

Anyway, I hope this is convincing enough that it's better to have two
separate programs that can cooperate rather than try to fit everything
into one program.  And all this stuff is already implemented, so it
would be silly to turn around and do it again only in c++ this time.

> bidirectional OSC is a nightmare that you should probably not
> investigate further. the protocol is inherently unsuited to this.

Fair enough.  I'll think about alternatives.  Some kind of synchronous
RPC protocol may be too invasive for the taste of the ardour devs, but
I think it can be done simpler than that.

So here are some brief questions:

If I want to investigate how configure and modify ardour's audio
graph, where should I get started?  I'm assuming libardour has the
mechanics, and I can always go chase down the GUI actions and see what
they're doing.  I'll wait until I can compile an ardour3 before
getting started on this.

If I wanted to add the features I mentioned, would they be rejected
out of hand or is there a chance of them getting if I do all due
diligence?  I know that's impossible to answer in full accuracy, but I
don't want to waste my time if there really is zero buy-in on the
whole concept.  I really hope that's not the case though...