WebMidi is only supported in chromium-based browsers so this can't be Hotlist-Interop: http://caniuse.com/#feat=midi

This appears to be fixed in Canary 60.0.3088.3

Closing this issue as per comment #3.
Please feel free to raise a new issue if you face any issue on chrome further.

Thanks,

This issue appears to have returned in Canary 60.0.3093.0. I'm unclear why this is being marked as wontFix. The issue is a chromium issue, it used to work on previous builds and webMIDI still works on the release build. This is a bug.  

Can you manually set a flag of chrome://flags/#enable-midi-manager-dynamic-instantiation to Disabled?

Canary and Dev channels run a field study test of incomplete new backend running mode on macOS and Android.

This seems to be fixed in Canary 60.0.3094.0 again. I will try out the dynamic instantiation flag when this breaks again. Thanks for the info on the midi-manager flag and the field study.

Thank you for the feedback. Now the 'Default' mode of the flag enables the new mode for 50% browser sessions in Dev and Canary. So if you want a stable MIDI functionality on Dev and Canary, please disable it explicitly. Sorry for inconvenience.

We have been getting a lot of user error reports lately with this error on ChromeOS 9334.72 running Chrome 58 and ChromeOS 9460.60 running Chrome 59 here at Soundtrap. 

Thank you for contacting.
We have noticed a problem that some Chromebook devices using Linux kernel 4.4 can not allow to use MIDI from Web MIDI API. We already fixed this problem on head, and is trying to merge the fix to m60 beta branch.

See the  issue 722143  for details.

This issue appears to have resurfaced in Canary 61.0.3136.0. i have #enable-midi-manager-dynamic-instantiation on default.
This probably also affects this bug:
https://bugs.chromium.org/p/chromium/issues/detail?id=725448

 Issue 736739  has been merged into this issue.

Now the dynamic instantiation mode should work even on mac after 62.0.3175.0.

I'm still experiencing this issue on 62.0.3202.94 on Mac OS 10.11.6; It's somewhat intermittent but it appears to happen after opening the page a second time, after that page was visited and the tab or window closed. But it always seems to work the first time, then never work after it fails.

I can confirm what ledlam...@ is reporting, also on latest stable version 62.0.3202.94 and Mac OS 10.12.6. We've also received a number of bug reports with the above error (Platform dependent initialization failed) from our users with this version of Chrome on Mac OS. In my case restarting the browser caused the error to go away. If you have any trouble reproducing the problem we can look into providing more concrete reproduction steps. Thanks!

I investigated this problem a little, but macOS's Core MIDI seems to start failing on MIDIClientCreate randomly. Let me flip the Chrome runtime configuration flag for m62 to be the legacy mode.

You should be able to workaround this issue by manually flipping the configuration to "Disabled" from chrome://flags/#enable-midi-manager-dynamic-instantiation. But once my configuration change is distributed, this manual change won't be needed.

I also get this consistently with Canary 64 (the chrome://flags/#enable-midi-manager-dynamic-instantiation option is not available in Canary 64) so the only option is to restart the browser every time this happens. I would be happy to test this out on Mac whenever needed. 

I was testing something, when suddenly I saw the 'InvalidStateError: Platform dependent initialisation failed.' - googled it and found this thread.

I've never seen this error before, and I test midi a lot (I am a manufacturer of a MIDI device)

Here is my version info:

Google Chrome	62.0.3202.94 (Official Build) (64-bit)
Revision	4fd852a98d66564c88736c017b0a0b0478e885ad-refs/branch-heads/3202@{#789}
OS	Mac OS X
JavaScript	V8 6.2.414.42
Flash	27.0.0.187 /Users/paulobarcelos/Library/Application Support/Google/Chrome/PepperFlash/27.0.0.187/PepperFlashPlayer.plugin
User Agent	Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36
Command Line	/Applications/Google Chrome.app/Contents/MacOS/Google Chrome -psn_0_36873 --restore-last-session --flag-switches-begin --flag-switches-end
Executable Path	/Applications/Google Chrome.app/Contents/MacOS/Google Chrome
Profile Path	/Users/paulobarcelos/Library/Application Support/Google/Chrome/Default
Variations	c134752e-ca7d8d80
c68ab9a3-3f4a17df
3095aa95-3f4a17df
7c1bc906-f55a7974
47e5d3db-3d47f4f4
1210a805-ecd831c
d43bf3e5-bd7cd813
ba3f87da-45bda656
79616653-3f4a17df
ed7ba060-91c810ef
9e201a2b-6e3ce1c
5b3ed0a1-3f4a17df
68812885-4d2fac87
684d1cdf-160692dc
b684f56f-4d2fac87
f347910c-3d47f4f4
9773d3bd-f23d1dea
99144bc3-3cc2175e
9e5c75f1-2ad3bd2f
e79c5ffa-28ad44a
f79cb77b-3d47f4f4
27219e67-b2047178
4ea303a6-ecbb250e
d92562a9-ca7d8d80
1c2f7bbf-ca7d8d80
b2f0086-93053e47
ef25c1eb-ca7d8d80
494d8760-21549ebe
f47ae82a-86f22ee5
3ac60855-486e2a9c
f296190c-2502111b
4442aae2-a90023b1
ed1d377-e1cc0f14
75f0f0a0-d7f6b13c
e2b18481-a5822863
e7e71889-e1cc0f14
94e68624-803f8fc4
828a5926-9d7acf42
da4aaa01-ca7d8d80

Deleted: Screen Shot 2017-11-21 at 15.44.34.png 19.9 KB

	Screen Shot 2017-11-21 at 15.44.34.png 19.9 KB View Download

I just push the server side configuration to distribute the new setting. You will pick up a legacy mode by default in a few days on the Stable 62.

For other channels, I'm trying to find and fix the issue, and merge the fix to each branch. If I missed the deadline, I will restore the flag even on Canary/Dev. 

> #21

b684f56f-4d2fac87 in the last variations list is the code to use the new broken mode. Sorry for inconvenience.
Once you get the legacy mode to work without this problem, it will be changed to b684f56f-9ab525bc, or you can manually change the mode at chrome://flags/#enable-midi-manager-dynamic-instantiation by changing Default to Disable.

Hum... it looks that Chrome hits OS side issue, but I'm not 100% sure.

My repro step is
1. open chrome and navigate to a page that uses Web MIDI
2. reload repeatedly, it just works
3. open another tab, but do not navigate at this point
4. close the first tab that shows a page using Web MIDI
5. navigate to a page that use Web MIDI in the second tab

With this step, I can reproduce the issue almost every time usually, but stop reproducing it sometime. Seems like it rarely happens during I open Audio MIDI setting app.

What happens when it fails.

- the last shutdown seems to be fine, Core MIDI's MIDIClientDispose returned 0
- but the very last initialization fails because Core MIDI's MIDIClientCreate returns -50

macOS start providing a new version of MIDIClientCreate, MIDIClientCreateWithBlock from the 10.11, but I could not try it since Chrome build expects code can compile for 10.10.

Ah, I can reproduce it just by reloading the same page, but it rarely happens in comparison with the last my repro step. Using a different client name does not help.

For 62 and 63: New configurations will be distributed on a few days, and your Chrome will be switched back to the compatible mode with the 61.

For 64: I will submit a workaround to avoid the OS issue. But it is a thing to disable the new mode virtually. So, I won't restore the chrome://flags/#enable-midi-manager-dynamic-instantiation on 64, but 64+ will run on the modified legacy mode that avoid the Core MIDI issue.

A record for myself: Calling MIDIClientDispose on the ClientTaskRunner did not solve the problem.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/bbad635161243d7ed619724a8d63b54b94a7e7a4

commit bbad635161243d7ed619724a8d63b54b94a7e7a4
Author: Takashi Toyoshima <toyoshim@chromium.org>
Date: Mon Nov 27 10:00:16 2017

MidiService: do not destruct MidiManagerMac to avoid Core MIDI errors

This patch virtually disables the dynamic instantiation mode on macOS,
it keeps the first MidiManagerMac instance during the browser lifetime.

But, it still instantiates the MidiManagerMac on demand, and keep the
thread model to be consistent with other platforms.

Since there is not clear benefit to have a real dynamic instantiation
mode on macOS, we would keep this workaround for a while.

Bug:  718140 
Change-Id: I63c9a6674d7ab2114c682059a4c625b7e8ccdef7
Reviewed-on: https://chromium-review.googlesource.com/788721
Commit-Queue: Takashi Toyoshima <toyoshim@chromium.org>
Reviewed-by: Yutaka Hirano <yhirano@chromium.org>
Cr-Commit-Position: refs/heads/master@{#519264}
[modify] https://crrev.com/bbad635161243d7ed619724a8d63b54b94a7e7a4/media/midi/midi_service.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/6fec81537a19d88541e96e5979f8683b08a98967

commit 6fec81537a19d88541e96e5979f8683b08a98967
Author: Takashi Toyoshima <toyoshim@chromium.org>
Date: Tue Nov 28 11:21:20 2017

MidiManager: registers failed clients to finalize correctly

EndSession will fail if the client is not registered, and it results
in leaking the MidiManager instance inside MidiService when the dynamic
instantiation mode is enabled.

This happens when the StartSession fails and returns non-Result::OK
status. Once a failure happens in the MidiManager initialization,
the failed MidiManager instance is living until the browser shutdown,
and continues to return the same error.

This patch changes to register clients even on failure cases, and
allows to succeed EndSession call from the failed client.

This does not fix the macOS specific dynamic instantiation mode issue,
but would help to save it from potential similar cases on all platforms.

Bug:  718140 
Change-Id: I1b6ddf3020fd9f9a26c4c1f0e30bcd7974be2894
Reviewed-on: https://chromium-review.googlesource.com/788720
Reviewed-by: Yutaka Hirano <yhirano@chromium.org>
Commit-Queue: Takashi Toyoshima <toyoshim@chromium.org>
Cr-Commit-Position: refs/heads/master@{#519653}
[modify] https://crrev.com/6fec81537a19d88541e96e5979f8683b08a98967/media/midi/midi_manager.cc
[modify] https://crrev.com/6fec81537a19d88541e96e5979f8683b08a98967/media/midi/midi_manager_unittest.cc