Re: [linux-audio-dev] Real time plug ins

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

Subject: Re: [linux-audio-dev] Real time plug ins
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Tue Mar 14 2000 - 14:02:12 EST


Both of you are talking about quite different things, as far as I can
tell.

The instantiation that happens in real time within SC is equivalent to
voice instantiation (and reuse) in Csound.

The instantiation that has been discussed so far in the context of
LADSPA, and to some extent MuCoS as well, has been at a higher
level. Specifically, the instantiate function has been intended to be
called after the code has been dynamically linked into the host. It is
*not* called in response to real time events; since dynamic linking
cannot possibly happen in real time (well, not for a few years yet :),
instantiation similarly would not be expected to happen in real time.

Thats not to say that it couldn't possibly cover the SC-like case, but
that most of the envisaged uses I have seen don't happen in response
to any real-time event - a plugin is instantiated when it is inserted
into the flow graph in response to some event (say, a mouse click
somewhere, or an instruction in some language in some script/program
that is not the description of the current flow graph.)

For example, when we were discussing this in the context of MuCoS,
David Olofson specifically pointed out that he imagined polyphony to
be handled *within* a plugin, c/o some suitable event that would be
delivered to it (via some mechanism) and that indicated the need for a
new voice at sample N. That is to say: just because some audio (or
MIDI or whatever) event has indicated the need for a new voice, we do
not run the plugin instantiation function again - we just tell the
plugin about the event, and expect it to do the right thing for the
relevant period of time.

In the case of SC, unless you allow the generation of a new plugin
identifier during audio generation from the data at hand, I would have
thought that the SC can tell when it parses an SC program what plugins
are required to be linked in. Thus, in LADSPA terms, you would load
the plugins and instantiate them at parse time; during execution, some
other level of activity is responsible for what James is calling
"instantiation". Does SC support dynamic linking of new
ugens/plugins/opcodes/whatever-we're-calling-them-this-week, or is the
entire language built in ?

LADSPA currently contains no provision for sample accuracy or event
delivery, which as David Olofson has helped me to understand are
really just two sides of the same coin. So right now, it can't
possibly support what SC does.

However, "voice" reutilization, as practised in Csound, Quasimodo and
presumably, in some form in SC, can happen in real time very
easily. To reuse an existing "voice" in Quasimodo takes about 100
instructions. Its a completely different process from instantiation.
Presumably, a Quasimodo-ish synthesis plugin would create N voices
during its instantiation routine, and would limit the number of voices
it supported to N, or would know that it always create another one in
a bounded, and low, time.

All this suggests to me that the "instantiate" routine ptr should be
renamed to "initialize". Or is it already ? :)

--p


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

This archive was generated by hypermail 2b28 : Tue Mar 14 2000 - 22:00:54 EST