

Okay, that’s all very interesting and I love the idea about dynamic music, I’ve had similar thoughts myself but wouldn’t have thought to go this far to make it happen. I’d love to see what you come up with!
My only real thoughts are about the transpiling, so the editor uses relative time codes but the format itself uses absolute, if I understand you, and you’re converting between the two?
That to me hints of code smell, because I wonder why that’s necessary. For example, could you program the editor to display and work in absolute time codes, or is there something stopping that from happening?
Alternatively you could simply make the format capable of natively understanding both relative and absolute commands, so whichever is more appropriate to the context is what gets used.
Keeping them different seems like it will require you to program two formats, make them compatible with one another and deal with bugs in both of them. Essentially you’ve not only doubled the number of places where bugs can arise within the formats, you’ve added the extra step of transpiling which also doubles the number of interactions between the formats, adding even more complexity, even more places where inconsistencies can show up, even more code to sift through to find the problem.
It’s the sort of thing that shows up in legacy systems where the programmers don’t have the freedom to simply ditch one of the parts.
Personally if I had the freedom of programming the system from scratch I would rather commit completely to a single format and make it work across the entire stack, so then I only have one interpreter/encoder to consider. That one parser would then be the single point of reference for every interaction with the format. Any code that wants to get or place a note for any reason - for playing, editing, recording, whatever - would use the same set of functions, and then you automatically get consistency across all of it.
Edit: another thought about this: if you need some notes to be absolute and others to be relative, it might be worth having an absolute anchor command that other commands can be relative to, and have it indexed, so commands are relative to anchor 1, 2, etc. Maybe anchor 0 is just the start of the song. Also maybe you could set any command as an anchor by referring to its index. That way you can still move around those commands in a relative way while still having the overall format reducible to absolute times during playback. Also a note “duration” could just be an off command set relative to its corresponding on command.
I say that because as another principle I like to make sure that I “name things what they are”. If the user is programming things in the editor that are relative, but under the hood they’re translated into absolute terms, that will probably lead to unexpected behaviour.












I’m just perusing my old comments and came across this, 7 months later. This is an amazing article, thank you.