sysexEnabled:false even on https
Reported by
ch...@studionexus.ca,
May 20 2018
|
||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.181 Safari/537.36 Steps to reproduce the problem: 1. run site with https enabled, valid cert. 2. webMidi reporting sysex messages are invalid on port 240 What is the expected behavior? Following some online advice, I read that sysex messages could be sent if the connection to the site was https. I swiftly went out and purchased an ssl cert, and began digging into it deeper. I'm developed an online application for launchpads, a light up / drum pad instrument created by novation / focusrite (www.launchpaddr.com). I'm fairly adept with web midi already and already have a working site which users already use for over a year now. without sysex messages, I can still work within the confines laid out by the manufacturer, with very limited flexibility. Without sysex messages, I cannot use full RGB mode, only a limited 128 color palette, so my workaround has been to convert the rgb values into a lookup table which gets referenced on every send. I would really appreciate any advice you could offer getting sysex enabled, as it would greatly improve my user experience. I already have code I've tested in c# / unity working fine, and am working on a webgl Port of it, using webmidi as the backbone. (https://launchpaddr.com/LaunchpaddrPro/) if you need to review my js for the connections, it's in https://launchpaddr.com/LaunchpaddrPro/inc/launchpad.js What went wrong? Everything works, aside from the sysex messages. I think webmidi is groundbreaking for the web and allows for more projects like this to grow. My userbase loves the site, and has sparked others similar to it. Did this work before? No Does this work in other browsers? Yes Chrome version: 66.0.3359.181 Channel: stable OS Version: 10.0 Flash Version: I say No - I think it never worked, because I have yet to see an example of sysex over midi. I can understand the reasoning behind not wanting to allow sysex messages over http, which is why I was convinced getting a certificate would be my solution. I understand that there is also flashing risks that shouldn't be just attempted at whim obviously, but following the documentation from the manufacturer generally doesn't steer you wrong. I'd appreciate any help you could offer. Cheers ! chris@studionexus.ca
,
May 20 2018
My connection is very similar, however, I call it on window.load:
window.addEventListener('load', function() {
if (navigator.requestMIDIAccess({sysex:true})) navigator.requestMIDIAccess().then( onMIDIStarted, onMIDISystemError );
});
function onMIDIStarted ( midi ) {
console.log (midi);
midi.onstatechange = midiConnectionStateChange;
}
midi returns :
inputs:MIDIInputMap {size: 4}
onstatechange:ƒ midiConnectionStateChange( e )
outputs:MIDIOutputMap {size: 4}
sysexEnabled:false
__proto__:MIDIAccess
,
May 20 2018
navigator.requestMIDIAccess({sysex:true}) returns a promise (so your if-condition always returns true, for MIDI supporting browsers and an exception for non-supporting browsers) and you end up requesting MIDI access without sysex: true, so I am not sure your code is correct...
I think you need to check whether navigator.requestMIDIAccess exists and if so, call it with sysex: true -
if (navigator.requestMIDIAccess)
{
navigator.requestMIDIAccess({sysex:true}).then(onMIDIStarted, onMIDISystemError);
}
,
May 20 2018
Also, I believe Web MIDI in general requires HTTPS (and did so from the beginning), whether you ask for sysex: true or not.
,
May 20 2018
I just ran your code from the console and I do see what you get back from a = navigator.requestMIDIAccess({sysex: true});
I was looking for it in the onMidiStarted callback in the midiAccess that gets passed to it. Is this normal ? I would have expected the sysex value to be passed through as well ?
I will try and change up the code to midi=navigator.requestMIDIAccess({sysex: true}); and ignore the midiAccess that gets passed to onMidiStarted for now. Will keep you posted.
,
May 20 2018
No, you are correct, only sysex: true requires HTTPS. http://sites.google.com/a/chromium.org/dev/developers/design-documents/web-midi
,
May 20 2018
No, midi=navigator.requestMIDI... will not work as you expect, because in this case, midi will be promise, not the WebMIDI object. onMIDIStarted should get the WebMIDI instance as the midi parameter (in your code) and the WebMIDI instance should have a sysexEnabled property.
,
May 20 2018
*will be a promise The code and the result I showed in comment 3 is from the console, after expanding the internal [[PromiseValue]] property.
,
May 20 2018
Huzzah! we have liftoff! I've got it up and running in sysex mode with full rgb. Thank you so much for your help!
,
May 20 2018
,
May 20 2018
I am glad it worked. |
||
►
Sign in to add a comment |
||
Comment 1 by phistuck@gmail.com
, May 20 2018On the surface, when querying the API, it seems enabled > a = navigator.requestMIDIAccess({sysex: true}) Promise {<pending>} > a Promise {<resolved>: MIDIAccess} {__proto__: Promise [[PromiseStatus]]: "resolved" [[PromiseValue]]: MIDIAccess {inputs: MIDIInputMap {size: 0} onstatechange: null outputs: MIDIOutputMap {size: 0} sysexEnabled: true __proto__: MIDIAccess} } (I have not actually tried using it) Do you get different results from the API itself?