Drum triggers...removing false/bleed triggering
So I got me a pair of DDrum drum triggers (one for kick and one for snare) and they are nice and sturdy little guys.
My plan is run them into my soundcard as audio, and then use onset detection in Max to generate the trigger data (to avoid having a separate brain/power thing to deal with.)
The problem I'm running in to is that the triggers are sensitive enough, and the drums are close enough, that they are triggering each other. I'm trying all sorts of stuff with filter each input before the onset detection, but I can't get it to trigger consistently and independently.
Below is the best I've gotten so far. It works fine for loud independent hits, but when there are variable dynamics it's not working too hot.
Attached is an (mp3) recording of the triggers in various dynamics etc..
Hi Rodrigo,
filters are good, but I'd combine them with some gates with hysteresis going on for optimum isolation.
There could also be problems relating to the placement of these triggers - getting as close to the beater as possible with the kick, for instance, would let you keep the sensitivity lower, of course.
As in gating the opposing one? Hmm.
The triggers are commercial ones that mount along the rim. They are pressed firmly against the head.
I own a midi drum module and think it's worth the money. The alesis trigger io is relatively cheap.
On these things you can set a threshold and then it just works.
Oh, and you already added some gating with the onebang construction.
I have so many little bits already that having a drum brain, then a midi to USB, then a spare USB port (full up already) would really be brutal.
I'll try adding a onenang lockout for opposing triggers too as it would mean less aggressive filtering.
I meant as in using an audio gate with volume sensing and a threshold - well, two, for hysteresis, like on the drum brains. Not "max gates", as such. Hope that's clearer :) Gating both simultaneously, as it were.
Could you post an example of what you mean? I've not done that in max before.
hmm. I thought for sure there'd be one in max... can't find it, for some silly reason.
Anyhoot, here's one implemented in jamoma, but without hysteresis. Still looks like a solid design:
Ooh goody. Ill check this when I get home. So by hysteresis, you mean a lockout?
Ok, wrestled with this a bit more today. I'm using a gate~ with some hysteresis to block the opposing trigger. That with some harder filtering seems to give very good results. It does, however, produce the problem of not being able to trigger both things at the same time. I've tuned the rampsmooth so it triggers more accurately, but it means hits can't be within 50ms of each other (as in kick/snare at the same time).
I guess there's a compromise that has to be made in terms of ability to trigger both at the same time vs accidentally triggering both at the same time.
Also not sure if I have the gate~ and rampsmooth~ in the right places.
Here is the "done" patch. It does very solid onset detection, does good blocking (using gates/hysteresis), and generates velocity data for each attack. All at audio rate.
The velocity detection adds a tiny amount of latency (180samples (about 4ms)), which is unfortunate, but it's the tightest I was able to get it while still having accurate velocity data.
Would probably work for general audio to midi percussion applications too if you remove the biquad, as that's tuned to pickup mainly the piezo "slap" of the triggers.
So after some further playing with this, it's working wonderfully BUT it's picking up false triggers from hihat/cymbals and general ambient sounds (picking up sticks, or touching the snare). I messed around with the values in thresh~ quite a bit, and tried more aggressive filtering using filterdesign (20 order butterworth picking up only between 800-1200ish range, and others around there) and it would still pick up stuff.
I don't know what frequency is best to hone in on for the piezo trigger emphasis or if I just try something else to get it to just trigger of drum hits.
Have you done spectral analysis of the average hit? Maybe you know the but HISS tools are a great libary, and you could at least get a very good spectral display with legend, peak and averageing, for tuning your filters more accurately.
Also FFT gating may be a way to go.. although i admit this seems a bit much. I cant believe that this is actually happening in these little boxes usually doing the job. Might there be maybe an additional signal('balanced' cables, rigth?) indicating something useful on the other channel?
I'm using the hiss spectrum display for all the tweaking, though I haven't gone so far as to analyze for peak/averageing of the whole buffer/sampler.
I thought about trying to get some fft filtering but didn't want to add further latency, and as you mentioned, I can't imagine drum brains have that kind of thing going on.
The sensor in the trigger is super simple, just a piezo pressed up against the head using a foam square.
There is an xlr connector, but only 2 pins are real (the +/- from the piezo element).
The only thing I can think of us cranking the threshold waaay up, but it would suck to sacrifice dynamic range.
Late to the game, but it still may be of use: you might look at the transient detection circuit in my envelope shaper:
http://www.subtlesonic.com/envelopeshaper/
It uses two different envelope followers with different attack/decay times to detect transients. It works pretty well, and gives you the benefits of the hysteresis without feedback.
I'm using more or less your onset detection (though cobbled together from another onset detection patch). Main difference is abs instead of average. I did a bunch of testing/tweaking and that seemed to work the best with the different types of materials I was throwing at it. (not just percussive).
In this particular case it's just percussive, but latency is a bigger deal. The big problem here is detecting just the actual trigger, and not ambient sounds. Hmm, maybe tuning the slide will help as only things on the drum itself would have really fast transients, everything else should be a slower/smoother transient.