• Music Composition Languages
  • Music Composition Languages
  • Music Composition Languages

Magazine Archive

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

Article Group:
Computer Musician

Music Composition Languages (Part 3)


The idea behind this series of articles is to follow the path taken by musical notation, from the traditional principles to be found on any sheet of printed music to the development of special high-level languages for the synthesis of music on computer-based equipment. In the third part, David Ellis takes a look at how well a couple of commercial MCLs — the Mountain CME and the Fairlight Composer — are singing for their supper.


The major problem encountered in putting an MCL into practice is one of making it all things to all men. Nobody has exactly the same ideas when it comes to creativity, and the ways in which musicians go about ordering their musical building blocks is about as variable as any other aspect of human existence. Unfortunately, life doesn't revolve around one-off personalised MCLs, so compromises are generally the order of the day - particularly when it comes to tailoring one's requirements to what technology is able to offer in the way of cutting the cloth. Whilst it is true that microcomputers sometimes impose too much of their own character on their musical activities, both from the standpoint of sound synthesis itself and getting an MCL to work efficiently enough so that it's a help rather than a hindrance, technological advances are rapidly sweeping aside many of the limitations, leaving the only real performance deficit to be one of the human origin.

To anyone who's been following the digital disc saga, it'll be pretty obvious that the professional audio engineer's view of the audio obtainable from 8-bit systems is generally as damning as he can get. In some senses, that's justified (256 steps of resolution isn't quite like what Mother Nature intended), but we're now seeing the emergence of special custom VLSI (Very Large Scale of Integration) chips, such as those developed by Texas Instruments (the TMS 320 Digital Signal Processor) and Yamaha (the FM operator chips in the DX-7 et al.), which do the lion's share of the huge number of arithmetic operations and so on required in these synthetic situations, and at significantly better than 8-bit resolution, leaving the standard Z80-type host processor relatively unburdened by the task in hand.

A further limitation to the musical extravaganzas perpetuated on the ever-so-humble microcomputer is that the amount of memory available for storing instrument specifications and the music itself is fairly restricted. An example is in order, so let's take the alphaSyntauri as a representative of mid-price digital synthesis systems. In fact, this system uses an Apple II with 48K of RAM, which sounds like a fair whack of memory from a music storage point of view, but this rapidly gets whittled down by all the system requirements:

System space 1K
Page 1 text 1K
Waveform tables, etc 6K
Page 1 HIRES graphics 8K
Program space 16K
Notes storage 16K

Note that the Apple's Disk-Operating System doesn't appear in this list - that's because the 10K that this takes up is moved onto a 16K RAM card. If this wasn't the case, ie. if DOS was in its normal position at the top of available memory, then there'd be just 6K left for note storage.

Anyhow, given that DOS is elsewhere and that 16K is sufficient for about 2,500 notes, we're a simple division away from the stark realisation that each note uses up six bytes on average. So, where do all those bytes go? Well, the bulk of them go to determining the pitch and duration of the note, but others assign a part to a particular instrument, set velocity-sensing, and so on. Not surprisingly, the disappearing bytes game holds equally true for Sequential Circuits Model 64 MIDI sequencer for the Commodore 64, where the 64K of memory provides space for around 4,000 notes, or the Fairlight CMI, which has space for something in the region of 10,000.

The point to realise is that the multidimensional nature of music demands a whole mass of parameters to describe even the simplest pitched event, and these tend to eat up memory like there was no tomorrow. Of course, there's always the option of adding more memory, but that means more expense, more power consumption, and, anyway, that's escaping from answering some highly pertinent questions: namely, a) what can the user leave out in the way of note parameters without compromising the end result, and b) what ways are there for making better use of the available memory?

Well, one way of answering those questions is to look at some idea of where to go next. And that, in a nutshell, is really the raison d'etre of this series. After all, if 'Wordstar' can become the word processor of choice for CP/M systems, I don't see why we shouldn't be allowed our own 'Music-star' (sic) on MIDI/MSX systems. Well, we'll see.

To start the ball rolling, here are a few basic guidelines worth bearing in mind when looking around the Wonderful World of MCLs:

1 Are the characters used to represent notes, durations, and so on easy to remember?

2 Are default values used to minimise the number of keystrokes?

3 Are notes entered in one part immediately visually comparable with notes in another part?

4 Are parts immediately playable after entry?

5 Are there comprehensive editing facilities, including search and copy?

6 Are repeat sections specifiable without re-entering the same notes?

7 Are different parts capable of accessing the same sequences?

8 Are the operations of the program the limiting factor for the rate at which music can be entered?


