Another adaptation I'm struggling with:

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

@ddw_music ,

Maybe ok for one second

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

@y0g1 My friend who uses Max/MSP just explained to me that phasor~ resets when the right input signal changes to a non-zero value, which means that in my fexpr~ version the test should be "$x != 0 && $x != $x[-1]"

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

@jameslo

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

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

@y0g1 wrote:

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.

@ddw_music wrote:

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

@lacuna [phasor~] only resets at block boundaries..... https://forum.pdpatchrepo.info/topic/3699/phasor-with-sample-accurate-phase-reset
So this might be what you need...... vphasor~.zip
I think this was the previous discussion...... https://forum.pdpatchrepo.info/topic/12865/samphold-noise-phasor-noise-round-off-error-or/3
David.

@lacuna

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~ ?

@whale-av Cheers !

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" )

I think I achieved replicating this in puredata ,I'm also pretty sure this can be done way more efficiently...!

Here's a screenshot & the patch attached.

genDetrendTest.pd