https://en.wikipedia.org/wiki/ABC_notation https://abcnotation.com/
MTXT focuses on editable recordings of live performances, preserving all of those tiny irregularities that make the music human. It can represent arbitrary timings, subtle expressive variations and even arbitrary tuning systems. MTXT can also capture transitions like crescendos and accelerandos exactly as they happened.
* Perl MIDI::Score -- https://metacpan.org/pod/MIDI::Score
* Csound standard numeric scores -- https://csound.com/docs/manual/ScoreTop.html
* CsBeats (alternative score language for Csound) -- https://csound.com/docs/manual/CsBeats.html
https://en.wikipedia.org/wiki/LilyPond#Integration_into_Medi...
https://www.mutopiaproject.org
https://lilypond.org/text-input.html
\relative c' {
\key d
\major
fis4 fis g a
a g fis e
d d e fis
fis4. e8 e2
}
...but why is it so complicated? A novice interpretation of "music" is "a bunch of notes!" ... my amateur interpretation of "music" is "layers of notes".You can either spam 100 notes in a row, or you effectively end up with:
melody = [ a, b, [c+d], e, ... ]
bassline = [ b, _, b, _, ... ]
music = melody + bassline
score = [
"a bunch of helper text",
+ melody,
+ bassline,
+ page_size, etc...
]
...so Lilypond basically made "Tex4Music", and the format serves a few dual purposes:Engraving! Basically "typesetting" the music for human eyeballs (ie: `*.ly` => `*.pdf`).
Rendering! Basically "playing" the music for human ears (ie: `*.ly` => `*.mid`)
Librarification! Basically, if your music format has "variables" and "for-loops", you can end up with an end score that's something like: `song = [ intro + chorus + bridge + chorus + outro ]`, and then not have to chase down and modify all the places you use `chorus` when you modify it. (See this answer for more precision: https://music.stackexchange.com/a/130894 )
...now imagine doing all of the above for multiple instruments and parceling out `guitar.pdf`, `bass.pdf`, `drums.pdf` and `whole-song.pdf`
TL;DR: Music is haaard, and a lot closer to programming than you think!
Can I suggest a guarded mode that specifies how far apart each given note/chord is by the count, e.g.
#1.0:verse1
Am - C - G - E - F F F F
#
You could then repeat this or overlay a melody line like #0.25:melody1
C4 - C4 - C4 D4 C4 - D4 - D4 - D4 E4 D4 -
#
Etc. I think this would be easier to parse and produce for an LLM, and it’s would compile back to the original spec easily as well. 2.0 voice1 | voice2 | ...
Like a text version of old school tracker interfaces: POS | TRACK #1 | TRACK #2 | ...Looks like MTXT tool here does not quite work for this use case, the result of the roundtrip of a midi I tried has a segment folded over, making two separate segments play at the same time while the total duration got shorter.
https://files.catbox.moe/5q44q0.zip (buggy output starts at 42 seconds)
I created an issue here: https://github.com/Daninet/mtxt/issues/1
For me it was coming from tracker notation (buzz), where i was wildly underwhelmed by all that whitespace for timing (well, empty cells for timing) and the lack of parameterizable macros. A seriously underexplored field, perhaps because almost everybody who ever started got pulled in by the lure of textually defined synthesis.
http://www.colinfraser.com/m5000/ample-nucleus-pg.pdf
For macros, see:
https://www.retro-kit.co.uk/user/custom/Acorn/3rdParty/Hybri...
Also, any apps that uses it would benefit from being add to the repo assuring usability in addition to readibility.
Now I'm working on a synth that uses MTXT as its first-class recording format, and it's also pushing me to fine-tune a language model on it.
I feel that one challenge of programming languages is how to remember these rules, formats, and keywords. Even if you're using familiar formats like YAML or JSON, how do you match keywords?
When developing Glicol (http://glicol.org/), I found that if it's based on an audio graph, all node inputs and outputs are all signals, which at least reduces the matching problems. The remaining challenge is ensuring that reference documentation is available at the minimal cost.
Not so sure how human-friendly the fractional beats are? Is that something that people more into music than I am are comfortable with? I would have expected something like MIDIs "24 ticks per quarter note" instead. And a format like bar.beat.tick. Maybe just because that is what I am used to.
I'm planning to add support for math formulas in beat numbers, something like: "15+/3+/4" = 15.58333
Can you explain how to read that? 15 plus divided by 3 plus divided by 4?
I played around with a similar idea on my own (very simple / poor) text music environment:
https://github.com/jasonjmcghee/vscode-extension-playground?...
in the middle of making an extension to allow making vs code extensions live because I wanted a faster development feedback loop.
They have a notation that looks similar (basically a JavaScript port of the Haskell version).
I like this, but I'm curious why I would want to use this over strudel. Strudel blends the language with a js runtime and that's really powerful and fun.
Which has a text format, and typesets it for you nicely.
That's literally what "prompt engineering" is, though.
I'm wondering if it can be used alongside strudal https://strudel.cc/ Either mtxt => strudal or strudal => mtxt
Heres strudal in action https://www.youtube.com/shorts/YFQm8Hk73ug