Re: [linux-audio-dev] audio routing (was: Re: LADSPA GUI Issues)

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] audio routing (was: Re: LADSPA GUI Issues)
From: David Olofson (david_AT_gardena.net)
Date: Wed Mar 15 2000 - 23:04:29 EST


On Mon, 13 Mar 2000, David Slomin wrote:
> 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.

Yes, this is one of the reasons why I want a simple, low level
standard for control ranges and formats. If they're not generic, like
MIDI Control Change messages, it'll be a nightmare (and performance
killer) to use them for anything but plugin<->GUI communication.

> 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.

To understand the MuCoS basics (the event system, which actually
makes up some 90% of the API) to some extent, rip a direct control
port write access out of LADSPA, add a timestamp and the necessary
port/channel address info, and package as an Event. Send to the event
input port of the plugin.

Now, when a plugin is run(), it may (should, if it's a real MuCoS
plugin) loop over the events queued on it's input port, decoding and
applying changes for each event found, and running the inner
(proccessing) loop until the position of the next event, according
to it's timestamp. The loop terminates when a terminator event is
found, or when the plugin has something *very* important to tell/ask
the host about, which cannot wait until the normal end of the buffer.

That's it, basically. There is some more to it of course, but most
of that is design level stuff, most of which I (think I) have sorted
out. Shouldn't be much more to worry about than the above for the
average plugin, that is.

In short, the difference between a LADSPA control port and a MuCoS
event port is that the latter supports multiple, sample accurately
timed changes of various parameters during a single run() call.

//David

.- M u C o S --------------------------------. .- David Olofson ------.
| A Free/Open Multimedia | | Audio Hacker |
| Plugin and Integration Standard | | Linux Advocate |
`------------> http://www.linuxdj.com/mucos -' | Open Source Advocate |
.- A u d i a l i t y ------------------------. | Singer |
| Rock Solid Low Latency Signal Processing | | Songwriter |
`---> http://www.angelfire.com/or/audiality -' `-> david_AT_linuxdj.com -'


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Thu Mar 16 2000 - 06:42:06 EST