Re: Oscillator syncing

I have to admit that I don't fully comprehend how the 2d wavetables would
work.  I'm sure I can and will figure it out if thats the implementation
that makes sense.  I do think there is value in keeping things as simple
and easy as possible for web developers but perhaps oscillator syncing
isn't super common enough need to warrant its own dedicated effect.  On the
other hand the 2d wavetables seem like they could open up a lot of other
interesting possibilities.  I already had in mind trying to implement PWM
by swapping out wavetables so maybe its not that far of a leap.


On Wed, Jun 5, 2013 at 5:10 PM, Chris Rogers <crogers@google.com> wrote:

>
>
>
> On Wed, Jun 5, 2013 at 3:53 PM, Russell McClellan <russell@motu.com>wrote:
>
>> While possible, it's not completely trivial to implement oscillator sync
>> without causing aliasing.  Also, there are many other nice analog
>> oscillator effects that are not implemented in the web audio API (PWM
>> strikes me as the most important).
>>
>> Perhaps a more realistic approach, rather than to separately specify
>> every oscillator effect a user might want, would be to implement "two
>> dimensional" wavetables where there's a time axis and an "effect" axis.
>>  For sync this "effect" would represent the ratio between master and slave
>> osc, where for PWM it would be the pulse width.  It would cover most of
>> these "synthesis" type oscillators while also elegantly solving aliasing
>> issues.  I remember a discussion with Robert Bristow-Johnson about this
>> quite recently on the list.  As Robert said then, implementations of these
>> type of wavetables are both fairly straightforward and quite common.
>>
>> While there's plenty of beauty in the idea of doing things as closely as
>> possible to the "analog" way, there's a fair bit of precedence for doing
>> analog-type effects using 2d wavetables - for a classic example see the PPG
>> Wave digital synth, and more recently you might look to Native Instruments'
>> Massive.
>>
>
> Sounds good to me!
>
> For now, we're trying to go a bit slowly now that Mozilla is finishing up
> their implementation, but I'm definitely interested in this and think it
> would be valuable.
>
>
>> While we're talking about blue-sky ideas for synthesis effects (and maybe
>> this falls into the "Web Audio 2.0" category), I think by far the most
>> useful single node to add would be a "SpectralScriptProcessorNode" that
>> would behave the same as the script processor node but would act on
>> frequency-domain data rather than time-domain data.  The back-end for this
>> is already more or less in place (consider the convolver node and the
>> analyzer node), and it would provide a great deal of power to advanced
>> users of the API.  Potential applications would be moog-style synth
>> filters,  high quality additive synthesis, real-time pitch shifting, custom
>> beat detection, and spectral morphing.  The only complication I can think
>> of is the fact that the data would have to be complex numbers.
>>
>
> In a previous life, I actually worked on a phase vocoder engine (SVP and
> AudioSculpt) at IRCAM, so know a bit about this.  It becomes a bit tricky
> when you have some nodes which work with time-domain data, and some with
> frequency-domain, connecting them, etc.  So it could be tricky to spec this
> well.
>
>
>>
>> Thanks,
>> -Russell
>>
>> On Jun 5, 2013, at 6:20 PM, Chris Rogers <crogers@google.com> wrote:
>>
>>
>>
>>
>> On Wed, Jun 5, 2013 at 2:28 PM, Josh Nielsen <josh@joshontheweb.com>wrote:
>>
>>> Hey All,
>>>
>>> It is a common technique with synthesizers to sync oscillators in a
>>> master/slave setup where the slave oscillator's waveform restarts every
>>> time the master oscillator's waveform restarts.  A lot of more complex and
>>> natural sounding timbres are possible this way.  I don't see any mention of
>>> this in the API spec.  Is this going to be added or is there some clever
>>> way to accomplish this with the existing api that I haven't thought of?
>>>
>>
>> Indeed, this is a nice effect.  There's currently no way to do it, but
>> we've discussed this before, and might want to add this ability.
>>
>> One way we could approach it is to add a new attribute to OscillatorNode
>> called .master (or something like that):
>>
>> osc2.master = osc1;
>>
>> By default, the attribute would be null and thus would just run
>> normally...
>>
>> Chris
>>
>>
>>>
>>>
>>> --
>>> Thanks,
>>> Josh Nielsen
>>> @joshontheweb <http://twitter.com/joshontheweb>
>>> joshontheweb.com
>>>
>>
>>
>>
>


-- 
Thanks,
Josh Nielsen
@joshontheweb <http://twitter.com/joshontheweb>
joshontheweb.com