Subject: Re: [linux-audio-dev] Introducing DMIDI
From: Dominique Fober (fober_AT_grame.fr)
Date: Fri Dec 21 2001 - 13:01:24 EET
>
>We've clocked sustained, two-handed, fast piano improvisation at about
>20 events per second -- significantly less than the 1000-event "maxing
>out the MIDI cable" number above. For the MWPP target application of
>network musical performance of musical groups, the "number of events
>produced by a human" metric seems more appropriate than the "max out
>the cable" metric. BTW, note that using controllers seems to decrease,
>not increase the number -- its hard to generate data faster than fast
>fingers sweeping across a piano keyboard.
>
>This fast, two-handed playing is the sort of input that yields the
>4700 bits per second figure for MWPP's payload (the RTP way of
>comparing bandwidth is to use packetization payloads, since there are
>good header-compression techniques for RTP, UDP, and IP headers that
>can be brought into play if saving every bit is important).
>
The two-hands piano performance is a simple case. We may consider a more general case where the performance appears as remote control of audio synth. The controler may be a MIDI instrument but also an acoustic instrument which signal is transformed into MIDI using a pitch tracker for example. In this case, you may have a lot of control information (pitch bend, controlers) generated, which rate depends on the tracker audio input buffer size. Using a fft on a 512 frames buffer for example may reach a 200 events per sec. data flow.
More generally, the MIDI limitations in regard of control have been pointed out very early and some proposals have been made for improvements or replacement [see Computer Music Journal Vol 18 No 4 Winter 1994 for example]. This was just to highlight the fact that in common musical situations and depending on what king of control you want, you may rapidly reach a substantial data flow.
>If you wanted to send these "max out the MIDI cable" flows through
>MWPP, you'd have two alternatives using the existing scheme:
>
>
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>|R|R| LEN | MIDI Command Payload ... |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>| Recovery Journal ... |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>-- Place one MIDI command per RTP packet, to minimize time skew
>at the expense of bandwidth.
>
>-- Pack multiple MIDI commands into each MIDI Command Header, and
>pay the price in systematic jitter.
>
not necessary in systematic jitter, you can choose to group the events at regular interval. Of course, the interval length is to be added to the end to end delay but as it is constant, it should have no effect on the jitter. The problem then is to evaluate wether such an interval exists, which meets the real-time performance requirements while providing a real bandwith economy.
>The alternative is a more sophisticated coding of the MIDI Command
>Payload, that codes time deltas between commands; this information
>wouldn't be of use for simple "play when received" implementations,
>but would be of use for implementations which did latency variation
>removal. This would be an example of the sort of thing that could be
>added to a future MWPP I-D revision ...
You can consider delta time between commands or time offsets to the packet timestamp. In both cases, the delta values are bounded by the grouping interval which should be always be kept low. Therefore I don't think that any specific strategy (as in MIDI Files for example) is to be provided to code delta times.
--df
----------------------------------------------
Dominique Fober <fober_AT_grame.fr>
----------------------------------------------
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
This archive was generated by hypermail 2b28 : Fri Dec 21 2001 - 12:55:40 EET