MIDI drum pads · velocity · aftertouch
Velocity vs Aftertouch on MIDI Drum Pads: A Two-Pad Test
A louder hit does not prove aftertouch, and a silent pressure gesture does not prove that no pressure message was sent. Read the raw MIDI stream first. This four-stage probe uses two pads to separate onset velocity from pressure after the strike, distinguish note-specific Polyphonic Key Pressure from channel-wide Channel Pressure, and follow the evidence through recording, storage, replay, and one controlled receiver mapping.
Scope: this is a MIDI 1.0 raw-message probe for two drum pads that send distinct note numbers. It tests a quick strike, pressure while a pad remains held, two-pad message scope, and record/store/replay preservation. It does not measure pad force, acoustic loudness, latency, or sound quality; a value from 0 to 127 is MIDI data, not decibels. A controller that sends no aftertouch is not automatically defective, and an audible change still requires a receiver that supports and maps the incoming message. Control Change is a different raw message type; MPE is a channel-allocation context that can carry ordinary messages such as Channel Pressure on member channels, so this test records route context and raw type separately. This article does not claim that FingerDrum transmits, records, maps, or responds to aftertouch. P0–P3, the evidence ledger, result codes, receiver A/B, and stopping rule are the FingerDrum Editorial Team's test framework synthesized from the cited sources.
Open a raw MIDI monitor that shows message type, channel, note number when present, value, and order. Run P0 quick taps, P1 one-pad hold-and-press, P2 two-pad scope changes, and P3 record/store/replay. A positive-velocity Note On belongs to the onset. Polyphonic Key Pressure carries a note number; Channel Pressure does not. Do not use the sound alone to classify the sender, because the receiver may ignore, filter, remap, or audibly transform the same messages.
Velocity, Polyphonic Key Pressure, and Channel Pressure carry different evidence
The MIDI Association places Note On, Polyphonic Key Pressure, Channel Pressure, and Control Change in the Channel Voice family, but their payloads are not interchangeable. The Association describes Note On as carrying channel, key number, and velocity for the initial activation. Polyphonic Key Pressure carries a key number plus pressure, while Channel Pressure carries one pressure value for the channel and no key number. Apple labels the latter “aftertouch” in Logic Pro and shows its Number field as unused; Logic's separate poly-aftertouch event retains the MIDI note name.
| Observed data | When it describes the gesture | What its scope can identify | What it cannot prove |
|---|---|---|---|
Note On: channel, note number, velocity | The initial pad strike in this test | Which note began and its onset velocity value | Pressure applied later, acoustic dB, or the receiver's loudness curve |
Polyphonic Key Pressure: channel, note number, pressure | Pressure changes after the note has begun | The pressured note on that channel | Which audio parameter will change, or whether the receiver supports it |
Channel Pressure: channel, pressure | A pressure value for the current MIDI channel | The channel only; there is no note-number field | Which held pad caused the value when several notes share the channel |
Control Change: channel, controller number, value | A controller-specific continuous-control route | The named CC on a channel | Polyphonic Key Pressure or Channel Pressure merely because a pressure gesture produced it |
Known MPE-member route plus its actual Channel Pressure, CC, Pitch Bend, or other event | An MPE-configured performance path | The raw event type and the member channel assigned to one note | That “MPE” is a fifth raw message type; it is routing context |
Ableton's Push manual makes the practical separation visible: its Expression settings offer MPE, Poly Aftertouch, and Mono Aftertouch as different modes, while its Sensitivity settings separately shape incoming note velocity. Yamaha likewise documents separate output, fixed-value, curve, minimum, and maximum controls for Note On velocity and aftertouch, plus a choice between Channel and Poly aftertouch. Hardware labels therefore do not replace a message capture.
Build one direct, observable path before listening to a drum sound
- Use a raw monitor first: connect the controller through the shortest practical MIDI or USB-MIDI route to a monitor that exposes event type, channel, note number, value, timestamp or order, and input port. Turn the receiver's audio down or bypass it for P0–P3.
- Name two pads: choose Pad A and Pad B with different note numbers. Confirm their messages rather than relying on printed pad labels; the one-hit mapping audit gives a separate procedure if their identities are not stable.
- Hold the channel constant: for the classic P2 comparison, use two notes on the same ordinary MIDI channel. If a documented MPE configuration deliberately assigns member channels, mark the route
MPE-member, record the actual event type separately, and exit the ordinary same-channel P2 comparison. - Record the controller state: write the preset, pad bank, velocity curve, fixed-velocity state, aftertouch output setting, pressure type, and threshold if exposed. Disable note repeat, arpeggiation, MIDI effects, input transforms, and duplicated routes. A fixed onset is a separate question covered by the fixed-velocity audit.
- Prevent echo: monitor one physical input only, turn MIDI Thru or local echo off where it would return events to the input, and clear the event list before every pass. Unexpected duplicate Note Ons make pressure evidence ambiguous.
- Use comfortable force: test only within the manufacturer's normal playing guidance. The goal is a repeatable message pattern, not the largest possible value.
Save a screenshot or text export of each raw list if the monitor permits it, but do not merge passes. “The sound got brighter” is an audio observation; “Polyphonic Key Pressure, channel 10, note 38, values changed while note 38 remained held” is message evidence. Keep them in separate columns.
P0: use quick taps to establish the onset-velocity baseline
Clear the monitor. Tap Pad A once and release it without deliberately pressing farther after the strike. Repeat with four comfortable taps that span light to firm playing, then do the same on Pad B. Preserve the event order for each isolated tap.
| P0 observation | Record | Interpretation | Do not conclude |
|---|---|---|---|
| One Note On and its release for each tap | Channel, note number, onset velocity, release event, order | Basic pad identity and onset path are visible | That pressure after the onset is supported |
| Velocity values differ across taps | The raw values, not “soft/loud” alone | The current path is not forcing one observed onset value | That values are linear force, amplitude, or dB |
| Every onset velocity is the same | Value plus fixed/curve settings | A fixed or compressed onset path is possible | That aftertouch is also fixed or absent |
| A pressure message also appears | Its exact type, channel, note field, and position after Note On | The quick tap crossed the device's pressure threshold or lingered long enough to report it | That the event should be discarded because this was “only” P0 |
| Extra Note Ons appear without extra taps | Input port, channel, note, and timestamp/order | Retrigger, MIDI echo, note repeat, or another route must be isolated | That later pressure events can be trusted yet |
P0 is not a calibration contest. If onset values bunch together, finish this protocol with the setting documented, then use the dedicated 20-hit velocity calibration to investigate response consistency.
P1: strike once, keep one pad held, then change pressure
Clear the monitor. Strike Pad A once, keep the finger on the pad, increase pressure smoothly, ease it back without lifting, and then release. Do not make a second impact. Repeat the gesture four times, then run four equivalent passes on Pad B.
- Onset gate: exactly one intended Note On starts the gesture. If further pressure creates another Note On, mark
RTRGand solve that before treating the stream as continuous pressure. - Order gate: any pressure events must be logged after the onset and before or around release in the order actually received; do not sort the list by value.
- Type gate: write
PPAonly for Polyphonic Key Pressure andCPAonly for Channel Pressure. A CC or other raw expression stream isALT, not “close enough” aftertouch. RecordMPE-memberseparately as route context, never as the event type. - Identity gate: a PPA event should expose the note number in the raw record. A CPA event has no note-number field, even if the monitor's interface visually associates it with the last-played pad.
- Absence gate: if no pressure-type event appears, write
NONE. Check the manual, output toggle, selected mode, and threshold once; absence is not automatically a hardware fault.
Yamaha's FGDP-30 guide is a useful example of why the settings record matters: aftertouch transmission can be switched off, its message type can be Channel or Poly, and its curve, fixed value, minimum, and maximum are configured separately from Note On velocity. That does not imply another controller has the same controls; it shows why an undocumented preset is insufficient evidence.
P2: two held pads reveal whether the message identifies a note or only a channel
Use Pad A and Pad B on the same ordinary MIDI channel. Strike and hold A, then strike and hold B. Keep B steady while changing pressure on A; then keep A steady while changing pressure on B. Finally release both. Run four passes in total, alternating which pad is struck first.
| Repeated P2 evidence | Classification | Scope statement you may make | Remaining limit |
|---|---|---|---|
| Pressure events carry A's note number when A changes and B's when B changes | PPA | The raw Polyphonic Key Pressure events identify the affected note | The receiver can still ignore or map both notes identically |
| Pressure events carry only the shared channel and a value | CPA | The raw event is Channel Pressure and does not name A or B | The log alone cannot attribute a value to one held note |
| Pressure-like changes arrive as CC number and value | ALT | The controller sent Control Change on that route | Its musical target is receiver- and mapping-dependent |
| Held notes occupy different member channels in a documented MPE configuration | Actual raw code plus MPE-member route tag | For example, Channel Pressure remains CPA, while the member channel can make it per-note in that MPE zone | Channel separation alone does not prove Polyphonic Key Pressure |
| No pressure or alternate expression events repeat after settings are checked | NONE | No pressure message was observed in this controlled route and configuration | The result does not prove a defect or describe every preset, port, or mode |
Channel Pressure can affect all active notes on an ordinary shared channel when a receiver maps it that way, but the MIDI message itself only supplies channel and pressure. In MPE, assigning one note to each member channel can give that same Channel Pressure event per-note meaning. That route is outside this same-channel P2 comparison, but the raw event is still classified CPA; MPE-member is recorded beside it as context.
P3: follow the same events through record, storage, and replay
A live-input monitor proves only what reached that monitor. P3 asks three different questions: did the recorder receive the event, did the clip or file retain its type and fields, and did playback emit it again?
- Record one known pass: capture the complete P2 gesture into an otherwise empty MIDI region or sequence. Keep input transforms, retrospective merging, quantization, and MIDI effects off.
- Inspect before playback: open the recorder's event list. Compare event count, order, channel, note number where applicable, and value with the live P2 capture. Apple documents separate Logic event types for aftertouch and poly aftertouch, including the unused note-number field for channel aftertouch and the retained note field for poly aftertouch.
- Store and reopen: save the project or a duplicate test file, then reopen the stored region if the workflow allows it. Do not overwrite the raw P2 export. Confirm that the same pressure event type and fields remain.
- Replay to a second monitor: take your hands off the controller, disable the live input route, and play the stored region to an output monitor. A replayed event must come from the stored path, not a doubled live-thru path.
- Compare four columns: mark live input, recorded event list, reopened storage, and replay output separately. One checkmark cannot stand in for all four.
If pressure exists live but not in the recorded list, or appears in that list but is missing after the saved copy is reopened, use CAP and inspect record filters, event support, or persistence. If the reopened event is present but absent from output, use OUT and inspect playback filters or routing. This is the same reason that choosing between MIDI evidence and audio evidence matters: an audio waveform cannot preserve the original MIDI message fields for later inspection.
A controlled receiver A/B separates message delivery from audible response
Only run this comparison after P3 shows a repeatable PPA or CPA event through replay. Use the stored performance so Note On velocity, timing, and pressure values are identical in both conditions. Monitor at a conservative level.
| Condition | Keep fixed | Change | Question answered |
|---|---|---|---|
| Receiver A — neutral | Stored MIDI clip, route, patch, level, notes, and velocities | No destination intentionally mapped to the tested pressure type | What does the patch do without a deliberate pressure mapping? |
| Receiver B — mapped | The same clip, route, base patch, level, notes, and velocities | Map the exact observed PPA or CPA type to one modest, reversible parameter | Can this receiver audibly respond when the correct message is supported and mapped? |
If the output monitor receives pressure in both conditions but only B changes, the transmitter and replay path were not the cause of A's silence. If neither changes while the messages arrive, investigate receiver support, message-type selection, and mapping before blaming the pad. If the receiver changes without the tested pressure message arriving, inspect velocity response, envelopes, MPE, CC, automation, and duplicated routing. Even when B changes amplitude, a MIDI value of 127 is not 127 dB and does not predict a fixed acoustic level.
Keep one evidence ledger, assign result codes, and stop at the first unresolved layer
Do not summarize the session as “aftertouch works.” State what message was observed, its scope, whether it survived storage and replay, and whether one controlled mapping produced an audible response. Replace the illustrative values below with your own raw evidence.
| Stage / gesture | Live raw input | Recorded event list | Reopened storage | Replay output | Receiver A / B | Code |
|---|---|---|---|---|---|---|
| P0 / Pad A quick tap | Note On ch10 note36 vel42, then release | — | — | — | Not tested | VEL |
| P1 / hold A, press farther | Poly Pressure ch10 note36 18→75 | Present | Present | Present | Same / changed | PPA |
| P2 / A and B held | Channel Pressure ch10 35→92; no note field | Present | Present | Absent | Not reached | CPA+OUT |
| P1 / press creates another onset | Second Note On without a second intended strike | Not tested | Not tested | Not tested | Not tested | RTRG |
| P1–P2 / checked direct path | No PPA, CPA, CC, or other pressure-related raw event observed | Not applicable | Not applicable | Not applicable | Not applicable | NONE |
| Code | Evidence statement | Next controlled action |
|---|---|---|
VEL | Note On onset velocity was observed | Continue to P1; do not rename velocity as aftertouch |
PPA | Polyphonic Key Pressure with note number was observed | Use P2 to verify note-specific messages, then P3 |
CPA | Channel Pressure with no note number was observed | Use P2 to document shared-channel scope, then P3 |
ALT | CC or another non-PPA/non-CPA expression message was observed | Preserve its exact type; add an MPE route tag separately when applicable |
NONE | No pressure stream repeated after route and settings checks | Document the configuration; do not label the device faulty without separate evidence |
RTRG | Pressure movement generated an unintended new Note On | Isolate retrigger, threshold, note repeat, or MIDI echo before continuing |
CAP | Live pressure was absent from the recorded list, or a recorded event was missing after reopen | Inspect record filters, event support, and persistence |
OUT | The pressure event was stored but not emitted on replay | Inspect playback filters, output routing, and the output monitor |
MAP | The correct message reached the receiver but the intended response was not mapped or supported | Configure one exact receiver destination, then repeat A/B |
PASS | Type, scope, storage, replay, and receiver response are all accounted for | Archive the ledger with preset and route details |
Codes can be combined when they describe different layers: CPA+OUT, for example, means the raw type was Channel Pressure and the first failed downstream layer was replay output. Never combine codes to hide an unresolved event type.
Velocity and aftertouch questions for drum-pad testing
Is velocity just the first aftertouch value?
No. In this MIDI 1.0 test, Note On velocity is part of the note's onset message. Aftertouch arrives as later pressure data: either Polyphonic Key Pressure with a note number or Channel Pressure without one. Preserve the event types instead of combining their numeric values.
Does poly aftertouch guarantee that only one drum sound will change?
No. The message identifies a note, but the receiver decides whether it supports the message and what it controls. A plug-in could ignore it, map several notes to the same parameter, or use it for filter, pitch, amplitude, an effect, or another destination.
Why can I see aftertouch but hear no change?
The monitor proves message arrival, not receiver mapping. Run the same stored performance through neutral Receiver A and deliberately mapped Receiver B. If B still does not respond, check whether it supports the exact PPA or CPA type and whether any filter removes it.
Does no aftertouch mean my pad is broken?
No. The controller may not implement pressure after the strike, the current preset or port may disable it, the threshold may not be crossed, or the route may filter it. Report NONE for the tested configuration; a fault diagnosis requires separate device-specific evidence.
Is MPE the same as polyphonic aftertouch?
No. MPE is a performance and channel-allocation method, not a raw Channel Voice message. A member channel may carry ordinary Channel Pressure, CC, or Pitch Bend for its assigned note. Record the exact event first and add the MPE member-channel context separately; per-note behavior alone does not prove Polyphonic Key Pressure.
Can a pressure gesture be sent as a CC instead?
A controller can expose expressive data through a Control Change route, but CC carries a controller number and value and remains a different message type. Record it as ALT, preserve the CC number, and test its documented mapping separately.
Does 127 mean maximum volume?
It is the top value in the 7-bit field shown by these MIDI event views, not a sound-pressure measurement. The receiver's instrument, velocity curve, pressure mapping, gain staging, amplifier, speakers or headphones, and listening position determine the audible result. It is never “127 dB” by definition.
Branch after P1/P2. If a direct route and documented settings repeatedly produce NONE, record that bounded result and stop; there is no pressure event to store or map. If the result is ALT, or a documented MPE-member route exits the ordinary same-channel P2, preserve the exact event and continue only with its protocol-specific audit. Only repeatable ordinary-route PPA or CPA proceeds through P3 and receiver A/B. On that branch, stop successfully when live, recorded, reopened, replayed, and receiver evidence all agree; stop earlier at RTRG, CAP, OUT, or MAP and repair only the first failed layer.
Sources and access dates
These official sources support the MIDI 1.0 message-field distinctions, the separation of onset velocity from later pressure, MPE member-channel allocation, device-level independence of velocity and aftertouch settings, Push expression-mode differences, and Logic's stored aftertouch event fields. They do not prescribe the P0–P3 sequence, two-pad gesture order, evidence ledger, result codes, receiver A/B, gates, or stopping rule; those are FingerDrum's original synthesis.
- The MIDI Association — About MIDI, Part 3: MIDI Messages (accessed October 13, 2026)
- The MIDI Association — MIDI Polyphonic Expression Specification Adopted (accessed October 13, 2026)
- Yamaha FGDP-30 User Guide — Trigger settings, Note On, and MIDI Aftertouch (accessed October 13, 2026)
- Ableton Push 3 Manual — Expression and Sensitivity settings (accessed October 13, 2026)
- Apple Logic Pro User Guide — Aftertouch events (accessed October 13, 2026)
- Apple Logic Pro User Guide — Poly aftertouch events (accessed October 13, 2026)