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
}
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...
]
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
#
#0.25:melody1
C4 - C4 - C4 D4 C4 - D4 - D4 - D4 E4 D4 -
#
2.0 voice1 | voice2 | ...
POS | TRACK #1 | TRACK #2 | ... 2.0 note Cmaj7 ch=1
2.0 note D ch=1
2.0 note C dur=0.15 ch=2
2.1 note C ch=2
2.1 note Cmaj ch=1I 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.
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
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.
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?
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...
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 also don't get how you can claim we don't have to 'punch holes in cards to help the machine "think"', and also mention a MIDI file in your next comment. MIDI is much closer to punch cards than the proposed file format in the post.
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