Web MIDI API : permission et confidentialité des appareils

BotBrowser peut valider un flux Web MIDI autorisé lorsqu’un navigateur contrôlé expose navigator.requestMIDIAccess() et qu’une action déclarée démarre la demande. Il ne peut pas créer un instrument physique, choisir un port à la place de l’utilisateur, accorder une permission hors médiation du navigateur ni transformer le nom d’un port en propriété. Le contrat utile est visible : demander, afficher le résultat, valider chaque message, réconcilier les changements et conserver une voie sans MIDI.

TL;DR

Web MIDI donne accès aux ports d’entrée et de sortie après permission du navigateur. Il ne fournit ni inventaire matériel illimité ni identité stable d’un instrument. Détectez navigator.requestMIDIAccess, appelez depuis un contrôle explicite, demandez seulement la capacité nécessaire et traitez MIDIAccess comme une vue vivante. Écoutez statechange, validez MIDIMessageEvent.data et libérez les écouteurs quand un port disparaît.

La spécification W3C Web MIDI définit MIDIAccess, les ports, les changements d’état, les événements de message et l’accès optionnel à System Exclusive. MDN indique une prise en charge limitée. BotBrowser peut enregistrer les états visibles de permission et de port, mais ne prouve ni la présence physique d’un instrument ni sa propriété.

Sommaire

• La permission est une limite de capacité
• Demander depuis une action utilisateur
• Traiter les ports comme une session changeante
• Borner les messages MIDI
• Minimiser les métadonnées et garder un repli
• Table des résultats
• Tester avec BotBrowser
• Conclusion

La permission est une limite de capacité

navigator.requestMIDIAccess() demande une capacité gérée par le navigateur, pas l’ouverture de tous les appareils USB. Contexte sécurisé, activation, permission et support de plateforme peuvent être nécessaires. Un objet MIDIAccess résolu signifie que la surface a été exposée ; il ne garantit aucun port connecté ni autorisé pour une personne.

Demandez le périmètre minimal. Pour des notes et contrôleurs ordinaires, utilisez { sysex: false }. System Exclusive peut contenir des commandes constructeur et des séquences opaques ; il faut une décision séparée et une explication. N’activez pas sysex: true par simple commodité. Le guide Web USB : accès et confidentialité applique la même règle : une permission n’est pas un inventaire.

Les noms, fabricants et versions peuvent aider un sélecteur visible, mais ne prouvent ni propriété ni appareil unique. Conservez seulement granted, denied, unsupported ou no-port quand la tâche le nécessite. N’assemblez pas ce résultat avec réseau, écran et profil pour créer une étiquette durable.

Demander depuis une action utilisateur

Détectez la capacité au moment de l’usage. Un bouton « Connecter MIDI » peut rester désactivé si l’API manque. Appelez depuis un clic ou une touche, jamais au chargement, dans un minuteur ou après un fetch.

async function connectMidi() {
  if (!window.isSecureContext || !navigator.requestMIDIAccess) {
    return showMidiState('unsupported');
  }
  setMidiState('requesting');
  try {
    const access = await navigator.requestMIDIAccess({ sysex: false });
    attachMidiAccess(access);
    renderPorts(access);
  } catch (error) {
    setMidiState(classifyMidiError(error));
    showMidiFallback();
  }
}
connectButton.addEventListener('click', connectMidi);

requesting évite les sélecteurs doubles et donne un état accessible. En cas de rejet, classez seulement ce que la page sait : NotAllowedError, support absent ou délai local. Ne dites pas qu’un appareil nommé a refusé. Restaurez le contrôle et permettez une nouvelle action visible.

Le guide Web Bluetooth : permission et confidentialité présente un sélecteur comparable. Les protocoles diffèrent, mais il faut séparer API présente, accès accordé et appareil utilisable.

Traiter les ports comme une session changeante

MIDIAccess.inputs et MIDIAccess.outputs sont des cartes des ports exposés à cet instant. Écoutez statechange lors d’une connexion, déconnexion ou reconfiguration et redessinez toute la carte. Ne conservez pas d’anciennes lignes.

function attachMidiAccess(access) {
  access.onstatechange = event => {
    const port = event.port;
    renderPorts(access);
    if (port.state === 'disconnected') detachInput(port.id);
    if (port.state === 'connected' && port.type === 'input') attachInput(port);
  };
  for (const input of access.inputs.values()) attachInput(input);
  for (const output of access.outputs.values()) renderOutput(output);
}

