Subject: Re: [linux-audio-dev] Real time plug ins
From: James McCartney (asynth_AT_io.com)
Date: Tue Mar 14 2000 - 14:44:45 EST
on 3/14/00 1:02 PM, Paul Barton-Davis at pbd_AT_Op.Net wrote:
> 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 ? :)
It is not the loading of the plug-in "class" that must be real time, but the
instantiation of an instance of that class.
SC never statically allocates voices or unit generators before hand since
there is no way to know ahead of time what will happen in a completely
dynamic environment. Everything is instantiated in response to events in
real time. There is no reuse of voices. SC garbage collects expired objects.
Sorry I came in the middle of all this. I'm just trying to determine what
the parameters are.
--- james mccartney james_AT_audiosynth.com <http://www.audiosynth.com>
SuperCollider - a real time synthesis programming language for the PowerMac.
<ftp://www.audiosynth.com/pub/updates/SC2.2.7.sea.hqx>
This archive was generated by hypermail 2b28 : Tue Mar 14 2000 - 22:42:02 EST