[LAD] CV data protocol in apps.
compose59 at gmail.com
Fri Feb 19 13:20:19 UTC 2010
On Fri, Feb 19, 2010 at 4:05 PM, alex stone <compose59 at gmail.com> wrote:
> 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;
>>> x = 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 !
>> Linux-audio-dev mailing list
>> Linux-audio-dev at lists.linuxaudio.org
> An obvious question i guess, but is 1/16 a fine enough resolution for
> a wide selection of use cases?
> midi-subscribe at openoctave.org
> development-subscribe at openoctave.org
The use case i'm thinking of is a crescendo or decrescendo using gain
in a continuous stream of data. Will 1/16 reduce the......
midi-subscribe at openoctave.org
development-subscribe at openoctave.org
More information about the Linux-audio-dev