double-trigger diagnosis · MIDI evidence path · drum-pad troubleshooting
Why Does One Drum-Pad Hit Trigger Twice? A Four-Layer MIDI Test
A flam-like echo, two recorded notes, and two layered sounds can feel identical while playing, but they need not share a cause. Compare one physical gesture, the earliest MIDI you can actually observe, the stored clip, documented live audio, and isolated dry clip playback. Use only observation points whose locations you can name.
Scope: this is a device-neutral diagnostic for pad controllers, electronic drums, drum modules, DAWs, and software instruments whose MIDI or audio output can be observed. Menus, zone behavior, trigger algorithms, and monitoring points differ by product. FingerDrum does not claim access to third-party trigger waveforms or hardware parameters, and it cannot change settings inside external devices. The P/M0/M1/A evidence ledger, A-live/A-play comparison, optional M2-live/M2-play observations, result tags, neutral-state localization, and A0→B→A1→B2 reversal are the FingerDrum Editorial Team's original synthesis from the cited documentation.
Preserve the faulty state, then perform 20 slow, isolated single strikes. For every strike, compare P (physical contact), M0 (earliest observable MIDI at a named location), M1 (the stored clip), and A-live (audio while you perform, with its route and effects declared). When the MIDI counts remain singular but A-live doubles, disable live input and play exactly one inspected M1 event through one dry receiver to capture A-play. At the same trustworthy receiver-input location, record optional M2-live during performance and M2-play during isolated playback; never merge their counts. A duplicate at M0 means only that it exists at or before M0—it does not prove pad hardware. If A-live doubles but A-play is singular, inspect every branch removed or changed for A-play, including Local/direct sound, live monitoring or MIDI returns, live-only post-FX, delay/send/bus paths, and parallel audio outputs. If A-play doubles, use M2-play—not M2-live—to separate playback-time MIDI generation from receiver layering or audio routing. Mark an unobserved gap unresolved. A time gap or lower second velocity alone does not prove mechanical bounce.
“Triggers twice” can describe three different event counts
The MIDI Association documents a Note On message with channel, note number, and velocity information. That message is evidence of a MIDI onset; it is not a photograph of the pad surface. Two Note On messages at a raw monitor—or two stored note starts at M1—show that two MIDI onsets exist by that observation point, but not whether the cause was a rebound, a sensor/module decision, a Repeat feature, or a duplicated route.
Audio count is different again. Ableton documents that multiple Rack chains can share the same Receive note, in which case that one note reaches every matching chain. A single MIDI event can therefore legitimately trigger several chains or layers. Conversely, a Note On followed through two monitoring routes can produce two audible attacks without creating two events in the stored clip.
| Observation | What it proves | What it does not prove |
|---|---|---|
| Two confirmed physical contacts | The gesture had more than one physical contact | That the device emitted two Note Ons |
| Two Note Ons at an observation point | Two MIDI onsets exist by that point | Mechanical bounce, based only on interval or velocity |
| One Note On, two dry attacks | The duplication happens after the observed MIDI point | Whether layering, zones, monitoring, or routing caused it |
| Two sounds with different timbres | More than one audible voice or path may be active | That the pad itself double-triggered |
Do not use a “very short interval” or “weaker second velocity” as a bounce detector. Those patterns are useful clues, but a deliberate grace note, roll, Repeat stream, rim response, or transformed copy can share them. Attribution requires a named boundary comparison and a repeatable control change.
Use four evidence categories without pretending they form one serial chain
Label the evidence before changing anything: P physical contact; M0 earliest observable MIDI at a named location; M1 stored clip; A declared audio captures. These are categories, not a guaranteed P→M0→M1→A signal chain. A DAW can record M1 while sending live input down a parallel monitoring branch to A-live. On playback, M1 can pass through MIDI effects that create events before the receiver. Draw only the branches your hardware, host, and monitors actually expose.
| Evidence | Record for each strike | What the comparison can establish |
|---|---|---|
| P — physical | One intended gesture; note only a confirmed second contact, or mark contact count unobserved | Distinguishes confirmed multi-contact gestures from gestures whose contact count is unknown |
| M0 — earliest MIDI | Count, channel, note, velocity, timestamp, and the monitor's exact location | If a second event is already here, it arose at or before M0—not necessarily inside the pad or module |
| M1 — stored clip | The saved events after recording, before manual edits | If a singular M0 becomes a doubled M1, the recording branch between those named points is implicated |
| A — audio | A-live: attacks while performing, with route/effects declared. A-play: attacks when live input is disabled and one inspected M1 event plays through one dry receiver | A-live versus A-play identifies behavior that depends on branches removed or changed for isolated playback |
Add receiver-input MIDI evidence only when the setup exposes a trustworthy monitor. Label its two passes separately: M2-live counts events at that named location during A-live; M2-play counts events at the same location while one inspected M1 event produces A-play. Do not substitute one pass for the other or compare them if the monitor location changed. If A-play doubles and M2-play also doubles, inspect playback-time MIDI transforms or routes before blaming the receiver. Only a singular M2-play—or equivalent reliable playback-path receiver-input evidence—plus multiple A-play attacks supports testing receiver chains, sample layers, zones, or audio routing. If M2-play is unavailable, keep that playback boundary unresolved.
M0 means the earliest MIDI view your setup actually exposes, even if known or possible processing sits before it; name that limitation. Write M0 unavailable only when no suitable MIDI observation exists. Do not relabel a later view as raw input. Apple describes Logic Pro's Event List as a view for note events in a project; its note rows include channel, note number or pitch, velocity, and length. That makes it useful evidence for M1, the stored clip, but not automatic proof of the electrical or unprocessed output from a pad.
Give every monitor its real location and pass: “isolated module MIDI out,” “DAW input after an all-inputs merge,” “recorded region,” “receiver input during live performance,” “receiver input during isolated playback,” or “instrument output.” A controller's own Repeat may sit before M0; a host MIDI effect may sit between M0 and M1, on the live branch, or only on M1 playback. If an observation point is unavailable, retain the gap instead of assigning its events to hardware or software by guesswork.
Preserve failing state A0, then use neutral state N only for localization
First save a reproducible failing state as A0: duplicate the project or preset, keep the faulty clip and A-live capture, photograph or write down the routing, and export the relevant event list if the application permits. Complete A0's 20-strike ledger before changing the state. Then create a separate neutral copy called N. N deliberately removes several confounds, so a passing N can localize the search but cannot prove which removed variable caused A0.
- Declare one target pad and its expected signature: write every documented note, channel, and zone that one center hit is meant to emit. An intentional multi-note or multi-zone signature is not a duplicate merely because its count exceeds one.
- Freeze event-altering features in N: after recording their A0 states, switch off Repeat, arpeggiator, roll, note echo, probability, randomization, MIDI FX, quantize-on-record, clip looping, follow actions, and retrospective capture or merge where applicable.
- Keep one documented MIDI route: use one physical source, one enabled input path, and one armed track. Remove duplicate controller ports, mirrored tracks, unintended returns, external-MIDI sends, and parallel capture paths. If the source's internal generator is the intended receiver, keep one documented DAW return and record its route rather than categorically removing it.
- Use one dry receiver: choose a simple patch with one declared chain, bypass sends and master effects, and remove delay or reverb from the evidence bounce. Keep monitoring mode written down.
- Separate live and playback evidence: capture A-live during the strike and optional M2-live at the named receiver input. Then disable live input, play one inspected M1 event through the declared receiver, and capture A-play plus optional M2-play at that same receiver-input location.
- Remove timing confounds: stop unrelated playback and loops, leave a clear silence between strikes, and do not edit or quantize the capture before counting it.
- Run N as a matched screen: after A0's baseline is complete, repeat the same 20 strikes in N with the same target zone, intended gesture, pacing, expected signature, and named observation locations. Save a separate N ledger; do not overwrite A0.
- Use N only to shortlist candidates: compare A0 and N counts at each named boundary. If N passes, list every difference from A0. Restore A0 and reproduce the fault before testing exactly one candidate as B in the later A0→B→A1→B2 reversal. If N still fails, it has not cleared that boundary; do not keep removing unrelated variables.
One special routing example is Local Control on a keyboard, drum instrument, or module that has its own built-in sound generator. Apple explains that Local Off disconnects a device's performance controls from its internal sound generator so Logic can route MIDI back to it. With Local On, one direct local sound plus the DAW-returned note can make A-live sound twice while A-play remains singular. That comparison requires the intended return to remain documented and active. This is only an example for devices with built-in sounds and an applicable Local setting—not a universal fix for controller-only pads, and not permission to toggle an undocumented control.
Run 20 isolated strikes and keep a per-hit ledger
Place the target on a stable surface and use the same declared zone. First, in A0, perform 20 intentional single strikes, each separated long enough that the previous audio and any Repeat window have ended. Do not discard “bad” rows. For each strike, count events rather than writing only “good” or “bad.” If camera or touch evidence is unavailable, record P as “one intended gesture; contact count unobserved.” Record A-live and optional M2-live during performance. When the audio branch needs isolation, disable live input and capture A-play plus optional M2-play from one inspected M1 event. After building N, copy the ledger, label it N, and repeat the same 20-strike conditions before comparing boundaries.
| Hit | P contact | M0 events / IDs | M1 events / IDs | A-live attacks / M2-live events | A-play attacks / M2-play events | First observed duplicate / tag(s) |
|---|---|---|---|---|---|---|
| 01 | ___ | ___ | ___ | ___ | ___ | ___ |
| 02 | ___ | ___ | ___ | ___ | ___ | ___ |
| 03 | ___ | ___ | ___ | ___ | ___ | ___ |
| 04 | ___ | ___ | ___ | ___ | ___ | ___ |
| 05 | ___ | ___ | ___ | ___ | ___ | ___ |
| 06 | ___ | ___ | ___ | ___ | ___ | ___ |
| 07 | ___ | ___ | ___ | ___ | ___ | ___ |
| 08 | ___ | ___ | ___ | ___ | ___ | ___ |
| 09 | ___ | ___ | ___ | ___ | ___ | ___ |
| 10 | ___ | ___ | ___ | ___ | ___ | ___ |
| 11 | ___ | ___ | ___ | ___ | ___ | ___ |
| 12 | ___ | ___ | ___ | ___ | ___ | ___ |
| 13 | ___ | ___ | ___ | ___ | ___ | ___ |
| 14 | ___ | ___ | ___ | ___ | ___ | ___ |
| 15 | ___ | ___ | ___ | ___ | ___ | ___ |
| 16 | ___ | ___ | ___ | ___ | ___ | ___ |
| 17 | ___ | ___ | ___ | ___ | ___ | ___ |
| 18 | ___ | ___ | ___ | ___ | ___ | ___ |
| 19 | ___ | ___ | ___ | ___ | ___ | ___ |
| 20 | ___ | ___ | ___ | ___ | ___ | ___ |
For any row with an event beyond the declared expected signature, retain the channel/note/velocity values and timestamp differences. Those details help reproduce the result, but neither the interval nor the second velocity names the cause. If M0 and M1 remain singular while A-live doubles, run A-play and, where possible, record M2-live and M2-play at the same receiver-input location. A singular A-play makes every branch removed or changed for isolated playback a PATH candidate: Local/direct sound, live MIDI monitoring or returns, live-only post-FX or note generation, delay/send/bus paths, and parallel audio outputs. Test those candidates one at a time from A0. If A-play also doubles, inspect M2-play: two M2-play events implicate playback-time MIDI generation or routing; one M2-play event supports receiver-layer or audio-path tests. Without reliable M2-play or equivalent playback receiver-input evidence, keep that boundary unresolved.
Record the first observed boundary, then add hypothesis tags
The tags below are not mutually exclusive and do not replace the P/M0/M1/A counts. First write the earliest observation that contains an event or attack beyond the expected signature. Then add one or more tags only when a controlled comparison supports them.
| Tag | Evidence signature | Next controlled question |
|---|---|---|
| CONTACT | More than one physical contact is observed before the first duplicate event | Does stabilizing technique or the mounting surface remove the extra contact while the path stays fixed? |
| UPSTREAM | An event beyond the expected signature already exists at M0 | Is M0 a direct isolated device output, or can a built-in Repeat, merged port, return, or other unseen stage exist before it? |
| REPEAT | A documented Repeat, roll, arpeggiator, echo, or other note-generating stage accounts for the extra stream | Where does that stage sit—before M0, between M0 and M1, on the M2-live branch, or on M1 playback before M2-play—and does disabling only it restore the expected count? |
| PATH | A singular earlier observation becomes duplicated at a later MIDI point, or A-live doubles while A-play stays singular | Which one removed or changed port, track, Local/direct branch, live MIDI return, post-FX, delay/send/bus path, or parallel audio output makes the count change? |
| LAYER | A-play has multiple dry attacks while M2-play, or equivalent reliable playback receiver-input evidence, contains one expected event | Is the multi-chain sound intended, and does soloing one documented receiver chain remove the perceived double? |
| ZONE | The pair has documented head/rim or other zone identities | Does the product define this pair for that gesture, and can zone separation be tested without erasing intended articulation? |
| XTALK | A different pad, note, or zone is triggered by energy from the struck source | Does the source/victim pair follow mounting, contact, or the product's documented crosstalk control? |
| UNRESOLVED | The duplicate lies across an unavailable observation point, or the controlled result does not repeat | Does this gap require M2-live, M2-play, an earlier monitor, a vendor-local meter, or a support capture? |
UPSTREAM is a boundary, not a hardware diagnosis: the extra event exists at or before M0. Calling it a device or module fault requires an isolated direct output or vendor-local evidence plus a controlled reversal. A module's internal trigger meter or sound can also differ from what its MIDI output exposes, so a singular MIDI route does not universally clear the module. XTALK is specifically a source/victim interaction, often with another pad or zone. That differs from the same target signature duplicating through Repeat or routing.
Stop rule: do not promote an A-live/A-play difference to one specific PATH cause when constructing A-play removed several branches. Do not apply LAYER from M2-live, from M1 alone, or from sound resemblance. Without a trustworthy M2-play or equivalent playback-path receiver-input observation, leave the MIDI-versus-receiver boundary UNRESOLVED and test reversible receiver solos or obtain the missing capture.
Roland's TD-07 documentation illustrates why source controls must be product-specific. It describes Retrigger Cancel as suppressing false triggering from a distorted decay waveform, Mask Time as ignoring trigger signals within a set interval, and XTalk Cancel as preventing vibration from another pad from causing a trigger. The same documentation warns that excessive Retrigger Cancel can omit notes in fast rolls and excessive Mask Time can make fast consecutive strikes fail. Names, ranges, defaults, and algorithms vary: do not copy a TD-07 value into another product.
Do not adjust a trigger filter merely because M0 is the first MIDI view that shows the duplicate. First isolate the source side: use a direct single device output where available, turn off documented built-in Repeat or roll functions, rule out merged ports, and compare any vendor-local trigger meter or internal sound. Conversely, if M0 and M1 are singular but the module's own dry sound doubles, MIDI has not cleared the source; follow that exact product's diagnostic path. When the evidence gap remains, retain UPSTREAM or UNRESOLVED rather than guessing.
Use A0→B→A1→B2 to test one variable
State N may narrow the search, but its many deliberate changes cannot establish a cause. Return to the preserved, reproducible A0 and choose exactly one reversible variable with a documented relationship to the observed boundary. It might be one Repeat switch at a named location, one duplicate route, one Rack chain, one applicable Local setting on a built-in-sound device, or one source retrigger parameter after source-side evidence is established. Do not change sensitivity, threshold, mask time, curve, routing, patch, and technique together.
- A0 — baseline: restore the preserved failing state and repeat the same 20-strike window. Record duplicate rows, event identities, and audio attacks.
- B — one change from A0: alter exactly one declared setting or route. Repeat the 20 strikes without editing the clip. A pass means the duplicate count falls as predicted without missing intended singles.
- A1 — reversal: restore the original value. The same failure should return at the same first observed boundary. If it does not, the result may reflect technique, intermittent hardware, or another uncontrolled variable.
- B2 — confirmation: reapply the candidate value and repeat. Save the value, firmware/software version, project, and ledger only if the pass returns.
For a sporadic fault, compare counts rather than demanding identical hit numbers: for example, duplicates in A0 and A1, none in B and B2, with the same test conditions. Repeat the four-block reversal if the difference is small; one lucky 20-hit block is not proof. Keep the same observation locations and pass labels, including A-live/M2-live and A-play/M2-play, throughout the reversal. A setting that merely hides the second audio attack while M0 still contains two events has not removed that upstream event; label it an audio workaround.
Regression-test what a drummer actually needs
A clean expected-signature ledger is necessary, not sufficient. Trigger suppression can make an instrument appear fixed by rejecting real playing. Keep the lowest intervention that passes all relevant musical checks:
- Intentional fast doubles and rolls: every intended onset remains present at the named M0 and M1 observations and at M2-live during performance. In a separate regression playback of that pattern, M2-play must retain the expected intentional onsets when that monitor is used.
- Head, rim, and other zones: each documented identity remains separate; normal center hits do not spuriously create a second zone.
- Simultaneous pairs: two different pads struck together both survive, with neither suppressed as crosstalk.
- Light and strong dynamics: the expected range is retained without inventing or losing onsets. Velocity shape is a separate question from event count.
- Original musical passage: the fix survives the pattern that exposed the fault, not only slow test taps.
- Save, close, and reload: repeat a five-strike subset after reconnecting the device or reopening the project, and confirm the intended setting persisted.
If an increased Retrigger Cancel or Mask Time removes duplicates but loses intentional doubles or rolls, it fails regression. Return to the last passing value or investigate mounting, cabling, zone setup, routing, or vendor support with the A0/B/A1/B2 ledgers attached.
FAQ
Do two recorded notes prove that the pad bounced?
No. They prove that two stored MIDI events exist at M1. A second event's interval and velocity can help reproduce a pattern, but neither identifies its cause. You still need P, the earliest named MIDI observation available, the expected event signature, and a reversible one-variable test.
Can one MIDI Note On legitimately make two sounds?
Yes. Multiple receiver chains may listen to the same note, or a patch may intentionally layer samples. Ableton's Rack documentation explicitly allows multiple chains to share a Receive note. During isolated A-play, one expected event at M2-play plus multiple dry attacks supports testing LAYER. M2-live cannot establish that playback-path conclusion. If M2-play is unavailable, solo receiver chains but keep the preceding MIDI gap marked unresolved.
Is Logic Pro's Event List raw incoming MIDI?
Do not call it raw. Apple's Note Events documentation describes event properties in the project, including channel, note, velocity, and length. In this framework, a recorded Event List is M1. M0 is the earliest separate MIDI observation you can name; call it raw only when its documented placement supports that claim, and record any possible processing before it.
Should I immediately increase Mask Time or Retrigger Cancel?
No. First establish source-side evidence with an isolated direct output or the product's own trigger meter or internal sound, then consult the exact product manual. Excessive suppression can lose deliberate fast notes. Change one documented value, run A0→B→A1→B2, then test doubles, rolls, zones, simultaneous pairs, dynamics, and reload.
What if M0 and M1 each contain one event, but live playing sounds twice?
Compare A-live with A-play and keep M2-live separate from M2-play. If one inspected M1 event produces one A-play attack, investigate everything removed or changed for isolated playback: performance-time monitoring, a direct Local path plus the DAW return, live-only post-FX or note generation, delay/send/bus paths, and parallel audio outputs. If A-play also doubles, inspect M2-play: two events point to playback-time MIDI generation or routing, while one expected event supports a receiver-layer or audio-path test. Without M2-play or equivalent playback receiver-input evidence, keep that last boundary unresolved.
When does Local Off belong in this test?
Only when the source device has a built-in sound generator and an applicable Local setting, and A-live versus A-play suggests that both its direct sound and the documented DAW-returned path are audible during performance. Keep the intended return active for that comparison. A pad controller with no internal sound does not acquire this failure mode merely because another product's manual mentions Local Off.
Sources
Accessed October 17, 2026. Product documentation is used to establish message fields and concrete examples. The four evidence categories, A-live/A-play split, optional M2-live/M2-play points, neutral state N, tags, ledger, and reversal procedure are an editorial synthesis—not a claim that every device exposes the same monitors or controls.
- The MIDI Association — About MIDI, Part 3: MIDI Messages — Note On/Off structure and Note On channel, note-number, and velocity fields.
- Apple Logic Pro User Guide — Note events — the stored note-event fields shown in Logic Pro, including channel, pitch, velocity, and length.
- Roland — TD-07 Owner's Manual / Data List — product-specific Retrigger Cancel, Mask Time, XTalk Cancel, and fast-playing cautions.
- Ableton — Push manual — Repeat behavior and repeated-note performance controls.
- Ableton Live 12 Manual — Instrument, Drum and Effect Racks — chain Receive notes and the possibility of one note reaching multiple chains.
- Apple Logic Pro User Guide — Turn off Local Control — Local Off as a routing method for external devices with internal sound generation.