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 [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
