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:51 -0700
To: WebAudio/web-audio-api <web-audio-api@noreply.github.com>
Message-ID: <WebAudio/web-audio-api/issues/136/24244434@github.com>
> [Original comment](https://www.w3.org/Bugs/Public/show_bug.cgi?id=17367#3) by Marcus Geelnard (Opera) on W3C Bugzilla. Fri, 15 Jun 2012 15:45:57 GMT

(In reply to [comment #3](#issuecomment-24244426))
> 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

Reply to this email directly or view it on GitHub:
Received on Wednesday, 11 September 2013 14:35:31 UTC

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