[LAD] CV data protocol in apps.

Fons Adriaensen fons at kokkinizita.net
Fri Feb 19 12:48:24 UTC 2010

On Fri, Feb 19, 2010 at 03:51:22AM +0100, torbenh wrote:

> On Thu, Feb 18, 2010 at 06:09:42PM +0100, fons at kokkinizita.net wrote:
> > We may not be talking of the same thing. This is not about
> > 'generic events' but about reduced-bandwidth continuous
> > signals, represented as floating point samples. So I'd say
> > that all it takes is a shorter version of the standard
> > _audio_ buffer.
> could you define _shorter_
> is that app specific. or would that be a single factor for the whole
> jack graph ?

Apps using this may have a preference, but I see no difficulty
in defining the a fixed control/audio ratio of 1/16. 
The intended use is to patch control signals, e.g. source
positions in a spatialisation system, or more classical
automation data such as gains and filter paramaters.
1/16 would provide a bandwidth of 1500 Hz (for a sample
rate of 48000) which is some overkill in many cases, but
otherwise good to have.

> if we dont mandate that a jack period is always an integer multiple
> of a period, we basically need some phase association.
> so that apps can sort of know that CV sample 0 has the same time
> as audio_sample[phase]

With a ratio of 1/16 you can just define the first sample
of control buffer to coincide with the first sample of 
the current audio period.
> hmm... its not completely obvious to me how it could survive
> some arbitrary resampling.
> i am thinking of:
> x[0] = 0;
> x[1] = 0.75;
> x[N] = 1.0  | N>1
> to encode an event to switch from 0 to 1 at t=0.666666
> (this representation is not causal, so it would need to be shifted...
> but this is what i have in mind)

You're close, see below. 

> i am a bit wary because this still seems a lot more expensive than
> having timestamped float events. and i am not sure the ease of recording
> this kind of data weighs it up again.

It's not meant as a replacedment for generic timestamped events.
I just mentioned it to make the point that a lower sampling rate
does not limit timing precision.

If your 'perfect' control signal would be a digital one
using -1,+1 at e.g. audio rate, and the transitions 
always have a minimal distance, then downsampling it
preserves all information. You can later upsample it
again, and the zero-crossings will be at the original

Exactly the same thing can be done if the original
signal consists of singe-sample triggers (Dirac
impulses). In that case, the peaks of the resulting
waveform will be at the original positions.

Now suppose you have audio tracks at 48 kHz and 
control tracks at 3 Khz, and you need to resample
the audio to 44.1 kHz. Resampling the control
tracks to the same ratio will again preserve all

Using full-quality resampling algos for this is of
course just a wast of resources. You could just use
cubic interpolation. In that case each impulse or
transition would required four 'samples', and they
could even overlap a bit. So at 44.1 or 48kHz / 16
you could roughly have one transition or impulse
each millisecond, with 'infinite' resolution.



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

More information about the Linux-audio-dev mailing list