Hallo zusammen, ich wieder 
Seit wir die neuste Version installiert haben funktioniert bei uns die MIDI-Ausgabe aus einem mAirList-Skript nicht mehr. Wir schalten damit beim Wechsel Auto/Assist die Snapshots in RME TotalMix um.
Umgebung
- mAirList 8.1.3 Build 6109 (Professional Studio)
- Windows 11 Pro 10.0.26200 (mit den neuen Windows MIDI Services / MidiSrv)
- RME HDSP AES-32, Audio über ASIO, MIDI über “AES-32 Midi Port 2”
Skript (Notification Script, gekürzt)
procedure OnLoad;
begin
MidiOutOpen(2);
end;
procedure OnAutomationOn(PlaylistIndex: integer);
begin
MidiOut(2, 144, 55, 127);
MidiOut(2, 128, 55, 127);
end;
Was wir festgestellt haben
- MidiOutListDevices zeigt: 0 = Microsoft GS Wavetable Synth, 1 = AES-32 Midi Port 1, 2 = AES-32 Midi Port 2. Das ist dieselbe Reihenfolge wie in Windows.
- MidiOutOpen(2) und MidiOut(2, …) laufen ohne Fehler oder Exception, die Ereignisse werden korrekt ausgelöst (per SystemLog geprüft).
- Am Ausgang kommt trotzdem nichts an. Das haben wir mit einem MIDI-Monitor am zurückgeschleiften Eingang geprüft.
- Wir haben es auch mit Open/Out/Close bei jedem Aufruf versucht, mit demselben Ergebnis.
- Ein externes Programm (winmm, midiOutShortMsg) sendet über denselben Port mit denselben Daten problemlos. Das gilt für 32- und 64-Bit, auch während mAirList läuft.
- Ein Neustart von mAirList ändert nichts.
Umgehung:
Wir rufen jetzt mit ShellExecuteHidden ein kleines externes Programm auf, das die Noten sendet. Das funktioniert.
Ist das Problem bekannt? Hängt es eventuell mit den neuen Windows MIDI Services zusammen? Gerne liefern wir weitere Logs oder testen bei neuer Version.
Die Datei midisrv.exe ist vom 25.10.2026, Version 10.0.26100.9549. Sie kam mit den Windows-Updates vom 25. und 26.10. (unter anderem KB5127647, KB5127648, KB5127690).
Das klingt nach einem bekannten Windows Bug.
Mit der Einführung von MIDI 2.0 hat Microsoft MIDI komplett kaputt gemacht. Ich weiss nicht ob das inzwischen mit einem weiteren Patch mal behoben wurde. Also auf jeden Fall Win11 so weit es geht updaten. Wobei ich die 26h2 warscheinlich noch nicht installieren würde.
Ich habe da mal eine Windows Batch Datei für meine Kollegen gebaut um das zu lösen.
@echo off
CHCP 1252
title MIDI Fixer (C) Radio-Zoom
setlocal DisableDelayedExpansion
set "batchPath=%~0"
for %%k in (%0) do set batchName=%%~nk
set "vbsGetPrivileges=%temp%\OEgetPriv_%batchName%.vbs"
setlocal EnableDelayedExpansion
:checkPrivileges
NET FILE 1>NUL 2>NUL
if '%errorlevel%' == '0' ( goto gotPrivileges ) else ( goto getPrivileges )
:getPrivileges
if '%1'=='ELEV' (echo ELEV & shift /1 & goto gotPrivileges)
ECHO.
ECHO **************************************
ECHO Invoking UAC for Privilege Escalation
ECHO **************************************
ECHO Set UAC = CreateObject^("Shell.Application"^) > "%vbsGetPrivileges%"
ECHO args = "ELEV " >> "%vbsGetPrivileges%"
ECHO For Each strArg in WScript.Arguments >> "%vbsGetPrivileges%"
ECHO args = args ^& strArg ^& " " >> "%vbsGetPrivileges%"
ECHO Next >> "%vbsGetPrivileges%"
ECHO UAC.ShellExecute "!batchPath!", args, "", "runas", 1 >> "%vbsGetPrivileges%"
"%SystemRoot%\System32\WScript.exe" "%vbsGetPrivileges%" %*
exit /B
:gotPrivileges
ECHO.
ECHO **************************************
ECHO Stopping MIDI Service
ECHO **************************************
net stop midisrv
ping 127.0.0.1 > NUL
ECHO.
ECHO **************************************
ECHO Starting MIDI Service
ECHO **************************************
net start midisrv
ping 127.0.0.1 > NUL
exit
Danke für den Tipp und die Batch-Datei!
Wir haben es heute getestet, leider ohne Erfolg:
- Den MIDI-Dienst (midisrv) neu gestartet, genau wie in deinem Batch.
- Danach mAirList neu gestartet.
- Von Hand ein Test-Skript in mAirList ausgeführt: MidiOutOpen(2), MidiOut(2, 144, 55, 127), MidiOut(2, 128, 55, 127), MidiOutClose(2).
Das Skript läuft ohne Fehler oder Exception durch, aber am Ausgang kommt nichts an. Das haben wir mit einem MIDI-Monitor am zurückgeschleiften Eingang geprüft.
Ein kleines externes Programm sendet direkt davor bzw. danach über denselben Port mit denselben Daten (winmm, midiOutShortMsg). Diese Noten kommen am Monitor problemlos an.
Windows ist auf dem aktuellen Stand (11 25H2, Build 26200.9711).
Dabei ist uns noch etwas aufgefallen:
- Wird midisrv neu gestartet, während mAirList läuft, meldet MidiOutOpen danach „Error 1“, bis mAirList neu gestartet wird.
- Auch TotalMix FX hat nach dem Neustart von midisrv keine MIDI-Befehle mehr angenommen. Es kam keine Fehlermeldung, die Noten kamen nachweislich am Eingang an. Erst ein Neustart von TotalMix hat das behoben.
- Wer den Batch verwendet, sollte also danach alle MIDI-Programme neu starten.
Windows MIDI Services kann also offenbar Verbindungen stillschweigend „verlieren“, ohne dass das Programm einen Fehler bekommt. Bei mAirList sieht es für uns genau so aus. Der Unterschied: Bei mAirList hilft auch ein kompletter Neustart nicht, während andere winmm-Programme normal senden.
Vielleicht kann sich das jemand von mAirList anschauen (mAirList 8.1.3 Build 6109)? Interessant wäre, welche MIDI-Schnittstelle mAirList intern nutzt und ob Rückgabewerte beim Senden geprüft werden.