Re: [linux-audio-dev] [ardour] custom graphics + MIDI control for LADSPA plugins

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

Subject: Re: [linux-audio-dev] [ardour] custom graphics + MIDI control for LADSPA plugins
From: David Olofson (david_AT_gardena.net)
Date: Sat Dec 02 2000 - 03:21:23 EET


On Friday 01 December 2000 03:20, Paul Barton-Davis wrote:
[...RT plugin instantiation...]
>
> i just don't see the problem here. the is no reason that plugin
> initialization has to happen in an RT thread.
>
> plugin initialization happens when some non-RT (or at least,
> non-audio thread) detects an event that requires plugin
> initialization. for example, a thread handling MIDI i/o or some
> equivalent creates a plugin instance (or recyles one), initializes
> it and then requests the RT thread to insert it into the list of
> current plugins. the only thing here that has to be RT safe is the
> handling of the requests, which can be done using the event system
> of MAIA or the old standby, a lock-free FIFO queue of requests.

It *works* if you do it that way, but then you don't have bounded
response times. That may or may not be acceptable depending on what
kind of system you're building - if you're building a sampler or
synth for live use, it's most probably not acceptable.

> this is what quasimodo does, and as a result, we could handle more
> or less arbitrary rates of plugin creation and costs of
> initialization. the only limit comes from the plugin itself: if a
> synth voice plugin, for example, takes 2 engine cycles to
> initialize, there is no way whatsoever to do better than this, but
> it also has no effect on the RT/audio thread.
>
> the system you are imagining involves delivering the MIDI noteOn
> event, say, directly to the plugin.

I don't see how it would have to be that way. On the contrary, if
you're dynamically instantiating voice plugins, some *other* plugin,
or a part of the host, would have to deal with these events. You can
hardy operate a plugin that doesn't yet exist, can you...?

> but this is wrong: the
> plugin->run() method should not be handling instantiation and
> initialization. the event system should not be passing
> "global-state-changing" events to the instantiated plugins, but
> should instead be passing them to some "higher level" object.

Exactly.

> besides, how could you pass it to an instantiation of a plugin if
> there is more than one of them - how would you pick which one ?
> anyway, this would presumably still be plugin specific. we
> effectively need to say:
>
> "hey, plugin Foo, you got a MIDI noteOn message, what do you
> want do about it ?"
>
> unfortunately, this is quite distinct question from
>
> "hey, plugin Foo instance 1, parameter 34 changed to
> 23.45"

As long as plugins aren't going to instantiate and destruct
themselves, the difference is not that big. In the current MAIA
headers, there is one Property Protocol to deal with anything like
the second example, and a separate (optional) Instrument Control
Protocol, which is somewhat similar to MIDI. The only differences are
that the Property Protocol is actually just an interface to access
variables, while the Instrument Control Protocol is a way of sending
commands; some with multiple arguments.

Anyway, *all* MAIA events are to be used only with plugins that are
instantiated. Before instantiation, there simply isn't anywhere to
send any events.

> one would like to use the same event system for all event routing,

Yes, that's why I'm designing the event system so that you can send
and receive events anywhere; from whithin plugins, or from different
parts of the engine, including different threads. (No thread-safe
stuff in the event send/receive macros, though - we don't want the
overhead in every single connection...)

> but the semantics of certain kinds of messages suggest to me that
> not all messages should be delivered to instantiated plugins. any
> given plugin needs a "meta-receiver" to handle this kind of thing.

That would be the host, or a plugin that just translates various
events into requests that are then sent to the host.

If a host is to be "remote controlled" in any useful way, including
net building, this subsystem will have to be in place anyway. It
could be "abused" for dynamic net modification as well.

> whats ugly about this is that it attaches semantics to messages
> *before* they get to the plugin. i mean, maybe "parameter 34
> changes to 23.45" *means* "start a new voice" for a given plugin. i
> think we just have to know when to say "no!" :)

Well, if you send a MIDI Note-On to an application, the response
might be that it instantiates a few plugins, and then sends some
events to those plugins. (It probably will not pass the MIDI event
itself on, as the plugins won't understand MIDI, and/or the
application will translate the MIDI Note-On into various other
things, according to the instrument definition.)

Then, imagine that the code that translates the MIDI events is in a
plugin instead of hardcoded into the host. The host would have an API
for plugin instantiation and connecting, and - guess what - that API
would be implemented on top of the same event system that the plugins
use for communication within the net! :-)

Now it doesn't matter if the code that decides how to respond to MIDI
events is in the host, of in one or more plugins - just feed MIDI
into it, and connect the output to wherever you have your net
building toolkit.

//David

.- M u C o S -------------------------. .- David Olofson --------.
| A Free/Open Source | | Audio Hacker |
| Plugin and Integration Standard | | Linux Advocate |
| for | | Open Source Advocate |
| Professional and Consumer | | Singer |
| Multimedia | | Songwriter |
`-----> http://www.linuxdj.com/mucos -' `---> 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 : Sat Dec 02 2000 - 04:05:09 EET