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

> [Original comment](https://www.w3.org/Bugs/Public/show_bug.cgi?id=17367#8) by Chris Wilson on W3C Bugzilla. Tue, 03 Sep 2013 15:40:17 GMT

(In reply to [comment #8](#issuecomment-24244465))
> 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). 

I do not want to change types to be immutable, for the reasons Chris listed.

> 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.

Definitely agree.

> 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.  

Consistency with what?  The author doesn't have any phase control (other than doing the math, figuring out precisely when the earliest they can switch, and aligning phase that way).  I would lean toward (1) for that reason.

> - 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 ;

+1.

> - 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 ;

+1.

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