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
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
> I think a new type of 'audio'
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.
O tu, che porte, correndo si ?
E guerra e morte !
Linux-audio-dev mailing list