Here "phasor~"'s phase is reset when receiving a non zero signal.
The use case is resetting a sample counter.

Phasor~in puredata doesn't act the same,
Does anyone have a clue how to make a vanilla adaptation ?

Cheers

I just had to invert things:

fexpr~ if($x != 0, ($y + 1) % 44100, 0)

beautiful.

"phasor~"'s phase is reset when receiving a non zero signal.

If this was a test in college I'd be there during office hours arguing that the question was misleading

I try to be precise when asking for things, but when I post I've been struggling for a long time, smoke is coming out of my ears, I end up with confusing messages....

Here "phasor~"'s phase is reset when receiving a non zero signal.
The use case is resetting a sample counter.

Phasor~in puredata doesn't act the same,
Does anyone have a clue how to make a vanilla adaptation ?

I forget who is the pd forum user who taught me this trick, but, here's a neat way to have a signal reset a phasor:

[phasor~]
|  \
|  [samphold~]
|  |
[-~]
|
[wrap~]

Then the reset trigger goes into the right inlet of samphold~ (but IIRC it should be inverted, because samphold samples its input signal when its trigger signal decreases, see its help file).

Always works (think about it a minute, and it becomes clear why).

Btw phasor * sample rate is not safe as a sample counter, due to floating point rounding error. (Maybe ok for one second.) In pd vanilla, [rpole~ 1] can serve as an accumulator but resetting it at signal rate is a bit trickier. I'm not at the computer now but I could track that down later. Or use cyclone's count~.

hjh

The limitation here is that using a phasor~ for reset, the period is not 100% exact -- 10 seconds should range from 0 to 479999 samples, but I actually get 479991.

To reset rpole~, both the input and the coefficient need to drop to zero for exactly one sample. That's the point of taking the slope of the phasor, scaling it up by a ridiculous amount, and clipping. If there's another way to do this in pd vanilla that will cycle after exactly the right number of samples, it could be substituted here, but I don't know what that technique is.

(FWIW, the [count~] object from Cyclone is exactly correct.)

hjh

Maybe ok for one second

I count only 256 samples, I assume it will be precise then ?

Edit: argh, I even misunderstood my friend. @lacuna is correct below--it's when the signal changes to a non-zero value from zero

resets when the right input signal changes to a non-zero value

$x!=0 && $x[-1]==0

cpu friendly ?

I doubt that this simple checking and accumulating is very expensive.
(in the other thread, in the screenshot I see many [fexpr~] that you could replace with [expr~] or other Vanilla objects.)

@ddw_music wrote:

should range from 0 to 479999 samples, but I actually get 479991.

Oh, this is very bad news! I always thought that phasor~ frequency would be spot on.
(There are very few people who understand [phasor~]s code, here is a thread https://forum.pdpatchrepo.info/topic/14523/90-second-limit-on-audio-buffers)
Ok, this means in Pd-world a sample-counter made with phasor~ would be bad design.

Here is one more patch, this circles between 0 and 255 and stops and resets when input sig == 0.

rpole~reset2.pd

@jameslo wrote:

signal changes to a non-zero value

This would require to add or subtract sth like the [rzero~ 1] [*~ 1e+32][clip~] trick in the inlet.

Edit: Now I realize that in case it stops at counting 0, it never restarts. Adding a [+~ 1] in the feedback-path should fix this.
2nd Edit: But then it's not cicling anymore...hmmm don't know how to fix this. Maybe instead [rzero~ 1] [*~1e+32][clip~] trick on the inlet to get one sample going.

phasor~ for reset, the period is not 100% exact

Now I remember long time ago there has been a thread about very slow <1Hz [osc~] LFO being off.

@y0g1 wrote:

I count only 256 samples, I assume it will be precise then ?

Probably yes.

phasor~is-off.pd

Well, I think the counter being off isn't an issue, in the end it's off for the 4 mics and I end up with correct inter-onset values. ( I hope so )

The patch evolved and has fewer uncertainties ( the screenshot I posted in the previous thread was wrong in many ways... )

I gave up using Lowpass to filter onsets, I went on trying to reproduce some "Gen~" code with "fexpr~" ( as I understood a few things about expressions reading all the different answers I got on the forum.

I got better results ( I've been provided a 4 tracks recording, and a list off all inter onsets produced by the max patch so I can compare ) I spent a few hours trying to have the exact behaviour of :

in a fexpr object.

Question, does anyone think this Gen~ code can be transposed to fexpr~ ?

I never knew this topic would go that deep...
I'll try and improve my onset detection / detrending, then see if I need the counter to be that accurate ( my guess is "no" )

Here's a screenshot & the patch attached.

genDetrendTest.pd