Subject: Re: [linux-audio-dev] App intercomunication issues, some views.
From: Paul Davis (pbd_AT_op.net)
Date: Tue Jul 23 2002 - 14:48:45 EEST
>On Mon, 2002-07-22 at 22:11, Phil Kerr wrote:
>> One of the strong points of Linux, and UNIX in general, is the way small
>> app's can be strung together, this is the most flexible approach.
>
>This is true, but only of apps that can fit in to the way that Unix does
>its stringing together; ie, filestream-based apps. It is indeed
>advantageous to bend the way you work into this in many instances when
>you're trying to get a computer to do work. Unfortunately, audio work
>isn't one of them. There is no such framework to provide similar
>functionality to audio programs, yet.
>
>Jack provides an excellent transport for audio, but that is rarely the
>only thing that audio programs require; MIDI and parameter controls are
>also needed more often than not. This is, to some degree, what I'm
>attempting to provide with the app (or api, if you like) that I'm
>working on.
i would like to note that JACK *was* designed with the intent of
handling non-audio data as well. there are challenges in making it
work, particularly data that isn't streaming such as MIDI
(i.e. non-constant quantities of data in a given time period). but i
believe these challenges can be overcome relatively easily by anyone
with the motivation to do so.
the question is, however, to what extent is it worth it. the reason
JACK exists is because there was nothing like it available for moving
audio data around. this isn't true of the MIDI side of things, where
the ALSA sequencer, despite not being in user space and despite having
a complex and not particularly simple API (as befits a powerful
system), does the job of routing and sharing MIDI pretty well. the
task of simplifying MIDI I/O in a way analagous to what JACK does for
audio (everything is a port, all sample streams are 32 bit float, etc)
doesn't seem very obvious in its goals, at least to me.
parameters controls could be easily handled by OSC, which could be
integrated into JACK fairly easily. the problem with OSC is that the
reference implementation is probably the worst piece of coding i have
ever seen outside of the internals of Csound. i was very keen to add
OSC support to Ardour, but when I saw what I was working with, i gave
up the idea. if someone produced a clean, well written implementation
of OSC, it would help many people immensely. it could be used instead
of LCP, for example, which would probably be a good thing.
--p
This archive was generated by hypermail 2b28 : Tue Jul 23 2002 - 15:01:08 EEST