Re: Web Audio API sequencer capabilities

I'm having a related problem at the moment with setValueCurveAtTime, having a hard time figuring out how to scale a normalized Float32Array (values from 0 to 1) to another range (say, for a frequency from 2000 to 3000). Off course this could easily done in JavaScript but I'd prefer to generate just one Array for each curve at startup and scale it in the API, since it already can scale it in time.

Scaling a signal is pretty easy: Put the signal through through a Gain with value 500, patch it into the param, and set value to 2500 (it now should oscillate between 2000 and 3000).

Since the GainNode doesn't produce a signal we would need to feed him a Unity signal, but all the possibilities I see in the API would require the developer to specify the lifetime of the unity signal (I think it would be more straightforward for a UnitySourceNode to be collected automatically).

Easiest way for the setValueCurveAtTime would to have 2 additional parameters, a mul and an add (this is common in SuperCollider for example), with a formula like value * mul + add. As mul could default to 1 and add default to 0 you wouldn't need to set it if you don't need it.

Mut maybe a more general Mul/Add scheme for AudioParams could be found, such as a mul/add parameter, which would be applied to any value change. Again, with defaults of 1 and 0 it 

a) wouldn't break existing code
b) wouldn't clutter up code if the features aren't needed
c) made some operations much more easy (Scaling a signal for example wouldn't require the extra Gain node in many cases)

cheers,
Patrick



Am 06.10.2012 um 00:57 schrieb Joe Berkovitz <joe@noteflight.com>:

> Actually, I didn't ever think a GainNode would generate its own signal. Rather, it did not occur to me to drive a set of AudioParams with an envelope via the audio rate modulation feature, using a gain controlled unity signal. It is this last idea that seems a bit tricky and unclear for API novices. If there were something like a UnitySourceNode, I would feel better.
> 
> I'm interested in Chris Rs take since I'm sure he has given this some thought.
>