Re: [AVT] new MWPP I-D ...

[John Lazzaro <lazzaro@CS.Berkeley.EDU>]

> Colin Perkins <csp@csperkins.org> writes:
>
> Can you expand on the use for these untimed commands? What is the reason
> they can't be timestamped as they are generated? 


There are two separate issues here ...


[1] The actual "untimed command" scenario I was considering was a
"panic button" situation. Imagine a sender sending a high-latency MIDI
stream to a receiver, who is buffering 100ms of command time
locally. There are situations where a sender might want to
communicate:

  -- Discard the unexecuted MIDI commands in your local buffer, and
  -- Execute the provided list of MIDI command immediately
     (which would typically be commands that do "reset"
     functionality, like the "All Notes Off" commands).

This is inexpressible in a single MWPP stream, because you can't
"backdate" new commands -- all timestamps are monotonically
increasing. Neither could you really express it using two streams --
you can do the backdating, but you can't express the "flush the
buffer" concept.

I don't know if its really worth the effort to add this into MWPP,
though -- thus the appearance of the item in the "features to ponder"
list and not the "change log for -05.txt" list.


[2] Martijn's actual situation, which relates to MIDI sequencers that
combine low-latency live data with canned MIDI tracks. From his AVT
posting earlier today, it appears we're both in agreement now that
using multiple streams (a high-latency and a low-latency stream) that
both target the same MIDI name space is the best way to implement the
application, rather than add "dual-latency" features to the MWPP spec.

The remaining issues revolve around the text in Appendix C.4 that
mandates sender and receiver requirements to ensure the integrity of
splitting and merging a 16-voice + system MIDI name space into
multiple MWPP streams ... to quote his posting:

> There is, as far as I can see, only one problem with this
> approach. The sender cannot know exactly how both streams are going to
> be merged. The meaning of (N)RPN messages (and perhaps others?) may
> change when interleaved.

Basically, C.4.1 mandates that senders are not allowed to send streams
that have ambiguous merging semantics -- so, in the case of (N)RPNs,
if senders segregate all traffic for a particular MIDI voice channel
to one MWPP stream, all will be well. If this approach is too
restrictive for an application, then senders need to manage the two
streams in a finer-grained way, to ensure unambiguous semantics.


-------------------------------------------------------------------------
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
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt