[Ardour-Dev] ardour as audio backend

[Evan Laforge]

Hi, thanks for the response.

> 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,..

I don't mind bluntness, and I have a pretty complete answer.  It's not
really on subject for the list, but now two people have asked me to
get specific about features.  Feel free to contradict me too, I've
done some research but there's always new software popping up and I
haven't researched the capabilities of all of it.  And, I'm not saying
these aren't great programs that do what a lot of people want, I'm
just saying that I don't think they do what *I* want.  I'd be happy to
learn where I'm wrong... I do want to write music more than write
code!

Anyway, in my opinion what I'm doing is very different from every
single other music program I've seen out there.  Here's a list of
things which I don't think any of those programs can do:

[ off-topic, skip the next 6 paragraphs if you don't care about it ]

If you want any kind of control over pitch, you're mostly out of luck.
 You can't control vibrato depth, speed, and shape unless the
synthesizer happens to support it and you can assign it to some
controller.  You can't control portamento between notes except by
playing games with fingered portamento and controller 5, and once
again the interpretation totally depends on the synthesizer.  You
can't talk about pitch motions in any kind of high level way, for
instance "loosen vibrato, release breath slightly, slide to next note
overshooting it a little, tighten vibrato".  These are all things
singers and wind players and do routinely but existing programs can't
describe them.

If you want to use any scale other than 12-tet you're out of luck.
Even other programs that make an effort to support scales are
relatively primitive: you can't retune a scale depending on context or
a signal, you can't express that halfway between C and E is not the
same as halfway between C# and D#, you can't even express that
enharmonics may not have the same frequency, you basically can't do
anything.  You can't draw your own symbols for the scale or design
your own notation at all.

If you want any kind of more sophisticated control over tempo, you're
probably also out of luck.  You probably can't compose a ritardando
and a rubato except manually if you're lucky and then they're stuck
together.  You can't have multiple tempos going on at once.  You
probably can't express that some notes happen in absolute time and are
not affected by tempo (e.g. grace notes), or that some trills should
move with the tempo and others should be absolute and have an integral
number of cycles, or that some ornaments should change depending on
the context, or even that some instruments should change patterns
depending on tempo.  In addition, if you want to write in the "warp
map" style of some chinese scores instead of the "first derivative"
style of a tempo graph, or the "end-weighted" rhythmic grouping
characteristic of indonesian music, there's nothing for you.

You probably can't have much control over control signals at all.  I
was pretty surprised to learn that in cubase, supposedly with
"advanced midi support", you can't multiply signals, you can't low
pass filter them to smooth them, you can't pass them through a
waveshaper to bias them around certain values, you basically can't do
anything to them except draw them.  By hand.  Lining things up by
eyeball.  I'll bet some of these open source programs will let you
filter a control through an external program so you can write your own
transforms, but even then your changes are probably all destructive.
You're out of luck if you want to adjust the underlying tempo.

In addition, these all look like pretty traditional non-extensible
programs, except ones which really are a language like lilypond.  At
most they might have a scripting interface with second class access to
the program internals or a limited plugin interface, and won't let you
recompile parts of the program and hot-swap it at run time.  I really
don't think ardour wants to go there :)

As far as the score writing programs like musescore or denemo, if
you're writing anything other than 5-line western style staff notation
or some simple extension of it, you're out of luck.  Lilypond is
brilliant at the lines and dots stuff, but you have to give that stuff
to a live musician if you want to hear real music.

>> 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.

ecasound looks pretty interesting, and if it supports AUs an an
arbitrary audio graph then I'll be pretty happy.  But the thing is, I
*do* want a full DAW GUI because it really is the most convenient for
editing audio.

> 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.

I'm pretty sure ardour-MIDI is not going to ever support all that
stuff above.  For one, you'd have to abandon MIDI as the underlying
data type, and then it wouldn't be ardour-MIDI anymore.  I think
ardour *could* eventually usefully implement some of these things,
like higher level pitch signals or maybe even MIDI multiplexing, and
if someone's interested I'd be happy to see it happen, but I think
most people are not interested in these things or else other
sequencers would support them.  In my case, I already have a program
that does all that so my motivation to rewrite it all (and in c++ no
less) is not very great.

I don't know how other people work, but my impression is that most
people's workflow is basically *recording* music, not writing it.  So
they care about recording features like quantization and whatnot, but
not about writing music features.

> 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

My sequencer doesn't necessarily have a concept of western style bars
and beats but I assume I can leave those blank and talk about realtime
only.

> 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.

Ah, I didn't realize jack included scheduling.  My approach is to
timestamp all midi events and ship them off to the OS driver a couple
seconds in advance (so as not to overwhelm its internal buffers) and
let the OS worry about getting them out the ports at the right time.
If jack does that (and can merge multiple streams, which I use for
midi thru) then I'll be a happy camper.

But out of curiosity, is there any reason to suspect that a simple
"start now" message scheduled at some time wouldn't suffice for
synchronous play?