I have been developing a JUCE app (v8.0.12) that runs in MAC and Windows. The demoRunner app makes a similar ‘mistake’ in Windows. But my app makes the same ‘mistake’ in both operating systems.
My device is happily talking UMP on the wire in both OS’s.
it is May of 2026 do I need to be on the MIDI2 Branch of JUCE??
Here is the code that gets bogus results for getDeviceInfo()
auto endpoints = universal_midi_packets::Endpoints::getInstance();
auto availableEndpoints = endpoints->getEndpoints();
for (const auto endpointID : availableEndpoints)
{
auto endpoint = endpoints->getEndpoint(endpointID);
logMessage(endpoint->getName());
auto info = endpoint->getDeviceInfo();
auto mfr = info.manufacturer;
auto fam = info.family;
auto mod = info.modelNumber;
auto rev = info.revision;
logMessage (String::formatted(“mfr ID %02x %02x %0x2”,mfr[0],mfr[1],mfr[2]));
logMessage (String::formatted(“family %02x %02x”,fam[0],fam[1]));
logMessage (String::formatted(“model# %02x %02x”,mod[0],mod[1]));
logMessage (String::formatted(“revision %02x.%02x.%0x2-%02x\n”,rev[0],rev[1],rev[2],rev[3]));
}
The demoRunner app makes a similar ‘mistake’ in Windows. But my app makes the same ‘mistake’ in both operating systems.
It would be helpful if you could providing the following information:
What result do you expect?
What result do you actually see in your app, on each operating system?
What result do you see in the DemoRunner, on each operating system?
What operating system versions have you tested?
On Windows, have you done the additional setup steps to get the Windows MIDI Services SDK up and running?
I tried adding the code you provided in displayInfo() in the UmpDemo from the JUCE repo. I also updated the build to use Windows MIDI Services on Windows. My Roland A88-mk2 produces the following on macOS 15.7.5, and on Windows 11 Pro 25H2 build 26200.8328. I’m using the rc-4 release of the Windows MIDI Services nuget package.
A-88MK2
mfr ID 41 00 02
family 6b 03
model# 00 00
revision 00.02.12-02
I’m not @davestarkey (Hi, Dave!) but having a non-zero value in the 3rd byte of a Roland Sysex ID looks suspicious to me. UMP spec p 35 says:
3 bytes Device Manufacturer
This is the System Exclusive ID of the Device manufacturer. For System Exclusive ID values that are only 1 byte in length, the System Exclusive ID value is in the first byte and the remaining 2 bytes are filled with
zeroes: ID 00 00
I’ll try your suggestion in Windows. I have 4 windows machines running various versions. Mostly I do my code development on my Windows Canary PC. 26H1 build 28020.2075 "Installed MIDI Runtime 1.0.17-rc4.25. I am trying to decipher the nupkg stuff. It looks like I am up to date on WinRT.
Only JUCE_USE_WINDOWS_MIDI_SERVICES is required to enable the new UMP support. I’d recommend leaving the WINRT flag disabled unless you know you need it.
Are you building with the Projucer, or with CMake?
If you’re using the Projucer, then you should make sure that you’ve set this flag through the module config pane:
Now we are getting somewhere. I am using projucer. when I set the JUCE_USE_WINDOWS_MIDI_SERVICES enabled, visual studio (2012) will not compile. See the error message above.
Is that the very first error message you see? Based on the errors you’re seeing, it sounds like the Windows MIDI Services package isn’t being found, but I’d expect this to cause missing-include-path errors in juce_audio_devices.cpp first.
Yep you were right again. But I still don’t understand why - \winrt\Microsoft.Windows.Devices.Midi2.h is missing.
It seems to have something to do with an old version of Microsoft.Windows.Devices.Midi2 that is just acting like a ghost. Enough to keep it from compiling but not really there either.
Just for sanities sake I went back to the DemoRunner.app. I get exactly the same results… When I compile with the JUCE_USE_WINDOWS_MIDI_SERVICES on it will not compile. I’ve tried on three different windows variants, with VS2022 and with VS2026 and with my app and with DemoRunner still no luck. I am about to abandon this windows thing for awhile.
Should I be asking Pete Brown or perhaps Michael Loh for help?
What happens if you click the “uninstall” button on the right hand side of the screenshot you shared? That package is from the Customer Preview 2, Feb 28 2025 so it’s a bit outdated.
Projucer-generated projects depended on that version of the Midi2 package until approximately January of this year, when the required version was bumped to 1.0.14-rc.1.209. I’ve got a change in review that’ll bump the version again to the most recently-released version of the package.
Edit: the change is now merged to the develop branch.
My guess is that your Visual Studio project was generated with an old build of the Projucer. Please try the following:
Download the 1.0.14-rc.1.209 and 1.0.17-rc.4.25 packages to your local nuget package source.
Check out JUCE’s develop branch and pull all changes to make sure you’re up to date.
Build and run the Projucer using the project file at extras/Projucer/Builds/VisualStudio2026.
Using this copy of the Projucer, open the .jucer file for your project and resave it.
Finally, open the resaved Visual Studio files for your project and try rebuilding.
I don’t think so; projects using the new MIDI services are building fine on our CI and for me locally, so the problem is almost certainly to do with your nuget configuration or some other aspect of your build.
