Forums > MaxMSP

Fastest onset detection? (native or external)

December 15, 2012 | 11:42 am

I’ve used a couple of different things (spectral stuff) and have settled on this for all my onset detection.

It’s peakamp~ based with some autothreshold adjustment stuff going on.

Anyone have anything faster or more accurate than this? (preferably native, but externals are good too)

– Pasted Max Patch, click to expand. –
December 15, 2012 | 5:37 pm

This, ripped straight from Peter McCulloch’s transient designer patch ( ), works well for me,

– Pasted Max Patch, click to expand. –
December 15, 2012 | 6:14 pm

That looks pretty good.

I’m trying to figure out an objective way to measure the difference in time between them but it doesn’t seem to be working like I think it should be working (trying to use timer to tell the difference between attack and its detection).

– Pasted Max Patch, click to expand. –
December 16, 2012 | 1:03 pm

Couldn’t figure out how to measure the difference in response time between the two, but doing some less objective testing it seems like the volume differential version handles repeated fast attacks better. I need to try to figure out an autothreshold for the audio rate one so it doesn’t need tweaking between input types.

edit: Hmm, the volume differential has a real hard time detecting the vibes example audio attack.

– Pasted Max Patch, click to expand. –
December 17, 2012 | 11:31 am

I usually use a different raise time and down time in the env following part, replacing in your patches the average~ (or the bucket which is only averaging random-ish values from the speedlim) by the following stuff. I know it is not by-the-book but it is much more nervous, and I can change dynamically the attack and the release of the detection…


– Pasted Max Patch, click to expand. –
December 17, 2012 | 12:06 pm

Not 100% sure I follow. So you’re saying replace the average~ by your abs/slide, then still go into the slide that’s there?

By doing this it works more or less exactly the same EXCEPT it actually tracks the vibes attack (where as the average~ version does not).

I’ve dropped the bucket/speedlim thing as it’s doing the same thing as the other onset detector but in the max scheduler.

Here’s a comparison with what Roger posted and what I think you’re suggesting.

– Pasted Max Patch, click to expand. –
December 17, 2012 | 1:47 pm

I think it’s pretty much a swings and roundabouts thing; average~ works better in some cases, slide~ in others, depending on what you set the threshold and range values to and what the source is.
For example, If you try the drumLoop, setting the threshold to 0.3 and the range to 0.9dB , average~ seems to be better at picking up the little flams – but that’s only good if that’s what you want. If you just want the basic beat, you could say that it’s more susceptible to false triggers, and slide~ gives better results.
However, if you try the same settings for the vibes loop, slide~ is the one giving false triggers, giving a double trigger on each onset!
I wouldn’t know where to begin trying to automate the process – the thresholds are always going to depend on the nature of the source,

– Pasted Max Patch, click to expand. –
December 20, 2012 | 12:07 am

I think the slide~ works best for my general purpose stuff.

Now I’m trying to extract a reasonable velocity value from the attack too but not finding a good place for this. Since this new way (slide or average even) are audio rate, that happens faster than my max scheduler version which extracted a velocity.

Here is what I was doing before, but adapted to the slide~ onset detection. By the time the bang happens the velocity is lower than it peaked at.

I also tried sah~ to keep it audio rate, but the velocity value still isn’t very good.

Any thoughts?

– Pasted Max Patch, click to expand. –
December 22, 2012 | 1:01 pm

Don’t suppose our brush with mayan apocalypse gave anyone any insight to extracting velocity from onset detection?

December 22, 2012 | 9:38 pm

Yea but it’s only accurate to 74 Haab’..

December 22, 2012 | 9:40 pm

But not if I run the onset detection in the Haab scheduler.

January 19, 2013 | 7:52 pm

I prefer this envelope follower for percussive signals, since you get the RMS from average~, but it preserves the transient characteristic and exponential decay of the sound:

average~ 100 rms
*~ 1.4132
*~ slide~ 200 2500

Other tip: make two scope~s, one for the signal, and one for the envelope. Set one of them transparent, then overlay. This really helps with seeing how things work together. (you also may need to delay the input signal to account for the latency of the envelope follower)

March 13, 2013 | 10:15 pm

Please correct me if I’m wrong, but
thresh~ 0.5 5.
>~ 0.

gives the same result as
thresh~ 0.5 5.

March 14, 2013 | 5:48 pm

fwiw, fzero~ does some onset detection.

Viewing 14 posts - 1 through 14 (of 14 total)