Re: AnalyzerNode - magnitude/phase

Thanks for your feedback everyone, I've turned the suggestions into a PR

https://github.com/WebAudio/web-audio-api/pull/262

Cheers,

Chris


On 29 September 2013 16:56, Marcus Geelnard <mage@opera.com> wrote:
> Here's what I think...
>
> First of all I don't think that using an AnalyzerNode as a source for
> audio will work very well since it's not in sync with the rest of the
> audio engine (afaict). You really need to use a ScriptProcessorNode
> for that.
>
> With that said I think that getting full complex data from the
> analyzer node is a good thing. On the other hand I think that the most
> generic solution would be for the node to deliver full resolution time
> domain data and leave the fft details to the JS developer.
>
> /Marcus
>
> 2013/9/28, Srikumar Karaikudi Subramanian <srikumarks@gmail.com>:
>> (replying inline)
>>
>> On 27 Sep, 2013, at 10:48 PM, Chris Lilley <chris@w3.org> wrote:
>>
>>> Hello Chris,
>>>
>>> Friday, September 27, 2013, 11:22:52 AM, you wrote:
>>>
>>>> i) Allow getFloatFrequencyData() to return an array of complex values
>>>> somehow.
>>>
>>> Seems more technically correct and less likely to be implemented (oh
>>> no, complex numbers)
>>>
>>>> ii) Add methods for getRealFrequencyData() and
>>>> getImaginaryFrequencyData()
>>>
>>> ditto (name is correct but scary)
>>
>> An independent getComplexFrequencyData(realArray, imagArray) would serve
>> these purposes I think.
>>
>>>> iii) Add getFloatPhaseData() which would return the phase of the
>>>> calculated spectrum, and leave getFloatFrequencyData() returning the
>>>> magnitude.
>>>
>>> That seems like the best option to me. And yes, getting the phase is
>>> useful. What about an allpass filter as an example? Square waves in,
>>> tilted square waves out, that sort of thing.
>>
>> If such a getFloatPhaseData() is specified, then the standard would need
>> to include a specific way of dealing with phase continuity - i.e. phase is
>> modulo range [-PI, PI] or [0, 2PI] or decide that jumps across the 2PI
>> boundary
>> are resolved by offsetting the phase to be continuous, etc. The Real/Imag
>> split would simplify these decisions and put the power in the hands of the
>> dev. R/I would also be computationally simpler (no log->exp and
>> arctan->sin/cos
>> ops) when passing to an IFFT function for synthesis.
>>
>> -Kumar
>>
>>> --
>>> Best regards,
>>> Chris                            mailto:chris@w3.org
>>>
>>>
>>
>>

Received on Thursday, 17 October 2013 15:15:53 UTC