Re: bump: AudioParam constructor

What I had in mind was more like this:

partial interface JavaScriptAudioNode {
    AudioParam createAudioParam(name, defaultValue, minValue, maxValue,
units);
}

partial interface AudioProcessingEvent {
    Float32Array getParamValues(name);
}


The idea would be that these would be assigned to the JavaScriptAudioNode,
and then you could access the values with something like this, from within
the onaudioprocess event:

event.getParamValues(paramName);

And that would get the respective values of the AudioParam created with
that name, matching the time span of the AudioProcessingEvent. How would
that sound?

One idea would be to have both, to allow for ahead-of-time rendering as
well as an easy way to work with things that follow the normal callback
pattern.

Jussi

On Mon, Mar 19, 2012 at 9:57 PM, Chris Rogers <crogers@google.com> wrote:

>
>
> On Mon, Mar 19, 2012 at 11:51 AM, Jussi Kalliokoski <
> jussi.kalliokoski@gmail.com> wrote:
>
>> Hey group,
>>
>> Just thought I'd bring this up again, as I recently [1] told about the
>> oscillator.js that adds an oscillator class to the AudioContext prototype.
>>
>> To refresh your memories of prior discussion: [2] [3] [4] [5] [6] [7] .
>>
>> So just wondering if there's any progress, the discussion sort of faded
>> away then?
>>
>> Chris, I think the Float32Array containing the values matching sample
>> times sounds like the most reasonable way to go right now. Either way, I
>> still think we should expose this functionality to JavaScript nodes.
>>
>> Cheers,
>> Jussi
>>
>
> Hi Jussi, yes I think it's an interesting idea and one idea to consider
> could be something like:
>
> partial interface AudioParam {
>
>     double getValuesForTimeRange(startTime, endTime, defaultValue,
> valuesArray, sampleRate);
>
> }
>
> One tricky thing is that the "timeline" values are stateful because of
> the setTargetValueAtTime() method which does an exponential approach to a
> desired value.  That's why I included the "defaultValue" and return value
> above.  As an alternative, this default or current value can simply be
> considered to be the "value" attribute and is kept in the AudioParam
> itself, but then it's still necessary to be aware of the statefulness,
> since in that case getValuesForTimeRange() would be expected to be called
> on successive continuous time ranges, and you couldn't just call it in a
> "random-access" way...
>
> It's a bit tweaky and there's a bit to think about here, but interesting
> stuff...
>
> Chris
>
>
>
>>
>> [1] http://lists.w3.org/Archives/Public/public-audio/2012JanMar/0374.html
>> [2] http://lists.w3.org/Archives/Public/public-audio/2011AprJun/0085.html
>> [3] http://lists.w3.org/Archives/Public/public-audio/2011AprJun/0086.html
>> [4] http://lists.w3.org/Archives/Public/public-audio/2011AprJun/0087.html
>> [5] http://lists.w3.org/Archives/Public/public-audio/2011AprJun/0089.html
>> [6] http://lists.w3.org/Archives/Public/public-audio/2011AprJun/0101.html
>> [7] http://lists.w3.org/Archives/Public/public-audio/2011AprJun/0103.html
>>
>
>