@djodjonx/x32-simulator 0.0.1

package/docs/OSC-Communication.md

@@ -0,0 +1,184 @@
+# Protocol Analysis and Implementation Strategies regarding the Behringer X32 Digital Mixing Console Ecosystem
+
+## 1. Introduction to Networked Audio Control Systems
+The transition from analog to digital mixing consoles has fundamentally altered the landscape of live sound reinforcement, studio recording, and broadcast audio. Among the myriad devices that have driven this paradigm shift, the **Behringer X32** and **Midas M32** families of digital consoles stand as preeminent examples of commercial success and technical ubiquity.
+
+A central feature of these ecosystems is their capability for remote control and telemetry via standard network protocols. Unlike their analog predecessors, which relied on voltage-controlled amplifiers and physical patching, modern digital consoles operate as sophisticated computers that process audio signals via **Digital Signal Processing (DSP)** algorithms. This architecture allows the control surface—the physical faders, knobs, and buttons—to be decoupled from the audio processing engine. Consequently, the manipulation of audio parameters can be achieved not only through the physical interface but also via external software applications and automated scripts communicating over a Local Area Network (LAN).
+
+The mechanism governing this external communication is the **Open Sound Control (OSC)** protocol. Optimized for modern networking technology, OSC provides a flexible, URL-style symbolic naming scheme (e.g., `/ch/01/mix/fader`) that is significantly more human-readable and granular than the legacy MIDI standard.
+
+For the X32 ecosystem, this protocol facilitates the operation of:
+* The official **X32-Edit** software (PC/Mac/Linux)
+* The **X32-Mix** app (iPad)
+* The **Mixing Station** app (Android)
+* A host of third-party integration tools
+
+---
+
+## 2. The Documentation Landscape
+A critical challenge for developers and integrators working with the X32 platform is the scarcity and incompleteness of official documentation provided by the manufacturer, Music Tribe. While Behringer released a preliminary OSC document in late 2012 (Version 1.01), it has not been officially updated to reflect substantial feature additions (Firmware 2.x, 3.x, and 4.x), such as new effects engines, extended routing options, and the "User" layer.
+
+### 2.1 The "Unofficial" Standard
+To bridge this information gap, the user community—spearheaded by researcher and developer Patrick-Gilles Maillot—undertook a massive effort to reverse-engineer the complete protocol. The resulting document, **"Unofficial X32/M32 OSC Remote Protocol,"** is widely regarded as the definitive technical reference.
+
+> **Note:** This documentation distinguishes itself by detailing data types, value ranges, and context-dependent behaviors of the network stack, such as the critical distinction between the `/subscribe` command and the `/xremote` command.
+
+The documentation is maintained in a live repository, covering nuanced differences between hardware models (X32 Rack, Core, Compact) which share a common firmware core but report different hardware identifiers.
+
+---
+
+## 3. Network Transport and Architecture
+The foundation of the X32’s remote control capability is the **User Datagram Protocol (UDP)**.
+
+### 3.1 UDP vs. TCP in Audio Control
+TCP is connection-oriented, guaranteeing packet delivery via handshakes and acknowledgments (ACKs). In live mixing, however, **latency is the enemy**. If a packet containing a fader move is dropped, pausing the stream for retransmission is undesirable. The X32 network stack is therefore **stateless** and "fire-and-forget." It listens for incoming UDP datagrams, processes valid OSC messages, and sends replies to the source address without maintaining a persistent socket connection.
+
+### 3.2 Port Assignments and Addressing
+* **Target Port:** UDP Port **10023** (Hard-coded).
+* **Source Port:** Ephemeral (chosen by the client OS).
+
+**Critical Implementation Detail:** The X32 sends replies back to the *source IP* and *source port* of the incoming packet. Developers must bind to a specific local UDP socket for both sending and receiving. If the OS assigns a new port for the next message, the reply from the X32 will be sent to the original port and potentially discarded.
+
+### 3.3 Endianness and Data Representation
+The OSC specification 1.0 mandates Big-Endian (network byte order).
+* **Integers:** 32-bit signed ($i$)
+* **Floats:** 32-bit IEEE 754 ($f$)
+* **Strings:** Null-terminated ASCII ($s$)
+* **Blobs:** Int32 size count + binary data ($b$)
+
+**The Deviation:** While OSC headers are Big-Endian, the internal content of binary blobs returned by the `/meters` command is encoded in **Little-Endian** format, reflecting the internal architecture of the DSP (likely Analog Devices SHARC).
+
+---
+
+## 4. Device Discovery and Enumeration
+Applications utilize the `/xinfo` mechanism to locate the console, as IP addresses may be dynamic (DHCP).
+
+### 4.1 The `/xinfo` Handshake
+1.  **Query:** Client sends `/xinfo` (Broadcast or Unicast) on port 10023.
+2.  **Response:** X32 replies with ` /xinfo ,ssss`.
+
+**Response Arguments:**
+1.  **IP Address:** The console's self-reported IP (e.g., `192.168.1.50`).
+2.  **Console Name:** User-defined network name (e.g., `X32-FOH`).
+3.  **Model Identifier:** Hardware ID used to customize UI (e.g., `X32`, `X32RACK`, `X32CORE`).
+4.  **Firmware Version:** Critical for version control and compatibility checks (e.g., `4.06`).
+
+### 4.2 Application Implementation
+A typical implementation creates a UDP socket with `SO_BROADCAST` permissions, sends the `/xinfo` packet, and employs a short timeout (e.g., 2 seconds) to listen for the "business card" response.
+
+---
+
+## 5. Session Persistence and State Synchronization
+Since UDP is stateless, the X32 does not inherently know if a client is "connected." To support real-time animation of faders, the protocol implements a subscription-based heartbeat.
+
+### 5.1 The `/xremote` Command
+* **Function:** Acts as a subscription request.
+* **Behavior:** The X32 adds the sender to an internal list of "active remote clients" and mirrors **every** parameter change on the console to that client.
+* **Timeout:** A watchdog timer (approx. 10 seconds) purges clients if no further command is received.
+* **Keep-Alive:** Clients must resend `/xremote` in a background loop (every 7–9 seconds) to reset the watchdog.
+
+### 5.2 `/xremote` vs. `/subscribe`
+* **`/xremote`**: The "firehose" command. Requests *all* console changes. Efficient for full desktop editors.
+* **`/subscribe`**: Requests updates for specific addresses or ranges. Efficient for mobile apps focusing on specific features.
+
+For intercepting active channel info, `/xremote` is superior as it guarantees any selection change is broadcast without a priori knowledge.
+
+---
+
+## 6. Intercepting Active Channel Information
+"Active Channel" refers to the channel currently selected by the **SEL** button on the hardware surface.
+
+### 6.1 The `/-stat/selidx` Command
+The X32 broadcasts the selection state via:
+* **OSC Path:** `/-stat/selidx`
+* **Data Type:** 32-bit Integer (`,i`)
+* **Value Range:** 0 to 71
+
+### 6.2 Decoding the Selection Index
+The integer corresponds to a fixed map of channel strips:
+
+| Index Range (Int) | Channel Type | Specific Channels | OSC Address Path |
+| :--- | :--- | :--- | :--- |
+| **0 – 31** | Input Channels | Channels 1 – 32 | `/ch/01` ... `/ch/32` |
+| **32 – 39** | Aux Inputs | Aux 1 – 6, USB L/R | `/auxin/01` ... |
+| **40 – 47** | FX Returns | FX 1L, 1R ... 4R | `/fxrtn/01` ... |
+| **48 – 63** | Mix Buses | Bus 1 – 16 | `/bus/01` ... |
+| **64 – 69** | Matrix Outputs | Matrix 1 – 6 | `/mtx/01` ... |
+| **70** | Main LR | Stereo Master Bus | `/main/st` |
+| **71** | Mono/Center | Mono Bus | `/main/m` |
+
+> **Important:** DCAs are absent from this range as they are control groups, not processing paths with full channel strips.
+
+### 6.3 Implementation of Interception
+To intercept this data, a custom script acts as a parallel client:
+1.  **Subscription:** Send `/xremote` to register for updates.
+2.  **Listening:** Listen on the bound UDP port.
+3.  **Parsing:** When `/-stat/selidx` is received, parse the integer.
+4.  **Logic:** Map the integer (e.g., `0`) to the channel (`Channel 1`).
+
+### 6.4 The `/-prefs/autosel` Variable
+* **autosel ON:** Touching a fader triggers `/-stat/selidx`.
+* **autosel OFF:** Only pressing the "Select" button triggers the message.
+
+---
+
+## 7. Information About Channels: Command Hierarchy
+The root address for inputs is `/ch/` using a two-digit string index (`01`–`32`).
+
+### 7.1 Functional Blocks
+
+**Configuration (`/config`)**
+* `/ch/{n}/config/name`: String (User name)
+* `/ch/{n}/config/icon`: Integer (Icon index)
+* `/ch/{n}/config/color`: Integer (Color index)
+
+**Preamp (`/preamp`)**
+* `/ch/{n}/preamp/gain`: Float (0.0–1.0 mapping to -12dB to +60dB)
+* `/ch/{n}/preamp/rtnsw`: Integer (48V Phantom Power, 0/1)
+
+**Gate & Dynamics (`/gate`, `/dyn`)**
+* `/ch/{n}/gate/on`: Integer (Active/Bypass)
+* `/ch/{n}/dyn/ratio`: Enum (Compression ratio)
+
+**Equalizer (`/eq`)**
+* `/ch/{n}/eq/{b}/f`: Float (Frequency, log mapping 20Hz–20kHz)
+* `/ch/{n}/eq/{b}/g`: Float (Gain, -15dB to +15dB)
+
+**Mix & Fader (`/mix`)**
+* `/ch/{n}/mix/fader`: Float (Level, 0.75 ≈ 0dB)
+* `/ch/{n}/mix/on`: Integer (**Note:** 1 = Unmuted/On, 0 = Muted/Off)
+* `/ch/{n}/mix/pan`: Float (0.0 = Left, 1.0 = Right)
+
+### 7.2 "Sends on Fader" Telemetry
+Scripts can monitor `/-stat/sendsonfader` (0/1) to detect this mode. If active, fader moves control bus sends rather than the main mix.
+
+---
+
+## 8. Metering and Bulk Data Transfer
+To avoid network flooding, metering is handled via OSC Blobs.
+
+### 8.1 The `/meters` Command
+Request: `/meters ,s "/meters/1"` (where `/meters/1` covers input channels).
+
+### 8.2 Blob Structure and Endianness
+The response uses ` /meters ,b <binary_data>`.
+1.  **Size (Int32):** Big-Endian
+2.  **Count (Int32):** **Little-Endian**
+3.  **Data (Float32 Array):** **Little-Endian**
+
+**Critical:** Developers must switch byte-parsing logic after extracting the blob header to avoid nonsensical numeric values.
+
+---
+
+## 9. Application Analysis: X32-Edit
+The official software follows this blueprint:
+1.  **Startup:** Broadcast `/xinfo`.
+2.  **Connect:** Establish unicast UDP session to port 10023.
+3.  **Sync:** Send `/xremote` and dump console state (via `/status` or node requests).
+4.  **Operation:** Loop `/xremote` every ~9s; process `/ch/...` and `/meters` updates.
+5.  **Termination:** Stop heartbeat; session times out.
+
+---
+
+## 10. Conclusion
+The Behringer X32 OSC protocol is a robust system for remote audio control. By utilizing **UDP port 10023**, initiating discovery via **/xinfo**, and maintaining session persistence via **/xremote**, developers can effectively communicate with the console. Furthermore, intercepting "Active Channel" information is achievable by monitoring the **`/-stat/selidx`** command within an active subscription, enabling the creation of sophisticated custom controllers and automated workflows.

