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 - 04:51:10 EET
On Friday 01 December 2000 08:21, Paul Sladen wrote:
> On Fri, 1 Dec 2000, David Olofson wrote:
> > On Thursday 30 November 2000 15:13, Steve Harris wrote:
> > > On Thu, Nov 30, 2000 at 04:43:24AM +0100, David Olofson wrote:
> >
> > 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...
>
> For heavens sack, why(?) are you talking about doing initilisation
> in RT??
First, if initialization isn't done in RT, you don't have RT response
times. That isn't to say that it has to happen in the engine thread,
though.
Anyway, the answer:
Because that's the only safe way that you can ensure a bounded
"trigger event" -> "plugin up and operating" time, in the same range
as the engine latency, at least without RTLinux or similar RTOS.
Still, it seems popular to build softsynths that build voices
dynamically when responding to MIDI events. SuperCollider and
Quasimodo are two examples, AFAIK.
Frankly, I don't know if dynamic plugin instantiation is the way to
do a real time synth, even if it's possible. Hard RT systems are very
rarely designed that way, simply because it makes it very difficult
to keep the systems hard RT. Why should the design rules change
entirely just because we get a local X server and HD?
Going back to where all this started, I originally considered RT
instantiation as response to MIDI events Bad Design. I've pointed out
the problems several times, but people are still yelling "We want
real time instantiation!", and claim that it's not a problem.
I say it *is* a problem. Or doesn't MIDI event response count to
latency all of a sudden...?
But sure, MAIA will support out-of-thread instantiation of plugins,
and you can abuse that for soft synths if you like. There will also
be some kind of memory manager hook where you can throw in an RT
memory manager. (However, be aware that you have to resort to the
"react ASAP" type of response, rather than "react exactly T ms after
the event comes in", unless you set a fixed delay that's long enough
to cover approximately the worst case plugin instantiation time + one
engine cycle.)
Ok?
//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 -'
This archive was generated by hypermail 2b28 : Sat Dec 02 2000 - 07:42:14 EET