W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2013

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

From: Olivier Thereaux <notifications@github.com>
Date: Wed, 11 Sep 2013 07:29:53 -0700
To: WebAudio/web-audio-api <web-audio-api@noreply.github.com>
Message-ID: <WebAudio/web-audio-api/issues/136/24244479@github.com>
> [Original comment](https://www.w3.org/Bugs/Public/show_bug.cgi?id=17367#9) by paul@paul.cx on W3C Bugzilla. Tue, 03 Sep 2013 16:11:38 GMT

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

Consistency between switching between two basic oscillator and switching between a basic oscillator and a custom waveform (i.e. reset in both cases). I agree than (2) is probably okay as well, since it means less work for the author.

---
Reply to this email directly or view it on GitHub:
https://github.com/WebAudio/web-audio-api/issues/136#issuecomment-24244479
Received on Wednesday, 11 September 2013 14:30:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:11 UTC