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

[Colin Perkins <csp@csperkins.org>]

--> John Lazzaro writes:
>
>> 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.

How much of the playout model do you want to specify? The usual RTP semantic 
is that buffering is a local issue for the receiver, with the RTP timestamp
representing the timeline at the sender. You could make the sender aware of
the buffering at all receivers, but that would add significant complexity,
which may not be worthwhile.

>[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.

Multiple streams would seem to be the correct approach here, especially
since the usual RTP synchronisation mechanisms will take care of the dual
latency requirement. 

>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.

Seems reasonable, although I'm hardly a MIDI expert.

Cheers,
Colin
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt