Marathon Devlog 2: Text Command

[Link to Github]

Hey there, I’ve added a new, very useful preset to Marathon this week so I figured I might as well write a post about it. I added preset “99”, which is text command. Before now, you had to create a MIDI file by yourself, using an external program, and Marathon was really fragile about that. So, for now, I suggest to stay away from preset “1” and try “99” when creating custom beats, unless you are certain that your procedure for creating MIDI files is tolerated by the program.

With Text Command, you can write out rhythmic patterns that the program will translate into MIDI notes. Here is what is prompted once you choose preset 99:

Enter text notation for track 1

Separate each note by a space, tied notes with a dash

w: whole note
h: half note
q: quarter note
e: eighth note
s: sixteenth note
t: thirty-second note

Dots (after the note)
.: dotted
..: double dotted
...: triple dotted

Tuplets (after note and dots)
x/y: where x-tuplet notes are to be played in y non-tuplet notes

Rest (at the end)

Enter text command (track 1):

A similar prompt will appear for track 2. One of the main and only requirements is that the two commands should have the same number of notes. Without that, interpolation between note pairs can’t be achieved and the program will quit. What constitutes a note, in the program’s eye? Simply, a string of text. Different notes will be divided by the space that separates them. That means that a tied note (two notes linked with a dash) will be seen as one note, because it’s a single “NoteOn” and “NoteOff” event. For example, a half note can be written as h or q-q (similarly, it could also be written out a myriad of other ways, such as q3/2-q3/2-q3/2 or q.-e). In short: notes separated by a dash will count as one.

Other than that, you can easily create most rhythmic patterns you can think of. Since it doesn’t keep track of measures and adds the note lengths with tick values directly, you can easily write incomplete tuplets, as would happen in non-dyadic (a.k.a. “irrational”) time signatures like \(\frac{5}{7}\) or \(\frac{2}{3}\). Couple that with the tied notes, and you can create pretty much any note length you can think of. The only limitation here is that note subdivisions only go as far as thirty-second notes. If you need to use smaller subdivisions of time, I suggest you double every note value and then the tempo too. In any case, once you have your MIDI file, it’s easy to import it in a digital audio workstation (DAW) and modify it.

Speaking of tempo, I didn’t include it in Marathon, since it doesn’t matter. MIDI works with beat resolution—in this program 960 ticks per beat, the highest resolution possible—and this value doesn’t change whether you play it at tempo 20 or 400. Just import the program’s MIDI output into your project, and it will automatically synchronize with its tempo.

Since Marathon is mainly about rhythm, I didn’t add note height to Text Command. The output is, by default, on MIDI note 60, which is usually C4. Feel free to alter this as you wish and modify the MIDI output to create distinct harmonies or chords; anything you can imagine.

While adding the Text Command to Marathon, I also added a slight tweak on how notes are interpolated. I noticed that since a middle-ground value was calculated between two rhythms, the resulting MIDI file would have a duration somewhere between the two original beats. This was not optimal, I thought, because it would often give you a really weird track length not in sync with the beats. So I just added a little bit where the length of the output file is calculated based on the length of track 1. As such, I recommend track 1 to be your foundation or “steady beat”, if you plan to have any. So, if your steady beat is q q q q, then your output track will last four beats (unless you put more repetitions than 1), no matter what the absolute duration of your second track is. That also means that if your second track consists of notes of equal length, like w w w w, then your output track will be indistinguishable from track 1, no matter the morph value, because it works in proportions now.

What’s next? I think I will try to implement progressive morph values, as seen in Braff’s notations. That means that Marathon could ask you two morph values: the starting one and the last one, and that the program would create a track that automatically goes from, for example, 0% to 100% morph on the course of 4 repetitions, or 16. As of now, if you want a similar impression, you have to manually change the morph value for each repetition, and that can be quite cumbersome. I could also try to implement rests [actually I just did so right now].

I hope you have fun with it. Share me your compositions or anything!

On March 2 2019, this entry was posted.