Re: [ecasound] Chain operator bypass, or other solutions

[Kai V. <kve...@ec...>]

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