Subject: Re: [linux-audio-dev] LADSPA and run_adding()
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Sat Nov 18 2000 - 06:58:15 EET
>> i would really like to once again voice my opinion that run_adding()
>> should be the default mode of operation for all LADSPA plugins.
>
>--votes;
>
>I'm still not convinced. I like to keep things simple. For me, LADSPA
>plugins are loadable functions that process a given range of samples.
>'run_adding()' goes further. It implies that plugins are signal
>routers, etc ...
I don't think of it this way. What it says is "a plugin's output
buffer may not be used by it alone".
>- read_from_file(a)
>- plug1.run_inplace(a)
>- ...
>- plugN.run_inplace(a)
>- write_to_file(a)
>
>==> 1 buffer, N plugins, 1 chain
This is not the scenario I am thinking of. Consider this:
read_from_sourceA(a);
read_from_sourceB(b);
read_from_sourceC(c);
plug1.connect_port(0,busA);
plug2.connect_port(0,busA);
plug3.connect_port(0,busA);
plug1.run(a);
plug2.run(b);
plug3.run(c);
write_to_destinationN(busA);
(i.e. mixdown of independent plugin chains to the same buffer).
>> this is appearing of major significance is a large-scale multichannel
>> system right now.
>
>This sounds like marketing speak to me. ;)
Sounds like ungrammatical english to me. Lets change the "is" to an
"in" for a start :)
Seriously, if you can explain how I can implement the example I give
above without having to iterate over 3 output buffers, sum their
contents and store the result in a 4th buffer, I'll be very grateful.
--p (strupper_random(my_email));
This archive was generated by hypermail 2b28 : Sat Nov 18 2000 - 07:30:32 EET