Re: [LAD] CV data protocol in apps.

From: torbenh <torbenh@email-addr-hidden>
Date: Fri Feb 19 2010 - 04:51:22 EET

On Thu, Feb 18, 2010 at 06:09:42PM +0100, fons@email-addr-hidden wrote:
> On Thu, Feb 18, 2010 at 11:43:07AM -0500, Paul Davis wrote:
>
> > On Thu, Feb 18, 2010 at 11:32 AM, <fons@email-addr-hidden> 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
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Fri Feb 19 08:15:01 2010

This archive was generated by hypermail 2.1.8 : Fri Feb 19 2010 - 08:15:01 EET