Magazine Archive

Home -> Magazines -> Issues -> Articles in this issue -> View

Delaying Tactics

MIDI/Audio Delays

MT's Charter for those suffering delays on the MIDI line.


Much has been said about the speed of MIDI - or lack of it - but there's sometimes more to a late snare beat than a five-pin din plug.


COMPLAINTS ABOUT THE timing characteristics of MIDI aren't exactly hot news. Most critics claim that the transfer rate of MIDI data is too slow for certain musical applications. And in fairness, there's no doubt that the serial nature of MIDI can lead to delays, as MIDI data has to be queued up to await transmission. Gloves off, let's look at the situation more closely. At MIDI's transmission rate of 31.25Kbits per second, 3125 bytes of MIDI data can be transmitted in one second. Now consider that a MIDI Note On requires three bytes to transmit and takes 1ms. (The use of running status can reduce further Notes On with the same MIDI channel to just two bytes.) In fact, apart from System Exclusive messages, a standard MIDI event requires a maximum of three bytes - so is it fair to blame audible delays in the playback of a sequence (for example) on MIDI?

For the time being, let's not attempt to answer that question. Let's consider the delays caused by the reaction time of the voice generation of MIDI synthesisers. Some time ago, I used a digital oscilloscope to overlay the MIDI signal at the MIDI Out ports of a variety of synths with the audio signal at their audio outs. It was an extremely laborious exercise - what was needed was a computer program, preferably one which could carry out the same experiment and repeat measurements many times to even out any fluctuations.

At the Frankfurt Music Messe in March 1992, I met up with Florian Richter who had written a program for the Atari ST which could output MIDI events and measure the gap between the transmissions of a specific MIDI Note On and the audio reception from the tone generation of the connected MIDI synth. This is achieved by using the ST's cartridge port to connect a piece of hardware with an audio input. It's name is Timetool.


TIMETOOL OFFERS YOU many features, only a few of which are relevant to this article. In Single mode, it allows you to define up to 20 MIDI events to be transmitted; notes, Pitch Bend, Program Changes, Channel/Polyphonic Aftertouch and any MIDI Controllers, each event being on any MIDI channel of your choosing. Repeat mode allows up to 200 repeats of any experiment - the idea is that by stacking up MIDI events on transmission, an instrument's processor is put under greater strain than it is by a single event. Also, as MIDI channels can be set per event, this allows you to send data to different MIDI channels on a multitimbral device and to view the overall effect on the channel under consideration. In either of these modes, one of the events needs to be a MIDI Note which will result in the triggering of the cartridge.

The above test is rather static; it shows the delay due to the time taken to process data, but only for a fixed number of MIDI events. For instance, if you stack up ten MIDI Note Ons with the first nine being on MIDI Channel 1 and the tenth on MIDI Channel 2, it's possible to pan the sound generated by the last Note On to, say, the left output and the first nine to the right. However, this only shows the delay for nine notes - what about five notes, or 15 notes?

To this end, Timetool has two tests built in. Automatic 1 allows you to specify two events, for example a C3 Note On on MIDI Channel 1 and a D3 Note On on MIDI Channel 2. By routing the sounds generated to left and right outputs on the synth, you can time the audio delay of the second MIDI event. Timetool runs through the number of tests that you have set (up to 200) and then adds another Note On before the one you're timing. This continues until ten notes have been created, with the one under consideration moving one place down the list each time. A graph is drawn by the software to show the gradual build-up of delay; this graph also indicates the proportion of the delay due to MIDI, and the maximum and minimum delays for each series of repeats. By looking at a graph, you can identify the MIDI delay, the average audio delay, minimum and maximum variation and the calculated Mean Deviation, a measure of how spread out the data is within the number of repeats.

The Automatic 2 test is fixed at ten notes, but the one under consideration is moved down the list as each series of repeats finishes. This should keep the synth's processor under the same load throughout the test. Timetool also has a built-in database where results can be stored and recalled, which is useful for making comparisons.

To ensure that the audio input on the cartridge is not falsely triggered, the Calibration mode checks the level of quiescent noise and sets the threshold of the input just above this value. You also have the option of manually setting the threshold, something which has to be done if the pre-amps in the synth produce a variable level of background noise (some synths use noise gates on the output stage to mask this).

When carrying out a test, it's important that the sound you select has a reasonably fast attack and release. Effects such as reverb or delay have to be turned off as well. To ensure the accuracy of the tests I made, MIDI connections were made directly to synths, not via MIDI patchbays or Thru boxes. All tests were also carried out under Running Status.

The testing capability of Timetool isn't limited purely to audio delays - it can also measure MIDI delays by using the ST's MIDI In and MIDI Out ports. A particularly interesting test shows the delay attributable to the ST's own hardware. This appears to be negligible, but Timetool can only measure to the nearest 0.3ms.

