20 Feb
2010
20 Feb
'10
2:30 a.m.
On Fri, Feb 19, 2010 at 01:48:24PM +0100, Fons Adriaensen wrote:
not if the period is not a power of 2 :(
but maybe we should just go back to enforcing that again.
thanks for explanation :)
--
torben Hohn
On Fri, Feb 19, 2010 at 03:51:22AM +0100, torbenh
wrote:
good point. ok. so this still leaves us with the problem of the phase
relation in case of non-power of 2 period sizes.
(i am not sure if this patch slipped into jack1 accidentally or on
purpose, but the alsa driver doesnt enforce power of 2 anymore)
but that kind of thing can be fixed easily.
jack_nframes_t jack_cv_get_phase( jack_client_t *client );
i am basically more in favour of timestamped events.
but your argumentation in this thread is pretty convincing.
and timestamped events come with a galore of other problems,
which i think are harder to tackle in a jack context.
- multiple interpolation schemes
- how to get the current value when port is connected, and didnt see an
event yet.
so what do people think ?
shall we just add CV port type ?
(this would sort of rule out timestamped control events, since there
should be only one control port type)
On Thu, Feb 18, 2010 at 06:09:42PM +0100,
fons(a)kokkinizita.net wrote:
Apps using this may have a preference, but I see no difficulty
in defining the a fixed control/audio ratio of 1/16.
The intended use is to patch control signals, e.g. source
positions in a spatialisation system, or more classical
automation data such as gains and filter paramaters.
1/16 would provide a bandwidth of 1500 Hz (for a sample
rate of 48000) which is some overkill in many cases, but
otherwise good to have. 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]
With a ratio of 1/16 you can just define the first sample
of control buffer to coincide with the first sample of
the current audio period. 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)
You're close, see below.