cascading LADSPA plugins with ecasound

[Sergei Steshenko-2]

Hello All,

ecasound manual gives an example of LADSPA plugin usage, however, if I am
not missing something, it's an example with a single plugin.

Suppose I have two LADSPA plugins with the following data inputs and outputs:

1) plugin_1:

in1_L, in1_R,
out1_1L, out1_2L, out1_1R, out1_2R


2) plugin_2:

in2_1L, in2_2L, in2_1R, in2_2R,
out2_L, out2_R.

The plugins are meant to be connected this way:

out1_1L -> in2_1L,
out1_2L -> in2_2L,
out1_1R -> in2_1R,
out1_2R -> in2_2R.

in1_L, in1_R are meant to be the two inputs (left, right) inputs of
the resulting cascaded plugin, out2_L, out2_R are meant to be the two
outputs (left, right) of the resulting cascaded plugin.

Is it possible to do such a thing with ecasound ?

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@...
https://lists.sourceforge.net/lists/listinfo/ecasound-list

[Sergei Steshenko-2]

--- On Mon, 7/21/08, Jeremy Hall <jehall@...> wrote:

> From: Jeremy Hall <jehall@...>
> Subject: Re: [ecasound] cascading LADSPA plugins with ecasound
> To: ecasound-list@..., sergstesh@...
> Date: Monday, July 21, 2008, 6:25 AM
> if I understand you correctly, you want the loop device.
> Beware this MAY cost you one period, so make sure that your
> buffer size is small.  I don't know if this restriction
> has been relaxed, but at one time it was true.
>
> _J
>
> >>> Sergei Steshenko <sergstesh@...>
> 7/21/2008 8:29 AM >>>
> Hello All,
>
> ecasound manual gives an example of LADSPA plugin usage,
> however, if I am
> not missing something, it's an example with a single
> plugin.
>
> Suppose I have two LADSPA plugins with the following data
> inputs and outputs:
>
> 1) plugin_1:
>
> in1_L, in1_R,
> out1_1L, out1_2L, out1_1R, out1_2R
>
>
> 2) plugin_2:
>
> in2_1L, in2_2L, in2_1R, in2_2R,
> out2_L, out2_R.
>
> The plugins are meant to be connected this way:
>
> out1_1L -> in2_1L,
> out1_2L -> in2_2L,
> out1_1R -> in2_1R,
> out1_2R -> in2_2R.
>
> in1_L, in1_R are meant to be the two inputs (left, right)
> inputs of
> the resulting cascaded plugin, out2_L, out2_R are meant to
> be the two
> outputs (left, right) of the resulting cascaded plugin.
>
> Is it possible to do such a thing with ecasound ?
>
> Thanks,
>   Sergei.
>

Thanks, I'll check the loop device.

I am going to use ecasound only as LADSPA host, not for realtime recording,
but just for listening, so I probably don't care about that one period.

To avoid xruns I'll set buffer to be 4096 samples anyway.

Regards,
  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@...
https://lists.sourceforge.net/lists/listinfo/ecasound-list

[Kai Vehmanen]

Hi,

On Mon, 21 Jul 2008, Sergei Steshenko wrote:

> Suppose I have two LADSPA plugins with the following data inputs and outputs:
>
> 1) plugin_1:
>
> in1_L, in1_R,
> out1_1L, out1_2L, out1_1R, out1_2R
>
>
> 2) plugin_2:
>
> in2_1L, in2_2L, in2_1R, in2_2R,
> out2_L, out2_R.

[...]
> Is it possible to do such a thing with ecasound ?

that should work out of the box:

ecasound -f:16,2,44100 -i foo.wav -o bar.wav -eli:123,a,b -eli:456,c,d

... the inputs are mapped to channels 1,2,3,4, so it's important
to specify two open 'bar.wav' with two channels as well (for 'foo.wav',
whatever channel count is defined in the wave file header will be used).

--


-------------------------------------------------------------------------
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@...
https://lists.sourceforge.net/lists/listinfo/ecasound-list

[Sergei Steshenko-2]

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

> From: Kai Vehmanen <kvehmanen@...>
> Subject: Re: [ecasound] cascading LADSPA plugins with ecasound
> To: "Sergei Steshenko" <sergstesh@...>
> Cc: ecasound-list@...
> Date: Monday, July 21, 2008, 12:22 PM
> Hi,
>
> On Mon, 21 Jul 2008, Sergei Steshenko wrote:
>
> > Suppose I have two LADSPA plugins with the following
> data inputs and outputs:
> >
> > 1) plugin_1:
> >
> > in1_L, in1_R,
> > out1_1L, out1_2L, out1_1R, out1_2R
> >
> >
> > 2) plugin_2:
> >
> > in2_1L, in2_2L, in2_1R, in2_2R,
> > out2_L, out2_R.
> [...]
> > Is it possible to do such a thing with ecasound ?
>
> that should work out of the box:
>
> ecasound -f:16,2,44100 -i foo.wav -o bar.wav -eli:123,a,b
> -eli:456,c,d
>
> ... the inputs are mapped to channels 1,2,3,4, so it's
> important
> to specify two open 'bar.wav' with two channels as
> well (for 'foo.wav',
> whatever channel count is defined in the wave file header
> will be used).
>
> --

I am having difficulty relating your command line to my example:

1) where are my plugin names in the command line ?
2) which command line items relate to mu plugins inputs and outputs names ?
3) is it that LADSPA plugins input and output ports are accessed by number
rather than by name (probably yes) ?

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@...
https://lists.sourceforge.net/lists/listinfo/ecasound-list

[Kai Vehmanen]

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

--


-------------------------------------------------------------------------
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@...
https://lists.sourceforge.net/lists/listinfo/ecasound-list

[Sergei Steshenko-2]

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

> From: Kai Vehmanen <kvehmanen@...>
> Subject: Re: [ecasound] cascading LADSPA plugins with ecasound
> To: "Sergei Steshenko" <sergstesh@...>
> Cc: ecasound-list@...
> 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@...
https://lists.sourceforge.net/lists/listinfo/ecasound-list

[Sergei Steshenko-2]

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

> From: Kai Vehmanen <kvehmanen@...>
> Subject: Re: [ecasound] cascading LADSPA plugins with ecasound
> To: "Sergei Steshenko" <sergstesh@...>
> Cc: ecasound-list@...
> 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).
>
> --

Well, then another idea.

Can I use two ecasound instances connected through pipe ?

I.e. the first of the instances will use plugin_1 doing 2 -> 4 channels
conversion, and the second instance will receive data from the pipe, using
plugin_2 and doing 4 -> 2 cahnnels conversion and finally playing music.

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@...
https://lists.sourceforge.net/lists/listinfo/ecasound-list

[Kai Vehmanen]

Hi,

On Mon, 21 Jul 2008, Sergei Steshenko wrote:

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

that's not a a problem. From ecasound's point of view, plugin_1 takes two
channels in and four out, and this is perfectly ok. The four channels will
be fed out to plugin_2, and the final result will be written to channels
one and two (these are fed to the chain output).

>  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 is a bit dangerous as you might get compatibility issues with hosts,
but I understand the performance issues as well. So if it's enough to use
it with a limited set of hosts, that should be ok.

--

-------------------------------------------------------------------------
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@...
https://lists.sourceforge.net/lists/listinfo/ecasound-list