[LAD] CV data protocol in apps.

[alex stone]

On Fri, Feb 19, 2010 at 3:48 PM, Fons Adriaensen <fons at kokkinizita.net> wrote:
> 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
> position.
>
> 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
> information.
>
> 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.
>
> Ciao,
>
> --
> FA
>
> O tu, che porte, correndo si ?
> E guerra e morte !
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev at lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev
>

An obvious question i guess, but is 1/16 a fine enough resolution for
a wide selection of use cases?

-- 
www.openoctave.org

midi-subscribe at openoctave.org
development-subscribe at openoctave.org