Add Web MIDI support

[ryanbraganza]

This PR adds support for web exports by using webmidi.

Demo: (code)

Note: webmidi is not supported on all browsers

[Calinou]

Since there is a permission request involved, this should be documented in doc/classes/InputEventMIDI.xml's class description. Something like this:

[b]Note:[/b] On the Web platform, using MIDI input requires a browser permission to be granted first. This permission request is performed when calling [method OS.open_midi_inputs]. MIDI input will not work until the user accepts the permission request.

I would copy the same note at the end of OS' open_midi_inputs description.

doc/classes/OS.xml should have its open_midi_inputs and close_midi_inputs method descriptions modified to mention Web platform support.

PS: It seems OS.get_connected_midi_inputs() will not work on the Web platform if I'm reading the code right. It might be worth documenting this explicitly in its description as well.

[ryanbraganza]

This is where the connected_midi_inputs will be populated.

[ryanbraganza]

PS: It seems OS.get_connected_midi_inputs() will not work on the Web platform if I'm reading the code right. It might be worth documenting this explicitly in its description as well.

Kind of. OS.get_connected_midi_inputs() will be populated asynchronously. https://github.com/godotengine/godot/pull/95928/files#r1726105863

[Mickeon]

The extra note is very good, particularly in line with what I would've written myself.

[Mickeon]

I don't feel like it's necessary to note it here, because the prior description already says that you need to call open_midi_inputs() (whose description contains the details) for this method to work.

If the driver has not been initialized on Web due to lack of permissions, it won't work. The logic feels straightforward.

What isn't straightforward is the asynchronous nature of it, I assume? On Web, are there any chances that the array may "falsely" return empty? If yes, that's worth noting down.

[ryanbraganza]

What isn't straightforward is the asynchronous nature of it, I assume?

Yes, exactly.

On Web, are there any chances that the array may "falsely" return empty? If yes, that's worth noting down.

Apart from the async nature, and the permissions request being denied, the other "false" cases would be:

1. The midi device must be connected at the time of calling open_midi_inputs the first time - since the callbacks are cached after that. I could start listening to the statechange event, and then the array of connected inputs would change over time, but it doesn't look like any of the other MIDI drivers (alsamidi/coremidi/winmidi) do that? For example, every time you receive an InputEventMIDI, the device would need to be checked against the current OS.get_connected_midi_inputs() if you wanted to know which device it came from.
   • (re: "the first time") As a "workaround", you can "refresh" the inputs by calling close_midi_inputs() and then open_midi_inputs() again.
2. Apart from the permissions request being denied, these are the other limitations called out on MDN:
   1. The method must be called in a secure context.
      • But I don't think we need to call this out as being a special requirement for MIDI on web.
   2. Access may be gated by the midi HTTP Permission Policy.
      • Maybe this would be too obscure to note here? The default permissions policy is that midi would be allowed, so whoever is hosting the godot web app would have specifically blocked it for you to run into it.
3. The user's browser not supporting WebMIDI.
   • Mostly Safari, and Firefox for Android

[adamscott]

Good work! I have a few comments, but it's on the right track.

[adamscott]

Suggested change

	[b]Note:[/b] On the Web platform, using MIDI input requires a browser permission to be granted first. This permission request is performed when calling [method open_midi_inputs]. MIDI input will not work until the user accepts the permission request.
	[b]Note:[/b] On the Web platform, using MIDI input requires a browser permission to be granted first. This permission request is performed when calling [method open_midi_inputs]. The browser will restrain from processing MIDI input until the user accepts the permission request.

That's closer to reality. Because if the user declines the permission or takes time to accept, Godot will show no connected devices, but will never know that the permission has been declined.

[ryanbraganza]

Happy to rename any variables, or make any other changes. Just let me know!

[ryanbraganza]

It's been a while, but I am still interested in getting this merged!
Just rebased to fix merge conflicts.

[adamscott]

@ryanbraganza Sorry for the delay! I'm reviewing this PR right now!

[adamscott]

I'm currently investigating why it fails on the proxy_to_thread=yes build.

[adamscott]

So there's few issues, but overall, it's really nice. Once the changes are made, I'll approve and we'll put this in the merge queue.

[adamscott]

As said before, we need to change the signature of on_midi_message() to remove highly detailed types, and we need to add _on_midi_message(). 

Suggested change

	WASM_EXPORT static void on_midi_message(int p_device_index, uint8_t p_status, const uint8_t *p_data, size_t p_data_len);
	WASM_EXPORT static void on_midi_message(int p_device_index, int p_status, const uint8_t *p_data, int p_data_len);
	static void _on_midi_message(int p_device_index, int p_status, const PackedByteArray &p_data, int p_data_len);

[adamscott]

PROXY_TO_PTHREAD_ENABLED is essentially telling emscripten to put most of the logic not on the main thread. But as Godot expects some events to happen on the main thread, we essentially use callable_mp_static() to call deferred on the main thread if the event isn't received on it.

[ryanbraganza]

applied the changes and rebased

[adamscott]

Nice work! I have a few suggestions for the docs, but otherwise, all good!

[adamscott]

cc. @AThousandShips and @Mickeon for my suggested doc changes.

[ryanbraganza]

Applied all suggested changes, squashed, & rebased

[Repiteo]

Thanks!