This code generates all 8 note songs and saves them to disk, making you the proud copyright holder in the United States of all songs containing whole, quarter, eighth, and sixteenth notes that are 8 notes long (unless someone else has already done it, which surely they have)

The only problem is externality pricing.

Building https://negationgame.com

But you could also imagine trying to play a bit with the rules by only having one note value (duration you hold the note) but then using a musical tie to connect them

A tie is essentially a way for the composer to tell you to hold the note longer
https://en.wikipedia.org/wiki/Tie_(music)

Ties let us shrink the search

There are technical reasons that a composer might use a tie. They might want to connect two notes across a beat, or achieve a hold for which there's no standard symbol. E.g. a 5/8 hold, which could be done with a half note tied to an eighth note

We'll use ties to connect all possible repeated notes

This is going to be useful, because then we can save the sequence
A-A-A B "half-notes.txt"
as a file that indicates the base unit is half notes, and that gives us a new file sequence from 
A-A-A B "quarter-notes.txt"

Before that would have been:
A/2 A/2 A/2 B/2
and
A/4 A/4 A/4 B/4
respectively

Ok but problem

We still haven't shrunk the search space. In fact, now we've just made parts of it inaccessible. 

If we tie all sequences of notes, then it's impossible to generate these sequences:
A/2 A/4 B/4
or
A/4 A/2 B/4

They would all be
A-A-A B
Which if the base note value is quarter notes would be 
A/4 A/4 A/4 B/4

But that's exactly how we're going to shrink the space. We just need a new primitive: the optional tie.

The optional tie is a music notation sometimes found in jazz that instructs the player to tie the two notes together if they want to.

The syntax we'll use for an optional tie is:
A•A•A B
and we'll put it between all runs of the same note.

This now allows us to optionally treat all sequences of notes as one note.

Depending on how you look at it, with that single trick we've shrunk the search space from 2 to the aleph null down to merely aleph null over all possible note lengths.

That's the difference between trying to collect all Reals vs collecting merely the Integers.

If you're more pedantic (hello, nice to meet you) then you'll argue that note durations are not continuous: there is a minimum note length that a human can hear.

In that case, it's more like we've gone from searching the length 8 permutations of N × D, where D is the durations of the notes, to merely permutes of N

What has been puzzling me about the viral video that @jrf posted is how they managed to search such a large space. But I think I now understand it.

https://warpcast.com/jrf/0x09ff23

It turns out that the shortest duration that humans can hear is about 0.02 ms, or about 1/256 of a whole note

Let's plot the amount of time that you save with my approach.

Factorials are freaky huh? With my approach you save 8000 universe durations worth of compute.

But maybe they are just searching only up to 1/128 notes?

Huh, nope. My approach searching up to 1/128 saves you 35 age-of-universes worth of compute time.

P.S. by compute time I mean based on tests on my M1 Max

So I just don't understand how they searched all that, unless they're already using my approach or I'm doing something wrong.

Ok yeah I must be missing something because these search spaces are way too large to fit in 68.7 billion melodies? Maybe a melody is explicitly time-independent. That would clear things up. But then what about flats and sharps?

Anyway can you tell I have important work I'm supposed to be doing?

there are maybe two ways to think about how to go about generating these.

The first is the approach shown above, where you start with whole notes and then bifurcate down to smaller note values.

is anyone going to point out that my code is wrong?