[Ardour-Dev] ardour as audio backend

[Robin Gareus]

On 07/26/2010 04:54 AM, Evan Laforge wrote:
> 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 :)

Many thanks for the elaborate explanation.
Wow. I'm looking forward to your application. It sounds like ardour
integration is going to be the easy part of it :)

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

Indeed.

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

AFAIK it does not. It may not be too hard to add AU Plugin support for
plugins that do not require a GUI.

> But the thing is, I
> *do* want a full DAW GUI because it really is the most convenient for
> editing audio.

quite understandable. The question is if in the long run it'd be more
maintainable to write your own GUI (either using libardour or ecasound
or whatever..)
Ardour's OSC remote control may turn out to be insufficient for the
tight integration that you want.

Similar FLOSS projects that may come in handy to borrow code from are
Traverso and Openoctave.

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

Sorry, my bad, It's ardour3 - forget about the MIDI.
As Paul said: ardour3 was designed for generic event sequencing.

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

Just curious: what's the current language?

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

I am in between. Mostly doing sound-design for film, which involves
writing and recording. Sometimes I do use MiDi during the composition
stage, but never for the final mix: I go and record some musicians if
not myself. Same for Foley.

>> 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-Transport is quite flexible but for the fact that it's just one
transport and it does not do vari-speed. OTOH that's a feature :)

I assume you do a lot of internal time-mapping anyway.

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

It does - kind of: JACK uses a PULL API rather than PUSH.
jackd calls a function in your app at regular intervals and this
function has to fill the buffers for the coming cycle. You can also
schedule [MIDI] events with accuracy of the audio-samplerate in said
callback.

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

Depends what Clock your application uses. JACK is synced to the
audio-interface's oscillator not the system clock. If you use JACK for
timing a sync-start will suffice.

Well and you'll need to prevent the user from playing with ardour's
jog-dial, vari-speed, pull up/down features, clicking on the canvas or
doing anything else that'd relocate the transport of course :)

ciao,
robin