a-rate vs. k-rate AudioParams on scripted nodes

> 
> - Do we need to provide some distinctive treatment for k-rate AudioParams, resulting in a one-element value array (and corresponding efficiencies in the audio engine not bothering with frame-rate ramping etc)? It feels right to me, and knowing the rate of such params might enable some kinds of browser optimizations in the future. I think all we need is a 3rd argument specifying the rate on AudioWorkerNode#addParameter.
> 
> I thought through this, and discussed with Raymond beforehand.  I'm open to adding this, but it wasn't clear if you'd need a more definitive statement that "this is a k-rate AudioParam" than the fact that the arrays only have one element.  And, of course, all this saves is the generation of 127 entries in the block based on the scheduling; k-rate params can simply ignore them.  I simply avoided the complexity in this proposal, happy to add if there's some rough consensus we should do so.

I guess the key point for me is the ability to explicitly declare that an AudioParam is k- or a-rate when it’s added to the AudioWorkerNode. And making the arrays in AudioProcessingEvent contain only 1 element for k-rate parameters doesn’t seem like much of a win, now that you put it that way. Maybe it’s even a lose. 

For k-rate params, why not fill out the block to the full size, regardless. The values of the other 127 elements could be identical to the 0th one for k-rate params, and if all 128 values are always present, node implementors can write code that's rate-insensitive: use only the first value, or use the whole buffer, as the node pleases. That seems good.

I’m curious what others think on this point.

.            .       .    .  . ...Joe

Joe Berkovitz
President

Noteflight LLC
Boston, Mass.
phone: +1 978 314 6271
www.noteflight.com
"Your music, everywhere"