[LAD] CV data protocol in apps.

[torbenh]

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
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