USB MIDI Drum Pad Not Detected? A Five-Gate Test

“Not detected” hides five different observations

Do not begin with “the pad does not work.” Record the narrowest observation you can actually see. USB host/device negotiation, MIDI discovery, app routing, raw event delivery, and audible response are different layers. Fixing a later layer cannot create evidence that an earlier one passed.

For directional MIDI 1.0 ports, Android's MIDI documentation makes one common source of confusion explicit: input/output is named from the MIDI device's point of view, not from the app's. An app receiving pad strikes therefore opens the controller's output port. A MIDI 2.0/UMP interface can expose bidirectional ports, so use the route labels shown by that utility and the device documentation rather than forcing the MIDI 1.0 rule onto it.

Freeze one evidence card before unplugging anything

Take a photo or make a short record of the original route, then transcribe the fields below. This prevents a successful cable swap from being mixed with an unrecorded app, preset, or power change.

Use one controller and one host during the gate sequence. Disconnect unrelated MIDI devices, disable note repeat and arpeggiation, and start with one raw monitor that can show device/port, event type, channel, note number or other message fields, and order. Close another client only when the platform explicitly reports the port as busy/in use or the app/device documentation requires it. Do not install an unofficial driver or grant broad system access merely because a search result says to do so.

G1 DOC: prove that the documentation describes this host–device path

USB needs complementary roles. Android's official overview distinguishes host mode, where the Android device acts as USB host and powers the bus, from accessory mode, where the external accessory is host; it also warns that host/accessory support ultimately depends on hardware. The USB-IF MIDI class specification likewise describes a USB MIDI device exposing interfaces that host software discovers and selects. A cable cannot turn two endpoints with incompatible roles into a working route.

1. Identify both roles from documentation: record which endpoint is the USB host and which is the peripheral/device for this exact route. A controller jack printed “TO HOST” describes where it connects; do not infer the controller's electrical role from that phrase alone.
2. Check the supported platform path: find the controller maker's instructions for the exact phone, tablet, or computer family. Record required adapters, a powered connection, an official driver, or an app-specific limitation.
3. Separate class support from universal compatibility: USB-IF defines a MIDI device class and compatibility mechanisms, but the host hardware, operating system, app, available power, and device implementation still participate. Treat “class compliant” as one documented fact, not as a promise that every cable, host, and app will work.

Yamaha's FGDP-30 guide is a useful concrete example, not a universal wiring recipe: it publishes different connection diagrams for Android and iOS, includes external power in its Lightning adapter path, and documents a Yamaha Steinberg USB driver for Windows while showing a direct documented Mac path. Use the equivalent page for your own device.

G2 LINK: prove a data path and the specified power condition together

Power and data are separate evidence columns. Apple documents that USB-C iPads can connect to MIDI devices and that an adapter may be needed for USB-A devices; that connection guidance is not a promise that every controller, cable, power condition, or app is compatible. A lit pad therefore remains only a power observation until a compatible device list discovers it.

• Cable identity: use the controller maker's supplied cable or a known data-capable replacement with the required connector and specification. Do not classify a cable by connector shape or charging success.
• Adapter path: compare every adapter and hub with the documented diagram. Record the exact port used; some docks expose charging, data, and host-facing ports with different functions.
• Power condition: use only the specified supply, powered adapter, hub, or controller battery condition. Record whether the controller starts, resets, dims, or disconnects when pads are struck.
• Stable reconnect: close the test app, disconnect the controller, restore the documented power order, reconnect once, reopen the monitor, and wait for the host's normal discovery interval. Do not hot-swap several links at once.

G2 passes only when the physical path matches the documentation and stays powered long enough to attempt enumeration. It does not pass because an LED appeared. If the exact manual path is unavailable or unsupported, record DOC and stop rather than buying adapters at random.

G3 ENUM: prove that the host or MIDI service discovered the physical device

Discovery is the boundary between a physical USB link and route activation. Android's MIDI API supports USB transport and exposes device enumeration plus plug/unplug notifications. Apple documents, for the specific example of Logic Pro for iPad, that connected physical Core MIDI devices appear in its MIDI Input Devices and Ports list and are then activated as sources separately. Use a platform-provided MIDI utility or a compatible app's documented device list; this guide does not assume that every operating system has a global MIDI browser. If the same app handles G3 and G4, G3 records the physical identity appearing and disappearing, while G4 records whether it is enabled as an input source.

1. Capture the absent state: with the controller disconnected, save the current device list.
2. Reconnect once: use the unchanged G2 path and capture the list again. Write the exact new name and transport if one appears.
3. Remove once: disconnect the controller and confirm that the same entity disappears. A static name that remains may be a virtual or remembered port rather than this physical pad.
4. Repeat once: reconnect without changing cable, power, preset, or app. Discovery should produce the same identity twice before you advance.

