Magazine Archive

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

Adventures In MIDILand (Part 5)

Part 5. The adventure continues - the master of MIDI manipulations, Martin Russ, does the time warp!


In all the science fiction novels and short stories dealing with time travel, they always mutter something about the Laws of Time, usually to avoid any plot problems which might arise if a character goes back and kills off their ancestors. My own theory is that making rules like that is rather like expecting music to be popular because it is good - fine in theory, but unfortunately the world does not work like that. In this adventure we go well beyond the charted territory into a land where we can do some ridiculous things with time itself! You might be expecting a corny reference to the Rocky Horror Show at this point, so let's get it over with now: you could call this episode 'Let's do the Time Warp again!'.

WARP SPEED, CAPTAIN



MIDI time (or that in any synchronising system) is purely relative, which means that it works to whatever source you give it, regardless of real time. This even applies to a system which is synced to Linear Time Code (SMPTE, EBU etc) or MIDI Time Code, since if you want to you can do stupid things like stripe a tape at one speed and play it back at another.

But the most obviously relative MIDI time message is the MIDI Clock, and it is this which will form the basis of all the manipulations with time in this adventure. Because MIDI Time Code and the other Time Codes are usually used in situations where the actual timing is important, it is wise to leave well alone: 'If it ain't broke, don't fix it'.

Since MIDI Clocks happen at a fixed rate of 24 clock messages per quarter note, you may be wondering what could possibly be done to change time. A bar's-worth of MIDI clocks in 4/4 time always contains 96 messages, and I do not intend to change that yet. Instead, I will start by altering the relationship between the MIDI clock messages and real time in a special way. Ordinarily, MIDI clock messages tick away at a fixed tempo and the number of ticks can be mapped to the song position in bars and beats, as well as to real time. If you change the tempo then the bars and beats stay the same but real time will be different. What I intend to do is show you how to change the timing of the beats but leave the bars and real time alone.

You may be wondering why I would want to do this, but there is method behind the apparent madness, and what follows is a powerful technique which ought to be explored by more people. Much of the 'feel', 'drive' and 'rhythm' of a piece of music depends on subtle timing differences between the component parts of the rhythm section. Most software sequencers allow you to slide tracks back and forth in time to provide correction for slow attacks, and also to enable small changes to be made in the relative timing of tracks. Try it and see.

In a similar way, real drummers do not necessarily work to a fixed tempo, either long-term or short-term. Over a bar's length, the actual timing of drum events may not fall exactly as you would expect (or would program into a drum machine), but instead show the same sort of timing variation. Some commercial drum machines have built-in 'humaniser' functions which attempt to mimic this 'slightly off-beat' drumming, and the first program in this part does much the same thing, except it will work with almost any MIDI drum machine (or sequencer).

I will assume that a 'bar' is four beats long for the following description, although the program also caters for 3/4 time signatures and could be altered to any other ratio. The MCLOCK program produces a MIDI Clock output at the standard rate of 24 $F8 messages per beat, and 96 per bar, but it enables the timing between beats to be altered, so that the rigid 'on the beat' timing feel of drum machines can be avoided. The program uses a series of timing loops, one for every 12 MIDI clock messages, so that you can alter the timing eight times in the bar. The range of alteration in each of these eight time segments is variable over a wide range, so you can make both subtle and very obvious modifications. The larger the number entered for each of the eight periods of time, the longer each segment will be delayed, so entering the same value in each segment will produce no overall change.

Note that the timing variation is the same for each set of 96 beats - the program does not 'humanise' in quite the same way as some drum machines, which concentrate on timing variations on a larger scale than individual bars. Instead it concentrates on providing access to the moments in time just before and after the rigidly fixed beats of most drum machines. You may be surprised at how different rhythm patterns sound with only slight changes to important beats. The actual theory behind the psychoacoustic effects of these minor timing changes is beyond the scope of this series, but it is a fascinating subject, well worth further investigation. Keyboard players may also like to try using the MCLOCK program to drive their favourite sequencer and explore the possibilities of micro-time alterations, since it is not restricted to just drums.

The following program segment illustrates the important part of the program - the individual timing loop for a single segment:

Part of the MCLOCK program:
SUB segment(time_delay_value)
FOR midi_beat=0 TO (time_signature*3)-1
OUT 3,&HF8
FOR t = 1 TO time_delay_value:NEXT t
NEXT midi_beat
END SUB

This segment is a subroutine which is called for each of the eight time segments. The parameter 'time_delay_value' is passed to the routine so that each segment can have its own individual timing. 12 MIDI clock messages are output in the 4/4 version when the 'time_signature' variable is equal to 4. The 'OUT 3, &HF8' line actually outputs the MIDI clocks themselves.

DOUBLE TIME



