Re: oscillators and the Web Audio API

> 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.

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?
2) Are there any foreseeable complications/gotchas to doing this?








>
> 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

Received on Wednesday, 8 February 2012 20:27:37 UTC