package/docs/X32-INTERNAL.md

@@ -0,0 +1,262 @@
+Voici le texte converti en format Markdown structuré et technique.
+
+# Rapport Technique Exhaustif : Conception et Implémentation d'un Simulateur de Console Numérique Behringer X32 via le Protocole Open Sound Control (OSC) en TypeScript
+
+## 1. Introduction et Contexte Architectural
+
+La conception d'un simulateur haute fidélité pour la console de mixage numérique **Behringer X32** représente un défi d'ingénierie logicielle complexe, nécessitant une maîtrise approfondie des protocoles réseaux temps réel et de l'architecture des systèmes embarqués audio. Ce rapport technique a pour objectif de fournir une spécification exhaustive pour le développement d'un émulateur "serveur" en **TypeScript**, capable d'interagir de manière indiscernable avec les clients officiels tels que l'application **X32-Mix** (macOS/iPad) et des plugins tiers communiquant via OSC.
+
+Contrairement à une simple télécommande qui envoie des commandes, un simulateur doit répliquer le comportement d'état (**"State Machine"**) de la console physique. Il doit :
+
+* Gérer les connexions concurrentes.
+* Maintenir la cohérence des données entre les clients.
+* Répondre aux mécanismes de découverte ("Handshake").
+* **Point crucial :** Générer les flux de données de vumètres ("Metering") selon un format binaire propriétaire spécifique.
+
+L'analyse des documents techniques et des travaux de rétro-ingénierie révèle que le protocole X32 OSC s'écarte des spécifications standards sur des points critiques tels que l'endianness (boutisme) des données binaires et la gestion des souscriptions.
+
+---
+
+## 2. Fondamentaux du Protocole de Transport et Configuration Réseau
+
+### 2.1 Architecture UDP et Gestion des Ports
+
+Le socle de communication de l'écosystème X32 repose quasi exclusivement sur le protocole **UDP (User Datagram Protocol)**. Pour un simulateur, cela implique que la couche réseau doit être résiliente à la perte de paquets et ne pas dépendre de mécanismes de reconnexion complexes propres à TCP.
+
+* **Port d'écoute :** **10023** (Standard pour X32/M32).
+* *Note :* La série X-Air utilise le port 10024.
+
+
+* **Implémentation Node.js :** Utilisation recommandée du module natif `dgram`.
+* **Binding :** Lier le socket à `0.0.0.0` pour accepter les diffusions ("broadcasts").
+
+### 2.2 Structure des Paquets OSC et Alignement Mémoire
+
+Le protocole suit des règles d'alignement mémoire strictes (32 bits / 4 octets). Chaque composant (Address Pattern, Type Tag String, Arguments) doit être aligné.
+
+**Règle de Padding :** Si une chaîne (incluant son `\0` terminal) ne remplit pas un multiple de 4 octets, elle doit être complétée par des octets nuls.
+
+> **Exemple pour la commande `/info` :**
+> * Chaîne : `/info` (5 chars) + `\0` = 6 octets.
+> * Multiple de 4 supérieur = 8.
+> * Padding nécessaire = 2 octets nuls.
+> * Hexadécimal : `2f 69 6e 66 6f 00 00 00`
+>
+>
+
+Une erreur d'un seul octet rendra le paquet illisible pour X32-Mix.
+
+### 2.3 Typage des Données et Robustesse du Serveur
+
+Le simulateur doit impérativement inclure les chaînes de types (Type Tags) dans les réponses.
+
+* **Int32 (`i`)** : Entier signé 32 bits, **Big-Endian**. (Énumérations, ID, Booléens).
+* **Float32 (`f`)** : Flottant IEEE 754 32 bits, **Big-Endian**. (Niveaux, Fréquences).
+* **String (`s`)** : Chaîne ASCII terminée par nul + Padding.
+* **Blob (`b`)** : "Binary Large Object". *Voir section 6.2 pour la spécificité d'endianness.*
+
+---
+
+## 3. Séquence d'Initialisation et Protocole de Découverte
+
+### 3.1 Découverte du Serveur : La commande `/info`
+
+Dès le lancement, X32-Mix émet `/info`. Le simulateur doit répondre immédiatement avec 4 arguments de type string (`,ssss`).
+
+| Argument | Valeur Type | Description |
+| --- | --- | --- |
+| **Arg 1** | `V2.05` | Version du protocole serveur. |
+| **Arg 2** | `osc-server` | Nom réseau de la console. |
+| **Arg 3** | `X32` | **Critique.** Modèle de console. Utiliser `X32`, `M32`, `X32RACK`. Une valeur inconnue bloque le chargement de l'UI. |
+| **Arg 4** | `2.12` | Version du firmware (ex: `4.06`). |
+
+### 3.2 Vérification d'État : La commande `/status`
+
+Réponse attendue (`,sss`) :
+
+1. **État :** `active` (Moteur audio fonctionnel).
+2. **IP :** Adresse IP locale du simulateur.
+3. **Nom :** Nom de la console.
+
+### 3.3 Négociation de la Session : Le mécanisme `/xremote`
+
+La X32 est un serveur passif par défaut. Le client doit s'abonner aux mises à jour.
+
+1. **Réception :** Le simulateur reçoit `/xremote`.
+2. **Enregistrement :** Ajout de l'IP/Port du client dans une "Subscribers List".
+3. **Watchdog :** Timer de 10 secondes. Sans renouvellement, le client est éjecté.
+4. **Feedback :** Tant que le client est abonné, **chaque** changement d'état interne (fader, mute) doit générer un message OSC sortant vers le client pour éviter l'effet "rubber-banding" (saut de fader).
+
+---
+
+## 4. Architecture de la Carte Mémoire (Address Map)
+
+### 4.1 Hiérarchie Principale
+
+* `/ch/[01..32]` : Canaux d'entrée.
+* `/auxin/[01..08]` : Auxiliaires.
+* `/fxrtn/[01..08]` : Retours d'effets.
+* `/bus/[01..16]` : Bus de mixage.
+* `/mtx/[01..06]` : Matrices.
+* `/main/st`, `/main/m` : Sorties Master.
+* `/dca/[1..8]` : DCA.
+* `/config`, `/headamp` : Configuration et Préamplis.
+
+### 4.2 Structure d'une Tranche ("Channel Strip")
+
+Sous-modules pour `/ch/01/...` :
+
+* `/config` : `name`, `icon`, `color`.
+* `/preamp` : `trim`, `inv` (phase), `hpf` (passe-haut).
+* `/gate` : `mode`, `thr`, `attack`, `hold`, `release`.
+* `/dyn` : Compresseur (`ratio`, `thr`, `knee`, etc.).
+* `/eq` : Paramétrique 4 bandes (`/eq/1` à `/eq/4`). Paramètres : `type`, `f`, `g`, `q`.
+* `/mix` :
+* `fader` : Float (0.0 - 1.0).
+* `on` : Mute (0/1). **Attention :** Logique inversée possible selon le contexte, mais généralement 1 = Audio Passant.
+* `pan` : 0.0 (G) - 1.0 (D).
+
+
+
+### 4.3 Normalisation des Valeurs
+
+Les valeurs sont normalisées sur `[0.0, 1.0]`.
+
+* **Faders :** Non-linéaire. `0.0` = -∞ dB, `0.75` ≈ 0 dB, `1.0` = +10 dB.
+* **Fréquences :** Logarithmique (20 Hz - 20 kHz).
+
+---
+
+## 5. Gestion des Scènes et Fichiers
+
+Commandes clés à supporter :
+
+* `/-action/goscene ,i [index]` : Charger une scène.
+* `/-action/setscene ,i [index]` : Définir la scène courante.
+
+Le simulateur doit parser les fichiers `.scn` (texte clair contenant des commandes OSC) et les appliquer ligne par ligne à l'état interne.
+
+---
+
+## 6. Implémentation Avancée du Système de Vumètres (Metering)
+
+### 6.1 La Commande `/meters`
+
+Requête client : `/meters ,si [Chemin] [Temps]`
+
+* `/meters/0` : Global.
+* `/meters/1` : Canaux détaillés (Entrées + Gate + Dyn).
+* Mise à jour continue (~50ms) pendant 10s si Temps = 0.
+
+### 6.2 Le Format Binaire Hybride (Mixed Endianness)
+
+**Anomalie Critique :** Alors que l'en-tête OSC est en Big-Endian, le contenu du Blob ("Payload") contenant les vumètres utilise le **Little-Endian** pour les flottants.
+
+**Structure du Blob :**
+
+1. **Taille du Blob (Int32)** : **Big-Endian** (Format OSC Standard).
+2. **Taille Interne (Int32)** : **Big-Endian** (Début du Payload).
+3. **Nombre d'Éléments (Int32)** : **Little-Endian**.
+4. **Données (Float32 Array)** : **Little-Endian**.
+
+**Implémentation TypeScript :**
+L'utilisation de bibliothèques OSC standard échouera ici. Il faut construire le buffer manuellement.
+
+```typescript
+// Exemple conceptuel de génération de blob pour /meters/1 (96 valeurs)
+function generateMeterBlob(values: number[]): Buffer {
+    const numFloats = values.length; // 96
+    const headerBytes = 4; // Taille interne
+    const countBytes = 4; // Nombre d'éléments
+    const dataBytes = numFloats * 4;
+    const totalBlobSize = headerBytes + countBytes + dataBytes;
+
+    // Création du buffer pour le contenu du blob
+    const blobBuffer = Buffer.alloc(totalBlobSize);
+    let offset = 0;
+
+    // 1. Taille Interne (Big Endian) - Spécificité X32
+    blobBuffer.writeInt32BE(totalBlobSize, offset);
+    offset += 4;
+
+    // 2. Compteur d'éléments (Little Endian)
+    blobBuffer.writeInt32LE(numFloats, offset);
+    offset += 4;
+
+    // 3. Données Flottantes (Little Endian)
+    for (let i = 0; i < numFloats; i++) {
+        blobBuffer.writeFloatLE(values[i], offset);
+        offset += 4;
+    }
+
+    return blobBuffer;
+}
+
+```
+
+### 6.3 Mapping des Vumètres (`/meters/1`)
+
+* **0-31 :** Canaux 1-32 (Pre-Fader).
+* **32-63 :** Gate Gain Reduction.
+* **64-95 :** Compressor Gain Reduction.
+
+---
+
+## 7. Architecture Logicielle du Simulateur en TypeScript
+
+### 7.1 Gestionnaire d'État (State Store)
+
+Utiliser une structure arborescente émettant des événements.
+
+```typescript
+type X32Parameter = number | string;
+
+class X32Node {
+    private value: X32Parameter;
+    private path: string;
+    
+    setValue(val: X32Parameter) {
+        this.value = val;
+        this.emit('change', this.path, this.value);
+    }
+}
+
+```
+
+### 7.2 Boucle de Rétroaction
+
+Le serveur UDP s'abonne au Store :
+`StateStore.on('change', (path, value) => { Server.broadcast(path, value); });`
+
+---
+
+## 8. Méthodologie de Rétro-Ingénierie avec le Simulateur
+
+1. **Mode Espion (Snooping) :** Logger chaque paquet entrant pour mapper les commandes inconnues envoyées par X32-Mix.
+2. **Validation par Écho :** Envoyer périodiquement des commandes au client pour vérifier si l'UI réagit (boutons qui tournent).
+3. **Analyse Wireshark :** Filtrer sur `udp.port == 10023` pour valider les séquences d'initialisation et l'endianness des blobs.
+
+---
+
+## 9. Conclusion et Tableaux Récapitulatifs
+
+La réussite du simulateur repose sur le respect strict des spécificités Behringer : **Port 10023**, **Handshake précis**, **Souscription active**, et **Endianness hybride** pour les vumètres.
+
+### Tableau Récapitulatif des Types OSC X32
+
+| Type Tag | Description | Encodage Réseau (Standard) | Encodage Vumètres (Blob Payload) |
+| --- | --- | --- | --- |
+| `,i` | Entier 32 bits | Big-Endian | N/A |
+| `,f` | Flottant 32 bits | Big-Endian | **Little-Endian** |
+| `,s` | Chaîne | ASCII + Padding | N/A |
+| `,b` | Blob | Taille en Big-Endian | **Mixte** (Taille BE, Data LE) |
+
+### Tableau des Principaux Chemins OSC
+
+| Chemin | Description | Arguments Typiques |
+| --- | --- | --- |
+| `/info` | Découverte serveur | Réponse: `,ssss` |
+| `/status` | État système | Réponse: `,sss` |
+| `/xremote` | Souscription | Aucun |
+| `/ch/[01-32]/mix/fader` | Fader Canal | `,f` [0.0 - 1.0] |
+| `/meters/[id]` | Requête Vumètres | `,b` (Blob réponse) |

