Subject: Re: [linux-audio-dev] No IPC in LADSPA?!
From: David Slomin (david.slomin_AT_av.com)
Date: Tue Mar 28 2000 - 21:19:55 EEST
Paul Barton-Davis wrote:
>
> The problem with "delivering individual events as fast as it
> can" is demonstrated rather nicely in Quasimodo. Because of the way it
> implements "patches" between modules, external events (GUI stuff, MIDI
> data, etc.) that alter parameter values happen *too* fast.
This is a good point, but I don't have any data on the response time
of my external synths (I suppose I could write a little test program).
During the realtime takes, I want messages to go through the
flowgraph as fast as possible, but during playback I do want the delay
to be taken into effect. However, I'm already used to fiddling with
offsets manually to acheive the latter (I'm sure most other folks are
too).
> For point-to-point communication, if the data flow rate is not an
> issue (ie. its not audio or video), than a Unix pipe will probably
> work just fine. If you need to multiplex, then use shared memory
> queues. In short, use the existing IPC mechanisms, since what you
> want is in fact *IPC* not a plugin API.
Thoroughly agreed, but what happens when I want to talk to a program
designed around LADSPA or MuCoS? Will either of those offer an easy
(out of the box) way to talk to a pipe, socket, or shared memory
queue? If they go out of their way to accomodate me, then I don't
have to go out of my way to accomodate them; I just didn't expect
to get off that easily. :-)
Div.
-- David Slomin, Engineer mailto:david.slomin_AT_av.com AltaVista Business Solutions http://solutions.altavista.com/ RFC 822 plaintext email strongly preferred except for attachments
This archive was generated by hypermail 2b28 : Tue Mar 28 2000 - 23:02:18 EEST