On Fri, Feb 19, 2010 at 12:39:35PM -0500, Paul Davis wrote: > that all makes sense, but if you had a single floating point event per > process cycle, you'd accomplish the same thing, and it would work no > matter what the process cycle size was,
Assuming that control changes can be synchronised to Jack periods is one thing I've learned *not* to do. It can be done if the source of the control data is a GUI, or some other human interface and the timing is not critical. In all other cases it is an invalid assumption. And not all control is discrete events which can be timestamped. In my recent applications it almost never is. > and could be used for denser > control values (i.e. more events per process cycle) when > appropriate/necessary/desirable. The Fs/16 stream is *not* meant as a data channel that multiplexes different event types, or values for more than one controller. It represents a *signal* in all cases - exactly *one* value that is a function of time. You could use it for events (e.g. as a trigger of an envelope), but the number of events on a single parameter that makes sense is limited by human hearing, and already some orders of magnitude lower than what a 3 kHz stream would allow. So 'denser control values' don't make any sense here. 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
