Ô cycle~'s phase inlet, i don't like you.
Hey,
So this is a little bugging me. Here is attached a tiny little patch
What happens is :
-if i send a 0. float message to the right inlet, the phase does not, never ever, go to its position 0. as i would expect
-if i plug a signal in the phase inlet, if it's a 0 then the cycle~ goes to its phase position 0 at the time of plugging the cable. But then, even though the signal is still there, and it's still a 0, the cycling goes on, and the phase is soon no longer 0.
-if i unplug the signal and play with a [flonum], the phase changes, but i don't understand how or why.
I suspect it's more me understanding things wrongly than a real bug. It's as if, for an incoming signals, there was a built-in [change] in that phase inlet. And for floating numbers, i really really don't know. It's a problem when i use a cycle ~ at very low frequencies and want to reset the phase at will. As always, any help would be more heartily welcome !
expected behavior ... for all objects.
when a signal and a float are both connected to a signal inlet, the number will multiply the signal.
:)
-110
Thanks !, but ?...
even if i disconnect, on purpose, the signal patchcord ? and when i don't connect a signal at all ?
and what about the phase not staying at the signal's value ?
And also :
when a signal and a float are both connected to a signal inlet, the number will multiply the signal.
Reaaallyyy ?? i though the number was simply ignored in those cases...
edit : this quick test shows that number is ignored when signal is connected
Hi
I recall (from somewhere in the documentation), and through observation, that a signal to an inlet overrrides message input. I would of course hesitate to correct Roman; I would guess that the multiplication only applies in certain specific cases and inlets.
Brendan
Hi Brendan, what does 'phase is dynamic' mean ? And, hm, playing with your example made me think that maybe, those phase controls are not setting the current cycle~'s phase position, but rather adding an offset to said phase. This would lead the conclusion that there is no way to 'resetting' a cycle~'s phase, and hence if i need that kind of control i should use something else. A read at the cycle~'s reference did confirm that cruel realization.
So thanks for your attention, and sorry for your time !
I think I can clarify a couple things for you.
1) When an inlet is capable of accepting either a signal or a float, as in the case of the right inlet of a cycle~ object, and a signal patch cord is connected to that inlet (say, for example, coming from a phasor~), float messages are ignored. The signal and the float are not combined in any way. You can use one or the other but not both.
2) It is more correct to think of the value supplied in the right inlet of cycle~ not as the instantaneous phase, but rather as the phase OFFSET that is applied to the otherwise independent operation of the cycle~.
Some examples might help to make that last sentence clear.
a) A cycle~ object generates a cosine wave at the specified frequency and with the specified phase offset whenever MSP audio is on. A cycle~ object with no frequency specified as an argument and no frequency info coming in its inlet has a default frequency of 0 Hz. Likewise, its phase offset is 0 by default. Since its frequency is 0, it does not increment through the waveform at all. So, a cycle~ object with no arguments and nothing connected to its inlets will generate a constant output signal of 1 (the 0 phase position of a cosine function).
b) A 0 Hz cycle~ with a phasor~ connected to its right inlet will be totally controlled by the phasor~. Its frequency will be equal to that of the phasor~. Its instantaneous position within the cosine function will depend on the signal being supplied in its right inlet; when the phasor~ is at 0.5, for example, the cycle~ will be sending out -1 (1/2 cycle through the cosine function).
c) Each time MSP audio is turned on, cycle~ starts at 0 phase plus whatever phase offset is supplied in its right inlet. If a cycle~ is running at some nonzero frequency and you later send it a float phase offset of 0 hoping to set it back to its initial default phase, you will be disappointed because all you have done is change its phase offset (or not changed it at all if its phase offset was already 0) relative to where it was in its cycle at that instant; it will continue to run from wherever it was (offset by whatever phase offset has been specified for it).
d) A float message in the right inlet of a phasor~ object is different. It does reset the phasor~ to whatever phase you specify, at the moment that it receives a float in its right inlet. So let's say you want to apply a sinusoidal vibrato to a note, and you want it always to begin on the center frequency of the vibrato. You would therefore want to ensure that your LFO is in sine phase at the moment the note is played. You could control your LFO with a phasor~, and set the phase of the phasor to 0.75 (specifying sine phase for the cosinusoidal cycle~ object) at the moment each note is played.
Hi vichug
yes, I meant not only that phase is variable, but that it updates, rather than resets, the phase. This is only based on our use of [scope~] in this context, which I am increasingly suspicious of for these purposes.
If I was more dedicated I would read [cycle~]'s reference, but in practice - as you know and say - the right inlet to cycle is best used to turn a linear ramp into a curve (when cycle has no frequency argument). A changing float message to this inlet pushes the phase forwards or backwards; a static float message to cycle which has a frequency will reset its phase only once.
Best regards
Brendan
Wow. Christopher's description is more precise and eloquent, and predates my previous response :)
Christopher, once again to the rescue :) phasor~ driven cycle~ shall be my answer here. Thanks again everyone, problem solved !