0

As soon as I convert the app, the midiOutOpen function starts to return 1 on being called.

I declare it as:

VB
Shared Function midiOutOpen(ByRef lphMidiOut As IntPtr, uDevID As IntPtr, cBack As IntPtr, dwinst As IntPtr, dwFlags As UInt32) As UInt32

Is there a way to use winmm.dll/midiOutOpen from a packaged app(.appx) that can still be published to MS store? Or some other way to acquire the handle of the midi device (ID 0)?

UnhandledException-InvalidChar
  • 145
  • 1
  • 7
  • So you are having a desktop app that used call this method successfully, right? Then you converted this app to appx. Could you please tell me how do you package your desktop app? – Roy Li - MSFT Oct 12 '21 at 06:19
  • Maybe this is the reason - I'm packing on an offline pc that hasn't been updated for around 5 years. Currently, I'm trying to get my hands on a wim expanded base image, but I find **Docker** to be a horrible app (not working). I'm thinking to put the wim image on the offline computer and then refer to it from Desktop Converter. I've already installed _Project Centennial_ on the offline machine. Am I going the right path? – UnhandledException-InvalidChar Oct 12 '21 at 08:50
  • Just tested... The same behaviour when packed by using VS2019 on a different machine. MidiOutOpen returns 1. – UnhandledException-InvalidChar Oct 12 '21 at 11:45
  • @RoyLi-MSFT Yes, before conversion it returns 0 and a call to midiOutShortMsg produces sound. Addition to my previous comment: I did packaging from source with side-loading. – UnhandledException-InvalidChar Oct 12 '21 at 12:24

1 Answers1

0

It looks like the midiOutOpen function and other APIs like midiOutShortMsg function do not work in desktop bridge apps.

Currently, we'd suggest you use the modern MIDI from Windows.Devices.Midi Namespace. You could refer to the sample here:MIDI sample.

Roy Li - MSFT
  • 8,043
  • 1
  • 7
  • 13