Vérifiez port.state et port.connection juste avant l’usage et interceptez l’échec d’envoi. À la déconnexion, retirez l’écouteur et effacez l’état associé. Utilisez port.id seulement comme clé de session courte ; ne l’ajoutez pas à un profil ni à une empreinte. send() ne prouve pas qu’un son a été produit ou entendu.

Borner les messages MIDI

MIDIMessageEvent.data est une suite d’octets non fiable. Vérifiez longueur, octet de statut, canal et plage avant de modifier l’état. Une application peut accepter une liste plus petite que le protocole complet.

const MAX_MIDI_BYTES = 3;
const allowedStatus = new Set([0x80, 0x90, 0xb0, 0xe0]);
function acceptMidiMessage(event) {
  const bytes = [...event.data];
  if (bytes.length < 2 || bytes.length > MAX_MIDI_BYTES) return;
  const status = bytes[0] & 0xf0;
  if (!allowedStatus.has(status) || bytes.slice(1).some(byte => byte > 0x7f)) return;
  updateMusicState({ status, channel: bytes[0] & 0x0f, data: bytes.slice(1) });
}

Cet exemple ignore System Exclusive, realtime et messages système. Les activer est un changement de protocole avec limite de taille et documentation. Ne journalisez pas tous les octets par défaut et limitez les événements haute fréquence. Pour un diagnostic, capturez seulement une courte fenêtre explicitement demandée.

Minimiser les métadonnées et garder un repli

Un clavier virtuel, une importation de fichier, des raccourcis ou une partition maintiennent la tâche sans MIDI. La page doit dire que le navigateur n’a exposé aucun port, sans prétendre contrôler un instrument. Séparez le modèle musical de l’adaptateur : après déconnexion l’édition continue ; après une nouvelle connexion la sélection est explicite.

Un relevé court peut contenir support, permission, type et état du port, étiquette locale, compteur accepté et date. Il n’a pas besoin du fabricant complet, de la carte entière, des octets bruts ou de propriétés de navigateur sans rapport. Un nom de port peut révéler un modèle ou un studio ; définissez donc but et durée de conservation.

Table des résultats

Résultat observé	Action sûre	Ne pas affirmer
API absente ou contexte non sûr	Garder clavier ou fichier	Support universel
Permission refusée	Expliquer et conserver la tâche	Un appareil nommé a refusé
Accès sans ports	Afficher aide et repli	Aucun instrument physique n’existe
Entrée connectée	Installer un écouteur validé	Elle appartient à quelqu’un
Sortie connectée	Exiger le choix avant envoi	Un son a été produit
statechange déconnecte	Retirer l’écouteur, marquer hors ligne	Retour automatique
Octets invalides	Rejeter et classer	Identifier l’émetteur
SysEx demandé	Exiger une décision distincte	Données inoffensives par défaut

Tester avec BotBrowser

Un contexte contrôlé BotBrowser peut exécuter un bouton déterministe, un repli synthétique, un validateur borné et un relevé visible des ports. Enregistrez présence de l’API, résultat de permission, compteurs, événements statechange et visibilité du repli. unsupported, permission-denied et no-port sont valides si aucune lecture sonore n’est affirmée. La documentation des fonctions avancées ne garantit pas un appareil MIDI sur le runner.

{
  "api": "requestMIDIAccess",
  "permission": "unknown",
  "ports": { "inputs": 0, "outputs": 0 },
  "states": ["fallback"],
  "messagesAccepted": 0,
  "rawBytesRetained": false,
  "physicalInstrument": "not-asserted"
}

Répétez le fixture en changeant une variable : version, contexte sécurisé, permission, connexion ou type de message. Comparez la première divergence sans généraliser le résultat à chaque système ou pilote.

Conclusion

Web MIDI est une capacité médiée par permission et changeante. Demandez depuis une action visible, utilisez le périmètre minimal, affichez une carte vivante, validez les messages et libérez les écouteurs à la déconnexion. BotBrowser peut rejouer ces branches visibles dans des contextes autorisés ; il ne crée pas d’instrument, ne contourne pas la permission, ne garantit pas un port et n’infère pas la propriété depuis les métadonnées.

Sources publiques

• Web MIDI API, W3C
• Web MIDI API, MDN
• Fonctions avancées BotBrowser

À lire ensuite

Voir Web Bluetooth : permission et confidentialité et Web USB : accès et limites de confidentialité.