On 18 Feb 2010, at 17:32, alex stone wrote: > So it's feasible to create another type of port, (CV/Fs), without > crippling something else in jack, or damaging the current API? > > If so, surely that would enhance further Jack's capabilities, and open > it up to more options for devs and users alike.
A reduced rate CV port doesn't really make much possible that's not already possible with a full buffer of values at the audio sampling rate. Its an optimisation -- *perhaps* -- but thats not the same thing as a new capability. If a receiving application, for example, wants to update its filter parameters at 1/16th the full sampling rate it is perfectly capable of skipping 16-at-a-time along an audio-rate buffer of values all by itself. Or 8-at-a-time. Or 32 or whatever divisor makes most sense for *that* application, or was configured by the user of that application, or whatever. Meanwhile this same buffer can be routed at the same time to applications that would prefer the full rate data. _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
