CommunitySchreiben & Editierengithub.com

Hardware-Protokoll-Erfassung

Verwenden Sie dies, um zu dokumentieren, wie ein Musik-Hardware-Gerät über MIDI (CC, NRPN, SysEx) oder USB gesteuert wird, sodass ein Controller, Editor oder Librarian erstellt werden kann: Offizielle Dokumente finden, Datenverkehr vom eigenen Gerät erfassen, Patch-Dumps dekodieren und ein verifiziertes MIDI-Implementierungsdokument schreiben.

Was ist Hardware-Protokoll-Erfassung?

Diese Fähigkeit (Skill) ist ein Leitfaden für Entwickler, um die Steuerungsprotokolle von Musik-Hardware wie Synthesizern, Drummachines oder Effektgeräten zu dokumentieren. Sie beschreibt einen systematischen, hardwarebasierten Ansatz: Finden offizieller Dokumente, Erfassen von MIDI- und USB-Datenverkehr vom eigenen Gerät, Dekodieren von SysEx-Dumps und Erstellen einer verifizierten MIDI-Implementierungstabelle. Der Skill betont, dass das reale Gerät die alleinige Quelle der Wahrheit ist; Dokumente können fehlerhaft oder veraltet sein. Er unterstützt Linux (amidi, aseqdump, usbmon), Windows (MIDI-OX, USBPcap) und macOS (Snoize MIDI Monitor, XHC20). Rechtliche Aspekte werden beachtet: Kein Reverse-Engineering von Software oder Veröffentlichung geschützter Inhalte. Der Output ist eine strukturierte Markdown-Datei (MIDI-IMPLEMENTATION.md) mit Statusangaben für jeden Befehl, die als Grundlage für die Entwicklung von Controllern, Editoren oder Librarians dient.

Funktioniert mit✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/SpeakingColors/claude-skills/tree/HEAD/skills/hardware-protocol-capture

Installed? Explore more Schreiben & Editieren skills: steipete/notion, langchain-ai/langchain, bytedance/podcast-generation · View all 6 →

In Ihrer bevorzugten KI fragen

Öffnet einen neuen Chat, in dem dieser Agent-Skill bereits geladen ist.

Dokumentation

Was macht Hardware-Protokoll-Erfassung?

Inoffizieller Community-Skill. Keine Rechtsberatung. Erfassen Sie nur Geräte, die dem Benutzer gehören.

0. Regeln

  • Das Gerät ist die Quelle der Wahrheit. Dokumente können falsch oder veraltet sein; eine Erfassung vom echten Gerät mit der Firmware des Benutzers ist der Beweis.
  • Quellen-Reihenfolge: 1) offizielle Dokumente des Herstellers, 2) Erfassungen von der eigenen Hardware des Benutzers, 3) Dokumente Dritter (als unverifiziert kennzeichnen, bis sie an der Hardware überprüft wurden).
  • Jeder Eintrag im endgültigen Dokument trägt einen Status: an Hardware verifiziert, nur aus offiziellem Dokument oder unverifiziert.
  • Sichern Sie die Patches und Einstellungen des Geräts, bevor Sie etwas Unbekanntes senden. Senden Sie niemals Firmware, Bootloader, Flash-Schreib- oder Werksreset-Nachrichten, bis deren Format vollständig verstanden ist.
  • Geben Sie Nicht-Programmierern nur einen Schritt nach dem anderen. Zuerst kurze Antworten.

1. Offizielle Dokumente finden

  • Suchen Sie auf der Support-Seite des Herstellers nach einem „MIDI Implementation“- oder „MIDI data format“-Dokument für das Produkt sowie nach der MIDI-Implementierungstabelle im Handbuch. Beispiel: KORG veröffentlicht die MIDI-Implementierung des minilogue xd als separate Textdatei (Download nach Annahme einer persönlichen, nicht-kommerziellen Lizenz). Verlinken Sie auf solche Dokumente; kopieren Sie sie nicht in öffentliche Repos, es sei denn, ihre Lizenz erlaubt dies.
  • Überprüfen Sie Revision und Datum des Dokuments mit der Firmware-Version des Geräts. Firmware-Updates können Formate ändern. Beispiel: Eine Drittanbieter-Bibliothek für diesen Synthesizer stellt fest, dass einige Preset-Dateien neuerer Firmware 448-Byte-Programm-Blobs verwenden, nicht das 1024-Byte-Format, das die Spezifikation beschreibt (V: oxur/minilogue-xd README). Testen Sie immer einen Dump von der tatsächlichen Firmware des Benutzers.
  • Community-Listen (wie midi.guide, CC BY-SA 4.0) sind nützliche Ausgangspunkte. Behalten Sie deren Lizenz und Quellenangabe bei und überprüfen Sie Einträge.

