- From: Chris Lowis <chris.lowis@gmail.com>
- Date: Thu, 17 Oct 2013 16:15:19 +0100
- To: public-audio@w3.org
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