18 Feb
2010
18 Feb
'10
10:50 p.m.
On Thu, Feb 18, 2010 at 06:09:42PM +0100, fons(a)kokkinizita.net wrote:
On Thu, Feb 18, 2010 at 11:43:07AM -0500, Paul Davis
wrote:
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]
On Thu, Feb 18, 2010 at 11:32 AM,
<fons(a)kokkinizita.net> wrote:
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. 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.
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