Re: [linux-audio-dev] Plug-in API progress?

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

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


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

This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:12 EST