Re: [web-audio-api] (OscillatorTypeModification): Oscillator type modification (#136)

> [Original comment](https://www.w3.org/Bugs/Public/show_bug.cgi?id=17367#4) by Chris Rogers on W3C Bugzilla. Fri, 15 Jun 2012 19:30:55 GMT

(In reply to [comment #4](#issuecomment-24244434))
> (In reply to [comment #3](#issuecomment-24244426))
> > I don't think it's essential for the change to occur with minimal delay.  In
> > other words, I don't think it's as critical for this change to happen as
> > quickly as say a call to noteOn(0) (representing playing a sound immediately). 
> > I'm expecting the type will be changed as a result of some user action in the
> > UI (changing osc-type menu from square->sawtooth).
> 
> Since the interface isn't designed for (near) sample-accurate waveform switches
> (which would be required for doing things such as emulating some sounds from
> 8-bit systems, e.g. the rapidly changing waveform that can be heard in [1]), I
> think that an acceptable solution would be to move the type and WaveTable
> attributes to the constructor instead (and remove them from the interface). I
> can't think of a single application that would not work even with this
> restriction (either replace nodes when you change waveform, or use AudioGain to
> switch between multiple oscillators at precise times), and it sure would
> simplify a lot of things.
> 
> Otherwise, I think that the specification must say something about the expected
> latency associated with changes to the type/WaveTable parameters.
> 
> [1] http://www.youtube.com/watch?v=CT2GEVqsomQ&t=179

I think it's important to support changing the oscillator type and to be able to set the wavetable after creation, because these are features of the oscillator that are important to control.  Even basic analog synthesizers allow this.

An example use case changing oscillator type:
http://chromium.googlecode.com/svn/trunk/samples/audio/oscillator.html

An example use case calling setWaveTable():
http://chromium.googlecode.com/svn/trunk/samples/audio/tone-editor.html

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