package/package.json

@@ -0,0 +1,68 @@
+{
+  "name": "@djodjonx/x32-simulator",
+  "version": "0.0.1",
+  "description": "X32 Simulator",
+  "type": "module",
+  "main": "./dist/index.cjs",
+  "module": "./dist/index.mjs",
+  "types": "./dist/index.d.mts",
+  "bin": {
+    "x32-simulator": "./dist/server.mjs"
+  },
+  "exports": {
+    ".": {
+      "import": {
+        "types": "./dist/index.d.mts",
+        "default": "./dist/index.mjs"
+      },
+      "require": {
+        "types": "./dist/index.d.cts",
+        "default": "./dist/index.cjs"
+      }
+    }
+  },
+  "scripts": {
+    "dev": "tsdown --watch",
+    "build": "tsdown",
+    "test": "vitest run",
+    "test:coverage": "vitest run --coverage",
+    "test:watch": "vitest",
+    "lint": "oxlint -c .oxlintrc.json",
+    "type-check": "tsc --noEmit",
+    "prepare": "husky",
+    "release": "standard-version"
+  },
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/djodjonx/x32-simulator.git"
+  },
+  "publishConfig": {
+    "access": "public",
+    "registry": "https://registry.npmjs.org/"
+  },
+  "keywords": [],
+  "author": "Jonathan Moutier <djo.moutier@gmail.com>",
+  "license": "MIT",
+  "lint-staged": {
+    "*.ts": [
+      "npm run lint",
+      "bash -c 'tsc --noEmit'"
+    ]
+  },
+  "devDependencies": {
+    "@commitlint/cli": "^20.3.0",
+    "@commitlint/config-conventional": "^20.3.0",
+    "@types/node-osc": "^9.1.0",
+    "@vitest/coverage-v8": "^4.0.16",
+    "husky": "^9.1.7",
+    "lint-staged": "^16.2.7",
+    "oxlint": "^1.38.0",
+    "standard-version": "^9.5.0",
+    "tsdown": "^0.19.0-beta.4",
+    "typescript": "^5.9.3",
+    "vitest": "^4.0.16"
+  },
+  "dependencies": {
+    "node-osc": "^11.2.2"
+  }
+}

