On Fri, Feb 19, 2010 at 3:48 PM, Fons Adriaensen <[email protected]> wrote: > On Fri, Feb 19, 2010 at 03:51:22AM +0100, torbenh wrote: > >> On Thu, Feb 18, 2010 at 06:09:42PM +0100, [email protected] 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 > [email protected] > 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 [email protected] [email protected] _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
