Re: [ecasound] cascading LADSPA plugins with ecasound

From: Sergei Steshenko <sergstesh@email-addr-hidden>
Date: Mon Jul 21 2008 - 23:13:30 EEST

--- 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).
> --


Probably then ecasound is not a good tool for me.

In my case:

1) number of channels changes:

  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.



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
Ecasound-list mailing list
Received on Tue Jul 22 00:15:04 2008

This archive was generated by hypermail 2.1.8 : Tue Jul 22 2008 - 00:15:04 EEST