Warping time is OK, but how about speeding it up and slowing it down? The two programs MCLKDB and MCLKHA double or halve the rate of MIDI clocks which are passed through the ST. This means that you can run time faster or slower depending on which side of the ST you connect things. Possible applications include running two drum machines at different time signatures to give a more complex compound result, or even apparently doubling (or halving) the resolution of the time quantisation. On a simplistic level, the MCLKDB program doubles the tempo itself, since by turning every MIDI clock into two MIDI clocks, the drum machine is fooled into thinking that the tempo is twice what it should be.

The following program segment waits for a MIDI clock and then outputs two MIDI clocks.

MIDI clock -> 2 x MIDI clocks

Part of the MCLKDB program:
start:
n = INP(3) AND &HFF
retest:
a = n AND &HF0
escape$ = INKEY$
IF escape$ <>"" THEN GOTO leave
IF NOT(n = &HF8) THEN
GOTO start
END IF
OUT 3, &HF8
FOR ty = 1 TO 1000:NEXT ty
OUT 3, &HF8
GOTO start

The FOR... NEXT loop is used to introduce a slight time delay between outputting the two MIDI clock messages. The timing between the clocks is not the same as half the time between the incoming clocks. It would need a much more complex program to interpolate two clocks evenly into the spaces between incoming clocks.

Song position pointers are not affected by the doubling or halving of MIDI clock messages, which means that since the position in the song is determined by the number of MIDI clocks since the start, then the position information would be wrong relative to the processed MIDI clocks. I can't think of a serious use for this feature, and so the program does not pass any other messages through it.

Going back to mapping, the MCLKDB program maps each incoming MIDI clock to two outgoing ones, and so we could use the same underlying program to make other clock mappings...

ACTIVE SENSE



The strangest message I could think of to map to MIDI clocks was Active Sensing! Normally sent out at a maximum rate of three per second, the active sensing message is designed to mute expanders which lose contact with a remote keyboard. However, variations in interpreting "at least every 300ms" mean that manufacturers use very different rates of sending the messages. The MASCLK program converts $FE Active Sensing messages into MIDI clock messages, which means that you can 'listen' to the speed of any equipment which sends active sensing messages by connecting the ST's MIDI output to a drum machine or sequencer.

Active Sense -> MIDI clock

Part of the MASCLK program:
start:
n = INP(3) AND &HFF
retest:
a = n AND &HF0
escape$ = INKEY$
IF escape$ <>"" THEN GOTO leave
IF NOT(n = &HFE) THEN
GOTO start
END IF
FOR ty = 1 TO 16
OUT 3, &HF8
NEXT ty
GOTO start

As promised, this program segment is very similar to the clock doubler, except that the program waits for an incoming active sense message, and then outputs a series of MIDI clocks. The rate of three active sense messages per second translates to a very slow tempo, and so by outputting 16 MIDI clock messages the program multiplies the active sense rate to one which works well as a tempo:

120 beats per minute = 2 beats per second
2 x 24 = 48 MIDI clocks per second

So, for three active sense messages per second to correspond to 120bpm, each active sense message needs to trigger 48/3 = 16 MIDI clock messages.

Another possible application which uses the idea of interpolating beats and mapping would be to convert pedalled bass notes from the lower end of a keyboard into MIDI clocks, using a similar program to MASCLK (bass notes -> MIDI clocks). This would give a tempo which tracked any changes in the playing of the performer (and not the other way around!). You may like to experiment with modifying the MASCLK program to do this sort of thing...

UNIFICATION



The unification of MIDI clocks and tempo leads to another useful program, MCKBPM, which counts the number of MIDI clock messages in a set time, and displays this as a tempo:

time -> tempo

Part of MCKBPM program:
DO
count=-1
t!= TIMER
DO
n = INP(3) AND &HFF
escape$ = INKEY$
IF escape$ <>"" THEN GOTO leave
IF (n = &HF8) THEN
INCR count
END IF
LOOP UNTIL (TIMER-t!)>2.49
PRINT "BPM :_"_+STR$(count)+" "
leave:
all_notes_off
IF (escape$="Q") OR (escape$="q") THEN
GOTO tidy_up
LOOP

This program segment uses two loops, the outer one displays the results of the timing calculation, whilst the inner loop actually does the timing itself. The time for which the MIDI clocks are counted is chosen so that the count translates directly to a tempo - the program specifies a time slightly less than the theoretical value of 2.5 seconds to take account of the time it takes to go around the inner loop. (For a tempo of 120 beats per minute, there are 120/60 = 2 beats per second. 2 beats equals 48 MIDI clocks, and so 48 MIDI clocks will be counted in 1 second. So for a timing period of 2.5 seconds, 96 MIDI clocks will be counted in the first 2 seconds, and a further 24 will be counted in the remaining half a second, giving a grand total of 120 MIDI clocks, which is the correct tempo! Magic numbers like the 2.5 used here are a whole topic on their own...)

A display of tempo in beats per minute can be used to verify the accuracy of the readout on drum machines and hardware sequencers which have a tempo display, although usually the readings will agree. The program is more useful for calibrating equipment which does not have a control marked in tempo readings, or for monitoring the changes in tempo which can occur when you are syncing to events on video or film.

DRUM CONTROL



After some programs of dubious usefulness, the final mapping in this adventure is actually very useful, and neatly rounds off the topic of clocks and timing:

Note -> Start / Stop

The MKN2D program uses a trigger note to send Start and Stop messages to control a drum machine or hardware sequencer. This means that you can control devices without having to move your hands away from the keyboard. The program is similar to previous trigger note examples.

Part of the MKN2D program:
st=0
start:
n = INP(3) AND &HFF
a = n AND &HF0
escape$ = INKEY$
OUT 3, n
IF escapeS <>"" THEN GOTO leave
IF NOT((a = &H90)) THEN GOTO start
n = INP(3) AND &HFF
v = INP(3) AND &HFF
OUT 3, n
OUT 3, v
IF ((n=add) AND (v<>0)) THEN
IF st=0 THEN
OUT 3, &HFA
st=1
ELSE
OUT 3, &HFC
st=0
END IF
END IF
GOTO start

The current status of the drum machine is stored in the 'st' variable, and this is used to toggle between sending Start and Stop messages. In this way the first time you press the trigger note the drum machine starts playing, whilst the second time you hit the note the drum machine stops.

CONCLUSION



That completes the roll-call of programs given in part 2 of this series. The majority of the programs have now revealed their most intimate secrets and the adventure is almost over. The concluding part next month tries to put the program examples into the wider context of what they show about MIDI itself, instead of concentrating on the programming aspects.

PROGRAM DISKS

All the programs mentioned in this series can be found on the MIDILand Programs disk set (order code S101) which is available from SOS Software, price £7 inc postage.

SOS Software, (Contact Details).

THE REAL WORLD

Writing a series like this, where the programs are an integral part of the content and yet are really only examples rather than fully-blown programs, invites questions about using them in the real world. I have already said that it is not feasible for me to produce a comprehensive MIDI mapping/processing program, but perhaps this is not really necessary... There are already rumours of at least one commercial universal MIDI processor utility which does many of the things which this series covers.

The Hollis Research MIDIman utility is an example of a program which can be pressed into action for some limited real-time mapping activities, although it needs a slightly different programming approach to the one adopted here.

Do not forget the often unexplored features of more conventional software. Many sequencers have facilities for doing at least some processing of MIDI data, from the very simple transposition of note pitches through to the mapping of one event to another. Manuals do have a tendency to be vague when describing the capabilities of the more powerful facilities, and perhaps you now have a good idea why. Most sequencers seem to concentrate on providing post processing of recorded information, rather than real-time transformations.

Hardware to achieve many of the effects described in this series is also available in various forms. The long-deleted Yamaha MEP4 MIDI Effects Processor was an early attempt to provide some unusual MIDI facilities, but it never seemed to really catch on. The Lexicon MRC MIDI Remote Controller may be advertised as a means of controlling the LXP1 and LXP5, but it can also be used to provide some mapping.

Trying to convey the concept of mapping pitch events to drum machine start/stop commands is useful when you can understand it but can seem pointless if you have no frame of reference. Hopefully, if you have understood this series then you will be able to look at the MIDI processing part of professional sequencers, hardware and utility programs with a new insight!


MAPPING?

The concept of mapping is not restricted to the one dimensional form which we have been using here. Merging can be described using the same notation with only minor additions:

Input 1 -> Output
Input 2 -> Output

And this allows us to define some of the common uses of merging:

Keyboard Performance Data -> Output
MIDI Clocks & Timing Data -> Output

Which is the situation where you need to use a master keyboard and an external clock source to drive a software sequencer, and so need both note and timing information into the same MIDI In socket.

Keyboard Note Data -> Output
Performance Controls -> Output

This is what sometimes happens when you use an electronic piano as a controller (for its weighted keyboard), but need to use pitch bend or modulation in order to control something like a saxophone voice on an expander. Trying to put that into words is much harder than giving a semi-diagrammatic mapping list.

MIDI Patchbays also perform mapping, but of MIDI cable connections, rather than transformations of message types. Again the list of mappings is almost like a diagram:

Input 1 -> Output 1
Input 2 -> Output 4
Input 3 -> Output 2
Input 4 -> Output 3


Series

Read the next part in this series:
Adventures In MIDILand (Part 6)



Previous Article in this issue

Stratospheric!

Next article in this issue

Win An Alesis SR16 Drum Machine!


Sound On Sound - Copyright: SOS Publications Ltd.
The contents of this magazine are re-published here with the kind permission of SOS Publications Ltd.

 

Sound On Sound - Dec 1990

Topic:

MIDI


Series:

Adventures In MIDILand

Part 1 | Part 2 | Part 3 | Part 4 | Part 5 (Viewing) | Part 6


Feature by Martin Russ

Previous article in this issue:

> Stratospheric!

Next article in this issue:

> Win An Alesis SR16 Drum Mach...


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!

Donations for September 2020
Issues donated this month: 0

New issues that have been donated or scanned for us this month.

Funds donated this month: £38.00

All donations and support are gratefully appreciated - thank you.

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