Subject: Re: [AVT] MWPP notes ...

From: John Lazzaro <[email-masked]>
Date: Thu, 14 Feb 2002 13:45:03 -0800

> Dominique Fober <[email-masked]> writes
>
> Hi,

Hi Dominique!

[...]

>Appendix C. References
>
> You can add to reference 8: "Proceedings of the International
> Conference on WEB Delivering of Music 2001, pages 147-154"

Done.

[...]

>Appendix A.6. Chapter C: MIDI Control Change
>
> When you talk about controlers, could you add the control number
> to their name ? (less ambiguity to the reader: the Sustain pedal
> is commonly named Sustenuto on/off (#66) for example).

Sounds good, I'll do that in the next document update.

[...]

> I can't understand the purpose of the VALUE/COUNT field for some
> controlers: it's sometimes used like a serial number, 

The Sustenuto pedal is a good example. Imagine the pedal is down.

Two packets are sent in succession, the first lifts the pedal, the
second depresses it again. Both packets are lost, as is a third
unrelated packet, but the next packet (with the recovery journal)
arrives OK.

The loss is detected, and we examine the recovery journal. If we coded
the "value" of the pedal, we wouldn't see a change in state: it was
down before and its down now too. 

And because the "unrelated packet" was lost too, the S bits don't clue
us in that a change occurred.

We wouldn't know to release and re-depress the pedal, and depending on
the patch, we could have a sustained sonic cloud that lasted a long
time.

This is the sort of problem the "count" semantics addresses -- it
points to changes that can't be detected by "current state" alone.

Note that as the I-D is written today, thought has only gone into the
Controller numbers that Structured Audio used explicitly -- a very
small subset. Part of the remaining work is going through the
controllers number by number, uncovering these problems, and figuring
out what reasonable steps can be taken in the recovery journal coding
scheme to help out.

[...]

>>Appendix A.3. Chapter N: MIDI NoteOff and NoteOn
>
> [...]
>
>
> Why 16*LOW and 16*HIGH ? as 8*LOW and 8*HIGH is enough and
> may save one byte. [...]

I'll take a close look at this and get back to you; the Chapter N
coding evolved over a few months, and the motivations for the
decisions were complicated -- maybe changing the encoding as you
suggest is the right way to go, but maybe there's a subtle issue
somewhere ... I'll take a look at it.

[...]

> Isn't <rj> redundant with the G bit of the recovery journal ? 

The <rj> SDP flag and the recovery-journal G bit serve different
purposes, so I think both are needed.

The <rj> is useful if you're setting up a TCP stream, or if you're
setting up a UDP stream where you know the recovery journal mechanism
won't be used (possible example: drum machine triggers). You can use
the <rj> parameter to say "this stream only has MIDI command
sections."  No bandwidth is used to send recovery journals, and no
sender effort is used to encode them.

In contrast, the "G" bit is meant to handle two situations:

[1] The sender is trying its best to maintain the guarantee, but
something happens that makes it impossible to do so -- limited CPU
cycles, limited RAM, the MTU packet-size ceiling, etc. Accidents
happen in soft-real-time systems. When the G bit goes from 1 to 0, it
tells the receiver that there's been an accident, and from now on more
paranoia is needed.

[2] In some circumstances, you won't have an RTCP channel, and so its
impossible to maintain the guarantee at all -- but the application is
going to forge ahead, and do its best to recover from lost packets. In
this case, its still very valuable to have the recovery journal sent
in each packet, even if there's no guarantee. For example:

  [a] Receivers can keep a history of the N most recent recovery 
      journals received. When a packet loss is detected, it can
      check the "checkpoint packet seqnum" of the recovery journal
      sent before and after the loss. If the checkpoint packet hasn't
      changed, there's no problem. If the checkpoint packet _has_ changed,
      there may be a problem, but the receiver has many tools to help
      figure out if the problem is real: the receiver knows its own
      history, and it has the trace of N packets to examine.

  [b] If a receiver _does_ detect that there's been a potential failure
      in the guarantee, it may choose to take safety measures on its
      side, as a one time measure -- premature ending NoteOn's that it
      believes may have had a lost NoteOff, for example. Once this 
      one-time measure is taken, future journals can be considered 
      reliable again in many cases (until the next loss occurs).

[...]

> [on Congestion Control]
>
> In particular, control change and pitch bend commands may raise the
> congestion problem. Such flow is generaly made up of continuous
> variations. Filtering is one solution but it would usefull to provide
> a policy in appendix (normative or not ?): raw filtering of one
> message type ? or filtering part of a set of messages so as to keep
> the global shape of the variation ?

It sounds like addition SDP parameters to specify filtering policy for
a MIDI command type is what you want: once a parameter is defined, it
can be used for simple communication (the sender declaring via the SDP
what the policy will be for filtering) or more complicated
negotiations (senders and receivers exchange preferences, etc). The
actual use of SDP to do these sorts of negotiation is being
standardized generally, so the main issue for MWPP is parameter
definition.

That said, this might be the sort of feature that works best defined
in a separate Internet Draft, instead of being mixed into the brief
SDP descriptions in the main MWPP document. Keeping the MWPP memo to a
reasonable size is going to be a challenge, as System Exclusive
support gets added, and so figuring out how to factor out features
into their own documents is a good idea ...

[...]

> Support of system common and real-time messages would provide a nearly
> complete MIDI support.
> 
> Great work !

Thanks -- I'm closing in on updating the MIDI command section so that
it can encode any legal MIDI stream -- things like really long SysEx
message, System Realtime commands embedded in other commands, SysEx
commands where the timing of bytes encode information, etc. 

Once this is done, I'll release a new I-D version for comments, and
then start looking at the recovery journal implications for MIDI
System commands ...

-------------------------------------------------------------------------
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: John Lazzaro <[email-masked]>
Date: Sun, 17 Feb 2002 18:28:31 -0800

> John Lazzaro <[email-masked]> writes:
>
> I'll take a close look at this and get back to you;
>

You are correct; 8*LOW and 8*HIGH is what's actually used in
the sfront MWPP prototype code, I made an error writing up
the I-D. Thanks for catching this ...