Subject: Re: [linux-audio-dev] [ardour] custom graphics + MIDI control for LADSPA plugins
From: Richard C. Burnett (burnett_AT_tality.com)
Date: Sat Dec 02 2000 - 20:39:16 EET
I am new to this discussion but I agree I think with this. While it 'is'
possible it seems bad design. Obviously plugin realization is dependent
on the author. There may be some who design the initialization to be fast
whilst others don't, depending on what it is they are creating. I think
that if you expect a note on event to be able to initialize a plugin you
are most certainly going to find this could lead down a bad path. What if
you have two notes on with two new plugins or more? I know that it would
be 'nice' if it worked that way, but it I just see it as becoming more of
a hassle. It also depends on the situation. I mean if you are talking
about MIDI playback then read ahead operations can have plugins ready
before they are needed (provided there is some standard for initialization
time ) If its real time then there is just no way to know how long it
will exactly take to initialize some plugin chains. The only way I can
see this working is actually using the plugins ahead of time. Testing
them and using them together, because lets face it, with many different
people writing the plugins and having just an interface being the standard
protocol, you are going to get alot of different stuff :)
Just my two cents.
Rick
On Sat, 2 Dec 2000, David Olofson wrote:
> 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 -'
>
>
+------------------------+-----------------------+
| T a l i t y | +------+ |
+------------------------+ +----+-+ | |
| Richard Burnett | +-+ | |
| Senior Design Engineer +---+ +----+ |
| burnett_AT_tality.com | | |
| | | |
| Phone: 919.380.3014 | |
| Fax: 919.380.3903 | | |
+------------------------------------------------+
This archive was generated by hypermail 2b28 : Sat Dec 02 2000 - 21:26:27 EET