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

That's actually why I left it as it is; the difference between a node being
k-rate or a-rate is purely a semantic implementation on the part of the
node implementer - i.e., it's a choice made by the person implementing what
happens in onaudioprocess.  There's no difference to the rest of the audio
system; and one could easily envision, say, a bitcrusher node that is
implemented as k-rate or one that is a-rate.

I'd rather not, the more I think about it, mess with this semantic choice.
 It's important in the context of understanding how the built in nodes
interpret values, but I don't think it's important to the higher levels of
the API.  If we are to capture this, though, I'd want to only pass one
value, not duplicate the values in the rest of the array.  (If we're making
it different anyway, we should save the perf of copying the values.)


On Mon, Aug 25, 2014 at 2:09 PM, Joseph Berkovitz <joe@noteflight.com>
wrote:

>
> - 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"
>
>