<aside> 🎶 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 </aside>

Programming Clear Rules

When designing software, it’s critical to think in terms of data.

If you know what data you have, and what data you need, it becomes clear how your program must manipulate input data to create output data.

And by starting with constant data- the stuff you know will not change- you have a natural starting point for your software design.

In western music theory, notes are separated into octaves by 12 even steps.

This is technically out of tune:

https://www.youtube.com/watch?v=7JhVcGtT8z4

Thankfully for us it doesn’t matter, because this form of tuning is constant.

Those constants give us 12 notes, labeled A → G, with some funny ♯ and ♭ symbols thrown in to get us 12 notes.

My first stab at designing a music theory engine is to capture these as constants:

// For now we are only concerned with 12TET traditional western music
enum Notes {
	A,
	B,
	C,
	D,
	E,
	F,
	G,
	CSHARP,
	DSHARP,
	FSHARP,
	GSHARP,
	ASHARP,
	DFLAT,
	EFLAT,
	GFLAT,
	AFLAT,
	BFLAT
};

An enum (enumeration) gives us a symbolic representation of a set of related values.

These notes are related, and the enum gives us a intuitive way to understand the data of our program:

Notes tonic = A;