Midi Trouble with Leonardo / Invalid parameter passed to a system function

karistouf · February 23, 2026, 10:33am

Hum… this is a weird weird thing , I m actually building my midi device on an Arduino Leonardo, for its ability to be seen in nativ as a midi device

I have two computers with same version of gamma installed ( 7.1 prv 00165)
On my Laptop i received correctly the midi signal outputted from the leonardo on the Know my device patch But … on my tower i never received any signal, despite the status is open ok.

those are same drivers, same versions of gamma, but not same result.
the leonardo is recognize as an audio device.

i tried to uninstall the driver, re install it. i tred also on latest Gamma preview (171) same result.
I finally opened the debug and having this feedback, if anybody knows how to resolve this ?

thank you !

karistouf · February 23, 2026, 11:55am

hum restarted twice, and now this errors :

karistouf · February 23, 2026, 12:47pm

ok, now it seems my .NET environnement is broken. pfiou…

karistouf · February 23, 2026, 12:49pm

karistouf · February 23, 2026, 1:08pm

i have reinstalled the .NET sdk 08.0124. Now i m back to the error of this morning :

karistouf · February 23, 2026, 1:36pm

this is the thing i have on my computer when trying to connect in or out my Leonardo :

2026/02/23 14:35:34.427 [CRT] (App) 0 SendAndReceiveNotes An invalid parameter was passed to a system function.

Sanford.Multimedia.Midi.InputDeviceException: An invalid parameter was passed to a system function.
at Sanford.Multimedia.Midi.InputDevice.StartRecording()
at Sanford.Multimedia.Midi.InputDeviceMidiEvents..ctor(InputDevice inDevice)
at VL.Lib.IO.Midi.MidiInObservable.<>c.b__4_0(Int32 id)
at VL.Lib.Basics.Resources.ResourceProvider.<>c__DisplayClass14_12.<NewPooledSystemWide>b__1() at VL.Lib.Basics.Resources.ResourceProvider.<>c__DisplayClass1_01.b__0()
at VL.Lib.Basics.Resources.ResourceProvider.<>c__DisplayClass49_01.<Finally>b__0() at VL.Lib.Basics.Resources.ResourceProvider.<>c__DisplayClass27_01.b__1()
at VL.Lib.Basics.Resources.ConnectableProvider1.Connect() at VL.Lib.Basics.Resources.ResourceProvider.<>c__DisplayClass30_02.b__0()
at VL.Lib.Basics.Resources.ResourceProvider.<>c__DisplayClass3_02.<NewPooledInternal>b__0() at VL.Lib.Basics.Resources.ResourceProvider.<>c__DisplayClass27_01.b__1()
at VL.Lib.Basics.Resources.ConnectableProvider1.Connect() at VL.Lib.Basics.Resources.ResourceProvider.<>c__DisplayClass30_02.b__0()
at VL.Lib.IO.Midi.MidiObservable.<>c__DisplayClass7_0.<.ctor>b__0()
at System.Reactive.Linq.ObservableImpl.Using2._.Run(Using2 parent)
— End of stack trace from previous location —
at VL.Lang.Platforms.RuntimeHost.SharedStep(TimeSpan timeSinceStart)

karistouf · February 24, 2026, 3:42pm

hum after some hours between lechat and Claude, it seems there is a long long time about deployement of new midi driver structure and incompatibility with the Sanford midi portage in gamma. i run this tool : About Windows MIDI Services - Windows MIDI Services and get this result :

My midifighter then disappeared from the list of devices. Before it was in the list of devices, but not giving any data. If i use midi ox i can see my device and data arriving…

Claude give me this summary for devs :
Subject: MIDI input devices listed but no data received - Windows 11 24H2 with Windows MIDI Services

Hi,

I’m running vvvv gamma 7.1.165 on Windows 11 24H2 and experiencing a MIDI input issue that I believe is related to the new Windows MIDI Services stack recently activated via Windows Update.

Situation:

MIDI devices (Arduino Leonardo, MidiFighter Spectra) are correctly listed in gamma
No MIDI data is received in patches using MidiIn node
MIDI-OX receives data perfectly from the same devices
The issue only affects this PC — another machine running Windows 11 25H2 works fine with the same patch

Root cause identified: Microsoft has been rolling out Windows MIDI Services (new MIDI 2.0/ACX stack) via Windows Update. This PC has received the activation. The Sanford.Multimedia.Midi library used by vvvv gamma relies on the old WinMM MIDI 1.0 API which is no longer fully compatible with the new stack.

Error in logs:

InputDeviceException: An invalid parameter was passed to a system function
at Sanford.Multimedia.Midi.InputDevice.StartRecording()

Is there a known workaround or a planned migration from Sanford to the new Windows MIDI Services API?

joreg · February 24, 2026, 6:35pm

so you say it affects a pc running Windows 11 24H2 but not another running the newer Windows 11 25H2? any chance you can update windows on the pc that shows the problem?

joreg · February 24, 2026, 7:25pm