THE E-MU PRO/FORMANCE is essentially a monotimbral piano playback module. While it can work in a split mode for the generation of two simultaneous sounds, the tests I ran used a single sound.

For the first test, 16 notes were transmitted to Pro/formance, the time delay for the 16th note being measured. The graph shows that the average delay time was 16.2ms but 10.9ms of this is attributable to the MIDI delay. Consequently, Pro/formance is only responsible for a further 4.3ms. More to the point, the variation around this average delay is very small (as shown by the minimum and maximum broken lines) and the mean deviation of 0.4ms.


The problem here is that the sound generation circuitry of Pro/formance is not being used for the first 15 notes; these are simply being ignored as they're on MIDI Channel 1. All that can be ascertained from this result is that the processor takes about 4ms to accept the MIDI Note On, create and output a note. In fact, if the test is repeated with only a single Note On on MIDI Channel 2, a similar result is obtained (5.2ms delay).

The second test used Timetool's Automatic 1 test which builds up the number of notes appearing at the MIDI In and times the delay of the last note.

The broken line on the far left shows the delay attributable to MIDI; this increases as the number of notes increases. The other three lines show the minimum, average and maximum respectively (from left to right) while the figures on the right of the screen show the delays building up and the mean deviation at each step. The delay by the tenth note is 12.5ms of which 7ms is due to MIDI. Consequently, the audio delay of 5.5ms is in keeping with the above results. More importantly, the lines showing average delay and MIDI delay are parallel, meaning that the audio delay does not increase as the number of notes increase - an important consideration. If in the course of working with Pro/formance in a sequencer track a delay was perceived, one could confidently set a negative track delay without concern that the delay would get worse according to the number of notes playing.

Does the sound selected on Pro/formance affect the delays? Yes, but this is to be expected with a sample replay module. Presets 1 and 3 have similar characteristics, with slightly less delay than above, while Presets 2 and 4 also share similar figures. This tends to infer that the samples for these pairs are the same and that some internal filtering of the samples changes the actual sound.

THE AKAI S950 is an eight-note polyphonic sampler whose voices can be set to different MIDI channels - in other words, it's multitimbral.

The first test simply sent a single Note On 200 times. The resulting delay was 3ms, of which 1ms can be attributed to MIDI - a good result, but what's more impressive is the fact that the minimum and maximum times were also 3ms. There was absolutely no variation.

The second test transmitted eight Note Ons, with the delay for the eighth being measured. The seven notes on MIDI Channel 1 were distributed to audio outputs one to seven, while the note under measurement went to output eight. In this way, the S950 was under full load. The resulting delay for the last note was 10ms, of which 5.8ms is due to MIDI. The delay of about 4ms again displayed no variation. This test is particularly relevant to the S950 when used as a drum module; I've used one for many years specifically for this task and have always found the timing to be very tight. The results of this test concur with my experience.

THE ROLAND U220 has a total polyphony of 30 notes which can be spread over seven parts; six instruments and a rhythm section. All of the following tests used 200 repeats, and the instrument being monitored was Acoustic Piano 1.

The first test turned off all parts except for one, which then received a single Note On. The idea here is to see how the U220 runs in monotimbral mode.


The result shows a delay of 8.2ms, of which MIDI is responsible for 1ms. The results are a little spread but, from an audible context, not significantly so.

The second test sent eight notes to one part and a single note to a second part. This simulates the U220 being used for, say, a piano and a lead line instrument.


The resulting average delay is 32.3ms, with MIDI contributing 6.4ms of this. The net audio delay of about 26ms is disturbing, as the U220 is only being used for nine notes out of a total polyphonic capacity of 30 notes. Also of concern is the spread of data. As the average delay is about midway between the minimum and maximum delays, it would appear that the 200 results are equally spread between the two limits; the mean deviation of 2.0ms also bears this out.

The third test transmitted the same notes as in Test 2 but with two eight-note parts on the U220 doubled up to simulate the overlaying of two parts; for instance, a string pad underneath a piano part.


The MIDI delay is again only 6.4ms, but this time the audio delay is 40.5ms, a net audio delay of about 34ms. This is most certainly audible, and yet only just over half of the synth's polyphony is being used.

The fourth test transmitted three notes to each of five parts and a single note to the sixth part, a total of 16 notes. This is a not unreasonable scenario for a multitimbral synth.


The MIDI delay for this test is 12.2ms and the resultant average delay is 45ms, a net audio delay of about 33ms. This is closely allied to the previous result which would tend to infer that it is not the processing of the incoming MIDI data which causes the delay, but the creation and output of the audio signal.

