Listen for device connect/disconnect event

[mat1jaczyyy]

When a MIDI device is connected, its ports become available and can be checked for manually via RtMidiDeviceManager.

I was trying to come up with a way to turn this into an event, so that I can listen for when a device is connected or disconnected (or, when a MIDI port appears or disappears from the list). Tracing the code, I realized the manual checks directly query RtMidi's available ports via GetPortCount and GetPortName.

I don't know if there is a different call in the RtMidi API that can, similarly to the input listener callback, listen to changes in available ports? The event doesn't even necessarily need to carry information of what's changed - we can simply ask for the list manually once the event is fired and our method executes.

[mat1jaczyyy]

@micdah ?

[micdah]

@mat1jaczyyy Just took a look into rtmidi to see if there are any promising handles we could expose through the C-interface we are using - but alas I cannot find anything useful.

As far as I can see, it is not implemented in rtmidi - each platform might make available a system event about when midi devices are added/removed, but seems like it's not implemented. Might also be because such event is not consistently available on all platforms.

Would require to figure out how to receive those events via Windows MM and macOS Core as minimum, and at best including ALSA and Jack as well as these are the underlying system-specific API's used.

[micdah]

Of course one could do a poll-based solution as well, but that would require a timer or other thread-based entity doing a regular poll.

I think such a thing might be better placed in the application though, I wouldn't expect a library to start a background thread for doing a regular background poll.

[mat1jaczyyy]

Oh, so RtMidi asks the system as well when we ask it to enumerate the devices? If so, it's going to be a tricky thing to implement. For now, I'll stick to a 200ms Timer, should be enough. Thanks for the clarification

[mat1jaczyyy]

Is this worth making an issue about in the main rtmidi repository?

[micdah]

Just had a look in WinMM, to see if there were any Windows API's to support such an event, and I cannot seem to find anything: https://msdn.microsoft.com/en-us/library/windows/desktop/dd798495(v=vs.85).aspx

Might also be why there is nothing in rtmidi, because it's not widely supported or easily available

[mat1jaczyyy]

Okay. I know for sure Ableton does it on both Windows and macOS. Maybe they have a poll based solution as well. I will let you know how it works out for me in the end

[mat1jaczyyy]

After finishing other work, I finally got around to implementing a MIDI device management system with hot-plugging support (with a 200ms periodic Timer) on the application side.

While I believe my implementation should work okay, it actually doesn't work because it seems RtMidi.Core only gets the MIDI devices when the app is initalized - and never changes the info enumerables found in the MIDI manager. This means unplugging a currently connected device doesn't remove it from the list, and connecting a new device doesn't add it to the list - the enumerables never change.

Obviously, upon inspecting the source and debugging for a while, RtMidi.Core is asking RtMidi for a new port count and port names. It seems that the issue is in the underlying RtMidi library - it always returns the same port count and the same port names. Maybe we are somewhere forgetting to ask RtMidi to re-enumerate USB devices again? I'm not sure.

This severely limits my application and would be nice if it could be addressed as soon as possible. The original issue report is not important anymore, because an application-side implementation will most likely work properly to achieve behavior that is very close to the original report.

@micdah

[mat1jaczyyy]

After further inspection it seems the input/output device info enumerables properly update on Windows, but not on macOS which is my main working environment. I am targeting both operating systems.

[micdah]

That is strange, I have just tested this sample program:

while (true)
{
    Log.Information("Found the following available devices");

    foreach (var info in MidiDeviceManager.Default.InputDevices)
        Log.Information("  {Name}", info.Name);

    Thread.Sleep(TimeSpan.FromSeconds(2));
}

I ran it with no MIDI devices connected, and then connect a device, and proceeded to disconnect it again. This is the output.

2018-09-19 17:49:22 INF Found the following available devices
2018-09-19 17:49:23 DBG Creating default input device
2018-09-19 17:49:23 DBG Setting types to ignore
2018-09-19 17:49:23 DBG Setting input callback
2018-09-19 17:49:25 INF Found the following available devices
2018-09-19 17:49:27 INF Found the following available devices
2018-09-19 17:49:29 INF Found the following available devices
2018-09-19 17:49:29 INF   "X-TOUCH MINI"
2018-09-19 17:49:31 INF Found the following available devices
2018-09-19 17:49:31 INF   "X-TOUCH MINI"
2018-09-19 17:49:33 INF Found the following available devices
2018-09-19 17:49:35 INF Found the following available devices

