Re: oscillators and the Web Audio API

On Wed, Feb 8, 2012 at 11:33 AM, Alistair MacDonald <al@signedon.com> wrote:

> > As much as I like the idea of built in high quality oscillators, I am
> > concerned about scope creep.
>
> Your point about scope creep makes a lot of sense, though a couple of
> trade-offs spring to mind that I think are worth considering.
>
> 1) Performance & 2) Fidelity, in music synthesis.
>

I think that "Fidelity" is key here.  The difference between properly
anti-aliased oscillators and crude oscillators is huge.


>
> Assuming you are creating oscillators in JavaScript and using a Native
> Audio Processing graph for routing and effects, there could be a
> significant performance issue. For music production applications that
> would contain lets say "8" soft-synths, there could easily be upwards
> of 16 oscillators running on mono-synths alone. Some of these
> soft-synths would be going though a native lo/hi/band-pass filter,
> some would be using the Native convolution to add reverb, sometimes
> the signal would be being split and then additional JavaScript
> processing might be applied to the any of the signals for a specific
> effect before it's final delivery to the audio context.
>
> I think going back-and-forth between the Native Graph and the
> JavaScript Processing Nodes is going to be quite expensive, and having
> an OscillatorNode with several core wave shapes, that had the
> high-resolution parameter scheduling that the other nodes have, would
> be much less expensive than writing and modifying oscillators in
> JavaScript. Especially where the graph-to-javascript pathway becomes
> complex. I also think a good deal of industry
> musicians/artists/audio-developers would much-prefer to use the
> classic method of synthesis that was not sample-based and did not use
> wave-tables.
>
> Clearly the performance of an OscillatorNode would be different from a
> WaveTableNode, but it seems to make sense to have both options. Most
> good music synthesis applications have both.
>
> I want to re-iterate that this does not nullify Joe's point about
> scope-creep in any way. I am taking an idealistic look across the
> existing music software landscape.
>
> It would be interesting to know...  perhaps Chris Rogers / Phil Burk
> might be able to offer some thoughts on this...
>
> 1) How complicated would it be to add an OscillatorNode to the Native
> Graph?
>

I haven't yet examined Phil's code, but my feeling is that it should be
straightforward.


> 2) Are there any foreseeable complications/gotchas to doing this?
>

I share some of Joe's concerns about feature creep too, but in this case I
believe:

* the extra API footprint is minimal (one more AudioNode with simple
parametric control)
* the sound quality improvement is significant
* the node represents a fundamental building-block of audio as shown in
many previous audio systems and books written about computer music.  I like
Phil's metaphor "they can be considered the elements from which audio
molecules are built"

Chris




>
>
>
>
>
>
>
>
> >
> > Is it possible to take a v1 wavetable-like approach using prefilled
> buffers
> > containing various looped waveforms, played at varying playback rates.
> > instead of algorthmic oscillators?
> >
> > If this would suffice, it would allow a lot of experimentation with
> > oscillator waveform characteristics before we have to standardize, which
> > seems good.
> >
> > On Feb 8, 2012 9:31 AM, "Alistair MacDonald" <al@signedon.com> wrote:
> >>
> >> Agree with Phil on noise sources. A basic building block of drums and
> >> percussion needed for most drum sounds, and could be very useful
> >> generating water, engine and voice sounds in games too.
> >>
> >> On Tue, Feb 7, 2012 at 8:34 PM, Phil Burk <philburk@mobileer.com>
> wrote:
> >> > Hello Chris,
> >> >
> >> >
> >> > On 2/7/12 12:41 PM, Chris Rogers wrote:
> >> >>
> >> >> Up to this point we've relied on AudioBufferSourceNode for general
> >> >> sample playback, and also periodic waveform playback.  I completely
> >> >> agree that there are some challenges and limitations to this
> approach.
> >> >>  Nevertheless, I've worked on a demo using this approach in my
> >> >> "wavetable-synth" and have made some initial (although incomplete and
> >> >> not fully developed) anti-aliased wavetables:
> >> >>
> http://chromium.googlecode.com/svn/trunk/samples/audio/lib/wavetable.js
> >> >
> >> >
> >> > Your approach is similar to how I implemented a band-limited sawtooth
> in
> >> > JSyn. I used a series of 8 tables, one per octave, filled with
> >> > increasing
> >> > numbers of partials. I then interpolate between them depending on
> >> > frequency.
> >> > I window the partials using a raised cosine to eliminate the Gibbs
> >> > phenomenon.
> >> >
> >> > I also implemented a band-limited sawtooth using a Differentiated
> >> > Parabolic
> >> > Waveform (DPW) algorithm. It is *much* simpler, is more CPU efficient
> >> > and
> >> > sounds almost as good as the multi-wavetable approach.
> >> >
> >> > Band limited square and pulse waveforms can be generated from the
> >> > band-limited sawtooth.
> >> >
> >> >
> >> >> But, back to your proposal.  Having the pure and extremely
> high-quality
> >> >> anti-aliased oscillators would be great to have, especially if you
> have
> >> >> code to contribute.  Sound quality does matter, so I really
> appreciate
> >> >> this.
> >> >
> >> >
> >> > I would be happy to contribute 'C' or Java code to Web Audio API. I'll
> >> > study
> >> > the code base and then we can talk offline.
> >> >
> >> > Regarding sound quality, you can hear how truly terrible the aliasing
> >> > can be
> >> > in my example JSyn Applet.
> >> >
> >> > http://www.softsynth.com/jsyn/examples/tj_seeosc.php
> >> >
> >> > Sweep the regular Sawtooth back and forth between 3000 and 9000 Hz.
> Then
> >> > do
> >> > the same with the SawBL and SawDPW. Much smoother.
> >> >
> >> > If you hear pops and crackles it is due to a bug in JavaSound on Mac.
> >> >
> >> >
> >> >> One thing I'm curious about is how these oscillators can avoid
> >> >> aliasing when used in FM applications.  It's certainly a goal of mine
> >> >> to
> >> >> have audio-rate signals modulating AudioParams like .playbackRate or
> >> >> .frequency
> >> >
> >> >
> >> > Extreme FM using sine waves can produce aliasing. This technique will
> >> > not
> >> > prevent that. The problem gets really severe when using
> non-band-limited
> >> > sawtooth or square waves to do FM. Yikes! Using band-limited
> oscillators
> >> > will certainly help in this case but cannot completely eliminate
> >> > aliasing.
> >> >
> >> >
> >> >> The sine, sawtooth, square, pulse and impulse oscillators are
> >> >> considered
> >> >> common in computer-music and so would fit into the Web Audio API's
> >> >> philosophy of implementing common audio building blocks.
> >> >
> >> >
> >> > Noise sources are also pretty fundamental.
> >> >
> >> >
> >> >> I would suggest that the AudioOscillator could have an attribute
> called
> >> >> .oscillatorType which could be one of several values.  I would also
> be
> >> >> interested in your take on how to implement anti-aliased oscillators
> >> >> with arbitrary waveforms.  Optimally, the AudioOscillator would be
> able
> >> >> to handle more than just the simple waveform types.  I have some
> ideas
> >> >> of my own, but we can leave that for later discussion.
> >> >
> >> >
> >> > If the arbitrary waveform is represented by a table then one can
> >> > generate
> >> > pre-filtered tables for the higher frequencies. The key is to do the
> >> > filtering before sampling the wavetable at the high frequency.
> >> >
> >> > Phil Burk
> >> >
> >> >
> >>
> >>
> >>
> >> --
> >> Alistair MacDonald
> >> SignedOn, Inc - W3C Audio WG
> >> Boston, MA, (707) 701-3730
> >> al@signedon.com - http://signedon.com
> >>
> >
>
>
>
> --
> Alistair MacDonald
> SignedOn, Inc - W3C Audio WG
> Boston, MA, (707) 701-3730
> al@signedon.com - http://signedon.com
>
>