Re: Assistant Performer

Hi Chris,

Thanks for the reply. These questions are rather academic, since I'm not 
running into problems with unclosed ports and don't actually use/need 
running status (yet?).

>> 1. Should/Do Ports support opening and closing? (I think Jazz 1.2 is 
>> doing this automatically). I'm afraid I don't understand how this is 
>> supposed to work in the Web MIDI API.
> Not directly, no - ports "open" when they are obtained (from 
> getInput/getOutput), and close when they are released.
I just re-read the spec's section 6.2 about getInput. 6.2.4 says:
> If made necessary by the underlying system APIs, reserve the 
> corresponding port for use within the current process.
In other words: If the underlying system wants exclusive use of the port 
for a particular process, it releases the port when the process (i.e. 
window) closes.  Some systems don't require that ports are allocated to 
processes, so the ports don't need to be 'released'. Okay?

>> 2. The current spec says (section 7.3.1):
>>    "Running status is not allowed in the data, as underlying systems 
>> may not support it."
>> But some systems MAY support it, so why do we have to rule it out? Do 
>> some MIDI devices fail to ignore these events if they can't 
>> understand them?
> Any MIDI device that sends running status to a MIDI interface will 
> have it converted to standard messages before it gets into the OS MIDI 
> support anyway (and USB-MIDI does not support it).  What this does, is 
> prevent SENDING of running status messages through the send() method - 
> because otherwise, the Web MIDI implementation would be forced to 
> unroll the running status anyway (to check its validity, and to send 
> to USB-MIDI devices).  Note that this is not unique - CoreMIDI, for 
> example, explicitly disallows running status in a MIDIPacket's data. 
>  (See comment in the data parameter of 
> http://developer.apple.com/library/ios/documentation/CoreMidi/Reference/MIDIServices_Reference/Reference/reference.html#//apple_ref/c/tdef/MIDIPacket.) 
>
>
> This does not prevent you using a MIDI device, connected through a 
> 5-pin DIN connector, that sends running status - that running status 
> just gets converted in the chain before it gets to the Windows/Mac 
> API, or before it hits USB if you're using a USB-MIDI interface.  The 
> only thing this prevents you doing, pragmatically, is ramming data 
> containing running status into a send()'s buffer parameter - and we 
> don't really need message compression in that method, in my opinion, 
> particularly as we'll have to expand in to test validity (and to pass 
> on to CoreMIDI, at least) anyway.
Interesting. Put as simply as possible, that means that a Web MIDI 
application can receive, but not send running status messages. Right?
Section 7.3 is about sending messages (7.3.1 prompted my original question).
Section 8, which is about  receiving messages, says that the (read-only) 
MIDIMessageEvent.data is
> A Uint8Array containing the MIDI data bytes of a single MIDI message.
"a single MIDI message" therefore seems to include Running Status 
messages in this context. Maybe 8.1 should say so explicitly - just as 
7.3.1 explicitly excludes RS?

I ran into Running Status and SysEx messages while creating my Message 
'class', and decided to include them in my MIDI library in case they 
might be useful later. (Its better to get such things out of the way 
while close to the problem.)
With your permission, I'd like to include your explanation (credited, of 
course) in my Running Status documentation. Such things shouldn't get 
lost. :-) Okay?

All the best,
James

p.s. I'd really like to know if my application [1] is running (in 
Safari?) on an Apple computer. I have no way to test that myself. Can 
anyone hear anything? Is the running cursor visible and moving? This can 
be tested without having any MIDI input devices plugged in. Just select 
a score and output device, hit "Start" and then the "Go" button.
j

[1] 
http://james-ingram-act-two.de/open-source/publicAssistantPerformer/assistantPerformer.html