Re: [web-audio-api] WaveTable is poorly named (#170)

> [Original comment](https://www.w3.org/Bugs/Public/show_bug.cgi?id=19561#5) by Chris Rogers on W3C Bugzilla. Tue, 04 Dec 2012 19:56:01 GMT

(In reply to [comment #3](#issuecomment-24244656))
> I think I'm with Chris Wilson here. I find it a bit counterintuitive to have
> "Wave" in the name at all, since to me, a wave is a time domain thing but
> the WaveTable object holds frequency domain data (it's the OscillatorNode
> that produces the wave, not the WaveTable object).
> 
> More precisely, the data held in the object is the Fourier series of a
> periodic wave, but I guess PeriodicWaveFourierSeries is a bit too wordy to
> be practical?
> 
> As usual, interface naming is about the hardest thing you can do in computer
> science ;)
> 
> Here's another thought: You could treat the WaveTable object in a way that
> is independent of frequency/time domain. For instance, if the interface
> provided a way to set the object state from a time domain signal as well as
> from a frequency domain signal, and let it be up to the implementation to
> choose how to store the data internally (could be frequency domain for hi
> quality synthesis or time domain for low quality synthesis), and use
> FFT/IFFT internally for the setters, as appropriate for the implementation.
> 
> If so, I think "PeriodicWave" would be a very fitting name.

Actually, the object as it's currently implemented in WebKit *does* internally represent the data in the time-domain (in multiple tables to avoid aliasing at different playback rates -- this is an implementation technique I can share more details about...).  And I *do* think it's conceivable that we could have a way to create these objects given a time-domain array of data.

So this object isn't really tied to frequency-domain or time-domain and the current way of constructing it is simply a matter of convenience.

So I hope that "PeriodicWave" will be a good name.

---
Reply to this email directly or view it on GitHub:
https://github.com/WebAudio/web-audio-api/issues/170#issuecomment-24244672