2. MIDI erfassen (klassenkonformes USB-MIDI und DIN-MIDI)

Werkzeuge nach System (prüfen, ob jedes installiert oder installierbar ist):

  • Linux: amidi und aseqdump (ALSA-Utils) für rohe Ports und Sequencer-Ereignisse; receivemidi und sendmidi sind plattformübergreifende Befehlszeilenwerkzeuge.
  • Windows: MIDI-OX oder ein ähnlicher Monitor.
  • macOS: Snoize MIDI Monitor oder ähnlich.

Methode:

  1. Nehmen Sie eine Basislinie auf: Schließen Sie das Gerät an, starten Sie den Monitor, berühren Sie nichts.
  2. Ändern Sie jeweils ein Bedienelement. Notieren Sie die Nachricht, bewegen Sie dann das Bedienelement auf seinen Minimal-, Mittel- und Maximalwert und notieren Sie jeden.
  3. Notieren Sie die Richtung: Gerät zu Host (Drehregler bewegt) und Host zu Gerät (Nachricht an das Gerät gesendet). Testen Sie beide.
  4. Testen Sie das Gerät in verschiedenen Modi (global versus Teil, Layer, Sequenzer, Motion), da dasselbe Bedienelement unterschiedliche Nachrichten senden kann.
  5. Schreiben Sie eine Tabelle: Bedienelement, Nachrichtentyp, CC- oder NRPN-Nummer oder SysEx-Bytes, min, max, Auflösung (7-Bit oder 14-Bit), Richtung, Kanalbehandlung, Status.

Request-and-Dump SysEx:

  • Verwenden Sie den dokumentierten Dump-Request, empfangen Sie den Dump in eine Datei, ändern Sie dann genau einen Parameter auf dem Gerät, dumpen Sie erneut und vergleichen Sie die beiden Dateien. Die geänderten Bytes zeigen, wo dieser Parameter lebt.
  • Überprüfen Sie die SysEx-Hülle: beginnt mit F0, Hersteller-ID, Geräte- oder Modell-IDs, endet mit F7. Notieren Sie die Hersteller-ID-Bytes.
  • Viele Geräte packen 8-Bit-Daten in 7-Bit-SysEx-Bytes. Finden Sie die Packungsregel im offiziellen Dokument (z. B. ist KORGs 7-Bit-zu-8-Bit-Codec in seiner Spezifikation aufgeführt) und dekodieren Sie vor dem Vergleichen.
  • Finden und verifizieren Sie eine etwaige Prüfsumme, indem Sie einen Parameter ändern und neu berechnen. Raten Sie nicht; testen Sie gegen Dumps vom Gerät.

3. USB erfassen (nicht klassenkonforme Geräte, Hersteller-Apps)

