Re: FFT & IFFT with the Web Audio API

In that case better place would be at top level; provide generalised FFT
and iFFT as html5 API. Rather than coding some .js or plugin for FFT
calculation as it is being used in my apps now.

br,
kdj


On Mon, Jun 17, 2013 at 10:21 PM, Kevin Gadd <kevin.gadd@gmail.com> wrote:

> If you're going to expose a reusable FFT, there's an argument to be made
> that you might as well make it a commodity function so that it can be used
> on any stream of data in a TypedArray instead of specifically things that
> are being fed to Web Audio. After all, audio isn't the only place people
> use FFTs.
>
> -kg
>
>
> On Mon, Jun 17, 2013 at 8:56 AM, Russell McClellan <russell@motu.com>wrote:
>
>>
>> On Jun 17, 2013, at 11:29 AM, Marcus Geelnard <mage@opera.com> wrote:
>>
>>  My original proposal was to rip the FFT part out of the analyzer node
>> (it can just as well give the time domain signal only), and expose the FFT
>> functionality in a JS interface instead. That way we would have the same
>> functionality and performance for the analyzer node (when combined with the
>> JS FFT interface), but the FFT primitive could be used in the
>> ScriptProcessorNode too for a wide range of interesting effects (not to
>> mention for using it for non-Web Audio stuff as well).
>>
>>
>> As I said just last week, I think even better would be a
>> "SpectralProcessorNode", which would act exactly like the
>> ScriptProcessorNode except on spectral data.  You could control parameters
>> like overlap, window, and fft size, and these would have reasonable
>> defaults.  I think just exposing an FFT function would be a little too
>> "low-level" in character compared to the rest of the web audio API.
>>
>> Thanks,
>> -Russell
>>
>
>