IMHO I think I have found the solution to our problems.
I will try to state it as clearly as possible.
The LAAGA server uses one buffer per input port.
You stated correctly, that when there are multiple outputs for one
input, the plugins must somehow 'know' they have to use run_adding in
stead of run, so:
>>[cut]
>>
>So, the method used to send data to an output port is a function of
>what its connected to, and not a property of the port.
>
>Either that, or you prohibit multi-input ports. That might be OK to
>do, but it prevents a simple and efficient implementation of the "bus"
>concept, which seems like a significant loss.
>
Very important is the statement taht the _method_ is a function of the
connectivity.
Now, the LAAGA server has knowledge about the connectivity, the plugin
should be dumb (as in just there for DSP).
So we could give the LAAGA server the responsability to register a new
run callback for the plugin, based on it's knowledge of the
connectivity. Input buffers hooked up to multiple outputs are
automatically flushed by the server (as they will be used by run_adding
from the plugins that are connected to this buffer).
Once the network is setup, the connectivity for each is known and the
LAAGA server registers the correct callback (run/run_adding) for each
plugin [is there already a way to pass a callbackfunction to the plugin,
which it should call upon output ?] and they work fine without actually
knowing what will happen to their data when they call the output
callback function.
This can be done because run and run_adding have the same return type
and the same arguments (a pointer to a buffer, and a array of floats),
so they can be registered as the 'same' callbackfunction.
Now the only issue that this doesn't deal with is when a plugin serves
it output for some input ports which are already hooked up to other
outputs and *also* to some plugins as the only input. This woul mean
this particular plugin would invoke run_adding also for these last
plugins, which introduces a slight inefficiency.
This use of callback functions would even allow for a realtime change
from run_adding to run when an input would start to receive input from
only one output in stead of multiple, at in instance of time (like when
muting or removing some plugin). This would make our system run as
efficient as possible all the time.
This is introducing flexibility (dyncamically changing callbacks) and
reducing complexity (only one buffer per input).
I haven't considered how the callback change would affect performance
though. But I think this should be minor, after all this is only a
pointer change, and since the pointers to run and run_adding would be
frequently used, the translations (to real memory adresses) would reside
in the TLB (assuming some LRU strategy).
Comments please.
Kind Regards
Vincent
