Subject: Re: [linux-audio-dev] Plug-in API progress?
From: Juhana Sadeharju (kouhia_AT_nic.funet.fi)
Date: to syys 23 1999 - 10:51:30 EDT
>From: David Olofson <audiality_AT_swipnet.se>
>
>Hmm... I kind of like the hardcoding idea. But I doubt that it'll pay off:
>Have a look at the engine side... And what if you have say 15 parameters of
>which you may automate any few? That's a veeeeery long stack frame, most of
>which will be unused most of the time. (Or am I missing the point?)
Yep. But it is quite rare that all 15 channels are sent interleaved
through one channel.
I see my plug-in suggestion needs an improvement in the cases we want
send many channels to one plug-in. The function call would need to have
variable number of arguments and thus the closure system seems to be
much better. Besides I already moved to closure system.
>How do we access parameters (that are used less frequently) if they're not
>"registered" as an event input in the current net?
Parameters are part of the network. The network will have both the audio
network and the control network mixed together.
>(And BTW, if the code is supposed to be recompiled
No recompilation is needed. The plug-in indeed has to test what kind of
input/output systems (buffer, events, static) it should use.
If you want avoid the test, then write specialized plug-ins: only
buffer inputs and outputs are allowed (such as in Csound). It is up
to plug-in author. I just wanted to provide more than one choise.
>Unfortunately, there's probably no way to avoid the fact that plug-ins
>must be possible to deliver as closed source binaries...
Those works very well in the suggested system.
>He can just send some request events to the plug-ins init function.
Ok.
>Well, my idea was to make the basic system even simpler,
Your system sounds more complicated than my system... yes it does. :-)
>That is, an event output buffer is always sent directly to an input of some
>other plug-in?
Yes.
The engine firing the plug-ins will make sure the next plug-in gets only
the events relevant to the possible audio buffer the next plug-in also gets.
>I'm afraid that will result in two interfaces/subsystems that overlap too
>much... And is your event system really that much simpler to implement?
How would you implement the curve delivery in your system? Both static
predefined curve and the real-time curve coming from other part of the flow
network?
Yours,
Juhana
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:12 EST