Re: Phase offset for OscillatorNodes?

> It doesn't seem like it would be good to incur the actual delay/latency when "notes" are scheduled to start at an exact time.  You want the oscillator to start at the exact time, but at a particular phase offset in the cycle.  Also, if you want to modulate the phase for pulse-width modulation effects, etc. it seems better to handle this directly in the OscillatorNode since higher-quality interpolation can come for free.  Doing this with a DelayNode seems like it would be tricky since you'd have to account for the actual delay/latency of any scheduled parameters affecting the OscillatorNode.

Got it. It would indeed be tricky with a delay node. Time would be the wrong parameterization for phase in this case. It would indeed be nice (and fun) to have phase be directly controlled.

Best,
-Kumar

On 27 Nov, 2012, at 10:12 AM, Chris Rogers <crogers@google.com> wrote:

> 
> 
> On Mon, Nov 26, 2012 at 7:47 PM, Srikumar Karaikudi Subramanian <srikumarks@gmail.com> wrote:
> Hi Jussi and others,
> 
> Some questions came to my mind -
> 
> When an oscillator node generates a signal based on a given wavetable (or "fourier series" or whatever it is going to be renamed as) that has multiple frequency components in it, which component(s) would such a phase offset change? Only the fundamental f0? ... or will n x phaseOffset will be used for each of the n x f0 frequency components, which amounts to a time delay of the signal? ... Or is it going to apply only in the sine/square/triangle cases and remain an unused parameter in the case of wavetables?
> 
> I was expecting it to apply to all types.  Since we're talking about a periodic signal where each cycle has a tangible representation in the time domain, it really does make sense to talk about a particular phase position within the cycle.  We can represent that as 0 -> 2*Pi or from 0 -> 1
>  
> 
> If the n x phaseOffset approach is going to be taken, why not just call it "delay"? ... and what are the cases in which tacking on a delay node to the current oscillator node won't do to achieve the phase shift?
> 
> It doesn't seem like it would be good to incur the actual delay/latency when "notes" are scheduled to start at an exact time.  You want the oscillator to start at the exact time, but at a particular phase offset in the cycle.  Also, if you want to modulate the phase for pulse-width modulation effects, etc. it seems better to handle this directly in the OscillatorNode since higher-quality interpolation can come for free.  Doing this with a DelayNode seems like it would be tricky since you'd have to account for the actual delay/latency of any scheduled parameters affecting the OscillatorNode.
> 
>  
> 
> Best,
> -Kumar
> 
> On 27 Nov, 2012, at 3:08 AM, Jussi Kalliokoski <jussi.kalliokoski@gmail.com> wrote:
> 
>> +1 indeed!
>> 
>> On Nov 26, 2012 11:06 PM, "Chris Wilson" <cwilso@google.com> wrote:
>> >
>> > +1!
>> >
>> >
>> > On Mon, Nov 26, 2012 at 12:30 PM, Patrick Borgeat <patrick.borgeat@gmail.com> wrote:
>> >>
>> >> Sounds awesome!
>> >>
>> >>
>> >> 2012/11/26 Chris Rogers <crogers@google.com>
>> >>>
>> >>> Yeah, .phaseOffset is really what it needs to be I think.  This would be additive with the cummulative phase from .frequency (and .detune).  This seems nice since if you set .frequency to 0, then there would be no cummulative phase and you could control the phase directly with .phaseOffset.  How does that sound?
>> >>
>> >>
>> >
> 
>