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:[EMAIL PROTECTED]
AltaVista Business Solutions http://solutions.altavista.com/
RFC 822 plaintext email strongly preferred except for attachments
