Hi guys,

So I have been implementing a zero crossing rate detector in Pd. I am currently turning the signal into a square wave (-1s and 1s) and working out the difference between successive samples, then using [fexpr~] in order to check whether this difference is more than 0 in which I turn the block of 64 samples into a block of 0s and 1s (1 means a zero crossing).

All I have to do now is to sum the 1s in that block, but I'm having problems in doing that as I am new to Pd, and I don't really want to use [fexpr~] again as it's computationally intensive.

Has anyone got a solution for this?

@mattgomes28 The [env~] object provides the RMS value of one block of audio data scaled 0 to 100
in dB (the average of the block).

As you know that all values are all 0 or 1 the output of [env~ 128 64] should be a scaled sum of the "number of 1's"..... in a block of size 64?...... I think.
The math should be "easy?!".....

David.

@whale-av That makes a lot of sense! I'm fairly new to Pd, hence I haven't got much experience with all the object. Thank you very much tho!

@whale-av Hi mate, I have been trying to work with [env~ 128 64], however I tend to get values like 90 out of this object when really the zero crossing should be low (like at most 5 out of 64 samples). I'm not entirely sure what maths I need to scale it to the proper range. Do you have any ideas? The screenshot is Note that the [tab_sum] function is behaving weirdly, it loads fine when I open the help for iem/tab_sum then paste it into my abstraction, but when I close Pd and reopen it, it goes red saying "couldn't create...", to which I made a post about but no one seems to know a fix.

@mattgomes28 Yes...... there is a relationship, but the math is beyond me today...... well, since 1974 actually.
This should work............ test_env.pd
David.

to get the sum of all of the samples in a block you might be able to use [rpole 1] and send it a clear message every block

@whale-av Ah I see, but I was trying to avoid using until and tabread as I'm working with real time data, tab_sum seemed to work really well but has compatibility issues.

@mattgomes28
I would expect it to work, as [bang~] could read [tabread] before you write again with [tabwrite~] at the end of every block........you would have to set [block~ 64] and that could be too fast..... but maybe not? if the table is hidden in a sub-patch?

Solved. The number of "1's" needs to be read one audio block later, which can be done by adding [delay 0] to the read point. [delay] cannot be processed until the next [bang~] which is very useful in this scenario.......
test_zeros.pd
Connect [bang~] to the left inlet of [delay 0] for a working patch. The data will be sent at the end of every audio block of 64 samples.

Here is [once] as an abstraction in case anyone needs it.......once.pd
David.

@seb-harmonik.ar This is so far the best solution! Thank you, it worked like a charm.

@whale-av That works too! Thank you!