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 ( http://www.subtlesonic.com/envelopeshaper/ ), works well for me,
Cheers
Roger

— 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…

p

— 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,
Cheers
Roger

— 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.
|
change~
>~ 0.
|
edge~

gives the same result as
thresh~ 0.5 5.
|
edge~

March 14, 2013 | 5:48 pm

fwiw, fzero~ does some onset detection.

January 6, 2016 | 8:54 am

@Rodrigo: revisiting this thread in response to another post, how about peakamp~ for velocity?

At signal rate, you could use a running maximum that gets reset with each onset. One other tweak would be to look at the derivative of the onset for detecting the peak. When it switches to negative, patch the previous value. (this premised on a percussive signal with a smooth envelope)

January 6, 2016 | 9:15 am

Both of those are good ideas. I’ll give that a spin.

In the end (a couple of years ago!) I ended up keeping it signal rate and taking the value 180 samples after the onset is detected (I think I played a bunch to a sweet spot value).

I also built a drum-trigger type lockout so you can have 2 triggers on difference surfaces and there won’t be any cross triggering.

— Pasted Max Patch, click to expand. —
January 6, 2016 | 9:19 am

Here’s the audio I used to test with (direct recording from DDrum triggers on my kick/snare using my soundcard).

Attachments:
  1. test.wav_.zip
February 3, 2016 | 3:46 pm

Hi,

I looked at your example. I gather that when a p is in an object it’s referring to another object file. What is "p onset_velocity" in your example? Would you be willing to share the complete patch that includes the "p onset_velocity" object? I mean, when I type "onset" within an object it’s light brown, so I don’t think there’s such a thing as an "onset" object.

Further, do you have any example patches that are for live music? I would like to see if I could adapt them to send MIDI or OSC, for which I see some examples.

About myself, I’m new to Max and still don’t completely get the inputs and outputs nor special characters. The examples I’ve seen can be like spaghetti. I find it difficult to pinpoint where all the lines are going. I wish there were an easier way to make sense of objects that have been smashed together.

Best regards,
Truth

February 4, 2016 | 12:32 am

If you double click "p onset_velocity" it will open up and show the guts. "p" just stands for "patcher" or a subpatch, which is embedded in the patch itself. An abstraction is typically named and needs to be in the search path.

In terms of sending MIDI or OSC, it depends on where you want to go. The examples above spit out a velocity based on the incoming audio. Here is a more cleanly labelled version of things that takes incoming audio (or whatever) at the top, then spits out a "bang" on the left, or a velocity (0-127) on the right. You can then use those to send MIDI or OSC messages to whatever program you’d like.

— Pasted Max Patch, click to expand. —
Viewing 19 posts - 1 through 19 (of 19 total)

Forums > MaxMSP