but also can you please try this: Open the helppatch: HowTo Bind Channels to MIDI via the Channel Browser, then select the device, see if it opens and add a HoldLatest node to see if you receive any events:

(this is using an alternative midi implementation, would be interesting to know if it is also affected)

karistouf · February 24, 2026, 8:00pm

i have (on claude suggestion) posted on Gith repo, it seems for a microsoft devs that there is a leak in the sanford library that sounds quite very clear for him. i will send you by mp on element his mail, he is welcoming contact to help you in this case. He tried to reach you thruth linked in.

as midi ox (quite old) sees perfectly data from devices, i think we can say this is really a bug and not a windows update feature and the change of library.

my bugging PC is a 10 family automitially upgraded to 11 when installing a second hdd for dual boot session ( Destiny on one drive, Le La Couleur on another because of problems of drivers compatibility with leap motion).

about the 2 pc it seems that my bugging PC is affected by Windows 11 24H2 midi implementations to new driver type, while the working laptop is not affected for the moment. Deployement of midi modifications are not immediate and depends on machine updates and windows black magic. Thats the point we got to clear with Claude (thanks @lecloneur Claude is winning any compareason to other IA in diagnostics).

i m checking my computer about that patch and tell you

karistouf · February 24, 2026, 8:10pm

@joreg if i open HowTo Bind Channels to MIDI via the Channel Browser and i connect to my device, device is seen in device list, BUT :

the input stay in close state
if i push a key on the device its directly crashes gamma 7.01 preview 171
this with or without hold latest wich stays before and while crashing Null

I reproduced it 3 times and stop to test

joreg · February 24, 2026, 8:31pm

thanks for the test. we’ll see what we can do!

karistouf · February 24, 2026, 8:48pm

Hope this will help! Good Luck ! I m around if you need any tests

karistouf · February 25, 2026, 7:08am

@joreg received this link from Pete

github.com/atsushieno/managed-midi

Windows: Incorrect WinMM MIDI Header structure

opened 11:27PM - 24 Feb 26 UTC

Psychlist1972

The definition of the MIDI Header structure is not correct in this library. This… is now or will soon break for apps using the new Windows MIDI Services stack because we validate the size passed in for safety reasons. The new stack started rolling out last month to Windows 11 customers. Here is the C definition: ```cpp typedef struct midihdr_tag { LPSTR lpData; /* pointer to locked data block */ DWORD dwBufferLength; /* length of data in data block */ DWORD dwBytesRecorded; /* used for input only */ DWORD_PTR dwUser; /* for client's use */ DWORD dwFlags; /* assorted flags (see defines) */ struct midihdr_tag far *lpNext; /* reserved for driver */ DWORD_PTR reserved; /* reserved for driver */ #if (WINVER >= 0x0400) DWORD dwOffset; /* Callback offset into buffer */ DWORD_PTR dwReserved[8]; /* Reserved for MMSYSTEM */ #endif } MIDIHDR, *PMIDIHDR, NEAR *NPMIDIHDR, FAR *LPMIDIHDR; ``` Here's what's in your library (WinMMNatives.cs) ```csharp [StructLayout (LayoutKind.Sequential)] struct MidiHdr { public IntPtr Data; public int BufferLength; public int BytesRecorded; public IntPtr User; public int Flags; public IntPtr Next; // of MidiHdr public IntPtr Reserved; public int Offset; [MarshalAs (UnmanagedType.ByValArray, SizeConst = 4)] private int[] reservedArray; } ``` DWORD_PTR is a 64 bit value on 64 bit Windows. - `reservedArray` should be of type `IntPtr` to be 8 bytes per element vs 4 bytes. - Additionally, `SizeConst` needs to be 8, not 4. - BufferLength should be `uint` (but it will work as-is) - BytesRecorded should be `uint` (but it will work as-is) - Offset should be `uint` (but like the others, will work) Total size of the structure should be 112 bytes. This will show up as an invalid parameter error when you do something like add a buffer using the WinMM API calls.

Nava · February 28, 2026, 7:09am

I was wondering why my arturia keyboard stopped responding to my patch quarter way through a live performance after a blue screen and a reboot and windows updating omg. Think rolling back the update could work?

karistouf · February 28, 2026, 9:23am

yes it will ! courage ! devs will surely update the Sandford midi library

Nava · March 2, 2026, 10:40am

Ok what I did since its been less than 10 days and still available is use Settings → System → Recovery and go back to version 23h2 os build 22631.6.6199 . I also set gpedit.msc to pin updates to this version so that i can avoid this for now. I guess i have till the October 2026 for vvvv to update libraries and maintain security on this machine.

karistouf · March 2, 2026, 10:55am

Thats a good news !
Mostly i m avoiding to update my computers when on touring.
If i connect them to internet i make generally a check, as there is also many of my setup, opening all my shows, especially if they are very complexes. With time experiences and depending of shows, I have now a to-check list of things to look at.
DotNet updates may also interfer with Gamma at one moment (.NET version and Gamma versions) on little tricky things that may make an all patch unfonctionnal.

joreg · March 3, 2026, 1:43pm

continues here: Midi problem