Re: bump: AudioParam constructor

On Mon, Mar 19, 2012 at 1:47 PM, Jussi Kalliokoski <
jussi.kalliokoski@gmail.com> wrote:

> 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);
> }
>

Hi Jussi, yes this looks much easier.  But I would make a small change by
passing the AudioParam instead of name to getParamValues()


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