Subject: Re: [linux-audio-dev] Re: A Plugin API
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: ma helmi 28 2000 - 23:18:55 EST
[ LAD is back on the Cc: line ]
>>Just noticed:
>>
>>> Note that a port cannot be both an input and an output and that a
>>
>>why not ?
>
>First, it's conceptually simpler and it makes the plugin easier to
>visualise in a GUI.
>
>Secondly, consider a network where A feeds audio to plugins B and C and B
>feeds D:
>
>A---B---D-->
> \
> C-->
>
>If B is using the same port for both input and output then the buffer
>linking A and B will also be the buffer linking B and D. This means that
>process ordering becomes more difficult. If B has to run before C (for some
>reason not shown on the graph above) then B overwrites the output of A and
>C will receive the output of B in error. This can be got around by
>introducing further buffers and using buffer copying, however I think this
>is an unnecessary waste of CPU time and a fiddly case to spot.
I think you're thinking about it the wrong way. You've dropped the
"host" out of the picture. It could look more like this:
buf1 buf2 buf3 <== HOST OWNED BUFFERS
/ \ / \ /
/out \in /out \in /out
/ \ / \ /
A:port1 B:port1 C:port1 <== PLUGIN PORTS
In english: A writes into buf1, which is processed by B with the
result put into buf2, which is processed by C and the result stored in buf3.
I don't see how any execution ordering of A, B or C can cause
overwriting. All it can do is to create a delay. I will grant you,
however, that the above scheme could just as easily be created like
this:
buf1 buf2 buf3
| \ / \ |
out| \in out/ \in out|
| \ / \ |
A:port1 B:port1 B:port2 C:port1 C:port2
in which all ports were in or out, but not both. I am not sure which
of these is better. Mostly because in some ways, neither of them is.
Maybe you were imagining a scheme like this:
buf
/ | \
/ | \ all connections are in/out
/ | \
A:port1 B:port1 C:port1
Yes, in this scheme, the wrong execution order would lead to, for
example, C receiving the output of A, not B.
However, this is by far the most efficient scheme, and as I think I
wrote before, the plugin host *has* to keep track of who is connected
to who, because otherwise the execution order is wrong and you will
always get odd effects. You *must* flow sort the plugins. Quasimodo
had this problem until a few months ago. The sort algorithm is very
simple if you can determine the equivalent of:
bool Port::is_connected_to (Port)
Of course, doing it via such a function is not very fast; instead,
each time the host asks a plugin to connect a port to a memory
location, it makes a note, somehow, of the connection (or even resorts
right there and then). If you have the Quasimodo source, see
libs/quasimodo/process.cc for the sort algorithm used there. It is, I
hope, very self-explanatory.
As for the visualization, see the Nord Modular. It supports in/out
ports very easily, and visualizes them quite nicely.
--p
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:28 EST