Reply to thread

Message: [QUOTE="Bombastus, post: 90994, member: 2178"] Android supports MIDI over Bluetooth Low Energy through its platform MIDI framework when the phone provides BLE hardware support. That makes a wireless keyboard or controller usable without a USB cable, but Android still needs a compatible app to discover the device and open its MIDI ports. Simply seeing Bluetooth turned on is not enough. The setup makes more sense once you separate [B][URL='https://goldmidi.com/community/threads/what-is-midi-on-a-phone.23587/']wireless MIDI connections on a phone[/URL][/B] from ordinary Bluetooth accessories. A BLE MIDI controller sends performance and control messages, not the audio stream used by wireless headphones or speakers. Your music app receives those messages and decides what instrument, parameter, or function they control. That distinction also explains why Android pairing advice looks inconsistent across apps and keyboards. Some apps include their own Bluetooth MIDI picker, while others rely on a separate utility that connects the controller to Android's MIDI service first. Follow the method documented for the app you actually plan to use rather than assuming the system Bluetooth screen is always the right destination. [HEADING=2]Android apps often handle BLE MIDI discovery themselves[/HEADING] Android's MIDI API documentation expects an app to scan for Bluetooth LE MIDI devices and let the user connect to one. Once that connection is established through Android's MIDI service, compatible apps can expose the device as a MIDI input or output. Current pairing utilities use the same basic idea, connecting a BLE MIDI controller first so another MIDI-capable app can select it afterward. Permissions can stop that scan before MIDI enters the picture. Android 12 and later introduced Bluetooth scan and connect permissions within the Nearby devices permission group, while older app implementations may request location permission because Bluetooth discovery was historically tied to location access. If a pairing screen stays empty, checking the app's Nearby devices or requested Bluetooth permissions is more useful than repeatedly toggling the keyboard's MIDI channel. The controller also has to be advertising and available. Put it into its documented Bluetooth MIDI connection mode, keep it close during the first connection, and make sure another phone, tablet, or computer has not already grabbed it. Some BLE MIDI hardware stops waiting for a new host once an existing connection is active, so disconnecting the previous host can make an apparently missing controller reappear immediately. Do not assume that every product advertised as Bluetooth supports MIDI. A keyboard may offer Bluetooth audio for playing music through its speakers without providing Bluetooth MIDI control in the opposite direction. Look specifically for BLE MIDI, Bluetooth MIDI, or a manufacturer statement that the instrument can transmit or receive MIDI wirelessly. [HEADING=2]Bluetooth MIDI and Bluetooth audio create different delays[/HEADING] A successful MIDI connection can feel quick while the resulting sound still arrives late. The controller sends note data to the Android app, the app generates or routes the sound, and the phone then has to deliver that audio through its chosen output. Those are separate stages, so delay after a key press does not automatically identify BLE MIDI as the problem. This becomes obvious with Bluetooth headphones or speakers. Even when the [B]low-latency BLE MIDI path[/B] is behaving well, the audio output has its own buffering and wireless transport. Playing through the phone's wired output, built-in speaker, or a suitably low-latency audio interface can therefore feel tighter without changing the MIDI controller connection at all. The same diagnostic split helps with soft synths. If an app visibly reacts to note presses immediately but the sound trails behind, the MIDI messages are already reaching the software. Audio buffer size, the instrument engine, processing load, and the output device become better places to investigate than pairing the keyboard again. [HEADING=2]Stable timing depends on the whole BLE link[/HEADING] BLE MIDI uses timestamps so receiving software can preserve event timing more accurately even though Bluetooth packets do not arrive as a perfectly continuous stream. Android's compatibility guidance also calls for devices to minimize MIDI latency and latency variation across transports and to provide accurate MIDI timestamps. That does not make every phone and controller combination perform identically. The Bluetooth connection interval, controller implementation, phone hardware, operating system, and app behavior can all influence how quickly messages move through the link. Dense controller data can be harder on a wireless path than an occasional note because pitch bend, continuous controllers, aftertouch, and other messages may create much more traffic. USB remains the cleaner comparison when you need to determine whether a timing problem belongs to the wireless transport. Repeated disconnects deserve a different check from steady latency. Confirm that the controller is not reconnecting to another remembered host, then review the Android app's background and battery restrictions if failures appear mainly when the screen sleeps or the app leaves the foreground. Reconnecting from the same MIDI-aware picker or pairing utility you used initially is usually more reliable than creating several competing Bluetooth connections in different apps. [/QUOTE]

Name