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

[Bug 17367] (OscillatorTypeModification): Oscillator type modification

From: <bugzilla@jessica.w3.org>
Date: Tue, 03 Sep 2013 16:11:38 +0000
To: public-audio@w3.org
Message-ID: <bug-17367-5429-yY2zYtlvXc@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17367

--- Comment #10 from paul@paul.cx <padenot@mozilla.com> ---
(In reply to comment #9)
> > 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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Received on Tuesday, 3 September 2013 16:11:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:23 UTC