Re: bump: AudioParam constructor

On Tue, Mar 20, 2012 at 9:39 PM, Chris Rogers <crogers@google.com> wrote:

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

Hey Chris. Yeah. probably a good idea to do so!


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