[Bug 17367] (OscillatorTypeModification): Oscillator type modification

https://www.w3.org/Bugs/Public/show_bug.cgi?id=17367

paul@paul.cx <padenot@mozilla.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |padenot@mozilla.com
             Blocks|                            |17368

--- Comment #8 from paul@paul.cx <padenot@mozilla.com> ---
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Monday, 2 September 2013 11:31:57 UTC