[LAD] CV data protocol in apps.
torbenh at gmx.de
Fri Feb 19 02:51:22 UTC 2010
On Thu, Feb 18, 2010 at 06:09:42PM +0100, fons at kokkinizita.net wrote:
> On Thu, Feb 18, 2010 at 11:43:07AM -0500, Paul Davis wrote:
> > On Thu, Feb 18, 2010 at 11:32 AM, <fons at kokkinizita.net> 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
> 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;
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)
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.
More information about the Linux-audio-dev