Re: [linux-audio-dev] Introducing DMIDI

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] Introducing DMIDI
From: John Lazzaro (lazzaro_AT_CS.Berkeley.EDU)
Date: Tue Dec 18 2001 - 20:10:28 EET


[AVT folks -- CC'ing an MWPP-related thread from the linux-audio-dev
 mailing list ...]

> "martijn sipkema" <msipkema_AT_sipkema-digital.com> writes
>
>> John Lazzaro writes
>>
>> [...]
>>
>> http://www.ietf.org/internet-drafts/draft-lazzaro-avt-mwpp-midi-nmp-00.txt
>>
>
> this is great! it doesn't handle sysex does it? perhaps a seperate
> protocol for sysex dumps over tcp would work. there are some
> synthesizers that use short sysex messages for control data, i don't
> think i have a synthesizer that does that though, but perhaps this is
> just bad design.
>
> --martijn

In its present incarnation, it handles the subset of MIDI that
MPEG 4 Structured Audio uses -- all of the MIDI commands except
for the MIDI System commands (0xF*). Because one of the roles
of the packetization is to be a normative transport for SA,
there would need to be at least one mode of operation where this
restriction is kept, since SA demands it.

However, there are reserved bits in both the "MIDI Command Section"
and in the recovery journal, intentionally left to facilitate MIDI
System implementation (including the SysEx commands), as well as
to facilitate SASL/MIDI integration within Structured Audio. There
are a few distinct issues here:

-- Many of the MIDI System commands fall into the "real-time sync
   of machines that play MIDI data" category:

0xf2 song position
0xf3 song select
0xf8 timing clock
0xfa start
0xfb continue
0xfc stop

   Right now, the packetization rests pretty heavily on the idea
that the players are humans -- the latency over interesting
Internet distances are comparable to the acoustic latency of
musicians in a room (Berkeley-Stanford, 40 miles apart, has
an acoustic latency of 2.4 ft/0.7 meters/2.1ms; Berkeley-Caltech,
375 miles apart, has an acoustic latency of 16ft/4.9 meters/14.2ms).
Just like players can adjust to these latencies in the same room,
they can adjust over the net -- including small shifts in the
latency overy time. Figuring out a sensible way to implement the
real-time sync commands in that context is challenge, because the
players are robots, not humans, and they need to "listen" to the
latency of the link and adjust.

-- The other major MIDI System category is SysEx -- the "reliable
bulk data" usages of SysEx are really a bad match for RTP, and
need to be shunted to a TCP link; the "manufacturer-specific
control data" usage IS a good fit for RTP, though, and the
challenge here is to define a good recovery journal semantics
and bit-encoding that works in the context of MWPP (the recovery
journal is the forward-error-correction system built into MWPP to
gracefully handle lost packets).

----

These two issues (and a few other minor ones) were sufficiently complex, and sufficiently removed from the primary target application of the packetization (identical softsynths on all network nodes, to do network musical performance), that I thought the right thing to do for now was to leave reserved bits in all the right places in the packetization, so that when someone is motivated to solve these problems well, the packetization can be upgraded in a backward-compatible way. If someone is inspired to work on the problem now, I think that's a great idea -- you could write a companion I-D in the AVT working group for MIDI Systems semantics, defining how to handle MIDI Systems inside of MWPP.

--jl

------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro -------------------------------------------------------------------------


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Tue Dec 18 2001 - 20:04:59 EET