Re: [ecasound] cascading LADSPA plugins with ecasound

--- On Mon, 7/21/08, Kai Vehmanen <kvehmanen@email-addr-hidden> wrote:

> From: Kai Vehmanen <kvehmanen@email-addr-hidden>
> Subject: Re: [ecasound] cascading LADSPA plugins with ecasound
> To: "Sergei Steshenko" <sergstesh@email-addr-hidden>
> Cc: ecasound-list@email-addr-hidden
> Date: Monday, July 21, 2008, 12:55 PM
> Hi,
>
> On Mon, 21 Jul 2008, Sergei Steshenko wrote:
> > I am having difficulty relating your command line to
> my example:
> [...]
> > 1) where are my plugin names in the command line ?
>
> ecasound supports two ways to identify LADSPA plugins,
> either by name or
> by unique id. I used the latter in my examples:
>
> ecasound -f:16,2,44100 -i foo.wav -o bar.wav -eli:123,a,b
> -eli:456,c,d
>
> ... so plugins with ids '123' and '456' are
> instantiated. This is
> equivalent to:
>
> -el:pluginA,a,b -el:pluginB,c,d
>
> > 2) which command line items relate to mu plugins
> inputs and outputs names ?
>
> That's a good point. Ecasound doesn't allow to
> freely connect individual
> ports of plugins. Instead, plugin ports are mapped to chain
> channels, one
> port per channel. If a plugin has only one input and one
> output, and the
> chain has multiple channels, ecasound instantiates multiple
> instances of
> the same plugin (one for each channel). So it tries to do
> the "right
> thing" in these two different cases. With your
> plugins, the inputs are
> mapped to channels 1-N in the order they are enumerated in
> the LADSPA
> plugin descriptor.
>
> > 3) is it that LADSPA plugins input and output ports
> are accessed by number
> > rather than by name (probably yes) ?
>
> Yes, sort of, so they are mapped to channels 1, 2, ..., N
> in the order
> they appear in the descriptor. If you want to route
> specific channel of
> audio to a specific LADSPA plugin port, or route audio from
> a specific
> LADSPA plugin output port to a specific channel of the
> output audio
> stream, you have to utilize the channel routing operators
> offered by
> ecasound (-chcopy, -chmix, -chmove, etc).
>
> ...
>
> The reasoning for current design is that it would be quite
> difficult to
> offer a command-line UI for free routing of plugin ports.
> Just the names
> are a bit challenging, as they are long, commonly contain
> special
> characters and whitespace which would require a lot of
> escaping when
> referred to from the command-line or script. Additionally
> ecasound adds
> another layer of complexity, as there are quite a few ways
> plugins can be
> used, which would add to the overall challenge of providing
> a sensible UI.
> The current approach makes simple things simple (applying
> mono plugins
> to both mono and multichannel chains), while still allows
> more complex
> use-scenarios (use of N:M in-out port plugins in
> multichannel chains).
>
> --

Thanks.

Probably then ecasound is not a good tool for me.

In my case:

1) number of channels changes:

--/-->pligin_1--/-->plugin_2--/-->
  2 4 2

2) I do need certain connection between plugin_1 and plugin_2;

3) it is absolutely unacceptable for me to instantiate the same plugin
mor than one time for a number of reasons:

  a) performance - the plugins are quite "heavy";
  b) my implementation of the plugins - they use shared memory to get
     controls, I intentionally did it this way because the native LADSPA
     way is unacceptable for me for again performance reasons.

Thanks,
  Sergei.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Ecasound-list mailing list
Ecasound-list@email-addr-hidden
https://lists.sourceforge.net/lists/listinfo/ecasound-list
Received on Tue Jul 22 00:15:04 2008