New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Phase-offset of oscillator nodes #541

Open
pendragon-andyh opened this Issue Jun 9, 2015 · 30 comments

Comments

@pendragon-andyh

pendragon-andyh commented Jun 9, 2015

Can we have an a-rate parameter on the OscillatorNode that allows modulation of the phase offset? This would allow:

  • Linear phase modulation (which is how the DX7 implements FM synthesis).
  • Creation and modulation of band-limited pulse waves (this is normally done by summing 2 sawtooth waves - the pulse width is related to the phase difference).
@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Jun 17, 2015

+1, agreed that this is needed. A couple more use cases:

  • For a LFO used to control another parameter, the initial phase is pretty important
  • When reconstructing more complicated waveforms as a sum of sine waves, the phase is important (equivalent to the imaginary component in a FFT, for example).

ghost commented Jun 17, 2015

+1, agreed that this is needed. A couple more use cases:

  • For a LFO used to control another parameter, the initial phase is pretty important
  • When reconstructing more complicated waveforms as a sum of sine waves, the phase is important (equivalent to the imaginary component in a FFT, for example).

@mdjp mdjp modified the milestone: Uncommitted Jun 18, 2015

@joeberkovitz

This comment has been minimized.

Show comment
Hide comment
@joeberkovitz

joeberkovitz Jun 18, 2015

Contributor

Seems like a significant gap. We want to get implementors' feedback on the effort involved.

Contributor

joeberkovitz commented Jun 18, 2015

Seems like a significant gap. We want to get implementors' feedback on the effort involved.

@joeberkovitz joeberkovitz modified the milestones: Web Audio V1, Uncommitted Jun 18, 2015

@rtoy

This comment has been minimized.

Show comment
Hide comment
@rtoy

rtoy Sep 10, 2015

Contributor

@hoch and I took a quick look at this a while back. Seems doable without huge effort.

Contributor

rtoy commented Sep 10, 2015

@hoch and I took a quick look at this a while back. Seems doable without huge effort.

@padenot

This comment has been minimized.

Show comment
Hide comment
@padenot

padenot Sep 23, 2015

Member

Yeah it's not very hard and very useful, we should do it.

Member

padenot commented Sep 23, 2015

Yeah it's not very hard and very useful, we should do it.

@rtoy

This comment has been minimized.

Show comment
Hide comment
@rtoy

rtoy Sep 23, 2015

Contributor

I concur.

On Wed, Sep 23, 2015 at 2:00 AM, Paul Adenot notifications@github.com
wrote:

Yeah it's not very hard and very useful, we should do it.


Reply to this email directly or view it on GitHub
#541 (comment)
.

Ray

Contributor

rtoy commented Sep 23, 2015

I concur.

On Wed, Sep 23, 2015 at 2:00 AM, Paul Adenot notifications@github.com
wrote:

Yeah it's not very hard and very useful, we should do it.


Reply to this email directly or view it on GitHub
#541 (comment)
.

Ray

@mdjp mdjp assigned mdjp and unassigned mdjp Oct 16, 2015

@meszaros-lajos-gyorgy

This comment has been minimized.

Show comment
Hide comment
@meszaros-lajos-gyorgy

meszaros-lajos-gyorgy Jan 4, 2016

With this I would have more control on the wave and could change the oscillator's gain more smoothly. Currently the gain doesn't wait for the wave to reach 0, so it cuts the wave anywhere, resulting in a clicking sound whenever the gain is changed.

Please look at my bugzilla report for examples: https://bugzilla.mozilla.org/show_bug.cgi?id=1232644

meszaros-lajos-gyorgy commented Jan 4, 2016

With this I would have more control on the wave and could change the oscillator's gain more smoothly. Currently the gain doesn't wait for the wave to reach 0, so it cuts the wave anywhere, resulting in a clicking sound whenever the gain is changed.

Please look at my bugzilla report for examples: https://bugzilla.mozilla.org/show_bug.cgi?id=1232644

@jesup

This comment has been minimized.

Show comment
Hide comment
@jesup

jesup Jan 4, 2016

I agree with @meszaros-lajos-gyorgy -- make it easy/possible to do the most common thing, which would be to avoid pops/clicks. They're almost never what you want...

jesup commented Jan 4, 2016

I agree with @meszaros-lajos-gyorgy -- make it easy/possible to do the most common thing, which would be to avoid pops/clicks. They're almost never what you want...

@meszaros-lajos-gyorgy

This comment has been minimized.

Show comment
Hide comment
@meszaros-lajos-gyorgy

meszaros-lajos-gyorgy Jan 4, 2016

To add another example: I'm currently developing an app, which heavily relies on the Audio API's oscillators and gains and it is about constantly changing the volume and pitch of the generated frequencies. You can hear the clicking an popping almost every time you change something.

Live project: http://meszaros-lajos-gyorgy.github.io/microtonal/monochord/
Source code: https://github.com/meszaros-lajos-gyorgy/meszaros-lajos-gyorgy.github.io/tree/master/microtonal/monochord

meszaros-lajos-gyorgy commented Jan 4, 2016

To add another example: I'm currently developing an app, which heavily relies on the Audio API's oscillators and gains and it is about constantly changing the volume and pitch of the generated frequencies. You can hear the clicking an popping almost every time you change something.

Live project: http://meszaros-lajos-gyorgy.github.io/microtonal/monochord/
Source code: https://github.com/meszaros-lajos-gyorgy/meszaros-lajos-gyorgy.github.io/tree/master/microtonal/monochord

@modosc

This comment has been minimized.

Show comment
Hide comment
@modosc

modosc Jan 4, 2016

@meszaros-lajos-gyorgy fwiw i ran into similar issues and worked around them with setValueAtTime - this removed all clicks for both pitch and volume in my app. granted this isn't something we should have to do (setting value directly should work) but at least it's possible to avoid them for now.

modosc commented Jan 4, 2016

@meszaros-lajos-gyorgy fwiw i ran into similar issues and worked around them with setValueAtTime - this removed all clicks for both pitch and volume in my app. granted this isn't something we should have to do (setting value directly should work) but at least it's possible to avoid them for now.

@modosc

This comment has been minimized.

Show comment
Hide comment
@modosc

modosc Jan 4, 2016

also, it would be great to get a sync input/output on the oscillator node. then to implement hard sync you could do something like:

osc1.sync.connect(osc2.sync)

i suppose i could see this as a callback too (similar to processor.onaudioprocess) but i'm not sure how well this would work if it was buffered. having logic in the sync would be great since you could selectively sync based on the phase of the second oscillator for soft sync, implement reversing sync, etc. probably i should open a separate issue on this?

modosc commented Jan 4, 2016

also, it would be great to get a sync input/output on the oscillator node. then to implement hard sync you could do something like:

osc1.sync.connect(osc2.sync)

i suppose i could see this as a callback too (similar to processor.onaudioprocess) but i'm not sure how well this would work if it was buffered. having logic in the sync would be great since you could selectively sync based on the phase of the second oscillator for soft sync, implement reversing sync, etc. probably i should open a separate issue on this?

@modosc

This comment has been minimized.

Show comment
Hide comment
@modosc

modosc Jan 4, 2016

sorry, one more thing:

Currently the gain doesn't wait for the wave to reach 0

won't you potentially get weird behavior here if you have something other than a vanilla oscillator connected directly to the GainNode? if you're implementing some sort of weird synthesis technique which results in some unwanted dc shift you may never cross zero in which case gain changes would just get queued up and never occur. with a sync output / input this could be handled (although now we're talking about adding a sync input to the GainNode which is getting more complicated - the behavior would be "if something's connected to the sync input then queue gain changes up until there's a sync input")

modosc commented Jan 4, 2016

sorry, one more thing:

Currently the gain doesn't wait for the wave to reach 0

won't you potentially get weird behavior here if you have something other than a vanilla oscillator connected directly to the GainNode? if you're implementing some sort of weird synthesis technique which results in some unwanted dc shift you may never cross zero in which case gain changes would just get queued up and never occur. with a sync output / input this could be handled (although now we're talking about adding a sync input to the GainNode which is getting more complicated - the behavior would be "if something's connected to the sync input then queue gain changes up until there's a sync input")

@pendragon-andyh

This comment has been minimized.

Show comment
Hide comment
@pendragon-andyh

pendragon-andyh Jan 5, 2016

@meszaros-lajos-gyorgy - I have added a combination of SetValueAtTime and LinearRampToValueAtTime to your fiddle (see http://jsfiddle.net/0pjapu9c/1/). I think it fixes your problem.

pendragon-andyh commented Jan 5, 2016

@meszaros-lajos-gyorgy - I have added a combination of SetValueAtTime and LinearRampToValueAtTime to your fiddle (see http://jsfiddle.net/0pjapu9c/1/). I think it fixes your problem.

@meszaros-lajos-gyorgy

This comment has been minimized.

Show comment
Hide comment
@meszaros-lajos-gyorgy

meszaros-lajos-gyorgy Jan 6, 2016

@pendragon-andyh - I can still hear the clicking for every 'boop' in Firefox 43

meszaros-lajos-gyorgy commented Jan 6, 2016

@pendragon-andyh - I can still hear the clicking for every 'boop' in Firefox 43

@padenot

This comment has been minimized.

Show comment
Hide comment
@padenot

padenot Jan 6, 2016

Member

This is likely to be a firefox bug.

Member

padenot commented Jan 6, 2016

This is likely to be a firefox bug.

@svgeesus

This comment has been minimized.

Show comment
Hide comment
@svgeesus

svgeesus Apr 7, 2016

Contributor

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

Contributor

svgeesus commented Apr 7, 2016

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

@svgeesus

This comment has been minimized.

Show comment
Hide comment
@svgeesus

svgeesus Apr 7, 2016

Contributor

Note that naive hard-sync will introduce aliasing because the hard-synced waveform is no longer bandlimited. But see "Hard Sync Without Aliasing" http://www.cs.cmu.edu/~eli/papers/icmc01-hardsync.pdf

Contributor

svgeesus commented Apr 7, 2016

Note that naive hard-sync will introduce aliasing because the hard-synced waveform is no longer bandlimited. But see "Hard Sync Without Aliasing" http://www.cs.cmu.edu/~eli/papers/icmc01-hardsync.pdf

@toyoshim

This comment has been minimized.

Show comment
Hide comment
@toyoshim

toyoshim Jul 27, 2016

+1 on this feature request.

What I want to do more by OscillatorNode is

  • Reset each oscillator phase on each note-on timing (this is a common approach to implement a synth)
  • Reset LFO's oscillator phase on starting LFO
  • Start each oscillator from different phases at one, e.g. Osc-C starts from phase 0, Osc-L starts from phase -PI/2, and Osc-R starts from phase +PI/2 (to make a spacey sound)
  • Sync modulation.

The first three could be realized by having AudioParam phase that JavaScript code can manage. But the last one may need a special method to sync automatically as modosc suggested. Or could we do something equivalent by connecting "sawtooth" type OscillatorNode to the phase parameter?

toyoshim commented Jul 27, 2016

+1 on this feature request.

What I want to do more by OscillatorNode is

  • Reset each oscillator phase on each note-on timing (this is a common approach to implement a synth)
  • Reset LFO's oscillator phase on starting LFO
  • Start each oscillator from different phases at one, e.g. Osc-C starts from phase 0, Osc-L starts from phase -PI/2, and Osc-R starts from phase +PI/2 (to make a spacey sound)
  • Sync modulation.

The first three could be realized by having AudioParam phase that JavaScript code can manage. But the last one may need a special method to sync automatically as modosc suggested. Or could we do something equivalent by connecting "sawtooth" type OscillatorNode to the phase parameter?

@rtoy

This comment has been minimized.

Show comment
Hide comment
@rtoy

rtoy Jul 27, 2016

Contributor

I believe the intent is to add a phase (name TBD) AudioParam.

I have been trying to implement this in Chrome and it's rather hard if we want to preserve the band-limited requirement of the Oscillator. It's easy if you drop this requirement, but I think it's important for the oscillator to be band-limited.

Contributor

rtoy commented Jul 27, 2016

I believe the intent is to add a phase (name TBD) AudioParam.

I have been trying to implement this in Chrome and it's rather hard if we want to preserve the band-limited requirement of the Oscillator. It's easy if you drop this requirement, but I think it's important for the oscillator to be band-limited.

@hoch

This comment has been minimized.

Show comment
Hide comment
@hoch

hoch Jul 27, 2016

Member

@toyoshim

Reset each oscillator phase on each note-on timing (this is a common approach to implement a synth)
Reset LFO's oscillator phase on starting LFO

Is this to reuse a single oscillator without creating a new one? This is doable with osc.phase.setValueAtTime(0, time).

  • Start each oscillator from different phases at one, e.g. Osc-C starts from phase 0, Osc-L starts from phase -PI/2, and Osc-R starts from phase +PI/2 (to make a spacey sound)

Yeap. Also doable with oscA.phase.value = -Math.PI/2; oscA.phase.value = +Math.PI/2 and two stereo panners.

  • Sync modulation.

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.

Member

hoch commented Jul 27, 2016

@toyoshim

Reset each oscillator phase on each note-on timing (this is a common approach to implement a synth)
Reset LFO's oscillator phase on starting LFO

Is this to reuse a single oscillator without creating a new one? This is doable with osc.phase.setValueAtTime(0, time).

  • Start each oscillator from different phases at one, e.g. Osc-C starts from phase 0, Osc-L starts from phase -PI/2, and Osc-R starts from phase +PI/2 (to make a spacey sound)

Yeap. Also doable with oscA.phase.value = -Math.PI/2; oscA.phase.value = +Math.PI/2 and two stereo panners.

  • Sync modulation.

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.

@pendragon-andyh

This comment has been minimized.

Show comment
Hide comment
@pendragon-andyh

pendragon-andyh Jul 27, 2016

Currently Chrome's PeriodicWave::waveDataForFundamentalFrequency() function decides the lower and higher band-limited-tables to use from the frequency passed-in by the OscillatorHandler::process() function.

Instead of indexing the tables by their fundamental frequency, would it be possible to index by their phase-increment? A large phase-increment indicates a high frequency - so you need to cull more of its high harmonics.

pendragon-andyh commented Jul 27, 2016

Currently Chrome's PeriodicWave::waveDataForFundamentalFrequency() function decides the lower and higher band-limited-tables to use from the frequency passed-in by the OscillatorHandler::process() function.

Instead of indexing the tables by their fundamental frequency, would it be possible to index by their phase-increment? A large phase-increment indicates a high frequency - so you need to cull more of its high harmonics.

@pendragon-andyh

This comment has been minimized.

Show comment
Hide comment
@pendragon-andyh

pendragon-andyh Jul 27, 2016

@hoch

I anticipated that the phase parameter would have a values like:

  • -1 = 360 degrees behind the current frequency.
  • 0 = What we have at the moment.
  • +1 = 360 degrees ahead of the current frequency.

Is this to reuse a single oscillator without creating a new one? This is doable with osc.phase.setValueAtTime(0, time).

I would not expect this to work. In most designs, the phase parameter is normally an offset to what the unmodified phase of the oscillator would be. An easier way is to just start a new oscillator.

Sync modulation

I have a theory that (if we have a phase parameter) you could achieve this by the following steps:

  • Play a sine wave at 1 octave below your desired frequency.
  • Use a square wave to modulate its gain.
  • Pass the results through a waveshaper that is designed to flatten-out the sine into a true sawtooth (in my experiments you need a curve that has at least 16000 elements).
  • Play the result through a gain node (to apply the ratio between the oscillators).
  • Send the result to the phase parameter of an oscillator that has 0 frequency.

The "(sine*square)=>waveshaper" trick was the most accurate way that I have found of getting a true sawtooth. Most people would reach for a BufferSourceNode - but the interpolation between samples means that the result is a bit noisy.

pendragon-andyh commented Jul 27, 2016

@hoch

I anticipated that the phase parameter would have a values like:

  • -1 = 360 degrees behind the current frequency.
  • 0 = What we have at the moment.
  • +1 = 360 degrees ahead of the current frequency.

Is this to reuse a single oscillator without creating a new one? This is doable with osc.phase.setValueAtTime(0, time).

I would not expect this to work. In most designs, the phase parameter is normally an offset to what the unmodified phase of the oscillator would be. An easier way is to just start a new oscillator.

Sync modulation

I have a theory that (if we have a phase parameter) you could achieve this by the following steps:

  • Play a sine wave at 1 octave below your desired frequency.
  • Use a square wave to modulate its gain.
  • Pass the results through a waveshaper that is designed to flatten-out the sine into a true sawtooth (in my experiments you need a curve that has at least 16000 elements).
  • Play the result through a gain node (to apply the ratio between the oscillators).
  • Send the result to the phase parameter of an oscillator that has 0 frequency.

The "(sine*square)=>waveshaper" trick was the most accurate way that I have found of getting a true sawtooth. Most people would reach for a BufferSourceNode - but the interpolation between samples means that the result is a bit noisy.

@toyoshim

This comment has been minimized.

Show comment
Hide comment
@toyoshim

toyoshim Aug 2, 2016

I assume writing values to the phase make the OSC ignore the frequency value virtually. Is this correct?

This is my understanding. Here, I assume the range for a loop is 0 through 1, and the value will be clipped as set value % 1.

osc1.type = "sine";
osc1.frequency.value = x;
osc2.type = "sawtooth";
osc2.frequency.value = freq;
osc2.conect(osc1.phase);

This makes a sine wave in frequency freq. x could not affect under the phase controlled by something connected.

gain.gain.value = 1.5;
osc2.connect(gain).connect(osc1.phase);

This can generate a periodic wave with 1.5 cycle of sine wave.

This is what I meant in my previous comment about sync modulation.

toyoshim commented Aug 2, 2016

I assume writing values to the phase make the OSC ignore the frequency value virtually. Is this correct?

This is my understanding. Here, I assume the range for a loop is 0 through 1, and the value will be clipped as set value % 1.

osc1.type = "sine";
osc1.frequency.value = x;
osc2.type = "sawtooth";
osc2.frequency.value = freq;
osc2.conect(osc1.phase);

This makes a sine wave in frequency freq. x could not affect under the phase controlled by something connected.

gain.gain.value = 1.5;
osc2.connect(gain).connect(osc1.phase);

This can generate a periodic wave with 1.5 cycle of sine wave.

This is what I meant in my previous comment about sync modulation.

@rtoy

This comment has been minimized.

Show comment
Hide comment
@rtoy

rtoy Aug 2, 2016

Contributor

On Tue, Aug 2, 2016 at 2:06 AM, Takashi Toyoshima notifications@github.com
wrote:

I assume writing values to the phase make the OSC ignore the frequency
value virtually. Is this correct?

​That's a good question. No one has actually proposed anything yet, but I
was assuming that the resulting waveform would be something like

s(2_pi_f*t + phi(t))

where phi(t) is the phase input to the node. You can achieve what you want
by setting the frequency to 0.​ This formulation also makes it much easier
to design a cosine wave by setting phi(t) = pi/2.

I was also assuming that s(t) would still be band-limited when including
the effect of the phase term. But neither of these has been decided yet.

This is my understanding. Here, I assume the range for a loop is 0 through
1, and the value will be clipped as set value % 1.

osc1.type = "sine";
osc1.frequency.value = x;
osc2.type = "sawtooth";
osc2.frequency.value = freq;
osc2.conect(osc1.phase);

This makes a sine wave in frequency freq. x could not affect under the
phase controlled by something connected.

​Almost. Since osc2 is band-limited, the resulting sawtooth has ringing so
the output of osc1 won't quite be a sine wave.​

gain.gain.value = 1.5;
osc2.connect(gain).connect(osc1.phase);

This can generate a periodic wave with 1.5 cycle of sine wave.

This is what I meant in my previous comment about sync modulation.


You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#541 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAofPHJw_BoMgkTXBo-CiW5cHhe5sJ1bks5qbwiqgaJpZM4E9mrb
.

Ray

Contributor

rtoy commented Aug 2, 2016

On Tue, Aug 2, 2016 at 2:06 AM, Takashi Toyoshima notifications@github.com
wrote:

I assume writing values to the phase make the OSC ignore the frequency
value virtually. Is this correct?

​That's a good question. No one has actually proposed anything yet, but I
was assuming that the resulting waveform would be something like

s(2_pi_f*t + phi(t))

where phi(t) is the phase input to the node. You can achieve what you want
by setting the frequency to 0.​ This formulation also makes it much easier
to design a cosine wave by setting phi(t) = pi/2.

I was also assuming that s(t) would still be band-limited when including
the effect of the phase term. But neither of these has been decided yet.

This is my understanding. Here, I assume the range for a loop is 0 through
1, and the value will be clipped as set value % 1.

osc1.type = "sine";
osc1.frequency.value = x;
osc2.type = "sawtooth";
osc2.frequency.value = freq;
osc2.conect(osc1.phase);

This makes a sine wave in frequency freq. x could not affect under the
phase controlled by something connected.

​Almost. Since osc2 is band-limited, the resulting sawtooth has ringing so
the output of osc1 won't quite be a sine wave.​

gain.gain.value = 1.5;
osc2.connect(gain).connect(osc1.phase);

This can generate a periodic wave with 1.5 cycle of sine wave.

This is what I meant in my previous comment about sync modulation.


You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#541 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAofPHJw_BoMgkTXBo-CiW5cHhe5sJ1bks5qbwiqgaJpZM4E9mrb
.

Ray

@joeberkovitz

This comment has been minimized.

Show comment
Hide comment
@joeberkovitz

joeberkovitz Sep 23, 2016

Contributor

New feature; need to defer to a later iteration.

Contributor

joeberkovitz commented Sep 23, 2016

New feature; need to defer to a later iteration.

@svgeesus

This comment has been minimized.

Show comment
Hide comment
@svgeesus

svgeesus Mar 27, 2018

Contributor

Discussed at March 2018 f2f. Hard (phase reset) and soft (reversing) sync, difficulty of maintaining bandlimited with hard sync.

Contributor

svgeesus commented Mar 27, 2018

Discussed at March 2018 f2f. Hard (phase reset) and soft (reversing) sync, difficulty of maintaining bandlimited with hard sync.

@svgeesus

This comment has been minimized.

Show comment
Hide comment

@rtoy rtoy added this to To do in V2 Apr 12, 2018

@poojarfuturistic5

This comment has been minimized.

Show comment
Hide comment
@poojarfuturistic5

poojarfuturistic5 May 22, 2018

I have used webaudio API oscillator but getMediaUser doesn't work in ios microphones devices for sinewave
Please can someone help me

poojarfuturistic5 commented May 22, 2018

I have used webaudio API oscillator but getMediaUser doesn't work in ios microphones devices for sinewave
Please can someone help me

@meszaros-lajos-gyorgy

This comment has been minimized.

Show comment
Hide comment
@meszaros-lajos-gyorgy

meszaros-lajos-gyorgy Aug 17, 2018

Hi! I don't want to rush anyone, but since the ticket has been opened for over 3 years now, I feel an urge to ask: is there any progress with this? is anyone working on this? have every question been answered regarding this feature? can we help in any way to make this feature happen sooner? Thanks!

meszaros-lajos-gyorgy commented Aug 17, 2018

Hi! I don't want to rush anyone, but since the ticket has been opened for over 3 years now, I feel an urge to ask: is there any progress with this? is anyone working on this? have every question been answered regarding this feature? can we help in any way to make this feature happen sooner? Thanks!

@hoch

This comment has been minimized.

Show comment
Hide comment
@hoch

hoch Aug 20, 2018

Member

It is rather a design problem; how parameters do we expose? Is it involved with 2 oscillator nodes or a new node with multiple oscillators? I think the right course of action is to build a prototype design with AudioWorklet and gather feedback from the dev community.

Member

hoch commented Aug 20, 2018

It is rather a design problem; how parameters do we expose? Is it involved with 2 oscillator nodes or a new node with multiple oscillators? I think the right course of action is to build a prototype design with AudioWorklet and gather feedback from the dev community.

@rtoy

This comment has been minimized.

Show comment
Hide comment
@rtoy

rtoy Aug 20, 2018

Contributor

Let's keep this issue about a phase offset for the OscillatorNode. Those wanting to talk about hard sync and the like, please open a new issue to discuss that.

Contributor

rtoy commented Aug 20, 2018

Let's keep this issue about a phase offset for the OscillatorNode. Those wanting to talk about hard sync and the like, please open a new issue to discuss that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment