Re: Phase offset for OscillatorNodes?

On Sun, Nov 25, 2012 at 9:51 PM, redman <redman@redman.demon.nl> wrote:

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

I was thinking that it would literally detect "wraps around" from the end
of each cycle period of the controlling oscillator.


> 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 06:42:26 UTC