When you think about it, all we're really after is the musical equivalent of a decent word processor. It shouldn't matter whether you're a two-fingered stabber or a 100wpm Pitman-trained typist; the 'music processor' should work efficiently for either. But what you certainly don't want is a program that imposes its (or the programmer's) own character on your music. In other words, the MCL should be 'transparent' - like dyeline MS paper, in fact. A good example of the pit-falls that may beset the user of a less than 100% transparent musical amanuensis is the Music Editor program that Mountain Computer includes in the software for their Apple II-based MusicSystem.

Mountain Computer Music Editor



The Music Editor provides two means of entering notes: first, by using a light pen to select options from multiple menus; and second, by employing an MCL from the Apple's QWERTY keyboard. Now, the light pen, though superficially exciting (echoes of the Fairlight), is actually a complete disaster, because, a) it's unbelievably slow, and b) it's insensitive to anything less than retina-scorching levels of brilliance. So, let's get one thing straight at this juncture: man-machine interaction requires a modicum of mutual agreement as regards prevailing lighting conditions.

Fortunately, using the Music Editor from the QWERTY keyboard isn't nearly as much of a strain on the old eyeballs. So, to get a taste of this flavour of MCL, let's do our dirty deeds on the couple of bars in figure 1.

Figure 1


The key entries needed to specify this are shown in figure 2.

Figure 2


The characters used to represent notes and durations are certainly easy to remember, and default octave values and durations help to keep the number of keystrokes to a minimum. The fact that the Editor is unashamedly diatonic could be a pain to those of chromatic inclination, but that's the least of our worries. More annoying is the use of CHORDS and NOTES to switch between entering chords and individual notes (the Fairlight Composer approach of brackets is much more efficient - see later). Let's not carp, though, because one major point in favour of this program is that it converts your string of MCL code into pretty impressive HIRES music graphics (see photo) and that's something that most MCLs shy away from (for good reasons usually).

However, all that glitters is far from being gold, and the manner in which these graphical delights have been realised leads to a couple of problems: first, only one part at a time can be visualised (guideline 3 vanishes in a puff of smoke); and second, the graphics updating is so slow that there's a 1 to 2 second time lag between entering keystrokes and their notational effect appearing on the display (guideline 8: ditto). To be honest, it really isn't much fun when the creative psyche is being held to ransom by a recalcitrant keyboard buffer and snail's pace display updating.

When it comes to the other guidelines, the program tends to fare equally dubiously. First off on the black-list is the fact that you can't hear a part unless you exit from the Editor, run the Play program, and then reload the saved part, a process that takes minutes rather than seconds. Next, there's the hassle of the note buffer, a sort of 250-note scratch-pad, which obliges you to join Wimpey & Son, since multi-part pieces can only be constructed by a sort of pre-fab constructional process (where LOGO meets LEGO, you might say), the cement in this case coming from a Merge program that joins bits together by hook or by crook.

If it turns out that your maximum of 2,500 notes don't quite cohere into a meaningful mass, then you can at least be assured that the Merge program will do its utmost to inform you of of your momentary mental aberration. In fact, it takes great delight in stopping and sulking in a highly singular fashion after eliciting the customary user-error bleep from the micro. To add insult to injury, the Editor program resolutely believes in enforcing a principle of 'one man, one note' to those interacting with its MCL, and doesn't provide any means of programming repeats, copying sections from one part to another, or allowing anything that can be said to save time for the hard-worked muso. So, as far as those guidelines are concerned, the Music Editor gets the thumbs down with a score of just 2 out of 8.

Still, notwithstanding these problems, there's an interesting feature of this MCL to be found on the last line of the example: the coding of different sorts of accents. An MCL that takes the guesswork out of programming anything other than straight notes sounded in a straight way for their entire duration should be welcomed with open if sceptical arms. In fact, I'll go further and say that any MCL that's sussed out how to code all the nuances of articulation must be pretty damn clever, albeit probably living in a fool's paradise. But, just considering what this MCL is suggesting it can do, what alterations to the basic parameters of a note are needed to produce the effect of a staccato? Is it just the fact that the note is played shorter than its written length, or is there also an element of dynamic accentuation? It'd be nice if Mountain Computer had the answer to this quandary, but they don't, and it's sad to relate (sad because they at least made the effort to think of this sort of thing) that their idea of a staccato is most unlike anybody else's.

