On Fri, Feb 19, 2010 at 4:05 PM, alex stone <compos...@gmail.com> wrote: > On Fri, Feb 19, 2010 at 3:48 PM, Fons Adriaensen <f...@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, f...@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@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-subscr...@openoctave.org > development-subscr...@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...... "smoothness"? -- www.openoctave.org midi-subscr...@openoctave.org development-subscr...@openoctave.org _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev