- From: redman <redman@redman.demon.nl>
- Date: Mon, 26 Nov 2012 06:51:56 +0100
- To: public-audio@w3.org
On 26-Nov-12 5:36, Chris Rogers wrote: > On Sun, Nov 25, 2012 at 5:52 AM, redman<redman@redman.demon.nl> wrote: > >> On 25-Nov-12 9:41, Ray Bellis wrote: >> >>> On 24/11/2012 15:01, Patrick Borgeat wrote: >>> >>>> A phase offset could be passed as an optional double offset=0 parameter >>>> to the start method of OscillatorNodes. A modulateable phase parameter >>>> could be interesting as well off course, but might be overkill for the Web >>>> Audio API. >>>> >>> Being able to change the phase on the fly would though allow support for >>> oscillator sync, which is a feature I've seen requested here before. >>> >>> Ray >>> >>> >>> >>> >> Not very likely. >> For osc sync you would also need to monitor the 'carrier' waveform and >> implement a sample-accurate trigger and then hope the second syncing >> oscillator will react fast enough to the phase reset so that you get the >> desired effect. >> A better way would be to make a dual oscillator native module that allows >> for sync. >> At the very least you need some information about when the first osc is >> cycling around so that you can reset the second one but this information is >> not provided. Detecting it may be too slow as the triggering needs to be >> sample accurate. >> > I think it would be possible to get osc sync if OscillatorNode had an > attribute called something like .sync (not a great name) which could be > optionally set to another OscillatorNode. If they were linked in such a > way then it could be implemented to be sample-accurate. Sure, that would work and all you would need then is a triggering mechanism. Something simple like a sign change detector should do. BTW, if you don't like .sync you can always call it .reset which is what it basically should do. >> red >> >>
Received on Monday, 26 November 2012 05:52:29 UTC