[LAD] CV data protocol in apps.

[fons at kokkinizita.net]

On Fri, Feb 19, 2010 at 12:39:35PM -0500, Paul Davis wrote:

> that all makes sense, but if you had a single floating point event per
> process cycle, you'd accomplish the same thing, and it would work no
> matter what the process cycle size was,

Assuming that control changes can be synchronised to
Jack periods is one thing I've learned *not* to do.
It can be done if the source of the control data is
a GUI, or some other human interface and the timing
is not critical. In all other cases it is an invalid
assumption. And not all control is discrete events
which can be timestamped. In my recent applications
it almost never is.

> and could be used for denser
> control values (i.e. more events per process cycle) when
> appropriate/necessary/desirable.

The Fs/16 stream is *not* meant as a data channel that
multiplexes different event types, or values for more
than one controller. It represents a *signal* in all
cases - exactly *one* value that is a function of time.
You could use it for events (e.g. as a trigger of an
envelope), but the number of events on a single parameter
that makes sense is limited by human hearing, and already
some orders of magnitude lower than what a 3 kHz stream
would allow. So 'denser control values' don't make any
sense here.

Ciao,

-- 
FA

O tu, che porte, correndo si ?
E guerra e morte !