On Sun, Sep 25, 2011 at 4:41 PM, Fons Adriaensen wrote:
this is a reminder of the closing post from the last thread about this
subject. it came from you. to me it can be summarized as "a complete
control API would include both lower sample rate control signals and
timestamped events", which if true leads to my point about there being
a lack of consenus about the right way to tackle the issue, and as
usually happens with a project like jack, a lack of consensus *AND*
and a lack of any working patch means that things don't change.
neither of the two ideas was rejected. the subject is basically still open.
On Sat, Feb 20, 2010 at 07:31:04AM +0100, torbenh wrote:
> i am basically more in favour of timestamped events.
I'll repeat once again ** Low rate control signals are
not meant to replace generic timestamped events which
are still needed. **
They provide a solution for some cases that are quite
difficult to handle with events, even if you don't
consider the Jack context, i.e. the variable data
For example it would be quite hairy to use discrete
events to create a C1 continuous control signal -
C1 means no 'jumps' and no 'corners'. It can be done
but would require a level of complexity that breaks
the charms of the basic idea and would make most
potential users run away screaming. Just combining
(adding) two such streams with non-coincident events
would be a real nightmare.
With continuous control signals the burden of ensuring
it has the required qualities for a particular use (e.g.
any degree of continuity, or spectral limits) are on
the generator of the control signal. The receiver
would be safe to use it at its full bandwidth, but
doesn't have to do this - it could still cut corners
for efficiency if it wanted, and in most cases that
would actually happen as Fs/16 is overkill anyway.
The 1/16 rate is chosen because it ensures that even
with a period size of 16 (the practical limit IMHO)
all periods are still equal, and a factor of 16
reduction in stored data size makes it usable.
Having non-power-of-2 period sizes complicates the
picture. When and why was this allowed ? I'm pretty
sure it will break a lot of code (including some of
mine, including probably Aeolus and Jconvolver).
Linux-audio-user mailing list