20512 2012-12-24 10:45:24 +0000 MIDIEvent lacking constructor 2013-01-11 08:59:46 +0000 1 1 1 Unclassified AudioWG MIDI API unspecified PC All CLOSED MOVED P2 normal TBD 1 w3c dave.null chris cwilso olivier.thereaux w3c public-audio oldest_to_newest 80563 0 w3c 2012-12-24 10:45:24 +0000 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). 80593 1 cwilso 2012-12-26 17:10:53 +0000 Why should you ever need to construct a MIDIEvent? 80594 2 w3c 2012-12-26 17:17:47 +0000 (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.... 81057 3 chris 2013-01-08 16:45:45 +0000 (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? 81068 4 cwilso 2013-01-08 17:46:04 +0000 (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? 81075 5 w3c 2013-01-08 19:19:28 +0000 (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. 81076 6 cwilso 2013-01-08 19:26:57 +0000 (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 }); 81220 7 olivier.thereaux 2013-01-11 08:59:39 +0000 This issue now tracked at: https://github.com/WebAudio/web-midi-api/issues/1