[Ardour-Dev] ardour as audio backend

[Evan Laforge]

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

That's the big question.  I'm hoping I can get by with loose
integration.  Maybe it'll work, maybe not, but writing GUIs is time
consuming and just repeating things others have done already.  I'll
avoid it if I can.

Or maybe someone else has written a GUI for ecasound that I could stick on top.

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

Wow, I never realized there were so many slick looking music projects
out there.  Things have come a long way since the days of trying to
get MiXViews and csound ported from irix to linux.

>>> 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 stand corrected, sorry.  Actually, the underlying data type is
probably relatively easily changed, what I meant was the assumptions
built into the UI, which is where the real weight lies.  The recording
style of workflow naturally favors working directly down at the MIDI
message level anyway, so that's only appropriate.  So even if you
represent controllers as curves instead of samples people are going to
record samples and be upset if it doesn't come out the same way it
went in.

> Just curious: what's the current language?

It's about 80/20 haskell/c++ (I need c++ for the widget library).

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

I'd say you're %100 on recording then, MIDI is just for mockups so you
don't need anything fancy.  Maybe if the MIDI tools were more
expressive you could use it more.  In your case you don't have to
worry about expression, trained musicians will help you out... at
least until you write "nv" but by habit they stick a vibrato on
everything anyway.

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

My app doesn't have a clock at all, since it uses the OS's MIDI
scheduler.  On OS X this winds up being AudioGetCurrentHostTime(),
which hopefully is the audio clock too.  Maybe the ALSA midi scheduler
clock is also the audio clock.  If it's not, it sounds like I can use
JACK instead of CoreMIDI or ALSA directly then I don't have to worry
about it.

I actually don't need sample accurate-ness, since I don't have any
samples.  As long as the offset isn't audible it's fine.  It would be
a problem only if it drifted in time.

> 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 :)

Yes, it would be nice to be able to click on the audio track and have
a message go out saying "cursor is at n seconds" so my app can jump
there too.  I don't mind not synchronizing to scrubbing.  Vari-speed
might be kind of interesting to support, and if I don't support
changing it in real time then that's just a multiplier added to the
play msg.  But no support for anything other than 1:1 is fine too.