Subject: Re: [linux-audio-dev] audio routing (was: Re: LADSPA GUI Issues)
From: David Slomin (dgslomin_AT_alumni.princeton.edu)
Date: Sun Mar 12 2000 - 21:52:50 EST
Kai Vehmanen wrote:
>
> 3) Standard UNIX IPC-mechanisms (pipes, sockets, etc). These of course
> work, but are too clumsy for every day use.
I couldn't help but pipe up (pun intended)... FIFOs (named pipes)
and conventional pipes are quite practical for everyday use. A
Bourne script or two to tie things together, and they're virtually
transparent. I can say this with experience, since I run MIDI over
pipes on a regular basis (NetMIDI, Brainstorm, etc).
The only things you have to worry about about are buffer sizes and
latency issues; as has been pointed out on the list often enough,
you do better with shared memory than with pipes. I've yet to have
a problem with the relatively low-bandwidth MIDI, but you'd most
likely hit it with audio.
> 4) MIDI-sequencer controls everything (all audio apps MIDI-controllable).
> I don't see this happening (with Linux audio apps.. Windows/Mac world
> is a different thing).
Requiring a sequencer to be the controlling app is of course
ridiculously restrictive. However, if you make your apps and
plugins able to be controlled by MIDI or similar messages, then
they can be automated via a sequencer without any extra effort.
For this reason, I got very happy when the LADSPA GUI discussion
mentioned the possibility of having the GUIs communicate with the
computational part of the plugins via generic control messages.
If you do it this way, the control messages can be sent from a
sequencer just as easily as they can be sent from a task-specific
GUI.
As I've mentioned before, I kind of like the idea of using MIDI for
all control messages, placing ones which are not directly supported
inside of custom sysex messages. This gives the benefit of working
well with existing hardware and software, but has the serious
drawbacks of unnecessary overhead and baggage. The control side
(as opposed to signal side) of LADSPA sounds promising as a potential
alternative. MuCoS may well be even better, but I understand it
less... so much talk about the signal side has left the control side
rather neglected.
Div.
P.S. I'm still alive and PEGS is progressing, just very slowly
since real life has gotten in the way a lot in the past month.
There was a great post on Slashdot the other night from a
longtime pro-level user who seemed to view sequencers in the same
manner as I do: as a precise tool for manipulating events.
Accurate recording and playback are essential, but are a separate
issue from editing; they are best left to a separate engine.
Notation and continous audio signals have no place cluttering
up the core interface of a pure event sequencer. His description
was of the old Mac sequencer called MusicShop, but it's good to see
that I'm on the right track for PEGS.
This archive was generated by hypermail 2b28 : Mon Mar 13 2000 - 05:44:58 EST