package/src/application/use-cases/BroadcastUpdatesUseCase.ts

@@ -0,0 +1,120 @@
+import { SubscriptionManager } from '../../domain/entities/SubscriptionManager';
+import { INetworkGateway } from '../../domain/ports/INetworkGateway';
+import { X32State } from '../../domain/entities/X32State';
+import { SchemaRegistry } from '../../domain/services/SchemaRegistry';
+import { MeterService } from '../../domain/services/MeterService';
+import { ILogger, LogCategory } from '../../domain/ports/ILogger';
+
+export class BroadcastUpdatesUseCase {
+    constructor(
+        private subscriptionManager: SubscriptionManager,
+        private state: X32State,
+        private gateway: INetworkGateway,
+        private logger: ILogger,
+        private meterService: MeterService,
+        private schemaRegistry: SchemaRegistry
+    ) {}
+
+    public execute(): void {
+        this.subscriptionManager.getSubscribers().forEach(sub => {
+            if (sub.type === 'path' || !sub.alias) {
+                 if (sub.type === 'meter' && sub.meterPath) {
+                     const meterData = this.meterService.generateMeterData(sub.meterPath, this.state);
+                     this.gateway.send({ address: sub.address, port: sub.port }, sub.meterPath, [meterData.toBlob()]);
+                 }
+                 return; 
+            }
+  
+            const rinfo = { address: sub.address, port: sub.port };
+            
+            if (sub.type === 'batch' && sub.paths) {
+               if (sub.paths.length === 1 && sub.paths[0].startsWith('/meters')) {
+                   const meterData = this.meterService.generateMeterData(sub.paths[0], this.state);
+                   this.gateway.send(rinfo, sub.alias, [meterData.toBlob()]);
+                   return;
+               }
+  
+               let stride: number;
+               const dataSize = sub.paths.length * 4;
+               const factor = sub.factor || 0;
+               const count = sub.count || 0;
+  
+               if (factor > 0) {
+                   stride = Math.max(factor * 4, dataSize);
+               } else {
+                   stride = (sub.paths.length === 3) ? 16 : dataSize;
+               }
+               
+               const blobSize = count * stride;
+               if (isNaN(blobSize) || blobSize < 0) {
+                   this.logger.error(LogCategory.SYSTEM, `Invalid blob size`, { alias: sub.alias, blobSize, count, stride, factor, dataSize });
+                   return;
+               }
+  
+               const blob = Buffer.alloc(blobSize);
+               
+               for (let i = 0; i < count; i++) {
+                  const root = this.schemaRegistry.getRootFromIndex(sub.start! + i);
+                  let currentOffset = i * stride;
+                  
+                  if (!root) { continue; }
+                  
+                  sub.paths.forEach((s, pIdx) => {
+                      if (pIdx * 4 >= stride) return;
+  
+                      if (s.startsWith('/meters')) {
+                          blob.writeFloatLE(0.0, currentOffset);
+                      } else {
+                          const target = `${root}${s}`;
+                          const node = this.schemaRegistry.getNode(target);
+                          let val = this.state.get(target);
+                          if (val === undefined) val = node ? node.default : 0;
+                          
+                          if (typeof val === 'number') {
+                              if (node && node.type === 'f') {
+                                  blob.writeFloatLE(val, currentOffset);
+                              }
+                              else blob.writeInt32LE(val, currentOffset);
+                          } else blob.writeInt32LE(0, currentOffset);
+                      }
+                      currentOffset += 4;
+                  });
+               }
+               this.gateway.send(rinfo, sub.alias, [blob]);
+            } else if (sub.type === 'format' && sub.pattern) {
+               const stride = sub.factor ? sub.factor * 4 : 4;
+               const start = sub.start || 0;
+               const count = sub.count || 0;
+               
+               const totalSize = (start + count) * stride;
+               if (isNaN(totalSize) || totalSize < 0) return;
+  
+               const blob = Buffer.alloc(totalSize);
+               let offset = start * stride;
+               
+               for (let i = start; i < start + count; i++) {
+                  const id = i.toString().padStart(2, '0');
+                  const target = sub.pattern!.replace(/\*\*?/, id);
+                  let val = this.state.get(target);
+                  if (val === undefined) val = 0;
+                  if (typeof val === 'number') {
+                      const node = this.schemaRegistry.getNode(target);
+                      if (node && node.type === 'f') blob.writeFloatLE(val, offset);
+                      else blob.writeInt32LE(val, offset);
+                  } else blob.writeInt32LE(0, offset);
+                  offset += stride;
+               }
+               this.gateway.send(rinfo, sub.alias, [blob]);
+            }
+        });
+    }
+
+    public broadcastSingleChange(path: string, value: number | string): void {
+        this.subscriptionManager.getSubscribers().forEach(sub => {
+            const match = path === sub.path || sub.path === '/xremote' || (sub.path && sub.path.includes('*') && path.startsWith(sub.path.split('*')[0]));
+            if (match) {
+                this.gateway.send({ address: sub.address, port: sub.port }, path, [value]);
+            }
+        });
+    }
+}

