Magazine Archive

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

Article Group:
Computer Musician

The Art of Going Soft (Part 1)

The start of a new series designed to guide musicians through the intricacies of computer programming. Jay Chapman takes the first steps.

Introducing a new series that takes the mystery out of writing music software for home computers.

Convinced by the advertising on TV, the sales talk in the High Street showroom, and the ramblings of Computer Musician's regular contributors, you've done the logical thing and got yourself a home micro. You've also got a fair bit in the way of electronic music hardware, too, but so far, your attempts to fuse the two sides of modern technology together have proved less than fruitful.

In your search for education, you've consulted said High Street showroom, the computer's distributors, and several of the home micro magazines - all to no avail. You've also given E&MM's software articles more than a passing glance, but found them to be too far advanced, language-wise, for you to handle with any confidence.

Well, as the author of several of those software articles, I have to admit that, while most of them should have been of some educational value to those already fairly familiar with the ins and outs of computer programming, they'll have done nothing to relieve the novice's state of confusion. Why? Because unless you've got some grounding in computer programming, vast listings of programs aren't going to give you a lot of educational meat to chew on, regardless of whether your interest is primarily in computers or in music.

There's really no excuse for this yawning gap in education for the budding computer musician. After all, the process that takes somebody from programming novice to experienced software writer isn't that lengthy - just a teeny bit forbidding initially. That, in a nutshell, is why we're starting this new series. It'll be running more or less monthly, with a variety of different authors talking about a variety of different machines. The aim will remain consistent throughout, though: to describe commonly-used programming techniques and the application of programming language features by relating them to the sort of problems almost every writer of music software comes up against at one time or another.

It won't be easy, working your way through specific musical features and how software can be written to implement them, but since all the examples we'll be printing will be adaptable for use in your own software, there'll be no shortfall in the sort of rewards your endeavours will be capable of receiving.

Which Micro? Which Language?

Like I've said, the question of precisely which home computer to go for won't be answered by this series, as different months will see the spotlight shed on different micros. However, there are a few obvious good buys, like the low-cost Spectrum, the Commodore 64, and BBC Model B, all of which have enjoyed considerable attention from the professional music software writers over the last year or two. Alternatively, there are the Japanese MSX-standard micros, of which the Yamaha CX5M is not only the most musically comprehensive (thanks to its SFG01 FM sound chip and extensive range of Yamaha-originating music software) but also the most popular among musicians. The fact that it's also far and away the most expensive MSX machine is almost incidental.

There are some outsiders worth considering, like Amstrad's CPC464 and the Sinclair QL, or, if you're not yet in the market for a micro or are prepared to wait a little while, there are a couple of interesting-looking newcomers from Commodore (the Amiga) and Atari (the ST range) just around the corner. Watch this space for details.

As for programming languages, the choice here is somewhat less clear-cut, since it revolves more around suitability for specific problems than simple availability.

Almost all home microcomputers have some form of BASIC built into them, and most of the newer ones have progressed to some form of structured BASIC, which is a huge improvement. Unfortunately, BASIC is sadly lacking where the definition of data structures is concerned; and what's more, the structure of permissible program code simply isn't flexible enough for many musical applications. Result? An awful lot of confusion for programmers trying to use the system in a musical context. The fact is, BASIC can cope fine when problems and their software solutions are relatively simple: if anything, it has positive advantages in such situations. However, once you get into programs and problems of greater size, BASIC brings you a whole load of complications and code convolutions to go with them, and it's for these and other reasons that the language Pascal is generally a better vehicle for examples and their explanations.

So, we'll be using Pascal quite a bit to illustrate the use of data structures and programming techniques. And if you aren't familiar with Pascal as a language, don't worry: the meaning of Pascal programs is usually pretty self-evident, and in many cases, it reads pretty much like English (well, some sort of English, anyway). In cases where the translation into BASIC isn't too obvious, we'll be showing that language's more restricted facilities to the same effect, though since most micros incorporate Pascal as an optional language, most of you will be able to use Pascal directly in any case.

What we won't be providing is a programming course as such. There simply isn't the space for one thing, and for another, there are plenty of suitable books currently available that do the job better than we ever could - simply because they concentrate on a wide range of programming applications, not just music. So, a quick trip round your local bookshop (under the guiding hand of a knowledgeable friend, if possible) should yield plenty of informative bedtime reading material.

In the end, it'll be a combination of books, magazine articles, and above all, hands-on experience that turns you from a programming novice into someone capable of transforming a Casio pocket calculator into a Fairlight CMI. We'll just be giving you a helpful nudge or two in that direction.


A good many of the sample problems and solutions we'll be discussing won't actually result in the creation of complete programs. More likely, it'll be a case of the data structures that describe what a program is to work on (it might be anything from a chord to a complete musical score, or a real-time MIDI data stream, or some useful screen graphics, or...) being defined, and specific tasks that need to be performed on the data then being detailed in turn. Sometimes, these tasks can become quite complex, so it's useful to describe sub-tasks and their solutions, which can then be used as a kind of 'software toolset' in building the more complex solution to the main problem.

