Introduction

So, why the notion of an MCL in the first place? Well, as soon as you start using a computer for music synthesis, it rapidly becomes obvious that redundancy and inefficiency are out if you and the computer are to enjoy anything like a mutually beneficial relationship. Unfortunately, both of these attributes are only too commonplace in the two languages that a musician customarily uses — musical notation and his or her native tongue. A computer has to be told to put the right thing in the right place, and that's just as true for organising the complexities of a multidimensional musical structure as the multitude of columns in a Visi-Calc program. So, it's exceedingly unlikely that the plain English language will ever be usable as a music composition language, simply for the reason that you'd be forever correcting the sort of miscomprehensions that crop up between humans, let alone a human and a computer. Even if it were ever feasible to use English as a means of indicating musical instructions to a micro, how would you describe the picturesque clustering that's suggested by the graphics of Figure 1? Come to think of it, how would one describe it in MCL? That's one of the thorny problems we'll be attempting to get around later on in the series!

In looking at MCL, we'll aim to keep the semantics and communication theory to a bare minimum. Analysis of the language problem can help to clear the ground for further exploration, but, in this instance, we'll be spending the bulk of the time looking at practical implementations of MCLs. For instance, in a few issues time, we'll betaking a look at an interesting piece of software called AML, or Algorithmic Music Language, that can be run on any CP/M micro, and which offers extremely flexible facilities ideal for creating complex pieces entirely from one's own notes or by using auto-compositional procedures. Furthermore, it doesn't actually require you to know over much about computer programming to get the most out of it. By way of a trailer, Figure 2 shows a brief excerpt of an AML score.

This example of MCL is pretty much self-explanatory. Musical phrases are written as subroutines, which can then be repeated, with or without transpositions, simply by calling the name of that particular phrase. This approach is terrific for rock and other riff-based music, and enables complex pieces to be specified without using acres of memory space and a massive number of keystrokes.

At the other end of the micro scale, we have a review next month of AMICS, a software/hardware package for non-real-time sequencing on the ZX81 that offers professional standards for a cost that's affordable by the home musician. We'll also be reporting on how musicians actually get on with their MCLs, and computer systems in general, in the User Feedback section, and Francis Monkman will start things off with an inside look at the Synclavier's SCRIPT software. We'll also be taking a detailed look at that doyen of MCLs, the Fairlight Composer, and, later on, there'll be a Music Compiler program using an easy-to-learn MCL for the BBC Micro.

Universal MCL

Having examined the various MCL options already available, where do we go from there? Well, we could draw together all the good and bad points of the various existing MCLs and use this information to design a universal MCL afresh. However, the hotch-potch approach rarely delivers precisely the goods you're after, and one may be far better off looking for possible models in other computer languages. The crucial point is to make the language work for all musicians working in the field of micro music, regard less of the fine points of their musical predilections, and to provide the sort of flexibility and speed that a high-level language like Forth provides. Indeed, Forth may well turn out to be the best hope there is for a universal MCL, and the series will end by considering this possibility in some depth.

In closing this introduction to MCL, I'd like to suggest that, if we want really powerful musical languages, then it's up to us musicians to design them. Too many musicians have foregone the possibility of designing a language for themselves simply because they've seen musical language development as being indistinguishable from programming. However, if musicians are expected to know the rudiments of their instruments, why should composers be any different when it comes to computers? So far, it would seem as if we've allowed programmers to define MCLs according to their own concepts of musical composition and performance, when, in fact, these may bear little reality with what computer-based instruments are really capable of. The future lies with an MCL that truly communicates between the musician and the computer. If that means the composer has to add a modicum of programming skills to his musical vocabulary, then surely that's but a small price to pay for the rewards of putting the 'music' back into MCL.