🎶

This is part of a ongoing series called Building A Music Engine

It documents the process of me smashing my head against the keyboard to build a game called LETSGO

It’s gotten long enough to break into several sections:

‣

Building A Music Engine entries

Music Systems: The Design of Sound

Music systems are culturally defined rules to organize sound. Those rules create complex systems, that when navigated intelligently, can bring a human to tears.

Examples include Arabic Maqamat’s or Indian Shruti’s, or Western 12 Tone Even Temperament.

A few simple rules that establish the soundtrack of entire peoples.

The thing about these music systems is that the rules are constant- especially when musician’s bend those rules.

There are 12 notes in western music. Even when making microtonal music (in the western music system), those microtones are being thought of in terms of being “between” the 12 notes.

These constants allow for sprawl into deep complexity.

💡

WolframAlpha creator Stephen Wolfram has a whole thing about the exponential complexity from simple rulesets.

Music systems are relatively simple rulesets with deep complexity.

Rule 30

Rule 30 is an elementary cellular automaton introduced by Stephen Wolfram in 1983. Using Wolfram's classification scheme, Rule 30 is a Class III rule, displaying aperiodic, chaotic behaviour.

en.wikipedia.org

Music is the cellular automaton of how sounds make humans feel.

Rules + Constraints = Design

In one essence, the rules are arbitrary. There are some mathematical correlations- which are exploited by musicians to give their music a specific effect.

But these rules exist because of the effect it has on the listener- not the mathematics.

Music systems develop culturally over time, successively building atop already established rules.

For my purposes, these arbitrary rules are awesome, because clear rules make for clear software design.

You rarely create these rules in a vacuum. Those rules have to work around certain constraints- the tools you use, the time you have, etc.

The neat thing about constraints is they are actually the best thing for designing beautiful systems.

Knowing what you *can’t* do focuses what you can do.

The stronger your constraints, the clearer your design.

So, to build a music engine, I want clear rules and a well defined problem.

💡

In researching this, I found a very interesting book on The Mathematics of Musical Set Theory.

Something I’m putting here as an inefficient bookmark:

[BOOK] The Mathematics of Musical Set Theory - Online Technical Discussion Groups—Wolfram Community

Wolfram Community forum discussion about [BOOK] The Mathematics of Musical Set Theory. Stay on top of important topics and build connections by joining Wolfram Community groups relevant to your interests.

community.wolfram.com

The Problem to Solve

Why do I need a “music theory engine”?

Well I completed a Audio Trigger Experiment - a box that plays a musical note when you step on it.

I then made a Music Platform Spawner that will create one of these boxes with a random note.

The problem to solve is to replace “Random” notes with something that sounds “good”.

How the hell are you supposed to tell the computer how to select notes that humans feel good about?

If only we had arbitrary rules to define good combinations of sounds!

There's limitations:

Soulless (but the game includes player input, ie. Soul)

Aaaaand which notes to play is only half the equation.

When to play those notes is just as complex a question to answer as what notes to play.

For now we focus on the What. When comes later.

The next chapter we start creating the rules of music into software:

🔢Programming Music: Constant Data