[ardour-dev] Cool idea or Crackhead ramblings

Polashek, Matthew matthew_polashek at mcgraw-hill.com
Tue Apr 26 06:02:32 PDT 2005


Answers to d)

The idea is that during a live performance that one is both recording
and mixing using Ardour and some kind of multi-channel hardware I/O, a
unified user interface would be most useful.  Apparently I have a very
active fantasy world, because I further fantasize about a live system
that includes a 19" rack-mounted LCD touch screen (In one of those
angled racks intended for a mixer) that one would use to control Ardour
faders and such. (As opposed to implementing a separate control surface)
The hardware mixer (envy24contol/hdsp mixer) would most likely be used
to route audio to monitors (and possibly to the main speakers) of the PA
for ultra-low-latency live work.  The inputs would still need to be
routed to Ardour for recording and non-priority effects such as reverb.
Perhaps Jack could be modified to generate "hardware channels" or
something.  (I get errors when attempting to join the jack list, but
I'll try again to get this posted there.)  Perhaps Ardour could grow to
include "hardware channels" also, or something like that.  Then again,
perhaps I should just abandon this idea and route everything through
Ardour the way it works now.

Matthew Polashek

-----Original Message-----
From: Sampo Savolainen [mailto:v2 at iki.fi] 
Sent: Monday, April 25, 2005 3:39 PM
To: ardour-dev; Polashek, Matthew
Subject: Re: [ardour-dev] Cool idea or Crackhead ramblings

On Mon, 2005-04-25 at 14:00 -0400, Polashek, Matthew wrote:
> What if Ardour could take the place of, or integrate, envy24control or
> the hdsp mixer?  That would be neat-o!  Is this in the works?

Crackhead ramblings, mostly. But the good, visionary sort of crack.. :)

Like mr. McCoy said, Ardour works at a higher abstraction level than
hardware. Actually, Ardour shouldn't have _anything_ to do with audio
hardware, dealing with hw is jackd's problem. This abstraction is also
the reason why Taybin has been able to create OSX ports of both jackd
and ardour relatively easily. Clear API boundaries is essential for
porting applications, if you're a developer you will understand
otherwise you'll just have to take my word for it.

But: this isn't impossible to do in jackd. Jack already has some
monitoring options. Granted, these options are very simple and limited
to specific hardware. But it's not impossible to imagine a more complex
monitoring API evolving into post 1.0 versions of jack.

What this needs is a crack-free vision and design how to do this so that
it:
 a) will work for a wide variety of hardware
 b) actually provides something valuable to applications
    using jack
 c) is usable from the user POV / doesn't confuse the user

and most the most important one:

 d) What do you actually want to do with the hw mixers?
    How would you like to be able to control them from applications
    using jack (don't restrict yourself to Ardour) and how would
    other people like to control them.

You really need to answer d) before addressing a),b) or c).

Feel free to bounce ideas around. #lad, #jack, #ardour.

-- 
Sampo Savolainen <v2 at iki.fi>



More information about the Ardour-Dev mailing list