Process finished with exit code 0.

I'm running from macOS 10.13.6 - running it via .Net Core 2.1.402.

[micdah]

For good meassure, I also tried compiling the program using mono-mdk (5.14.0.177) and running the code - same output. So it doesn't seem to be related to the runtime either.

Used included nuget and msbuild binaries from mono-mdk to build the solution (msbuild /t:Publish) and then simply ran using mono RtMidi.Core.Samples.dll

[mat1jaczyyy]

After testing your sample, seems like you're in the right. Must be I've messed up somewhere in my application. I'll have a look, sorry for the confusion.

Original issue about connection events could still be addressed at some point in the future so I'm leaving this open.

[mat1jaczyyy]

Looks like it was the Timer doing weird stuff. Instead I made the function async and created a background thread for the using Task.Run. I have my device checking code run in a while (true) there with a Thread.Sleep to not waste CPU resources. Not sure why, but that seems to work.

Here's the commit should you want to take a look inside.

[mat1jaczyyy]

It's me again! 😝 Been getting a weird segfault recently after idling my app for just a few minutes.

Pinpointed it to the thread where I'm checking for devices every 200ms. I guess this happens if the thread falls behind or something. Really no idea what it is about, but that seems to have eliminated that. I guess I'm falling back to manually rescanning device for the time being.

I'm really dumbfounded about what's actually going on, thought I'd just document it here.

[micdah]

@mat1jaczyyy We discussed having some timer-based polling on devices and firing an event when new devices become available - is this still something you would like to see included in RtMidi.Core?

As we discussed there doesn't seem to be any such event from the underlying rtmidi library that we could make use of, so regular polling seems to be the only other option.

Would we be interested in disconnection events as well, i.e. when a device previously available becomes unavailable?

[mat1jaczyyy]

well, i do polling every 100ms in my app in a background thread right now, but i absolutely will segfault UNLESS i write something to the console in the timer event. i have no clue why. so my timer will output a simple "rescan" text into the console, and it works. this would be nice to have in the library, for sure though...

[micdah]

well, i do polling every 100ms in my app in a background thread right now, but i absolutely will segfault UNLESS i write something to the console in the timer event. i have no clue why. so my timer will output a simple "rescan" text into the console, and it works. this would be nice to have in the library, for sure though...

Looked into the commit you linked to earlier, assuming it's the code in there you are referring to.

Cannot see any obvious reason for a segfault either - although I did notice that you only call Refresh() when calling Start() once - so wouldn't the timer loop continouly look at the same old array of input and output devices?

The code might have changed since that commit of course, just something that popped into my eyes.

Another thought I had, is if the loop was a no-op, I'm not sure if C# might do some optimization. In general segfaults are rare in managed world :smile:

[mat1jaczyyy]

Check out https://github.com/mat1jaczyyy/apollo-studio/blob/master/Apollo/Core/MIDI.cs BTW, I no longer use RtMidi.Core directly, I stripped away all the stuff I didn't need like other MIDI messages as well as validation, for a slight performance boost (I send a LOT of midi, dozens of kB/s and USB is finnicky)

[slajerek]

Hotplugging would be really nice to have as this is a much better UX (as an event, not polling), enumerating in runtime works, so the solution to have a timer is a workaround but it is always better to not eat resources for polling.

[micdah]

Closing issue as there is currently no available API which can provide an event on device connect/disconnect, so any solution would be based on polling - in which case I think it's better for the user application to decide which polling strategy to take (which interval, potential exponential backoff strategy etc.).

[fedekrum]

FROM CHATGPT 4

Mac

In CoreMIDI on Mac, there is an event that is triggered when a MIDI interface is connected or disconnected. This is handled through MIDI notifications. You can use MIDIClientCreate to create a MIDI client and then MIDINotification to receive notifications when MIDI devices are connected or disconnected.

The basic process would be something like this:

1. Create a MIDI Client: Use MIDIClientCreate to create a MIDI client in your application.
2. Set Up a Notification Callback: Define a callback function that will be called whenever there is a MIDI notification. This function must match the MIDINotifyProc function type.
3. Register the Callback: During the creation of the MIDI client, you'll register this callback function to be called when relevant MIDI events occur.

When a MIDI device is connected or disconnected, your callback function will be called with a notification indicating the type of event (such as kMIDIMsgObjectAdded or kMIDIMsgObjectRemoved). You can use this information to update the list of available MIDI devices in your application.

It's important to check the CoreMIDI documentation for specific details on how to implement these features and handle the different types of MIDI notifications.

Linux

For Linux, handling MIDI device connection and disconnection events can be done using both ALSA (Advanced Linux Sound Architecture) and JACK (Jack Audio Connection Kit). Here's an overview of how you can manage these events in both systems:

ALSA (Advanced Linux Sound Architecture)

1. Sequencer Client: First, create a sequencer client using ALSA's API. This is done using functions like snd_seq_open.
2. Subscribe to System Announcements: Once you have a sequencer client, you need to subscribe to system announcements. This allows you to receive notifications about MIDI devices being connected or disconnected.
3. Event Loop: Implement an event loop that listens for ALSA events. When a device is connected or disconnected, ALSA generates a SND_SEQ_EVENT_PORT_START or SND_SEQ_EVENT_PORT_EXIT event, respectively.
4. Handling Events: In your event loop, handle these events to update the state of your application accordingly.

JACK (Jack Audio Connection Kit)

1. Create a JACK Client: Start by creating a client using JACK's API with functions like jack_client_open.
2. Register Callbacks: JACK allows you to register callbacks for various events. You can use jack_set_port_connect_callback to set a callback function that will be called whenever ports are connected or disconnected.
3. Callback Implementation: In your callback function, you can check the status of ports to determine if a MIDI device has been connected or disconnected.
4. Managing Connections: Use JACK's API to manage and monitor the connections between your application and MIDI devices.

Additional Notes:

• ALSA is more directly involved with MIDI devices and is often used for lower-level MIDI control.
• JACK excels in routing audio and MIDI between different applications and devices and is preferred in scenarios where complex routing is required.
• It's important to familiarize yourself with the specific APIs and callbacks of each system, as they offer different functionalities and ways to handle MIDI events.

Both ALSA and JACK are powerful tools for handling MIDI on Linux, and your choice between them may depend on the specific requirements of your application, such as whether you need advanced routing capabilities (JACK) or direct MIDI hardware control (ALSA).

Windows

On Windows, handling MIDI device connection and disconnection events in the Multimedia system involves using the Windows Multimedia API (WinMM). Here's a general outline of how you can manage these events:

1. MIDI Input and Output Devices: First, you'll need to enumerate available MIDI input and output devices using functions like midiInGetNumDevs and midiOutGetNumDevs. This gives you the number of MIDI devices currently connected.
2. Device Information: To get detailed information about each device, use midiInGetDevCaps and midiOutGetDevCaps. This allows you to retrieve the capabilities and the status of each MIDI device.
3. Opening and Closing Devices: Use midiInOpen and midiOutOpen to open a MIDI device for use, and midiInClose and midiOutClose to close it when done.
4. Monitoring Device Changes: Windows does not natively provide direct notifications for MIDI device connections and disconnections like CoreMIDI in macOS. Instead, you periodically check for changes in the number of devices or poll device information. This can be done by regularly calling the device enumeration functions and comparing with previous states.
5. Responding to Device Changes: When your polling detects a change (like a new device appearing or an existing one disappearing), you can update your application's state and user interface to reflect these changes.

Additional Considerations:

• Polling for Changes: Since Windows doesn't offer direct event notifications for MIDI device connections/disconnections, polling is a common workaround. However, this method may not be as immediate or efficient as event-driven notifications available in other operating systems.
• Using Higher-Level Libraries: To simplify MIDI handling and avoid low-level API calls, you might consider using higher-level libraries or frameworks that abstract these details. Libraries like RtMidi or frameworks like JUCE provide more straightforward and cross-platform ways to handle MIDI devices.
• Device IDs: In Windows Multimedia API, MIDI devices are identified by their IDs. These IDs can change if devices are added or removed, so your application needs to handle such changes gracefully.

Direct support for MIDI device connection/disconnection events might vary depending on the version of Windows and its MIDI implementation. Using external libraries may be an option.