If no physical device appears in a documented compatible list, the failure is still before MIDI mapping. Return to G1/G2 and substitute one documented link. Do not change MIDI channel, note map, drum plug-in, or audio output; none of those settings makes a missing USB device appear.

G4 PORT: prove that one app enabled the controller-to-app route

Once the device identity consistently appears, use one MIDI monitor. Refresh its list after connection, select or activate the physical controller as a source, and record every logical port exactly as named. A user interface may label this “input to the app.” For directional MIDI 1.0 ports, verify the controller's sending/output port; for MIDI 2.0/UMP or a bidirectional port, follow the app and device labels.

G5 EVENT: capture one expected event, then measure repeatability

Clear the raw monitor. Choose a pad and preset documented—or already proven on a known-good host—to send Note On when struck. Make one deliberate contact. If this mode is documented to send another MIDI message instead, declare that exact expected type before the test. The first event attributed to the G4 physical source proves event delivery; the follow-up probe measures repeatability.

• Detection gate: one expected event appears from the physical device and route selected at G4; disconnecting that controller removes the source. Assign EVENT at this point.
• Repeatability baseline: if the maker provides a single-note preset with layering, chord output, and note repeat off, tap Pad A four times and Pad B four times, one intended contact per hit. Log received onset count, channel, note number and velocity; do not grade timing or dynamics.
• Composite-mode baseline: if every supported preset deliberately emits a layer, chord, CC set, or other event bundle, declare that expected event set and count before striking. Do not force the single-note 8/8 rule onto it.
• Count boundary: 8/8 supports a stable single-note baseline. A missing or extra onset does not revoke USB detection; preserve EVENT and route the count difference to pad response, preset, note-repeat, echo or mapping diagnosis.
• Replug return: close the monitor, disconnect and reconnect through the unchanged passing path, reopen it, select the same route, and capture at least one expected event again. Repeat the eight-hit baseline only when response stability is part of the question.

When an expected raw event returns after reconnect, the tested USB-MIDI path is detected and delivering controller data. If the optional baseline is not 8/8, use the 20-hit pad-response audit; do not relabel it “not detected.” If a drum instrument remains silent, move to the note-and-channel mapping audit. If sound responds but feels late, use the separate four-layer latency test.

Use an A0 → B → A1 substitution ladder, one link at a time

If a gate fails, preserve the original route as A0. Change one documented component or endpoint, call it B, rerun only up to the failed gate, then restore the original as A1. Prefer a component already proven with data, not merely one that charges another device.

Do not compare A0 and B after also updating firmware, switching presets, granting new permissions, changing hubs, and reopening a different app. That result has no single cause. Firmware and drivers are separate documented interventions; archive the before-state and rerun G1–G5 after either changes.

Keep a five-column ledger and assign only the first failed gate

USB MIDI drum-pad detection questions

The pad lights up. Does that prove the USB cable works?

No. It proves only that the observed power state occurred. Data conductors, host/device roles, enumeration, app access, and MIDI events remain separate gates. Require repeatable G3 enumeration before calling the cable a working data path.

Does USB-C on both ends guarantee compatibility?

No. Connector shape does not establish USB role, supported function, data capability, required driver, power availability, or app support. Use the exact controller and host documentation.

Does “class compliant” mean the pad works with every phone?

No. A USB MIDI class implementation can reduce dependence on a vendor-specific driver when the host supports it, but host hardware, operating-system support, roles, power, app access, and the device implementation still matter. Treat the maker's compatibility statement as scoped to the platforms it names.

Why can the app list my controller but receive nothing?

The route may not be activated, the wrong logical port may be selected, or the controller may be in a different USB/preset mode. For directional MIDI 1.0, record the device's sending/output port; for UMP or bidirectional interfaces, follow the documented route label. Close another client only if the platform explicitly reports busy/in use, then capture one expected raw event before changing note maps.

Will a powered hub always fix detection?

No. It can only address a compatible, documented path where power or path stability is the failed variable. It cannot supply a missing host role, driver, operating-system MIDI support, app port, or controller mode. Use a hub only when the device/host documentation supports it.

Raw Note On events arrive, but the instrument is silent. Is USB still broken?

The tested USB-MIDI input route has passed G5. Preserve that evidence and move downstream: compare note/channel mapping, receiver input, track monitoring, and audio output. Mixing those layers with USB enumeration creates unnecessary reconnects.

Does this guide mean FingerDrum supports an external USB MIDI pad?

No. This is a general USB-MIDI troubleshooting framework. It makes no claim that the FingerDrum app accepts, maps, records, or monitors external MIDI controllers.