linuxaudio.org

On Thu, Feb 18, 2010 at 06:09:42PM +0100, fons@kokkinizita.net wrote:

quoted text
> On Thu, Feb 18, 2010 at 11:43:07AM -0500, Paul Davis wrote:

>

> > On Thu, Feb 18, 2010 at 11:32 AM,   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]
>

quoted text
> 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@lists.linuxaudio.org

http://lists.linuxaudio.org/listinfo/linux-audio-dev