Re: [linux-audio-dev] Re: A Plugin API

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

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


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:23:28 EST