Re: [LAD] CV data protocol in apps.

On Fri, Feb 19, 2010 at 01:48:24PM +0100, Fons Adriaensen wrote:
> On Fri, Feb 19, 2010 at 03:51:22AM +0100, torbenh wrote:
>
> > On Thu, Feb 18, 2010 at 06:09:42PM +0100, fons@email-addr-hidden 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.
> >
> > could you define _shorter_
> > is that app specific. or would that be a single factor for the whole
> > jack graph ?
>
> 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.

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)

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

not if the period is not a power of 2 :(
but maybe we should just go back to enforcing that again.

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

thanks for explanation :)

-- 
torben Hohn
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev