MML Workflows in Early Genesis Music Composition

Hello! Welcome to the first lesson in our final module, "Tools, Evolution, and Lasting Legacy."

This module shifts our focus from the composers' musical styles to the technical means of production they employed. We'll investigate the software, hardware, and workflows that defined the sound of the Sega Genesis.

Today's lesson addresses the very foundation of early Genesis music creation. Our goal is to describe the Music Macro Language (MML) based workflows used by composers for early Genesis titles. We will explore what MML is, how it was used in a practical development environment, and why the line between composer and programmer was so often blurred in this era.

Your background in implementing numerical simulations from scratch will be advantageous here. You're familiar with the process of translating abstract concepts into low-level code to control hardware, which is conceptually similar to how these composers worked.

Let's begin by defining what MML was in this context.

1. What is Music Macro Language (MML)?

In the late 1980s and early 90s, before the widespread adoption of graphical Digital Audio Workstations (DAWs) and standardized protocols like MIDI for game development, music was often "programmed" rather than simply "composed." Music Macro Language was a primary method for this.

MML is a text-based notation system. Think of it not as a universal standard, but as a domain-specific language tailored to a particular piece of software—the sound driver. Each sound driver had its own MML dialect. Composers would write text files with commands for notes (cde), rests (r), note lengths (l4 for a quarter note), and octaves (o4).

However, the crucial aspect of MML in the Genesis era was its ability to go beyond basic notation and directly control the synthesis hardware. To understand this better, please read the following excerpt from an article on Hidden Palace, which analyzes technical documents from Sega of Japan.

As you read, MML was essentially a form of "enumerated assembly." It gave composers access to:

• Opcodes and Flags: Direct commands to manipulate the sound chip's registers.
• Music Routines: Programming logic like loops, branches, and returns to structure the music data efficiently.

This provided a level of control that is abstracted away in modern tools. A composer could fine-tune the parameters of an FM patch mid-note, create complex looping patterns to save memory, or implement custom effects.

To see the practical implications of this control, let's turn to one of the masters of the craft, Yuzo Koshiro. In this interview, he reflects on the shift from MML to MIDI.

Koshiro's statement that he could use programming to "re-create [functionality] on the software side" is key. He gives the example of making a 3-voice chip sound like it has 6 voices, likely through extremely fast note-switching (arpeggiation) that creates the illusion of polyphony. This wasn't a feature of the hardware; it was a result of clever programming enabled by the MML workflow.

2. The MML Workflow in Practice

Now that we understand what MML is, let's examine the step-by-step process of using it to create music for a Genesis game. The workflow was a multi-stage process involving different pieces of hardware.

The same Hidden Palace article provides a clear description of the typical development environment.

Based on that text, we can outline the workflow as follows:

1. Composition & Programming (Workstation): The composer writes the music in the driver's MML dialect using a text editor on a computer like the NEC PC-9801. This is where the creative and technical work of defining notes, rhythms, and synth parameters happens.
2. Assembly/Compilation (Workstation): The MML source text is assembled into a binary format that the sound driver on the Genesis can understand.
3. Transfer & Testing (Dev Kit): This binary data is transferred to a special piece of Genesis hardware—a "ROM-RAM board"—which allows the developers to run their code on the console.
4. Playback & Debugging (Genesis Hardware): Using a tool like the "SOUND EDITOR" mentioned in the text, the composer can now listen to their music on the actual YM2612 and SN76489 chips. This is a critical step, as the sound could differ from PC-based emulators. They could view the data, debug issues, and tweak parameters in real-time.
5. Iteration: Any changes or fixes would be saved and transferred back to the workstation, and the cycle would repeat.

This iterative loop of coding, compiling, and testing on target hardware is fundamental to embedded systems development and may feel familiar.

Yuzo Koshiro's personal experience aligns perfectly with this general description.

His comment about composing at home on his PC-88 and using a "data converter" is a direct confirmation of this process. It underscores the separation between the creation environment (the PC) and the target environment (the Genesis).

3. The Composer as Programmer

This workflow implies that a successful composer needed more than just musical talent; they needed significant programming acumen. Yuzo Koshiro is the archetypal example of this fusion of skills.

The following video interview provides excellent insight into his background and how his programming skills were not just an asset but the very foundation of his musical career.

Koshiro's story makes it clear that for him, composition was an act of programming.

• He started as a programmer, contributing code to magazines.
• His familiarity with the PC-88's sound hardware gave him an immediate advantage on the Genesis.
• Most importantly, he wasn't just a user of MML; he was a creator of his own MML dialect and sound driver, "Music Love." This gave him unparalleled freedom to innovate.

This deep technical involvement was the key that unlocked the complex, dance-music-inspired soundtracks of games like Streets of Rage, which were unlike anything heard on a console before.

Finally, to place this technical work in a project management context, the Hidden Palace article also provides a glimpse into a typical production schedule.

This shows a structured process where music was typically composed and approved about two months before the game's completion, followed by sound effects, implementation, and final checks.

Conclusion

In this lesson, we have deconstructed the MML-based workflows that powered the music of early Sega Genesis titles.

Key Takeaways:

• MML as a Programming Language: In the context of the Genesis, MML was more than a simple notation system. It was a text-based language for a specific sound driver that gave composers low-level access to the sound hardware through opcodes and programming logic.
• The Development Workflow: Music was written as text on a PC workstation, compiled into binary data, and then transferred to a Genesis development kit for playback and debugging on the actual hardware.
• The Composer-Programmer: Early composers like Yuzo Koshiro were often skilled programmers. This technical expertise was not just a convenience but a powerful creative tool, allowing them to build their own drivers and push the hardware beyond its apparent limitations.

This deep, code-level approach stands in stark contrast to the more user-friendly, standardized tools that would come later.

In our next lesson, we will explore one of those later tools: the GEMS (Genesis Editor for Music and Sound effects) driver. We will compare its workflow to the MML-based systems and analyze the creative trade-offs between the two approaches.