[ecasound] Chain operator bypass, or other solutions

From: Ashley J Gittins <agittins@email-addr-hidden>
Date: Sun Aug 30 2009 - 07:04:40 EEST

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@email-addr-hidden
------------------------------------------------------------------------------
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@email-addr-hidden
https://lists.sourceforge.net/lists/listinfo/ecasound-list
Received on Sun Aug 30 12:15:01 2009

This archive was generated by hypermail 2.1.8 : Sun Aug 30 2009 - 12:15:01 EEST