Re: [ecasound] gate (-gc) retriggering?

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [ecasound] gate (-gc) retriggering?
From: Kai Vehmanen (
Date: Tue Aug 27 2002 - 02:08:53 EEST

On 25 Aug 2002, Nathan Stewart wrote:

> Ok, I've been going through the SAMPLE_ITERATOR stuff and have some more
> questions:
> Why is there no {pre,post}{inc,dec}rement, or previous?

No better reason than for simplicity. For all chain ops so far, using
next() with possibly multiple iterator objects iterating through the same
buffer, has been enough. An example of use of two iterators, take a look
at EFFECT_FAKE_STEREO (-etf) in audiofx_timebased.{h,cpp}.

If the iterators are not enough, it's always possible to access the audio
data directly (ie. SAMPLE_BUFFER::buffer data member). This is done for
instance in EFFECT_LADSPA (audiofx_ladspa.h). As long as there's not too
many of these ops (for maintenance reasons), direct access is a viable

> Why is there not a copy constuctor or assignment?

A very good point. Always writing explicit contructors and assignment ops
is a good policy (demanded for instance by Mozilla coding guide lines),
but again I try to limit the amount of source code and rely on the
implicit, compiler-generated functions. In this case they do exactly what
is wanted.

> My first stab at this, I was going to
> go through the buffer, and if the gate is open, and I hit a null, skip
> ahead several samples and see if the value was still zero, at which
> point I would close the buffer NOW. You could do some really neat (non
> real time) things with dynamics processors with look ahead capability.

You could do this using multiple sample iterators, although the look-ahead
would be limited to SAMPLE_BUFFER::length_in_samples() per buffer.

> Also, in GATE_BASE, why is SAMPLE_BUFFER* target private, rather than
> protected?

This is more of a coding style issue. I don't like to derive data members
in C++. Unlike in some other OO-languages, like Eiffel, in C++ data
members are second class citizens when it comes to inheritance - they
cannot be overridden nor they can be dynamically resolved. So it's
usually a better to wrap data member with access functions and make those
functions available to child classes (ie. in protected scope).

In this specific case, if subclasses need access to 'target', they should
override init() and process() and ignore the 'target' altogether. In other
words we make the common case simple.

 Audio software for Linux!

-- To unsubscribe send message 'unsubscribe' in the body of the message to <>.

New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Tue Aug 27 2002 - 02:05:59 EEST