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

No time at the moment but you could play with [env~ 2 1] which should give you the data... again after the fact.......
David.

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!

Maybe if you just take the impulses on the leading edges and compare their timings (uh, somehow), that will give you the info you need. I'm hand waving because I don't know how you'd determine which impulse was first.

Edit: I think the premise of your project is that the sound of the bead of the stick hitting the batter head is dominant. I wonder if that's true for a snare drum.

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.

i'm really not sure if i understand - but if it was only about that, a simple clipped derivative should be enough?

[rzero~ 1]
|
[max~]

but based on the rest of the discussion, it sounds like you want to know which mic received the first input? i assume that it's not enough to have this per block though - since some mics might have a rising edge in the block after the mic that detected first? (EDIT: when handling things on control rate)

EDIT: it should be doable though to only trigger one impulse each time after a defined "cooldown" period (not sure about the proper word here) on signal rate.

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.

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

"Convert to negative pulse" means instead of sitting at 0 with the occasional 1 pulse, it now sits at 1 with the occasional 0 pulse.

The formula for [rpole~ 1] in help means ""the output is the sum of the current input plus (the previous output times the current coefficient)." When both the input and coefficient are 0, the output is 0, and when they're both 1, it increments by 1 each sample (i.e. counts samples).

By now you probably know how to understand the formula for [rzero_rev~ 0], let me know if you don't. The reason you need it is so that [samphold~] grabs the highest previous count, not the reset value.

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

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:

If so, the only thing you need from my patch is the part that extracts the leading edge as a pulse, inverts it, and then counts the samples between pulses, but if the signal out of [fexpr~] isn't clean (i.e. outputs one and only one contiguous block of 1s for every drum note) then my counter will output junk. That's why I was asking about [lop~] and threshold in my patch, which is what I assumed you were using for signal conditioning, e.g. for novelty metronome sounds I had to adjust them to get clean square pulses.

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 ?

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 ?

Ugh, in audio domain? I dunno but off the top of my head I think it would be nasty/not worth it. Can't you just take a stream of timing intervals in control domain and process them in groups of 4? How you would align each group of 4 isn't obvious to me either, which is what I think @ben.wes was alluding to earlier RE "cooldown period". Edit: maybe [fexpr~] could help.

What is the overall latency-requirement?
And where do you output in the end, sigrate or controlrate?
Analyzing the blocks in control-rate is more common and easier but has at least 1 block additional latency, and can still be sample-accurate. (Sample-accurately one block late.)

reset the sample counter

When reset it? And why reset it at all?
Calculate difference by doing 'now minus before' without any reset.
But when has been before? i.e. what is Tzero? How do you decide which onset is now and which is before?

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.

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.

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.

next step would now be to measure the times for all mics starting from the first impulse.

I'll try it, and also learn from the way you graph the signal ( it must be an else object? )

@ben.wes your graph is a pdlua script of yours ?

yep. I'll write another message with download link and also the patch when getting home later. currently at work. thanks for your response!

• https://github.com/ben-wes/pdlua-show_tilde/releases

... and here's the patch from above so that you don't need to patch it again from the picture if you want to check it out: test-cooldown.pd

I guess some pdlua script would have worked ?
If so, I think a puredata vanilla "scripting" object would be a really nice feature...

pdlua script would have worked ?

yep. that would be an easy option in this case with its signal rate capabilities. currently, there's still a huge PR waiting to be merged into the official pdlua repo which also adds luajit support, increasing signal rate performance quite a bit.

anyway ... i think i ended up successfully implementing this in vanilla now:

... [pd cooldown] looks like this:

... my previous version had the main issue that cooldown reset and first impulse could overlap. it's fixed now by just using 2 consecutive 0s for the reset (and avoiding consecutive impulses for the first trigger).

this might still be way too complicated. but it seems to actually measure the impulses for 4 channels now.
here's the patch: test-cooldown-share.pd

if you'd want really exact localization, this should probably support subsample-measurements though. or at least a higher samplerate (since 1sp represents 7.15mm at 48kHz).

EDIT: the delay 100 for the snapshot is way too large here. 3ms is enough to cover the 100 samples range.
EDIT2: cleaned up the patch and comments. fixed some stuff and uses fewer objects now by reducing redundancy.