Erforderlich, wenn ein Gerät einen herstellereigenen Treiber oder benutzerdefinierte USB-Steuernachrichten verwendet (z. B. einige Audio-Interface-Mixer) und kein MIDI-Port die Daten trägt.

  • Wireshark zeichnet USB-URBs auf, die Übertragungen sind, wie der Host-Stack sie sieht, nicht einzelne USB-Pakete; rohe Pakete benötigen einen Hardware-Sniffer (V: Wireshark-Wiki, USB-Erfassungseinrichtung).
  • Linux: sudo modprobe usbmon, falls es keine /dev/usbmon*-Geräte gibt; Erfassung auf usbmonN für Bus N oder usbmon0 für alle Busse; der Benutzer muss die usbmon-Geräte lesen können (Gruppe, udev-Regel oder ACL) (V).
  • Windows: USBPcap verwenden (V). Frühere Probleme umfassten blockierte Maus- oder Tastatureingaben; vor der Installation das Wiki überprüfen.
  • macOS: Erfassung verwendet Schnittstelle XHC20 nach sudo ifconfig XHC20 up; das Wiki sagt, dass System Integrity Protection anscheinend auf Catalina und neuer deaktiviert werden muss (V). Bevorzugen Sie nach Möglichkeit ein anderes System.
  • Erfassen Sie die Kommunikation der herstellereigenen App mit dem Gerät des Benutzers, z. B. von einem Windows-Gast in einer virtuellen Maschine mit durchgereichtem Gerät, während ein Linux-Host auf dem passenden Bus erfasst (V: Methode beschrieben im Wireshark-Wiki).
  • Wenden Sie dieselbe Disziplin „eine Änderung nach der anderen“ an: Führen Sie eine Aktion in der Hersteller-App aus, erfassen Sie sie, markieren Sie sie im Protokoll.
  • Dekodieren Sie Kontrolltransfers (Request-Typ, Request, Wert, Index, Daten) in eine Tabelle. Wiederholen Sie jede Aktion, um zu bestätigen, dass die Bytes stabil sind.

4. Erlaubt und nicht erlaubt

  • Das Beobachten der Nachrichten, die ein Programm an das eigene Gerät des Benutzers sendet, und das Lesen offizieller Dokumentationen ist die normale Art, ein Protokoll zu lernen.
  • Dekompilieren oder disassemblieren Sie keine Software anderer und kopieren Sie nicht deren Code, Grafiken, Datentabellen oder Presets. Einige Gesetze erlauben eingeschränktes Reverse Engineering für Interoperabilität, aber Lizenzvereinbarungen können dies verbieten, und die Regeln variieren je nach Land. Erfassung auf Drahtebene liefert dieselben Fakten ohne diese Frage.
  • Veröffentlichen Sie keine Herstellerdokumente, Werkseinstellungen, Firmware oder Logos. Verlinken Sie darauf.
  • Verwenden Sie Erfassungen nicht, um Kopierschutz oder Lizenzierung zu umgehen.

5. Das MIDI-Implementierungsdokument schreiben

Verwenden Sie docs/MIDI-IMPLEMENTATION.md im Projekt-Repo:

  • Kopfzeile: Gerät, getestete Firmware-Version, Datum, Quellen (offizieller Dokumenttitel, Revision und Link; Erfassungseinrichtung).
  • Globale Konventionen: Kanal, Byte-Reihenfolge, 7-Bit-Packung, Prüfsummenmethode.
  • Tabelle der Bedienelemente: Name, Nachricht, Bereich, Auflösung, Richtung, Notizen, Status (an Hardware verifiziert, nur offiziell, unverifiziert).
  • SysEx-Abschnitt: Request-Formate, Dump-Formate mit Byte-Offsets, Dekodierungsmethode, Prüfsumme, Beispiele (kurzes Hex) vom eigenen Gerät des Benutzers.
  • Bekannte Eigenarten und Konflikte (z. B. zwei Dokumente, die sich über eine CC-Nummer uneinig sind), mit Auflösung.
  • Eine Test-Checkliste, die der Benutzer bei neuer Firmware wiederholen kann.

6. Sicherheitsprüfungen, bevor der Controller etwas sendet

  • Senden Sie nur Nachrichten, die in der Tabelle als verifiziert oder dokumentiert eingetragen sind.
  • Begrenzen Sie die Ausgabe und teilen Sie sie in Blöcke auf; einige Geräte verwerfen Nachrichten bei Überflutung.
  • Senden Sie niemals automatisch beim Start; lesen Sie zuerst, senden Sie nur auf Benutzeraktion.
  • Halten Sie eine Schaltfläche „Aus Backup wiederherstellen“ neben jeder Schreibfunktion bereit.

Quellen

Individual skills in this repo

This repo contains 2 individual skills — each has its own dedicated page.

Verwandte Skills