Subject: [AVT] Re: mwpp comments

From: John Lazzaro <[email-masked]>
Date: Wed, 13 Mar 2002 17:50:19 -0800

Hi martijn,

Thanks for your comments ...

> "Martijn Sipkema" writes:
>
> mwpp now provides sending ahead of MIDI commands. 
>
> This enables a packet to have commands scheduled for a later instance
> than a following packet's commands, i.e. the execution times of the
> commands are not monotonically increasing. I think normally this is
> not wanted and the sender should make sure it sends the commands in
> timed order.

Yes, there should be text to enforce monotonicity across packets, I'll
add this into the next revision.

> "Martijn Sipkema" writes:
>
> Most applications do however have events that they are able to send
> ahead of time and those that it can only send 'late', e.g. midi
> through funcionality in a sequencer application.

Rather than provide this functionality inside a single MWPP stream, an
alternative approach is to send two independent MWPP streams (the
on-time "sequencer" stream and the time-aligned "MIDI through" stream)
and signal to the receiver to merge them (using an SDP parameter that
doesn't yet exist).

The basic idea is, there will be an SDP parameter to denote the "MIDI
jack number" for this MWPP stream. If two MWPP streams have the same
MIDI jack number, the receiver knows that these streams represent
parts of the same "MIDI wire", and that the appropriate action is to
merge the two streams into one as accurately as possible (trivial for
pwe=0, trickier for pwe=1).  The random offset for the RTP timestamps
for all MWPP streams from the same jack should be the same, to
simplify the merge process.

We're going to need this functionality so that SysEx bulk dumps (for
which recovery journal resiliency won't work) can be sent over
reliable transport, without forcing the whole stream to go over
reliable transport.

However, once we have this functionality, we can also use two MWPP UDP
streams with the same MIDI jack number, to handle situations where two
sub-streams need merging, like the MIDI-through case. The advantage
here is that a "plain vanilla" MWPP receiver doesn't have to handle
the out-of-order case -- it can be an enhanced feature, provided by
supporting merging of multiple UDP streams.

Adding complexity of the base layer has a real downside here -- if
potential implementers get intimidated when the first look over the
standard, the odds of them rolling their own custom packetization go
up (especially for TCP folks who won't be using the recovery journal
at all).

Let me know if I'm misunderstanding the situation -- I tried to
understand your specific suggestions about changing the Z bit
semantics, but I couldn't follow it. So, if you need to reference
those suggestions in the followup, could you try re-explaining them,
maybe with a few examples? Thanks ...

-------------------------------------------------------------------------
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: Dominique Fober <[email-masked]>
Date: Thu, 14 Mar 2002 11:51:40 +0100

> "John Lazzaro" writes:

I agree: monotonicity should be enforced across packets.

>Also a MIDI status of 0 could be used to have commands with an execution
>time later than the status 0 to have their execution time set to the status
>0 command's execution time, e.g.

It would be meaning that the sender is doing some kind of remote control. 
Is it a desired purpose of mwpp ?

----------------------------------------------
Dominique Fober               <[email-masked]>
----------------------------------------------
GRAME - Centre National de Creation Musicale -
9 rue du Garet  69001 Lyon France
tel:+33 (0)4 720 737 06 fax:+33 (0)4 720 737 01
http://www.grame.fr

---

From: "Martijn Sipkema" <[email-masked]>
Date: Thu, 14 Mar 2002 13:05:47 +0100

> Is it a desired purpose of mwpp ?

It would allow a correction on scheduled events, but maybe this just makes
mwpp needlesly complex and might not really be needed. It offers correction
in only one direction anyhow.

I guess what the receiver does with time unordered commands could be left
implementation defined, as long as it does not change the command order.

--martijn

---

From: "Martijn Sipkema" <[email-masked]>
Date: Thu, 14 Mar 2002 13:08:20 +0100

> up (especially for TCP folks who won't be using the recovery journal

Well, it could be done this way also, but if this is really less complex?

> maybe with a few examples? Thanks ...

If an application needs to send scheduled commands, i.e. ahead of time,
all commands will have delta times including the first one. It could
indicate
this using Z = 1.

The receiving application will need to have a queue with scheduled
commands and add the commands received with Z = 1 to the queue.
It can then wait for either a new scheduled command to arrive or
the execution time of the first command in the queue, whichever
comes first.

(If a scheduled command with arrives an execution time smaller then
 the some of the commands in the queue it would then change their
execution time to the one of the command it just received and add
the latter to the front of the queue. This would allow a correction.
It would then also be usefull to allow a correction without adding
another command, using a NULL command of some sort.
However for simplicity one could just insist on monotonicity)

For a command that it needs to send immediately, the sender application
will not need a delta time. Also it will normally only need to send one
command since it does not know yet that it needs to send more immediate
commands. When Z = 0 would mean no delta times are used it could
send one or more commands with an implicit 0 delta time meaning either
simultaneous or following commands depending on pwe.

Multiple UDP streams could still be used when seperate scheduled streams
are needed, e.g. constant delay scheduled MIDI through, which would not
be possible within a sinle stream anyway.

Basically what I'm suggesting is to have Z = 0 mean
* implicit 0 delta times
* no monotonicity required with the timestamped commands

--martijn