- From: <bugzilla@jessica.w3.org>
- Date: Fri, 15 Jun 2012 15:45:58 +0000
- To: public-audio@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17367
Marcus Geelnard (Opera) <mage@opera.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|WONTFIX |
--- Comment #4 from Marcus Geelnard (Opera) <mage@opera.com> 2012-06-15 15:45:57 UTC ---
(In reply to comment #3)
> I don't think it's essential for the change to occur with minimal delay. In
> other words, I don't think it's as critical for this change to happen as
> quickly as say a call to noteOn(0) (representing playing a sound immediately).
> I'm expecting the type will be changed as a result of some user action in the
> UI (changing osc-type menu from square->sawtooth).
Since the interface isn't designed for (near) sample-accurate waveform switches
(which would be required for doing things such as emulating some sounds from
8-bit systems, e.g. the rapidly changing waveform that can be heard in [1]), I
think that an acceptable solution would be to move the type and WaveTable
attributes to the constructor instead (and remove them from the interface). I
can't think of a single application that would not work even with this
restriction (either replace nodes when you change waveform, or use AudioGain to
switch between multiple oscillators at precise times), and it sure would
simplify a lot of things.
Otherwise, I think that the specification must say something about the expected
latency associated with changes to the type/WaveTable parameters.
[1] http://www.youtube.com/watch?v=CT2GEVqsomQ&t=179
--
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Received on Friday, 15 June 2012 15:46:05 UTC