Hard-sync of two oscillators

[svgeesus]

Describe the feature
The phase of oscillator 2 is set to zero (typically, but could be some other phase) when the phase of oscillator 1 reaches zero (typically; or some other value).

For background, Oscillator sync on Wikipedia.

Called for at WAC16 (and other times):

This was asked for again (twice) at the WG plenary panel at WAC2016. One was a call for oscillator sync, to the hard sync effect, which can be done by resetting the phase. The second was the request for pulse waves, with a-rate modulation of mark/space ratio - which could be done with phase control, or could be added directly (to oscillator, or as a new pulseOscillator node).

Split out from Phase-offset of oscillator nodes.

Is there a prototype?
If you have a prototype (possibly using an AudioWorkletNode), provide links to illustrate this addition. This is the best way to propose a new feature.

Describe the feature in more detail

There are two types of oscillator synchronization in common use. Hard sync usually sets the phase of one oscillator to zero when a second oscillator has a phase of zero (other phase values could be used, but zero is easy in hardware). Soft sync (also called reversing sync) reverses the direction of one oscillator when the phase of another oscillator reaches zero (or some other value).

While this is easy to do in hardware (discharge the integration capacitor) and in non-bandlimited oscillators, the sudden level transition would make a hard transient so the resulting waveform is no longer bandlimited. However, seeHard Sync Without Aliasing

@hoch said

This has been bugging me for a while. I believe hard-syncing 2 oscillators on zero-crossing might not be possible with this AudioParam approach.

[hoch]

One idea discussed in TPAC:
Create osc.phaseReset AudioParam and it can be connected to the other source. When the incoming modulation signal has the value 1 and it resets the phase of the carrier.

[svgeesus]

related: Phase-offset of oscillator nodes

[ffd8]

Would be really helpful for custom synths. Last summer started adding wavetable synthesis to p5.sound, but stopped when it became impossible to constantly sync two custom PeriodicWave oscillators (hard-panned left / right) when sending to an oscilloscope in X-Y mode for vector display fun. Interesting to learn this is an issue that went beyond a library's implementation.

Not sure if minim's oscil offers some insights – even though it's Java/Processing based... could always sync oscillators there.

[padenot]

We're having a hard time speccing this. There is no concept of gate/trigger/bang in the Web Audio API, that could signal the end of a period, and trigger a phase reset.

If we have a phase AudioParam on the OscillatorNode, then we could connect a phasor to this AudioParam, but this phasor should be non-band-limited (I believe?). This was #244, but we decided not to proceed. This issue conclusion is right in that if we end up doing https://github.com/WebAudio/web-audio-api-v2/issues/9, then we can really easily have a go at this, writing a non-bandlimited oscillator in AudioWorklet is really quite trivial.

[padenot]

A prototype can be made in the following way:

• Implement non-bandlimited oscillators Add an way to request mathematically correct oscillators #244. Those would have the same API, but would be the "pure" mathematical waveforms and no bandlimiting
• Implement a band-limited oscillator that has a phase parameter. It's unclear to the group which technique can be used to implement this: directly reading from a wave-table obviously produces a discontinuity (and that's what implementations do for now), so we can't reuse the native nodes. However, https://github.com/WebAudio/web-audio-api-v2/issues/9#issuecomment-207114971 shows a route forward (chapter 4 is probably enough, no need to be fancy at this stage). So BLIP or MiniBLEP is what is really needed (fwiw we have old code in the Firefox repo history that does this in hopefully easy to read C++).
• Related to this, when the OscillatorNode has its phase modulated, it should probably switch to an other technique than wave tables. Or anything connected to it really. That's more of an implementation concern.

[rtoy]

FWIW, I had a prototype of the OscillatorNode with a phase AudioParam. Still used the wavetable approach. It was fairly difficult to do and get even the basics right. And I'm still confused on exactly on the phase value was supposed to work. However, I could get a pretty nice sine wave from a zero frequency oscillator where the phase AudioParam was automated with a linear ramp. That should give a constant frequency sine wave, and it did.

[ulph]

A prototype can be made in the following way:

• Implement non-bandlimited oscillators Add an way to request mathematically correct oscillators web-audio-api#244. Those would have the same API, but would be the "pure" mathematical waveforms and no bandlimiting

was the intention here to allow arbitrary phasor waveforms using said "pure" oscillators? which could for instance describe linear phase increments not exactly matching a set of full cycles, ergo a "sync"?

• Implement a band-limited oscillator that has a phase parameter. It's unclear to the group which technique can be used to implement this: directly reading from a wave-table obviously produces a discontinuity (and that's what implementations do for now), so we can't reuse the native nodes. However, Phase-offset of oscillator nodes #9 (comment) shows a route forward (chapter 4 is probably enough, no need to be fancy at this stage). So BLIP or MiniBLEP is what is really needed (fwiw we have old code in the Firefox repo history that does this in hopefully easy to read C++).
• Related to this, when the OscillatorNode has its phase modulated, it should probably switch to an other technique than wave tables. Or anything connected to it really. That's more of an implementation concern.

the approach outlined in the paper works well for square and sawtooth waves (and the hard-synced variant). not as much for arbitrary waveforms (as stated by authors, and from personal experience).

edit:
an aside note to this; it doesn't make as much sense to pass phasors to sawtooth and square oscs using the outlined approach above, as only end-of-cycle points as well as derivative (frequency) matters for the square / sawtooth internals. furthermore, the reset point needs to be subsample. can of course be numerically derived from the phasor curve.

so, not entirely clear to me how this would work