Music-X was the name of a popular Midi sequencer program that I created for the Commodore Amiga in 1988 and which was published by MicroIllusions.
To fully tell the story of how Music-X got created, however, I need to go back in time a decade or two.
Prologue
As a teenager growing up in the early 70s, I had been very interested in electronic music. I badly wanted to have a synthesizer of my own, but there was simply no way I could afford one. Instead, I used to spend hours in the music store fooling around with the latest Moog or ARP keyboard.
Fortunately, there was a company named PAiA Electronics which sold kits that would let you build your own synthesizer for a few hundred dollars. Somewhere around 1974 I bought one of their modular kits, the PAiA 2720:
A few years later, I upgraded to their larger system, the PAiA 4700:
The PAiA kits were a wonderful learning experience for me, but in other ways they were unsatisfying. These kits were designed to be as low-cost as possible, which meant that they used relatively cheap components, as well as unshielded wiring and circuit designs. This meant that they tended to be noisy, introducing a lot of unwanted distortion and hum into the output signal. It didn’t help that my soldering skills also left something to be desired.
These were also analog systems, which meant that they had limited programmability — changing sounds required a lot of tedious repatching and adjusting of knobs. That was fine if you had an expensive sound-on-sound tape deck that could be used to layer various instruments into a single performance, but I couldn’t afford something like that. They also had limited ability to play back sequences of notes.
PAiA eventually came out with a micro-controller board (based on a 6503-based microprocessor), which I bought and learned to program by entering instructions in hexadecimal on a keypad. This was the first computer I ever owned. However, it only had 256 bytes of RAM, which was frustratingly limited for storing musical sequences. I attempted to “upgrade” the computer to 1K of static RAM, and it worked for about 8 hours — after which something in the processor board overloaded, and never worked again after that. I was never that great with hardware, and so was unable to repair it.
I left the PAiA instruments behind during my Air Force career, however that does not mean that I stopped playing around with electronic music. I owned an ARP Omni (string synthesizer) which I kept in my room in the barracks, and which I occasionally played — although I am not a great keyboard player.
Also around that time I was starting to notice increasing use of electronic sounds in popular music. Prior to that time, synthesizers had only appeared in ‘novelty’ music albums like Jean-Jaques Perry’s The In Sound From Way Out. And while a lot of rock bands were starting to make use of synthesizers, it was only for occasional riffs — it was too experimental and exotic to be used for the ‘meat’ of the music.
I wanted to hear music that treated synthesizers in a serious, musical way — I was a huge fan of Larry Fast’s Synergy albums, particularly Electronic Realizations for Rock Orchestra and Sequencer. These, along with Rush’s 2112, were the LPs most frequently played on my turntable.
Another development during this time was my increasing interest in personal computers. Unfortunately, 8-bit systems like the Apple II or Atari 800 could only make primitive beeps and buzzes, and could barely handle any kind of polyphony.
However, in 1982, I started working on a game for the Radio Shack Color Computer called Guardian, which was a clone of the arcade game, Defender.
Guardian was published by a company called Quasar Animations, which was a fly-by-night operation run by a guy whose day job was a navy sailor; The marketing was terrible and I think I made a total of about $300 from the entire project.
As part of the development of Guardian, I had to create a whole bunch of arcade-like sound effects. The knowledge gained from my earlier experience with the PAiA system allowed me to manipulate square waves and modulate pulse widths in diverse and interesting ways. Because there was no multitasking or sound chip (just a digital-to-analog output port), I had to interleave the sound-generating instructions with the instructions responsible for drawing the graphics. This was my first real experience with creating sound on a computer.
The next few projects I worked on did not have any sound (one of them was a text editor for the Color Computer called “Color Scripsit” that was canceled before it was published).
In 1985 I started writing games for the Commodore Amiga (as detailed in my article about the Faery Tale Adventure). The Amiga had a dedicated sound chip which could play up to four 8-bit samples at once — this was a giant leap from what the Apple and Atari could do.
After finishing Faery Tale, I decided it was time to do a “serious” music program. I had already created Musica, my primitive score editor which I had used for Faery Tale and Discovery. I wanted a new program which would be aimed at the professional musician and would be much more powerful. I discussed this with Jim Steinert, the head of MicroIllusions, and he was OK with the idea (Jim never tried to focus MicroIllusions on any one type of product.)
However, there were a couple of major obstacles I had to deal with. The first is that I, myself, was not a professional musician. I had some ideas as to what kinds of features a “real” musician might want, but they were only guesses.
I thus spent many hours hanging out at the local music store pestering the store personnel with questions. I eventually convinced Jim to compensate the store for all of the time I spent there, by purchasing one of their Midi keyboards (I needed the instrument to test the software anyway). This was a Roland D-50, which I kept for many years afterwards.
The second problem was that the other competing platforms — specifically the Macintosh and the Atari ST — had gotten a big head start. Even though the Amiga, with it’s custom chips and multitasking OS, was a more powerful system, musicians were gravitating towards these other platforms because there were already professional-grade software packages for them. So I knew I had some catching up to do.
The Atari ST in particular had gotten an early lead because, despite it’s relatively primitive OS (we called it “CP/M with windows”) it came with built-in Midi ports. For the Amiga, you needed an extra hardware adapter to convert the output of the Amiga’s serial port into something that was Midi-compatible. So it was natural that musicians would get the impression that the ST was “the musician’s computer” — and I worried that even a small difference in perception could snowball into a major distinction in the market as the years went by.
Development
I made some key decisions up front. This would be a complex program, with multiple “modes”:
- A “whole-performance” view for arranging tracks and setting tempo.
- a “piano-roll” editor for individual tracks.
- A Midi control-mapper that let you decide how controller signals such as footpedals and modulation wheels would be processed.
- A patch librarian page, which let you record and store settings for individual Midi instruments.
- A musical keymap editor, that let you set up “split” keyboards, or even assign sequencer tracks to individual keys.
- A mode for setting up and playing sampled instruments using the Amiga’s internal sound chip.
Another thing I wanted was to take advantage of the Amiga’s wide color palette: I wanted the program to be colorful. Each of the different modes would be rendered in a different color theme. This required creating a custom UI library that would draw all of the various panels and buttons on the screen.
And I also wanted real-time audio feedback — so that you would be able to listen to the notes as you dragged them around with the mouse.
One particularly challenging problem was performance tuning the playback routines to be able to get consistent and accurate timing. Music-X used one of the Amiga’s four built-in timer chips to generate an interrupt signal at various rates depending on the current playback tempo, which gave me a solid time base. However, the assembly language routines I had written to service the interrupt would take different amounts of time depending on what needed to be done each tick of the clock.
(Skip to the next section if you are not interested in the technical details.)
I came up with an innovative way to measure the stability of the timing: by using the Amiga’s own graphics chips as a kind of oscilloscope. You see, one of the features of the Amiga’s graphics chips was that the color palette could be adjusted in real time, even as the video beam of the CRT was traversing the screen. That meant if, for example, you changed color palette register #1 from blue to yellow just as the video beam was halfway through the first raster line, you would see the left half of the line drawn in blue and the right half drawn in yellow. Several popular games used this trick to increase the number of colors beyond the normal limit of 32.
During my performance testing, I inserted additional assembly-language instructions into the playback code that would modify the palette as each part of the code executed. This produced a horizontally-striped interference pattern on the Amiga display.
Here’s how it worked: the resolution of the timer chip was set to 192 clock ticks per quarter note. Say the song tempo was set to 60 BPM (beats per minute). This works out to one quarter note per second, which would mean that the timer code would run 192 times per second, or once every 5.2 milliseconds. The Amiga video refreshed at a rate of 60Hz (60 times per second), so it took 16.6 milliseconds for the video beam to traverse the screen from top to bottom — a little over three clock ticks of the timer. Using the palette-changing trick, you’d see the execution of those three clock ticks as three colorful, horizontal stripes. By closely looking at the width of the various color bands within each stripe, you could get an idea of how long it took for each section of code to execute. I was then able to use this to fine-tune the performance of the code.
Changing the tempo would of course change the number of stripes on the screen — the faster the tempo, the greater number of stripes. However, if the tempo was not an even multiple of 60Hz, the stripes would “roll” — meaning that they would constantly scroll upward or downward on the display.
Publication
Finally, there was a decision of what to call the product. During my years competing in science fiction costume competitions, I had met many creative and talented costumers. One was a young woman, a punk-rock singer with pink hair, who went by the moniker “Animal X”. She had done a number of provocative costumes such as “War Bride” (a wedding dress done entirely in military camouflage cloth) and a corset made out of iridescent beetles. I thought the “X” had a nice punk vibe to it, so I called the product “Music-X”.
Allison Hershey, my girlfriend at the time, was a talented artist, and one of the things she had played around with is the idea of using electronic circuits as a visual motif in her art. So we came up with the idea of having a piano keyboard that ‘morphs’ into a circuit board, all done in a hot punky pink.
Allison and I are both very laid-back personality types by nature, but we also feel very strongly about art. During the five years we lived together, there was only one episode where we actually raised our voices at each other, and that was when we collaborated on the Music-X cover.
I remember one episode near the end of the project where Matt and I worked together on the manual. We had originally given the job of creating the manual to a professional typesetter, but she wasn’t experienced writing documentation for software and had made a lot of mistakes. Matt and I spent a marathon session (30 hours with no sleep) completely reformatting the manual before it had to be sent to the printers.
Reception
Music-X made a huge splash when it was released. There were numerous magazine articles that came out about the product. The program was especially popular in Europe, where the Amiga was still selling well (Commodore had not done a very good job of marketing the Amiga in the USA. As columnist Jerry Pournelle had once opined, “Commodore couldn’t sell eternal life!”)
MicroIllusions had a booth at various trade shows such as NAMM (National Association of Music Manufacturers), and Matt and myself were often in attendance. I remember one episode where the two of us, both tired after a long day of manning the booth, engaged in a stuntman-style fight, where we used the buttons on the Roland drum machine to supply the punch and kick sounds of our mock combat. (With cymbals to represent a konk on the head. The Three Stooges got nothin’ on us!)
Jim, always a big dreamer, had spent about $20,000 creating an MTV-style music video for Music-X. He had hired a director and a film crew, but these weren’t professionals, just some wannabe friend-of-a-friend types who claimed to have experience in movies. The idea of the video was that the “Spanky and our gang” characters from 1950s television had grown up and formed a rock band. Jim acted as one of the characters, “Reptile”, who was supposed to represent the grown-up version of the character Froggy.
I stayed far away from the whole video production, as I strongly felt that an advertisement for music software should focus on the features of the product and how it would expand your musical capabilities — not on the attention and fame of being a rock star.
This turned out to be wise decision on my part — the resulting film was an absolute stinker. What was particularly laughable is that the big musical number at the end did not only did not use Music-X, it didn’t even use synthesizers. During trade shows, Jim would have it playing in the background on a large TV monitor, but it was generally embarrassing and incomprehensible, and nobody paid much attention to it.
I think the high point of my involvement was when I got invited to appear on Computer Chronicles, a TV show about emerging computer technology:
An interesting anecdote about this video: I had been in a panic because I had forgotten to bring the power cord for the Roland D-50. However, I was able to unscrew the back panel of the D-50, and using alligator clips from the electronic workbench at the TV studio, rigged a power cable for it just minutes before the session. You may notice that the arrangement of objects on the desk where I am sitting carefully conceals the jerry-rigged cables.
Two other things about the video: 1) the shirt I am wearing is one I made. 2) I always hate seeing my old name, which I never much liked. I’m reminded of Chelsea Manning, who once said that she didn’t mind prison so much as she minded having the entire Internet see photos of her as a boy.
After Music-X was released, there was a lot of demand for additional features, and particular support for additional hardware. At one point I had a giant wall-sized rack of keyboards and sound processing modules in my home office so that I could test out the software with various hardware modules.
However, there was one rather serious bug that many people reported — that sometimes when recording Midi input data, Music-X would lose data — occasionally a note or control signal would be “dropped” and not appear in the final recording. I spent months trying to track down the cause, to no avail. It was only years later that I learned that the bug was indeed real, and was not the fault of my code, but due to a design flaw in the Amiga hardware itself. More on this later.
Eventually Jim asked me to produce a stripped-down version of Music-X that could be sold at a lower price point. I wasn’t super comfortable with the idea of deliberately crippling the software, but I agreed that it made sense to remove some of the more complex features. Jim called the new product “Music-X Jr.”
In the end I didn’t make nearly as much money off of Music-X as I had made from Faery Tale Adventure. In fact, I had negotiated with Jim a higher royalty rate by taking no advance money up front — instead I would live off the proceeds of Faery Tale while I created Music-X. This turned out to be a mistake — although Music-X was popular, MicroIllusions was struggling and made a lot of blunders in the market. In the end, I think I made less than a quarter of what I had made with Faery Tale, which left me in some fairly dire financial straits. It was at this point where I started to do contracting work directly for Commodore and other employers, although I did one more project for MicroIllusions, which was Discovery 2 (with Joe Pearce).
Joe later went on to create an embeddable player for Music-X files, called MaxTrax, which allowed you to play back Music-X performance files from within your own programs. This was used in a number of games such as Legend of Kyrandia (Amiga version).
Aftermath I
Several years later at an Amiga developers conference, I was approached by Bryce Nesbitt, an engineer working on the next version of AmigaOS for Commodore.
I don’t remember his exact words, but the gist of it was that he had finally solved the problem of why Music-X (and other Amiga music software) seemed to have a problem recording Midi data.
Because I went to all of the Amiga expos and developer cons, I knew all of the guys who worked on AmigaOS. I had long email threads where I had pleaded with them for help on solving this bug. One of the engineers (who was eventually fired by Commodore) cynically told me at one CES, “Your problem is simple. The Amiga can’t do Midi.”
And unfortunately, the market of professional musicians seemed to agree — more and more they were gravitating towards the Macintosh as the defacto platform for doing music and Midi, leaving products like mine and Todor Fay’s Bars and Pipes behind.
But Bryce, bless his heart, continued to poke at this problem behind the scenes and eventually came up with an answer. It turned out that the Amiga’s four timer chips were interfering with the serial port. Both the timer chips and the serial hardware were interrupt-driven, and the timer interrupts were a higher priority than the serial interrupts. Worse, the Amiga’s serial chip only had a 1-byte buffer — which means that if you didn’t pick up the data before the next byte arrived, the data would be lost.
Bryce was able to mitigate the problem somewhat by having AmigaOS turn off timer chips that weren’t in use. Unfortunately, they couldn’t all be turned off — AmigaOS needed one timer, and Music-X needed another. Turning off two of the four timers greatly reduced the frequency of the bug, but didn’t eliminate it entirely. And by this point the reputation of the Amiga had been stained beyond redemption, at least in professional music circles. It was too late.
Aftermath II
By 1991 it was clear that the Amiga was a dying platform, and that if you wanted a large customer base you were going to have to target MS-DOS as your primary platform.
However, there was a new contender on the block: the BeOS. Created by Be, Inc., BeOS was a modern operating system, lightning-fast, built from the ground up. It would not only have support for multi-tasking like the Amiga, but would even have multiple CPUs!
I decided that I wanted to create a new music sequencer for the BeOS. I couldn’t use the name “Music-X”, since that product was still being sold by MicroIllusions, or rather it’s successor AMP entertainment.
Instead, I came up with a new name: MeV, which stood for “Music enVironment” but also was the symbol used by physicists to indicate “mega electron volts”. I spent several months developing the product and was able to give some impressive demos.
However, the BeOS had some fundamental technical flaws. The biggest one is that they were so devoted to the idea of multi-tasking that they essentially forced programs to use multi-tasking whether they wanted to or not. You see, under BeOS, every window ran in a separate thread. The idea is that operations in one window would not block operations in another.
However, MeV was a multi-window app where all of the windows shared a common underlying data structure — the playback engine. MeV allowed you to have multiple ‘views’ of your music — you could open the piano-roll editor at the same time as the patch librarian and edit in both windows at the same time, while the music was playing.
Why is this a problem? You have to understand that writing multi-threaded code is hard. Well, let me correct that — writing multi-threaded code is easy, writing bug-free multi-threaded code is really, really hard. So hard, in fact, that many popular languages today, such as Node.js, don’t even support threading. People having been talking for decades how to create programming environments that allow simple, deadlock-free multithreading, and while there have been a lot of solutions proposed, there’s no clear winner even today, 25 years later.
On the Amiga, this wasn’t a problem because Music-X didn’t use threads, it used hardware interrupts — that meant that when the playback code was running, the code for editing was effectively frozen. You didn’t have to worry about one task trying to modify a piece of data while another task was attempting to read it.
But on the BeOS, having multiple editors trying to access the Midi data at the same time as the playback engine was trying to play it was a recipe for deadlocks and machine freezes.
I had long email discussions with the BeOS developers on how to manage complex shared data structures — they even added special features to the BeOS at my request, such as a read/write semaphore. But in the end, the problem was just too daunting and complex — the project collapsed under its own weight, and I moved on to other things.
Aftermath III
Somewhere around 1991–1992, I got a call from a producer at Electronic Arts named Hal Jordy who wanted to know if I was interested in creating a sequel to the popular Deluxe Music Construction Set for the Amiga.
The original DMCS was written by Geoff Brown for the Mac, and then ported to the Amiga, where it was very popular. Geoff was working on a version 2.0, and Hal wanted to know if I wanted to do the Amiga port.
This was just after we had founded The Dreamers Guild. Normally I would simply have accepted the contact, but I wanted to help promote our new company so I said I would do it if it could be an official Dreamers Guild project.
By this time I had a rich network of connections that I could draw on to help me, including Matt Nathan (who had helped out on Music-X) and Joe Pearce (my collaborator on Discovery 2 and many other projects).
I enthusiastically dove into the project, but quickly realized that all was not well. The original DMCS code from the Mac was an unstructured mess, and Geoff Brown’s new Mac version was behind schedule and struggling. Rather than wait for the Mac version to finish (which apparently it never did), I decided to go ahead and ‘fill in the blanks’ myself. In the end, I essentially re-wrote the entire program.
One thing I wanted for the project was to adopt the look and feel of AmigaOS 2.0, giving it a much more professional look.
However, Electronic Arts wanted the program to be compatible with earlier versions of AmigaOS. Once again, my collaborator Joe Pearce came to the rescue, by creating an adaptor library that would allow programs written for the AmigaOS 2.0 user interface to run on AmigaOS 1.3. We later sold this to other developers as an independent Dreamers Guild product.
Another thing I did was to create a new standard file format for storing sheet music. You see, one of the great things that distinguished the Amiga from other computers at that time was that many Amiga applications used a common file format (IFF — Interchange File Format) which let you export a file from one application and import into a different application. This might not seem particularly exciting today, where we have robust standards like MPEG and PNG, but it was fairly revolutionary back then.
I knew that the MMA (Midi Manufacturer’s Association) was working on a Midi standard for sheet music notation, but the technical white papers were basically just a rough sketch at that point. I decided to create a new IFF file format called CMUS (Complex Musical Score) which I had hoped would become a new standard. Unfortunately, I made some mistakes in the design of CMUS. And in the end it didn’t matter because the support for the Amiga was declining all over the world. This was the last major Amiga program that I worked on.
Coda
For my own musical creations, I eventually switched over to EMagic Logic, which eventually became Apple Logic. Part of my motivation for choosing this particular product is that I wanted something that would have many of the same features as Music-X, but ran on a modern computer.
I have also purchased many software synth modules from Native Instruments, Inc. I sold off my giant wall of synths and rack modules, and I am happy to have gotten rid of them. I never liked the idea that my music was confined to a studio, chained to the wall with thousands of electrical cords.
Interestingly, although I still use Logic to create music on my iMac, I do not use any other Apple-branded applications — not Safari, or Face Time, Mail or any other. I prefer open-source applications that work on any platform (my laptop runs Ubuntu) and which don’t lock me in to a single company’s “walled garden”.
You can find many of my recent musical compositions on my SoundCloud page.
If you liked this story, check out the next chapter: Inherit The Earth: Quest for the Orb.