In fact, the idea of carefully designing and encapsulating a sub-routine is common to most programming languages. In simple forms of BASIC, the idea surfaces as the GOSUB statement, in which the diamond brackets enclose a general description of what can appear: thus, GOSUB <1000>, in which 1000 is a specific line number in a program. This statement directs the BASIC interpreter to go off and execute at the given line number, and when the corresponding RETURN is found, execution continues after the GOSUB. There's no denying the usefulness of this facility, it allows a section of code to be called up several times from different places in a program, but it doesn't allow us to pay any attention to the interface between calling routine and called routine. What's more, no encapsulation of data has taken place - see later.

In several forms of structured BASIC and in Pascal, it's possible to give a subprogram a meaningful name in the cause of better understanding: compare GOSUB 1000 with edit-score. It's also possible to declare data structures that are private to the sub-program (the process is called 'encapsulation') so that global data structures, which usually hold data belonging to some other part of the program, aren't affected by what goes on inside the sub-program, unless we say so, of course. This means we can go about programming each new sub-program in an almost totally independent manner, without having to worry about clashes of variable names causing unexpected bugs, for example.

Most important of all, we can define the interface between sub-program and potential callers explicitly. By use of what's called parameter passing, data can be passed into (and, depending on the language, out of) sub-programs. Thus, we can write a general routine that'll read in, say, MIDI data from either of two data ports and specify (by way of the parameters passed) which port is actually to be used.

As it happens, several previous E&MM programming features, written in BBC BASIC, have made extensive use of parameter passing and procedures. The sub-program interface is defined by the DEF PROC( ) statement, while any local variables are defined in LOCAL , within the PROC code body.

So, we might define our routine to read MIDI ports with DEF PROCread-MIDI-port ( port-number ) and call it with PROCread-midi-port ( 2 ). In Pascal, the definition would become procedure read-MIDI-port( port-number : possible-port-number ) and the call read-MIDI-port( 2 ).

Note that the type and range of data that each variable and parameter can hold has to be defined in Pascal, which is why the : possible-port-number appears. This turns out to be an excellent idea, since if a silly value is assigned to a variable or parameter in a Pascal program, it'll complain there and then: a BASIC value will most likely run on and use the silly value quite happily. For example, if possible-port-number was defined in Pascal to allow only the values 1 and 2, a call of read-MIDI-port ( 1725458 ) (in which 1725458 is the chosen port) would fail, giving you a useful point from which to begin debugging. In BASIC, on the other hand, the program might trundle on for some time doing nothing of any use whatsoever, and you'd be none the wiser. And that's not a happy state of affairs for any programmer, I can tell you.

Don't worry if that last bit of language explanation has left you gasping for breath and in a state of mental confusion, because we'll be tackling the subject in greater detail in the not too distant future.


Well, no series on programming for musicians can be complete these days without considerable attention being paid to MIDI. It is, after all, the means by which most home micro owners escape the confines of their machine's internal sound chip, as well as the means by which synth users can give their instruments access to a computer's facilities. Which means that quite a few of the coming months' examples will relate to the driving of synthesisers and associated equipment from home micros. And if those examples are going to be of any practical value to anybody, we've got to make sure you understand the intricacies of the MIDI standard itself.

This is an important subject area that hasn't really been comprehensively explained from a potential programmer's point of view, so that's yet another gap for this series to fill! The MIDI standard defines the communication between machines rather than what information a program may care to define internally, but there's always going to be some fairly close correspondence in a lot of cases. An obvious example is the conversion between MIDI absolute and running status, something which, incidentally, can be awfully useful when it comes to saving on precious micro memory space.

With luck, future instalments will see us looking into the way different models of synth implement MIDI system exclusive information, and we also hope to be exploring the use of MIDI for driving sound-sampling modules and more specialised devices, too.

So, if you're interested in programming your own musical software packages that do exactly what you want, are inherently flexible, and can be expanded as and when you see fit (to accommodate extra gear, say), and will cost you nothing more than blood, sweat and tears, you've come to the right place. See you next month.

Series - "The Art of Going Soft"

Read the next part in this series:

All parts in this series:

Part 1 (Viewing) | Part 2 | Part 3

More with this topic

Browse by Topic:


Previous Article in this issue

Joreth Music Composer System

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


Electronics & Music Maker - May 1985

Computer Musician




The Art of Going Soft

Part 1 (Viewing) | Part 2 | Part 3

Feature by Jay Chapman

Previous article in this issue:

> Joreth Music Composer System...

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 June 2022
Issues donated this month: 0

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

Funds donated this month: £49.00

All donations and support are gratefully appreciated - thank you.

Magazines Needed - Can You Help?

Do you have any of these magazine issues?

> See all issues we need

If so, and you can donate, lend or scan them to help complete our archive, please get in touch via the Contribute page - thanks!

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!

Small Print

Terms of usePrivacy