package/src/application/use-cases/ManageSessionsUseCase.ts

@@ -0,0 +1,9 @@
+import { SubscriptionManager } from '../../domain/entities/SubscriptionManager';
+
+export class ManageSessionsUseCase {
+    constructor(private subscriptionManager: SubscriptionManager) {}
+
+    public cleanup(): void {
+        this.subscriptionManager.cleanup();
+    }
+}

package/src/application/use-cases/ProcessPacketUseCase.ts

@@ -0,0 +1,26 @@
+import { OscPacket, OscArgument, RemoteClient } from '../../domain/models/types';
+import { OscMessageHandler } from '../../domain/services/OscMessageHandler';
+import { INetworkGateway } from '../../domain/ports/INetworkGateway';
+
+export class ProcessPacketUseCase {
+    constructor(
+        private messageHandler: OscMessageHandler,
+        private gateway: INetworkGateway
+    ) {}
+
+    public execute(packet: OscPacket, rinfo: RemoteClient): void {
+        if (packet.oscType === 'bundle') {
+            packet.elements?.forEach((el: OscPacket) => this.execute(el, rinfo));
+        } else if (packet.oscType === 'message') {
+            const args = packet.args.map((arg: OscArgument) => {
+                if (typeof arg === 'object' && arg !== null && 'value' in arg) return arg.value;
+                return arg;
+            });
+
+            const replies = this.messageHandler.handle({ address: packet.address, args }, rinfo);
+            replies.forEach(reply => {
+                this.gateway.send(rinfo, reply.address, reply.args);
+            });
+        }
+    }
+}