Re: [Bug 21980] New: WaveTable is highly underspecified

On Sat, May 11, 2013 at 12:10 PM, <> wrote:

> Joe, i'm still learning what the Web Audio API is about.  i am snooping at
> some of the files and, at present, the oscillatorNode and waveTable classes
> are getting my attention.
The most important thing we focus on in these discussions is usually the
specification document itself:

We're trying to get enough detail in there, that somebody who knows DSP
could write good code to implement it.  The source-code of the oscillator
and wavetable we've been talking about is currently used in Safari, iOS,
and Chrome, so is actually deployed in these browsers today.  But, the idea
is that the specification document should be detailed enough that somebody
could independently come up with their own implementation code in C++...

> if this WebAudioAPI is meant to be only code for real-time synthesis and
> processing, then this note analysis is in it.  but, in the waveTable.cpp
> code, i saw definitions for the wavetables for sine and bandlimited square,
> sawtooth, and triangle.  (BTW, i am convinced that the SQUARE is also off
> by a constant factor.)  all that is good for what it is.  and there is code
> for wavetable playback that linearly interpolates (in one dimension)
> between two wavetables.  so there is the basis for coupling the timbre of
> the waveform to *some* control parameter.
> i just think that constructing wavetable code that can interpolate in 2 or
> 3 dimensions efficiently would be useful.  it already appears that the
> pitch or MIDI key value is one dimension that is being considered.  but you
> need different sets of wavetables to make it useful, otherwise, we may as
> well leave it and what you'll have left are just bandlimited oscillators.
> but, wavetable synthesis is more than a means of doing non-aliased
> analog-like waveform oscillators.  that's what the note analysis would be
> good for.  but it should be an app (or a web app, i dunno) but it should
> produce wavetable data in a format that this Web Audio API can take it and
> play it.  that's what i am suggesting.
Yes, I think it's definitely worth considering adding at least one more
dimension, so that we can sweep through tables of these waves.  I used to
have a Waldorf Microwave synthesizer, so can certainly appreciate this idea.

> Chris, the code comments say  "Copyright (C) 2012, Google Inc. All rights
> CONTRIBUTORS..."  so exactly what rights are Google or Apple reserving?
> this is public domain, right?
The license is very open and non-restrictive, so anybody can use the code
for anything (as long as they keep the copyright notice with the code).
 The reason it includes both Google and Apple, is because this was
developed in an open-source project called WebKit where both these
companies contributed.

> also, Chris, the real-time synthesis code can be tightened up.  if you're
> willing to add one more sample at the end of the 4096-sample wavetable, so
> that waveform[4096]=waveform[0], then linear interpolation can be done
> without having to do modulo arithmetic on the second point.
Thanks, this is a good optimization to consider for that code...

>   i found that to be a useful thing to do in the beginning.  wavetable
> synthesis can be done quite efficiently (compared to real-time additive
> synthesis) and you can "spend" some of the bandwidth saved by this
> efficiency at interpolating in other dimensions for control and musical
> effect.  like a Prophet VS.  but the number of wavetables that are being
> mixed (using linear interpolation) is 2^num_dimensions.  if you have pitch
> (keyboard position), a slider or modwheel, and one other dimension to slide
> around in (like slow time or something else), that's 8 simultaneous
> wavetables going and getting mixed just to get one note (but the phase
> accumulator and phase increment and modulo arithmetic and the mix
> parameters for between sample interpolation is the same for all 8).  so the
> core real-time synthesis code should be the *most* efficient as possible.
Yes, I understand how more dimensions can be added here.  The C++
implementation code is fairly straight-forward, but we would have to
consider what the extensions to the JavaScript API for OscillatorNode would
look like.  First of all the WaveTable object needs to be renamed to
something like PeriodicWave, then we'd have to define an array of these
called PeriodicWaveTable, and have some way to set this as an attribute on
the OscillatorNode, and then add a new AudioParam to sweep through this


> r b-j
> ---------------------------- Original Message ----------------------------
> Subject: Re: [Bug 21980] New: WaveTable is highly underspecified
> From: "Joseph Berkovitz" <>
> Date: Sat, May 11, 2013 1:38 pm
> To:
> Cc: "" <>
> --------------------------------------------------------------------------
> > As useful as note analysis will be, my opinion is that it doesn't belong
> in the Web Audio API. It very much seems like something that belongs at the
> application level as there can be many implementations with different pros
> and cons and different degrees of user control over the process.
> >
> > …Joe
> >
> >> Chris, does this Java script code for note analysis exist somewhere? i
> don't know how to write Java or Java script, but what i have seen of Java
> looks a lot like C at the low level. if there is a place for this analysis
> code, i can do this in C and let someone else wrap it up in Java. it
> requires pitch tracking, interpolation for the wavetable samples, and phase
> alignment of adjacent wavetables. the initial dumb version could have a
> wavetable for every millisecond or maybe every 2 ms. and, with a quick FFT
> on it, each extracted wavetable would have a line spectrum associated with
> it, in case someone wants to knock off some harmonics (as well as for
> wavetable culling)
> >>
> >>
> >> then we can discuss different ideas behind culling redundant
> wavetables. there are some issues there, particularly when interpolating
> along other dimensions. culling should happen only when the array of
> wavetables in *all* dimensions are being looked at. and adjacent wavetables
> should be phase aligned in all dimensions, not just the slowtime dimension.
> that spinning of wavetables (to align them) should happen before culling.
> to within reasonable limits, there is not a time constraint on this
> analysis and wavetable extraction, because it is not real time. but you
> don't want to have to take a long coffee break during the analysis either.
> >>
> >>
> >> L8r,
> >>
> >>
> >> r b-j
> >>
> >
> >

Received on Monday, 13 May 2013 17:07:17 UTC