> martijn sipkema writes > > A (variable length?) delta time would enable the receiver to schedule the > events in the packet, but adding this to MWPP isn't trivial, at least the > MIDI payload would have to be parsed to know where a MIDI message > ends, it can't be just sent. This is not a problem I think.
My plans at this point is to read over the RTESP-Wedel.pdf document carefully, and then take a shot at a redesign of the MIDI Command Payload encoding to provide relative timing information for latency variation compensation to work for multi-command packets. There are various tricks other RTP payloads have used for this sort of thing, and in addition the MIDI File encoding has its own delta representation which might be worth borrowing ... > MWPP as it is now has the possibility of combining several MIDI events > into a packet. MIDI events rarely occur at the same time exactly, unless > they are produced by a sequencer application. So for someone playing > a MIDI keyboard this funcionality doesn't make that much sense, or > I at least don't get it. One example is startup, you might want the first packet sent to have a bunch of MIDI Program Change and MIDI Control Change Bank Select commands, to set up presets. The loss of relative timing information doesn't matter in that case ... > One last comment about the RTESP-Wedel.pdf. Millisecond timestamps > are used in it. MWPP uses the audio sampling rate (set in the Session Description Protocol descriptor that creates the session), coded as a 32-bit integer ... any delta-t encoding would work off of that timebase. ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro -------------------------------------------------------------------------
