Jaeho Chang

Phasor in gen~ is supposed to be reset when it receives non-zero value.

It works when sending value 1 from the outside of the gen~, but does not work when sending the value inside.

comment

scope~

gen~

phasor

ezdac~

sig~

Phasor in gen~ is supposed to be reset when it receives non-zero value.
It works when sending value 1 from the outside of the gen~, but does not work when sending the value inside.

Phasor in gen~ is supposed to be reset when it receives non-zero value.
It works when sending value 1 from the outside of the gen~, but does

weird-problem-resetting-phasor-in-gen~-with-int-not-working

Don't understand your patch (why constant value, how is it triggered?), but maybe this one here helps.

The patch I attached was just an simplified one to reproduce the issue.

I was creating a bit complicated system inside the gen~ that makes the [phasor] run or stop but it does not stop when putting a non-zero value, while it does make other objects such as [counter] run or stop.

Thanks Martin.
The patch I attached was just an simplified one to reproduce the issue.

I was creating a bit complicated system inside the gen~ that makes the [phasor] run or stop but it does not stop when putting a non-zero value, while it does make other objects such as [counter] run or stop.

The sync inlet of gen~ [phasor] expects that the input would be an instantaneous nonzero trigger value, like the output from a [click~] object. That is, a signal of the form 0, 0, 0, 0, 0, 1, 0, 0, 0, ... Whenever a non-zero signal is received, the phasor resets its phase back to zero. It's a kind of oscillator hard-sync. Thus, if the signal is a stream of 1, 1, 1, 1, 1, 1, ... (as with [sig~ 1]), the phasor~ will be resetting itself at every passing sample of time, and thus remain stuck at zero.

The behaviour seems strange, but it is due to the fact that it makes no sense to hook up a constant value to the phasor's sync input. Since the patcher knows it is a constant, it treats it as if it was an initializer (not a signal), thus it is only observed when the patcher loads. That's why the phasor runs normally without resetting in this case.

It really needs to be a varying signal sent to the phasor's sync input. Here's an example that re-triggers the phasor from time to time:

The sync inlet of gen~ [phasor] expects that the input would be an instantaneous nonzero trigger value, like the output from a [click~] object. That is, a signal of the form 0, 0, 0, 0, 0, 1, 0, 0, 0, ... Whenever a non-zero signal is received, the phasor resets its phase back to zero. It's a kind of oscillator hard-sync. Thus, if the signal is a stream of 1, 1, 1, 1, 1, 1, ... (as with [sig~ 1]), the phasor~ will be  resetting itself at every passing sample of time, and thus remain stuck at zero.

The behaviour seems strange, but it is due to the fact that it makes no sense to hook up a constant value to the phasor's sync input. Since the patcher knows it is a constant, it treats it as if it was an initializer (not a signal), thus it is only observed when the patcher loads. That's why the phasor runs normally without resetting in this case. 

Thanks a lot for your detailed explanation.

I agree and that makes sense. However, I still doubt if this is a kind bug, because [counter] object resets itself from a constant. The attached patch demonstrates [counter] will send just zero due to the constant attached to the second inlet.

Hey Graham,
Thanks a lot for your detailed explanation.

It makes sense and I agree with the concept of constants. However, I still doubt if it's a kind of bug, because [counter] resets itself at a constant value, as the attached patch demonstrates.

weird problem : resetting phasor in gen~ with int not working