Subject: Re: [linux-audio-dev] [ardour] custom graphics + MIDI control for LADSPA plugins
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Fri Dec 01 2000 - 04:20:07 EET
>However, just dealing with the memory management isn't enough - truly
>hard RT instantiation capable plugins must also be able to do all
>init processing (create, init, prepare, start etc...) in about the
>same time as an average run()/process() call in the actual net. This
>might be a problem for plugins with large buffers or LUTs that are
>generated at init time, especially in very low latency settings. (A
>buffer could be 32 *bytes*...) This becomes very critical in systems
>that may occasionally instantiate lots of plugins during the same
>cycle.
>
>Now, one could "cheat" some, and accept that some plugins need one or
>more cycles to fully initialize, but that would require that the init
>code can be chopped up in arbitrary size bits. Possible but not
>beautiful...
>
>Another solution would be to run plugins with too heavy
>initialisation in another thread, but that adds another chance of the
>OS scheduling latency hitting the engine by occasionally delaying the
>initialization of plugins. That is, instantiation easilly becomes
>undeterministic, even if the plugins *can* instantiate in a well
>defined amount of time!
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.
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. 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. 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"
one would like to use the same event system for all event routing, 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. 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!" :)
--p
This archive was generated by hypermail 2b28 : Fri Dec 01 2000 - 05:30:52 EET