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

> [Original comment](https://www.w3.org/Bugs/Public/show_bug.cgi?id=17367#7) by paul@paul.cx on W3C Bugzilla. Mon, 02 Sep 2013 11:31:56 GMT

Do we still want to make the `type` oscillator types immutable? It may be too late for such breaking change (something like what comment 4 suggest). 

If we agree on keeping the interface as-is, we need to be more precise on the behaviour a conforming implementation should adopt when mutating the `type` attribute.

An author writing an application that requires high degree of synchronization when changing waveforms would need to use something like GainNodes and the automation functions (setValueAtTime and friends) anyways, so it might not be of too much importance to have very strict bounds, here. As comment 3 says, I also expect this to be mainly used as a response to a non time-critical action (say, a user changing the first oscillator in a multi-oscillator synth using a dropdown widget, when in the process of designing a sound).

In light of this use-case for modifying the `type` attribute on a playing OscillatorNode, we could spec it this way:
- Considering the node support "custom" waveforms, possibly out of phase with the basic waveform types, we have two options:
  (1) The phase is preserved when switching between basic oscillator type (we need to spec coherent phase among basic types for that, this is bug 17366). Switching to/from "custom" type resets the phase ;
  (2) Switching the type resets the phase, letting everything in the hands of the author ;

I'm in favor of adopting (2), for consistency.  

- There should not be a crossfade when changing the type. If an author wants  morphing between two or more waveforms, using GainNode with multiple OscillatorNode is easy enough ;
- Lower bound for the type change to be reflected in the node output could be the next block, making this act like an a-rate parameter does not make much sense ;
- I'm not sure about what could be a realistic upper bound. Depending on the generation method, switching oscillator can be virtually free (changing the algorithm when using time-domain generation), or more expensive (because an ifft is needed, for example). In practice, considering the above, this probably does not matter too much.

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