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

["Martijn Sipkema" <msipkema@sipkema-digital.com>]

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

Also apart from flushing (discarding) the buffer, draining it immediately
might somtimes be usefull.

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

This approach is not unacceptable, but I really hope a better way of
handling
(N)RPNs (and possibly other non-atomic messages) is be possible. I'm not
sure
how they are best handled.
If only for (N)RPNs, the receiver could be mandated to keep state
(current parameter) for a 'midiport' and handle (N)RPNs that way I
suppose...

--martijn






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