So, this is clearly a case where the programmer is trying to impose on the musician his own idea of what music is all about, and I can't see many people taking to that lying down. A better way of going about the coding of different sorts of articulation would be if the Editor had the provision to accept 'macros' - pre-defined sets of dynamic adjustments and note shortenings that the particular user felt adequately represented his case for whenever he wanted a note played staccato, staccatissimo, sforzando, or whatever - that are entered with keystrokes reserved for that purpose. Again, this is just part and parcel of the facilities that should be offered by any decent word processor.

Fairlight Composer



Now, the Fairlight Composer is widely considered one of the best examples of MCL around, and from the experience of my own ears, it certainly seems that it's capable of coding subtleties that do in fact reflect what the composer is trying to say.

Figure 3

Let's have a look now at the key entries you'd use to code the same snippet we fed to the Music Editor program in Fairlight MCL (Figure 3).

The first immediate difference is in the conventions department: the Fairlight Composer is working as a specialised sort of text editor, not as a means of putting notation on the screen, and so it goes the whole hog of using line numbers rather than bar lines, and provides a full range of editing facilities, including such useful things as string searching (in search of the lost chord...) and block copying. The Composer wins yet more bonus-points for providing the optional facility of using the CMI keyboard to enter pitches directly, which the program then turns into MCL text.

Unlike the Mountain Music Editor, there's no pregnant pause before a part can be played. In fact, the Fairlight interprets the entered MCL code as it goes along, and, what's more, if it comes across a human mistake, it'll inform you when, where, and how you made it - right down to the particular bit of code on a particular line number. Neat.

The Composer gets around the problem of different types of articulation by bringing everything up (or down) to the level of a sort of ghost keyboard. Thus, the parameter 'V' with values from 0 to 15, determines the key velocity of any one note; 'G' (for 'Gap') specifies the time between the end of one note and the start of the next; and 'H' (for 'Hold') specifies the duration of the conceptual key depression. Though the equivalence of the latter two as far as the MCL is concerned is a moot musicological point, the combination of these parameters makes for an MCL that's capable of ample shading. Furthermore, because the time resolution of MCL playing is as good as 1ms, alteration of the 'B' ('Beat') parameter can cater for any number of subtle timing offsets to de-mechanicalise a performance.

What really strikes me about the Composer is its transparent quality; if you hear something duff then you can bet you're to blame rather than the program. Just as the average word processor caters for situations as varied as sending the occasional begging letter to the bank manager (eg. if you've mortgaged yourself to the hilt to acquire a Fairlight!), or setting up the text of a book for direct printing, the Composer raises an equal gamut of possibilities, whether it be writing 3-part canons of the 'Three Blind Mice' genera (the example quoted in the Composer manual!), or an all-the-stops-pulled-out, multi-part, multi-sequence piece that makes full use of the nested repeats facility and the MCL's tree structure (Figure 4).

Figure 4


If there's any negative points to the Fairlight MCL, it's in the area of non-rock applications. It's all very well for any part to be able to play any sequence, but that's not likely to be of much interest to the composer who's main preoccupation is scoring the maximum amount of variation. (One could argue that he's the wrong sort of character for this sort of MCL, but that might be construed as a recipe for off-the-peg humans!) What the Composer does lack is the graphical means of assisting the musician to see relationships between notes. OK, there's no harm in persuading a rock musician to use his ears to sort out harmonies, but classically-trained bods are going to be a bit phased until they get used to perusing screeds and screeds of MCL printout. In fact, Fairlight's new music printing software goes some way to putting back the missing link, but that's another story.

So, a little nit-picking apart, the Fairlight Composer does what it sets out to do extremely well (a score of 7 out of 8 from the guideline point of view, in fact). However, there are areas that the Composer doesn't touch, and it's in one of these, the 'silent compositional processing' alluded to in Part 2 (E&MM November 83), that Algorithmic Music Language takes over from where the Fairlight MCL leaves off. That's for Part 4...



Previous Article in this issue

BBC Micro Show

Next article in this issue

Questionnaire Results


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

 

Electronics & Music Maker - Mar 1984

>

Should be left alone:


You can send us a note about this article, or let us know of a problem - select the type from the menu above.

(Please include your email address if you want to be contacted regarding your note.)

Computer Musician

Topic:

Computing


Series:

Music Composition Languages

Part 1 | Part 3


Feature by David Ellis

Previous article in this issue:

> BBC Micro Show

Next article in this issue:

> Questionnaire Results


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!

Please Contribute to mu:zines by supplying magazines, scanning or donating funds. Thanks!

We currently are running with a balance of £100+, with total outgoings so far of £859.00. More details...
muzines_logo_02

Small Print

Terms of usePrivacy