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

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

@ddw_music ,

Maybe ok for one second

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

@ddw_music , even better, I guess this would be more cpu friendly ?

@jameslo

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....

Thanks a lot, again!

I just had to invert things:

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

beautiful.

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

@ben.wes

EDIT2: and if it's about counting samples from the first hit to the others and then triangulating - that should also be achievable. let me know whether i understand correctly first. :)

Hi, I missed your post, but this is the idea. get the right number of samples from first hit to the others.
( The triangulation part is already sorted )

I should maybe start a fresh topic about this, as my original question was answered.

@lacuna Actually I could even attach the patcher, it would make it easier right ?

@lacuna

Why not translate the (up and running?) Max patch 1:1 into Pd? (I can not see the Max screenshot.)

Well this is what I'm doing, though my questions are about parts in max that are done in "Gen" ( hence my question about "detrending" a signal, the max patcher does it this in Gen ), there's a sample counter in the max version using "phasor~" , in Max the right inlet of phasor resets the phase with non-zero signal value, in order to reset the counter, in pd I can't figure out how to achieve this...

What is the overall latency-requirement?

the latency in the max patch is fixed, 256 samples.
Then as the distance from hits to each mic can't be more than 50 centimetres this latency could be dropped to 64 samples I guess ( @ 44100hz )

as for your last questions, "Tzero" is when the hit on the snare is received first, "before" is after the it's been received by all 4 mics.

Do you just need to know which mic onset has been first or do you need inter-mic delay of all 4 mics? Things like that can be done by calculating the cross-correlation, but you have not asked for that, so I assume the Max patch is not doing that.

the goal is to get the "cross-correlation" in order to calculate the position where the snare drum was hit, I think I explained this in a post above. Then my questions are about those max things that are not 1:1 transposable, and that got me lost a bit.

 (I can not see the Max screenshot.)

Would you mind helping me achieving this if I post a few screenshots of the max patcher ?
Let me know, I'd start a clean topic about this.

The initial question ( title of this topic ) has been resolved, but leading to other quirks I spent too much time on.

@jameslo Cheers,

I'm testing what I did to check if I get the onsets right.

the main difference with your exemple is instead of resetting the counter every other sample I need to reset it after the fourth onset is received .

another difference is the difference in between each onset is in the order of 4 to 20 samples.

Once I'm sure I get the onsets right I need to count from 0 for 1st Onset to 3 for the 4th onset and only then reset the counter and retrieve the values ( with samphold I guess )

How would you adapt metronome timer for getting the difference between 4 consecutive "onsets", then reset the sample counter to be ready for the next 4 onsets ?

@jameslo At first I didn't use "lop~" thinking my signal was a constant "1".
I added the low pass and was able to detect attacks.

I'm now confronted to other problems, really hard to tell what's wrong...
I didn't post a patch at first because it uses a big external library ( flucoma ).

But after. a few days attempting to get the delay difference in samples between 4 mics receiving the sound of a snare drum I post here the ( buggy) patch I ended up with.
If anyone can have a look ( installing flucoma first ) I'd appreciate...

This patch is an adaptation for an artist who did this in Max msp , he needed this to work in puredate in order to use it with "Bela Gem" hardware.

I could post the "Max" patcher as well if needed.interOnsetDetection.zip![Screenshot 2026-05-07 at 11.38.55.png]

I attach also a screenshot of where the patch is at:

@jameslo Thank you for the detailed explanations! I feel smarter than yesterday.

Though I noticed my signal is in fact a succession of 1 and 0, over a period of a dozen of samples, any advice about how to "debounce", I'd like my signal to be one , then 0 for 4410 samples ( ignoring all the next "1" ).

I hope it's clear, I can precise things, but I'd need to get my head out of it for an hour to do so... I'm way out of my comfort zone dealing with sample accuracy...

@jameslo said:

https://forum.pdpatchrepo.info/topic/13739/sync-in-ms-between-2-audio-signals/6

Hello,

your "metronome timer" patch contains the answer to my question, great !
( quite impressed by the reactivity on this forum )

I would have never thought of "rpole", "rzero", never used those it's a bit hard to understand how it works. The patch is well commented but still if you could detail a tiny bit the part where you take the impulse that would be lovely.

For knowing which one arrived first, I made a sample counter, but still I have to find out how to reset it when first mic is getting the signal. ( So being able to have only impulses might help me go further )

At least I know where to ask if I'm stuck again

@whale-av said:

https://forum.puredata.info/topic/13317/looking-for-velvet-noise-generator/69

Hello, thank you,

"env~" outputs a float, I think my question is confusing.

I'll try to be more precise, I'm analysing audio input signals, 4 audio inputs.
They are mics placed around a snare drumhead, each time there's an attack I generate
a signal that is 1 for all mics.

This signal is long, a few samples long, and I was scratching my head to find a way to turn it only into a 1 sample long impulse. It would make my life much easier.

all this stays at signal rate, then once a hit on the snare was detected on all 4 mics, I'll get the difference in samples in between them in order to know the position on the drumhead where the hit occurred.

thanks for the link to discussion, I'll read more into it to see if I can extract infos that could help. Any link to other posts about samplewise ways of doing things in general is welcome!

Hello all,

I'm having a hard time to achieve the following:

I have an audio signal that is 1 for 14 samples then 0, when it's "1" I'd like to output a "1" signal, then the next sample I'd like to output zero, in order to know at which sample the change occurred.

I want to avoid using "block~" to set audio block to 1 in a subpatch, and don't want to use externals.

Anyone has a clue about how to achieve this ?

Cheers

Cheers!

Hello everyone,

just a quick question, I'd like to know if there is a way to get the information inside my patch that it has been saved.
My goal here is that when the user saves his patch, a couple of json files are saved as well, I don't know much about pd's internal messages but I guess there must be one accessible that is sent each time I save.

Cheers

Cheers, it did compile.

hello,
Thank you for this tutorial, this was almost one year ago, I can't make it work. I tried with the same idf / adf, and with the most recent ones with no luck. Are you still able to compile it ?
Cheers