The fifth test pushes the U220 to its capacity; an eight-note chord duplicated by two parts, a five note chord duplicated by two parts, a three note chord and a single note which is under test, a total of 30 notes with a MIDI delay of 12.2ms.


The average delay here is 62.6ms, giving a net audio delay of just over 50ms. Is this audible? Well, 50ms is approximately a 32nd note at 140bpm.

How bad can timing delays get? By running an Automatic 1 test and ensuring that data is being continuously thrown at a synth, the processor will be seen under the worst possible conditions. The final test aims for this. Three parts are duplicating nine notes each and the delay of a single note after this is being measured; the MIDI delay of this note is 7ms.


The average delay here is 125.2ms giving a net audio delay of 118ms. This is practically a 16th note at 120 beats per minute and is painfully audible.

OVER A PERIOD of two months or so I put quite a few synths through their paces. The general trend of the results is that monotimbral synths have small, constant audio delays (typically 2ms-14ms). This is true also of multitimbral synths when used in a monotimbral manner. Using similar tests to the above:

Synth Audio Delay (ms) Mean Deviation
Oberheim Matrix 1000 6.2 1.3
Yamaha TX7 3.2 0.6
Korg 03R/W 4.2 0.4
Roland D550 with MEX board 8.8 1.8
Roland JV30 3.0 0.1
Roland JV80 5.6 0.2
Korg M1 4.6 0.7
Roland MKS20 4.0 0.5
Roland MKS70 13.2 0.8
E-mu Proteus 6.1 0.3
Yamaha SY22 4.0 0.1
Casio VZ10M 7.1 0.9
Korg Wavestation EX 2.0 0.1

This list is by no means exhaustive but gives a pretty good cross section. As these delays are constant and have a small degree of variation, they are likely to be either inaudible if below 7ms or otherwise resolvable by the use of a negative track delay on a sequencer.

Multitimbral synths are, however, a totally different kettle of fish. While the U220 was the worst that was measured, audio delays of 40ms upwards were common when running the processor under a substantial load. Using the same Automatic 1 test as was used in the final U220 test:

Synth Audio Delay (ms) Mean Deviation
Korg 03R/W 44.2 0.9
Roland JV30 22.2 3.9
Roland JV80 14.2 0.2
Korg M1 32.8 0.9
E-mu Proteus 93.1 0.4
Yamaha SY22 50.0 0.2
Casio VZ10M 44.0 1.0
Wavestation EX 24.9 0.2

These figures were obtained against a MIDI delay of 7ms and would appear to say that the audible delays obtained when using a multitimbral synth are primarily down to the processing time taken to create and output audio signal. Mean deviations are also higher; this means that there is a higher degree of variability in the delays. Put bluntly, you are more likely to hear delays when a song is at its busiest. The figures for Roland's JV80 are commendable, but must be taken in the tested context of being a pure sound module; the figures do not show how any synth reacts when being played from its own keyboard. The scan time, or how long the synth takes to recognise the fact that you are pressing a key down, is an inherent factor here.

IT APPEARS THAT the processors being used in many current multitimbral synths are simply not up to the job of creating and transmitting a large number of notes which is, of course, the primary reason why people buy them.

Is the MIDI delay inherent to its serial nature to blame? The answer would appear to be no. Do delays of the magnitude noted above matter? A far more pertinent question - there is little doubt that delays and variation of delay from a multitimbral synth will, at best, "smear" or thicken up the playback of music and, at worst, will be primarily responsible for audible inaccuracies.

And what of the advent of the 64-note polyphonic synth which is about to make its entry into the market place - are the delays going to be in keeping with the above results? If so, such synths will be unusable beyond half of their polyphony and no talk of a faster MIDI or "MIDI 2" will help in any way at all. Many thanks to Florian Richter for Timetool and his advice and help with this article.

Price £199 inc;. VAT.

More from Q-Logic, (Contact Details).



Previous Article in this issue

Cadenza For Windows

Next article in this issue

The Gatekeepers


Music Technology - Copyright: Music Maker Publications (UK), Future Publishing.

 

Music Technology - Aug 1992

Donated by: Mike Gorman, Chris Moore

Scanned by: Mike Gorman

Topic:

MIDI


Feature by Vic Lennard

Previous article in this issue:

> Cadenza For Windows

Next article in this issue:

> The Gatekeepers


Help Support The Things You Love

mu:zines is the result of thousands of hours of effort, and will require many thousands more going forward to reach our goals of getting all this content online.

If you value this resource, you can support this project - it really helps!

If you're enjoying the site, please consider supporting me to help build this archive...

...with a one time Donation, or a recurring Donation of just £2 a month. It really helps - thank you!
muzines_logo_02

Small Print

Terms of usePrivacy