[PD] osc~'s phase / second inlet
stffn at dibidut.dk
Wed Feb 7 11:56:37 CET 2007
On 06/02/2007, at 23.21, Frank Barknecht wrote:
> Steffen hat gesagt: // Steffen wrote:
>> I can't figure how the second inlet of osc~ work. As a test i tried
>> to sum and subtract two osc~'s with the same frequency. If i send 0
>> to the second inlet of the two osc~ objects, the difference is 0 -
>> which is what i though would happen. But how do i make the sum 0 -
>> ie. make them completely out of phase?
> Multiply on [osc~] by -1? ;)
> Just joking, that is not what you mean by your question, I suppose.
>> I've tried different things. For example I've tried to delay the
>> reset of the one osc~ while "immediately" resetting the other - by
>> resetting i mean sending 0 to the second inlet - assuming one can
>> only reset the phase. Another thing i've tried is to set them at the
>> same time by sending 0 to one of them and different numbers to the
>> other - assuming it would behave kind of like sin(f*x+0)+sin(f*x+a)
>> where a is the other number.
> The correct way would be to set one [osc~]'s phase to 0 and the other
> to 0.5 at the same time. The audio objects in (core) Pd like [osc~],
> [cos~] or [phasor~] assume a complete cycle to be of length 1, so
> setting the phase of one object to 0, and the other to 1/2 == 0.5 will
> set them to opposite phases.
Thanks a lot for clarifying this, Frank!
> See attached patch.
Thanks. The test i did is almost identical to you patch, only i
apparently didn't try with 0 and 0.5 - bummer.
> I guess they assume a cycle to be of length 1 and not of length 2*PI
> or so to appeal the non-mathletes and to make things like
> phase-modulation a bit easier, though you can only really modulate the
> phase of a [cos~] with an audio signal.
I see. That's alright, as long as one know, one can switch between
those two "formats".
> One additional thing to be aware of is, that the right inlet of [osc~]
> only is activated at block boundaries. That is, if you send any value
> to the right inlet, it will set the phase to that value only at the
> end of a block of normally 64 samples, unless you've reblocked your
> patch with [block~ ...] This is valid for manually triggered
> phase-changes and for "clock-delayed" triggering through a [metro] or
> a [delay].
Thanks again, Frank. I was beginning to get nut.
More information about the Pd-list