Re: [LAD] CV data protocol in apps.

On Fri, Feb 19, 2010 at 02:15:13PM +0000, Simon Jenkins wrote:
>
> On 19 Feb 2010, at 13:47, Fons Adriaensen wrote:
>
> > On Fri, Feb 19, 2010 at 04:20:19PM +0300, alex stone wrote:
> >
> >> The use case i'm thinking of is a crescendo or decrescendo using gain
> >> in a continuous stream of data. Will 1/16 reduce the......
> >> "smoothness"?
> >
> > No, the DSP code has to perform smoothing anyway, no matter
> > what the source of the control data is. Does your GUI fader
> > provide smooth audio rate updates ? Of course not, you'd be
> > lucky if it updates 25 times per second.
> >
>
> If the receiving application is going to smooth the data back
> up to audio rate anyway then what's the point? If the sender
> has already got audio-rate data then this is a big *lose*
> efficiency wise, with the sender spending cycles decimating
> a buffer that's going to be upsampled as soon as it arrives.

(1) Again, they have to do that anyway. Midi doesn't provide audio
rate controls. OSC doesn't. A generic timestamped event format
wouldn't. GUI controls don't.

(2) In almost all algorithms, if you want any efficiency at all
the smoothing is *NOT* done on the control value itself, but on
internal parameters (e.g. filter coefficients) computed from the
control value at lower rate. Sending an audio rate control is
useless, most of the data has to be ignored or lowpass filtered
anyway. Even a simple gain control has to filter an audio rate
control - you want a gain control, not a ring modulator.

(3) This would even be the case for a 1/16 rate signal. The
difference is that the latter takes 1/16 of the work to generate
it, and it takes 1/16 of the space when recorded. If you have
hundreds of them that makes a very big difference.

Ciao,

-- 
FA
O tu, che porte, correndo si ?
E guerra e morte !
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev