This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The MIDIEvent is lacking a way for authors to construct MIDI events. [Constructor(DOMString type, optional MIDIEventInit eventInitDict)] interface MIDIEvent : Event { readonly attribute DOMHighResTimeStamp timestamp; readonly attribute Uint8Array data; }; dictionary MIDIEventInit : EventInit { any data; }; (note that I left data as any, assuming UInt8Array conversion will be performed automatically).
Why should you ever need to construct a MIDIEvent?
(In reply to comment #1) > Why should you ever need to construct a MIDIEvent? This one is for consistency with the rest of the Web platform (every event in the platform has a public constructor, AFAIK). Use case is primarily for testing through constructing and firing synthetic events....
(In reply to comment #1) > Why should you ever need to construct a MIDIEvent? Because you are writing a sequencer, auto-chord maker, arpeggiator, etc?
(In reply to comment #3) > (In reply to comment #1) > > Why should you ever need to construct a MIDIEvent? > > Because you are writing a sequencer, auto-chord maker, arpeggiator, etc? That's a great reason why you should need to maintain MIDI event data - but not really a justification for why you would want to create an Event-derived object that contains said data. This isn't just a data container - it has all the Event stuff, too - and it's no longer used for sending data. (For an arpeggiator, for example, you'd just create the data array for each note and call send().) Marcos' "primarily for testing, firing synthetic events" is a justifiable reason, I suppose; however, I'm not sure I see how this is done in other specs. Is there a TouchEvent constructor somewhere?
(In reply to comment #4) > Marcos' "primarily for testing, firing synthetic events" is a justifiable > reason, I suppose; however, I'm not sure I see how this is done in other > specs. Is there a TouchEvent constructor somewhere? The TouchEvent spec is not a good guide as it lacks a link to UIEvent (maybe that spec has not been well reviewed, but not sure). I recommend looking at the new DOM UI Events spec... there is a whole section on constructors for events (the spec is currently not loading well in Chrome, so use FF or something else to view it): https://dvcs.w3.org/hg/d4e/raw-file/tip/source_respec.htm As an aside, the Event interface, from which MIDIEvent inherits, has a constructor. But I'm having trouble finding in WebIDL what it means to inherit from an interface that has a constructor on it.
(In reply to comment #5) > (In reply to comment #4) > > Marcos' "primarily for testing, firing synthetic events" is a justifiable > > reason, I suppose; however, I'm not sure I see how this is done in other > > specs. Is there a TouchEvent constructor somewhere? > > The TouchEvent spec is not a good guide as it lacks a link to UIEvent (maybe > that spec has not been well reviewed, but not sure). > > I recommend looking at the new DOM UI Events spec... there is a whole > section on constructors for events (the spec is currently not loading well > in Chrome, so use FF or something else to view it): > > https://dvcs.w3.org/hg/d4e/raw-file/tip/source_respec.htm > > As an aside, the Event interface, from which MIDIEvent inherits, has a > constructor. But I'm having trouble finding in WebIDL what it means to > inherit from an interface that has a constructor on it. I would think this would be symmetric with UI Events - so the answer to "how do I synthesize a MIDIEvent" would be: var event = new Event("message", {data: [...], timestamp: t });
This issue now tracked at: https://github.com/WebAudio/web-midi-api/issues/1