Re: [LAD] CV data protocol in apps.

On Thu, Feb 18, 2010 at 11:30:42AM +0100, Julien 'Lta' BALLET wrote:

> But actually, implementing it perfectly it jack apps may cost a lot if
> your control rate is the same as the audio rate (for example computing
> a filter coefs 96000 times per second).

You don't *have* to do it that way. As an example, AMS
uses audio-rate control signals, but the VCF and other
modules I wrote for it years ago just use one sample per
period (the last one in the buffer), calculate filter
parameters from these, and interpolate the final params
linearly at sample rate (which is cheap on CPU). You can't
do this with all filter types, it's one reason to avoid
e.g. biquads.

> I think a new type of 'audio'
> port having only a sample per period could be a simple and handy
> solution to this (one of the problem may be when you connect more than
> one cv to a port, mixing CV isn't necessarily the thing we want to do)

Mixing can still be handy if you have 'logarithmic' controls.
A reduced-rate port type in Jack (e.g. Fs/16 or Fs/64) would
be very useful IMHO. I've also been thinking of writing a
multichannel 'automation recorder' using such rates to capture
and playback 'control voltages'. There have been many times
when I'd wanted such a thing.

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.

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