Chain operator bypass, or other solutions

[Ashley J Gittins]

Hi all,
        Over the last while I have been working on putting together a purely software
system to use for jamming, on-site multitracking and potentially, performance.
After trying out lots of different ladspa hosts and other engines, I think
ecasound is the closest to meeting my needs by a fairly long margin.

One thing I have come up against though is not being able to find an efficient
way to bypass specific effects in a chain (like you do for an analogue board
of effects pedals for instance). Ideally I would like to be able to bypass
specific chainops via netECI so that I can (for example) switch in a gain
boost for a solo, or a heavy phaser effect, or switch out a delay momentarily.

Given that I couldn't find a cop-bypass function (which is something that
seems to have been raised some years ago but might have been forgotten about
since), I have been trying to think of alternative possibilities:

a) use cop-add, cop-remove to insert and remove effects in realtime
        This seems to be how TkEca does it's bypass feature, but I don't much like
the approach because it requires the controlling code to maintain all the
state information for the given effects, meaning that the ecs file is no
longer as useful as a master record of the setup, and also the add/remove
steps seem fairly resource-wasteful, and I think causes breaks in processing
which isn't ideal for use in realtime during performance

b) put each chainop in it's own chain, link the chains together, and use the
builtin chain-bypass feature
        This approach seems to have problems both with making the chainsetup
horrifically complicated and messy and, as far as I know, the only way to do
this is to use a lot of loop operators, which each introduce further latency
equivalent to the buffersize (do I understand that correctly?). Again, this
doesn't sound ideal for a live performance situation.

c) add a cop-bypass feature
        Given the above (and assuming I'm not missing something as far as other
options go) this would appear the best solution, but I am open to suggestions.
I would think this would have the advantage of not introducing any latency
(indeed, might it reduce latency if some cops didn't participate in the
process() loop?) and would allow for easy control via netECI or IAM.

Has anyone already done or attempted this? I have so little experience with c
(let alone c++) that I am not sure I'd be very effective trying to do this
myself.

As near as I can tell, it looks to me like the base class CHAIN_OPERATOR could
get a new property, is_active or similar, a new method to toggle the property,
then CHAIN::process() in eca_chain.cpp could add a check for chainops_rep[p]-
>is_active before calling its process() method.

The ECI/IAM code would then need glue to toggle the setting, via the engine
queue, I would guess.

Is that anywere near being on the right track? Or is there an existing
solution to my problem that I haven't even considered? By the way, I am using
mostly LADSPA plugins currently (I ported the effects setup from muddling
around in jack-rack) but might change some to built-ins, if there are
advantages to doing so.

If anyone is able to take a stab at doing this I'd really appreciate it,
otherwise just some direction on how I should approach it will definitely
help.

I am usually around on freenode (#jack and #lad) if anyone is interested in
collaborating via IRC (when it comes to C/C++, I am going to need all the help
I can get :-) ).

--
Regards,
        Ashley J Gittins
        web: http://www.purple.dropbear.id.au
        jabber: agittins@...


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Ecasound-list mailing list
Ecasound-list@...
https://lists.sourceforge.net/lists/listinfo/ecasound-list

[Joel Roth-2]

On Sun, Aug 30, 2009 at 02:04:40PM +1000, Ashley J Gittins wrote:

> Hi all,
> Over the last while I have been working on putting together a purely software
> system to use for jamming, on-site multitracking and potentially, performance.
> After trying out lots of different ladspa hosts and other engines, I think
> ecasound is the closest to meeting my needs by a fairly long margin.
>
> One thing I have come up against though is not being able to find an efficient
> way to bypass specific effects in a chain (like you do for an analogue board
> of effects pedals for instance). Ideally I would like to be able to bypass
> specific chainops via netECI so that I can (for example) switch in a gain
> boost for a solo, or a heavy phaser effect, or switch out a delay momentarily.

 

> Given that I couldn't find a cop-bypass function (which is something that
> seems to have been raised some years ago but might have been forgotten about
> since), I have been trying to think of alternative possibilities:
>
> a) use cop-add, cop-remove to insert and remove effects in realtime
> This seems to be how TkEca does it's bypass feature, but I don't much like
> the approach because it requires the controlling code to maintain all the
> state information for the given effects, meaning that the ecs file is no
> longer as useful as a master record of the setup, and also the add/remove
> steps seem fairly resource-wasteful, and I think causes breaks in processing
> which isn't ideal for use in realtime during performance

The breaks in the sound when adding and removing effects can
be annoying. One workaround is to fade the volume to zero
during the change over. I use this technique in Nama (an
Ecasound front-end.) However that may not be satisfactory in
situations where you want is a change in character of a
sustained sound. Also I have not implemented a bypass
function yet (it's on the TODO list.)
 
> b) put each chainop in it's own chain, link the chains together, and use the
> builtin chain-bypass feature
> This approach seems to have problems both with making the chainsetup
> horrifically complicated and messy and, as far as I know, the only way to do
> this is to use a lot of loop operators, which each introduce further latency
> equivalent to the buffersize (do I understand that correctly?). Again, this
> doesn't sound ideal for a live performance situation.

One chain per effect will add too much latency for live
performance. However for special cases, it might be worth
having two chains, one processed the other with an
equivalent latency, so you could fade smoothly between them.
 

> c) add a cop-bypass feature
> Given the above (and assuming I'm not missing something as far as other
> options go) this would appear the best solution, but I am open to suggestions.
> I would think this would have the advantage of not introducing any latency
> (indeed, might it reduce latency if some cops didn't participate in the
> process() loop?) and would allow for easy control via netECI or IAM.
>
> Has anyone already done or attempted this? I have so little experience with c
> (let alone c++) that I am not sure I'd be very effective trying to do this
> myself.

I expect there may be some technical limitations here.

Ardour was designed from the ground up to enable bypass.
I believe Paul Davis considered and rejected using Ecasound
as the audio processing engine for Ardour because of some
of these issues.
 

> As near as I can tell, it looks to me like the base class CHAIN_OPERATOR could
> get a new property, is_active or similar, a new method to toggle the property,
> then CHAIN::process() in eca_chain.cpp could add a check for chainops_rep[p]-
> >is_active before calling its process() method.
>
> The ECI/IAM code would then need glue to toggle the setting, via the engine
> queue, I would guess.
>
> Is that anywere near being on the right track? Or is there an existing
> solution to my problem that I haven't even considered? By the way, I am using
> mostly LADSPA plugins currently (I ported the effects setup from muddling
> around in jack-rack) but might change some to built-ins, if there are
> advantages to doing so.
>
> If anyone is able to take a stab at doing this I'd really appreciate it,
> otherwise just some direction on how I should approach it will definitely
> help.

I'm also interested in how we might approach this with
Ecasound.
 
> I am usually around on freenode (#jack and #lad) if anyone is interested in
> collaborating via IRC (when it comes to C/C++, I am going to need all the help
> I can get :-) ).
>
> --
> Regards,
> Ashley J Gittins
> web: http://www.purple.dropbear.id.au
> jabber: agittins@...
--
Joel Roth

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Ecasound-list mailing list
Ecasound-list@...
https://lists.sourceforge.net/lists/listinfo/ecasound-list

[Kai Vehmanen]

Hi,

On Sun, 30 Aug 2009, Ashley J Gittins wrote:

> One thing I have come up against though is not being able to find an efficient
> way to bypass specific effects in a chain (like you do for an analogue board

although I think the proper way is to implement 'cop-bypass', one hackish
workaround is to wrap the effects into presets and define subchains for
bypass on and off, e.g.:

~/.ecasound/effect_presets
--cut--
efl_w_bypass = -efl:%1 -ea:%2 | -ea:%3
--cut--

sh> ecasound -i foo.wav -o alsa -pn:efl_w_bypass,500,200,0 -c

Bypass off:
ecasound> cop-set 1,3,100
ecasound> cop-set 1,2,0
ecasound> cop-set 1,3,200

Bypass on:
ecasound> cop-set 1,2,100
ecasound> cop-set 1,3,0
ecasound> cop-set 1,2,200

When done from an ECI app, the result should be fairly good (as cop-set is
a real-time command). But this is still very clumsy (having to define a
wrapper preset for each effect), and can cause side-effects (amplitude
bump when toggling the bypass). Note that preset code (-pn) mixes the
subchains by doing averaging, so with multiple chains, you need to amplify
with 200% (6dB) to keep the original amplitude level.

> a) use cop-add, cop-remove to insert and remove effects in realtime
> This seems to be how TkEca does it's bypass feature, but I don't much like

This would be even better, but currently ecasound's engine is just not
suitable for this. IOW, changing the chain configuration is not a
real-time operation. And this is a fairly major change, so it's very
unlikely that this would get implemented anytime soon.

OTOH, the current changes I've been doing for OSC support, have resulted
in some infrastructure improvements that will eventually help in
implementing real-time cop-add/cop-remove. But on shorter term...

> c) add a cop-bypass feature
> Given the above (and assuming I'm not missing something as far as other
> options go) this would appear the best solution, but I am open to suggestions.

Yes, agreed. This is the most straightforward to implement.

> As near as I can tell, it looks to me like the base class CHAIN_OPERATOR could
> get a new property, is_active or similar, a new method to toggle the property,
> then CHAIN::process() in eca_chain.cpp could add a check for
> chainops_rep[p]->is_active before calling its process() method.

That would work, or maybe even more straighforward is to add a bypass
bitmask to CHAIN class (bit per chainop) and appropriate setter/getter
functions to the CHAIN public interface. And then in process():

  if (chainops_bypass_rep[p] != true) chainops_rep->process();

Only complication are chainops that alter the channel count in their
process() method. If processing is bypassed, this could cause problems.
But at least in theory the current code already handles this, even if we'd
skip some of the chainops (but needs to be thoroughly tested).

> The ECI/IAM code would then need glue to toggle the setting, via the engine
> queue, I would guess.

Yeps, a new real-time command is needed, but that is fairly simple to add
(well, not simple if you haven't modified the code before, but simple in
the sense that the code will look almost identical to e.g. 'c-bypass' and
'cop-set' which both are real-time safe). Basicly the files you need to
edit:

  - eca-iamode-parser.h (add new command to the enum)
  - eca-iamode-parser.cpp (link it to the parser, add constraints)
  - eca-control.cpp (link to an action)
  - eca-chainsetup.cpp (action part 1: route to correct CHAIN object)
  - eca-chain.cpp (action part 2a: actual action -> update bypass state)
  - eca-engine.cpp (action part 2b: for real-time commands only: these
    need to go indirectly via engine to synchronize the change with
    the engine processing cycle)

The existing commands (e.g. c-bypass, cop-set et al) serve as examples
what needs to be defined.

One thing to note is that current git tree has some changes both to
engine communication (new eca-chainsetup-edit.h interface) and to
eca-control.h (I've fixed a longlasting inheritance accident in the
ECA_CONTROL* classes ;)). These changes have been done to enable OSC
support (= and in more detail: to allow multiple independent entities to
feed ECI commands to the engine in parallel).

> Is that anywere near being on the right track? Or is there an existing
> solution to my problem that I haven't even considered? By the way, I am using
> mostly LADSPA plugins currently (I ported the effects setup from muddling
> around in jack-rack) but might change some to built-ins, if there are
> advantages to doing so.

Ecasound has been designed to support LADSPA plugins as first-class
citizens, so there shouldn't be any benefits to using the internal chainop
APIs (versus LADSPA).

> If anyone is able to take a stab at doing this I'd really appreciate it,
> otherwise just some direction on how I should approach it will definitely
> help.

This is an interesting idea and I will record it on the todo-list, but no
promises on the timeline. If you have time to take a stab at it, that'd be
great and I can try to help out if you encounter problems.

> I am usually around on freenode (#jack and #lad) if anyone is interested in
> collaborating via IRC (when it comes to C/C++, I am going to need all the help
> I can get :-) ).

At the moment I'm trying to avoid freenode. It's always fun, but also just
very, very time-consuming.. ;)

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Ecasound-list mailing list
Ecasound-list@...
https://lists.sourceforge.net/lists/listinfo/ecasound-list

[Kai Vehmanen]

Hi,

On Sun, 30 Aug 2009, Joel Roth wrote:

> Ardour was designed from the ground up to enable bypass.
> I believe Paul Davis considered and rejected using Ecasound
> as the audio processing engine for Ardour because of some
> of these issues.

just as a small correction -- I'm pretty sure Paul never considered
Ecasound code for Ardour. The two were developed basicly at the same time
and Paul had a fairly big codebase already from Quasimodo and Softwerk.
And most importantly, the design goals were quite different .. Ardour
targetted for full DAW functionality from the start, while Ecasound had a
much more narrow scope.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Ecasound-list mailing list
Ecasound-list@...
https://lists.sourceforge.net/lists/listinfo/ecasound-list