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: Jarno Seppanen (jams_AT_cs.tut.fi)
Date: ti helmi  29 2000 - 09:25:38 EST


Hello and thanks for the interesting discussion!

For a network wired A-->B-->C, I guess,
Paul Barton-Davis <pbd_AT_Op.Net> writes:

> 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

I agree that this may be the most efficient scheme for executing the above
network, but I think that there is no need for in/out ports in order to make
the above scheme possible.

In my opinion, using a single buffer for the three plugins and making the
plugins work "in-place" is a mere optimization from using three buffers, and
is based on the fact that the three plugins are connected in a cascade in this
case. Therefore, IMHO, the host must do the decision to use only one buffer
instead of three, and give all the three plugins the same buffer to read from
and to write to. An optimizing host that is.

In Sonic Flow we have successfully used the following motto: one buffer per
output port, and Paul's two other diagrams illustrate this approach nicely.
This concept lends itself naturally to wiring an output port to more than one
input, when needed.

> always get odd effects. You *must* flow sort the plugins. Quasimodo
> had this problem until a few months ago. The sort algorithm is very

> 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 it happens, we have also coded such an algorithm and written a lot of
comments. If somebody is interested, the code can be found from
http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/?cvsroot=sonicflow
in sf/src/libsf/network.cc under SF_Network::partition_network().

> As for the visualization, see the Nord Modular. It supports in/out
> ports very easily, and visualizes them quite nicely.

On the other hand, now that I think of it, making ALL ports be i/o in the
sense that one can add a wire to any an port and have the signals be summed
would be quite intuitive wrt. electronic devices. Isn't this about the way
how things happen in real modular synths or not?

-- 
-Jarno


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