Subject: [AVT] Re: Comments (1) on draft-ietf-avt-mwpp-midi-rtp-02.txt

From: John Lazzaro <[email-masked]>
Date: Thu, 14 Mar 2002 11:50:18 -0800

There's a few threads in motion now on MWPP issues, I think this
posting should conclude one of them ...

---

>> John Lazzaro writes:
>>
>> This makes sense; unless I hear objections otherwise, I'll delete
>> interleaving in the next revision.

> Martijn Sipkema writes:
>
> The interleaving of MIDI system realtime commands will not
> be deleted right?

Correct, interleaving System Realtime between SysEx segments remains
legal, in keeping with what MIDI permits on a MIDI cable.

---

>> John Lazzaro writes:
>>
>> This particular solution introduces a parsing ambiguity, any trailing
>> 0b1xxxxxxx octet patterns in a MIDI Command field need to be of known
>> length.
>>
>> [...]
>>
>> But there are alternative solutions to this issue, I'll find one with
>> good properties and incorporate it into the next revision.

> Martijn Sipkema writes:
>
> You are right.
>
> [...]
>
> It will have to be terminated, perhaps using some other status byte
> then 0xf7 (0xf0?).

There are four legal ways for a delta time to say "zero":

1:  0x00
2:  0x10 0x00
3:  0x10 0x10 0x00
4:  0x10 0x10 0x10 0x00

One possible way to code the dropped F7 construction: MWPP declares
that the only "normal" way to express the a zero delta time is 0x00,
and reserves the other three types of zeros to encode special
situations, such as:

  If the command following a verbatim SysEx command, or the final 
  segment of a segmented SysEx command, uses the 0x10 0x00 delta
  time, it signifies the dropped-F7 construction. 

I think there's no parsing issues with this approach ... and is
probably adaptable to whatever delta-time semantics we end up with for
pwe=0 and pwe=1.

-------------------------------------------------------------------------
John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley
lazzaro [at] cs [dot] berkeley [dot] edu     www.cs.berkeley.edu/~lazzaro
-------------------------------------------------------------------------

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: "Martijn Sipkema" <[email-masked]>
Date: Thu, 14 Mar 2002 21:51:04 +0100

> probably adaptable to whatever delta-time semantics we end up with for

Should the 0x10 0x00 then be followed by a delta time or is a sysex
segment/command not ending with a oxf7 only allowed to be followed
by a 0 delta time?

If yes, why?

If no, why use 2 bytes? As i suggested earlier one could use a any status
byte, except 0xf7/0xf0 (as I erroniously suggested using) for terminating 
the sysex segment/command, e.g. 0xff.

Also why was:

    -----------------------------------------------------------
   | Sublist Position |  Head Status Octet | Tail Status Octet |
   |-----------------------------------------------------------|
   |    first         |       0xF0        |       0xF0         |
   |-----------------------------------------------------------|
   |    middle        |       0xF7        |       0xF7         |
   |-----------------------------------------------------------|
   |    last          |       0xF7        |       0xF0         |
    -----------------------------------------------------------

   chosen instead of:

    -----------------------------------------------------------
   | Sublist Position |  Head Status Octet | Tail Status Octet |
   |-----------------------------------------------------------|
   |    first         |       0xF0        |       0xF0         |
   |-----------------------------------------------------------|
   |    middle        |       0xF7        |       0xF0         |
   |-----------------------------------------------------------|
   |    last          |       0xF7        |       0xF7         |
    -----------------------------------------------------------

, which would be more like the wire protocol where a sysex
command is also terminated with a 0xf7.

--martijn