On Thu, Feb 18, 2010 at 06:09:42PM +0100, [email protected] wrote: > On Thu, Feb 18, 2010 at 11:43:07AM -0500, Paul Davis wrote: > > > On Thu, Feb 18, 2010 at 11:32 AM, <[email protected]> wrote: > > > > > A reduced sample rate means less bandwidth. It doesn't mean > > > that controls can't be 'sample accurate'. You could even > > > extract 'sub-sample-accurate' discrete events from them, > > > it's just a matter of interpretation. > > > > this just needs a minor re-use of the existing midi port type. > > drobilla always felt that it was questionable that we called this > > stuff "midi" at all, because 95% of the infrastructure is about > > handling sample accurate events, and is utterly agnostic about the > > contents. > > 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 ? 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] > > The last paragraph in my previous post just hinted at the > possibility that even such low-bandwidth 'analog' signals > can represent discrete events with infinite timing accuracy, > and in a way that would e.g. survive operations such as > mixing or resampling. 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) 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. -- torben Hohn _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
