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

From: John Lazzaro <[email-masked]>
Date: Sun, 22 Sep 2002 16:49:49 -0700

Hi everyone,

	Just submitted the -05.txt draft for MWPP:

http://www.cs.berkeley.edu/~lazzaro/sa/pubs/txt/current-mwpp.txt

	The change log is 3 pages long, so I won't summarize the
additions here. The road ahead for MWPP:

  [1] Write the first draft of the BCP for sending and receiving
      MWPP RTP streams, hopefully in time for the Atlanta deadline
      (although this may be an optimistic schedule). Should this
      be an individual submission, or an WG item?

  [2] Revisit a few "big ticket" requests folks have made for 
      features in MWPP, that I've deferred for further research:

        -- The MWPP "recovery journal" is true to its name: it's
           a shallow, sketchy history for recovery, not the deep
           complete history of the recent past that classical
           redundancy schemes (RFC 2198, RFC 2733) offer. It may
           make sense to incorporate optional deep redundancy in
           the recovery journal, for efficiency reasons and to
           simplify streaming server design (Herbie Robinson).

        -- An "immediate execution" option -- a way to send MIDI 
           commands that truly have no timestamp, but instead have
           an "execute as soon as delivered" semantics relative to
           other timestampped commands. This is not possible to do by 
           manipulating timestamps in a single MWPP stream, because
           timestamps must be monotonically increasing, in order to
           simplify life for the recovery journal system. The current
           solution is two synchronized streams, the normal stream and
           an "emergency" stream whose timestamps lag (Martijn Sipkema).

   [3] Combine the "big ticket" decisions with received comments
       on -05.txt and bugfixes found during the BCP draft writing,
       to write (potentially) the first candidate for Last Call.

-------------------------------------------------------------------------
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: Mon, 23 Sep 2002 14:17:02 +0100

>            an "emergency" stream whose timestamps lag (Martijn Sipkema).

I've thought about this some more and perhaps it is better to handle this
using two streams. A typical sequencer application would use a 'scheduled'
stream for playback and an 'immediate' stream for MIDI through, both are
to be merged at the receiver.
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.
As stated in C.4.1 of the current draft "Senders must partition
the name space so that the rendered MIDI performance does not contain
indefinite artifacts.". When using two streams for playback/through this is
generally not the case, but it doesn't really matter. A user will expect
problems
when playing (through) on a channel that is also used for playback. (N)RPN
changes should just work though.
A solution could be to always send complete (N)RPN changes, i.e. set
the current parameter and change it, and to make sure this sequence does
not get interleaved with other (N)RPN messages, or more general to have
the sender be able to mark a sequence as 'atomic' so it won't be interleaved
(except for MIDI realtime messages).
Or perhaps the receiver should handle merging (N)RPNs.

--martijn

---

From: Colin Perkins <[email-masked]>
Date: Mon, 23 Sep 2002 10:29:55 -0400

>      be an individual submission, or an WG item?

Initially, it should be an individual submission.

>           an "emergency" stream whose timestamps lag (Martijn Sipkema).

Can you expand on the use for these untimed commands? What is the reason
they can't be timestamped as they are generated? 

>       to write (potentially) the first candidate for Last Call.

Cheers,
colin