Maybe AdditiveHarmonics?  FourierHarmonics? It would be nice to capture that this is a set of harmonics being added to generate the waveform.  All Oscillators are periodic waveforms.

(In reply to comment #1)
> Maybe AdditiveHarmonics?  FourierHarmonics? It would be nice to capture that
> this is a set of harmonics being added to generate the waveform.  All
> Oscillators are periodic waveforms.

I much prefer PeriodicWave because this captures the essence of what it is.  The OscillatorNode generates a periodic output based on a representation of a single cycle -- this is what I'm calling PeriodicWave

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.

What about FormantTable?

(In reply to off-issue-tracker comment)
> Formant implies an _absolute_ frequency.
>
> The WaveTable entries are harmonics, i.e. _relative_ to the oscillator's
> current fundamental frequency.

You're absolutely right, HarmonicTable is more accurate.

I didn't notice your earlier comment because it was made on the mailing list, please refrain from commenting on issues off the issue tracker to avoid the discussion from getting fragmented. :)

(In reply to comment #3)
> 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.

Chris (R), do you think it's a good idea to add another method for creating the WaveTable (aka PeriodicWave) object from time-domain data?

(In reply to comment #7)
> Chris (R), do you think it's a good idea to add another method for creating
> the WaveTable (aka PeriodicWave) object from time-domain data?

Hi Marcus, sorry for the long delay.  I think it's useful to add another method, but not critical we add it right now into the spec.

Fixed:
https://dvcs.w3.org/hg/audio/rev/7c4a40a9bb57

(In reply to comment #9)
> Fixed:
> https://dvcs.w3.org/hg/audio/rev/7c4a40a9bb57

Looks good to me. And yes, it's not critical to add another time-domain function right now.

Closing.