如题，从几周前就开始构思的。因为最先了解到的都是UI式的编排——这很不浪漫（，于是便有了这个的企划，途中遇见了lilypond，但是还是感觉因为顾及了排版而使我们不是那么专注于内容本身；再加上看了看示例代码可读性/易转写性还是不太好语法不优雅，决定自己写一个。暂且命名为μdown。
最先的话，先写规范；实现暂时打算用Python代码转为.ly再编译，不过都是规范大致完整之后的事情了。
0 原则
- 不在源码中涉及排版内容，交给编译器中的自定义来处理这些。
- 可写性最高，可读性次之，二者是需要最先考虑的。
- 视觉上的直观感受在编写时优于音乐专业知识。
- 比如说，第三间应该记为某个间或者线相对而言的数字，如0或者6，而非C或者do。
- 可以有方言。
1 语法元素
对于音乐本身的音符和各种标记，我们只需要两种元素：
- 音符
- 修饰
1.1 音符
而音符则由纯粹的整型数字构成，规定第三间为0，则第四线为1，第三线为-1，以此类推，附加线同理。不同的音符之间应当有语法规则上的分隔。
1.2 修饰
修饰被包含在()一对括号里。而修饰又包含两个部分：函数与变量，它应当遵守Lisp的前置表示方式。但是作为可写性强的标记脚本，函数与变量并不是必须都包含的。如：
- 纯粹的字符串会被理解为自动计算间隔打印在该行下，如
('My guiding star...')就是合格的修饰。 - 纯粹的函数名就多了，如
(#)和(b)分别表示在音符前添加升号和降号。
事实上，我们鼓励多编写不需要参数的函数，很明显，这样会让文件更自然且简短。
1.3 列表
请注意，修饰只对于括号后一个音符有修饰效果，如果要修饰多个连续的音符，建议为这些音符两侧添加[]使其变为一个列表并在之前添加修饰。
(func) a (func) b是等价于(func) [a b]的。
2 文件结构
文件 > 乐章 > 行
2.1 乐章
最基本的μdown文件（以下称为.mud文件）应当由两个乐章组成：
- meta乐章
- main乐章
其中meta乐章的乐章名（meta）是不可变的，而main乐章则是只要存在即可，你完全可以命名main乐章为mian乐章。
2.1.1 meta乐章
meta乐章采用yaml的语法，它声明这个谱子诸如作者、copyright、名字一类的信息。并且支持下文将要讲到的include函数。
2.1.2 main乐章
main乐章即为乐曲的内容，它遵循μdown的语法。
2.1.3 其他乐章
如果一部作品有多个乐章，则meta以外第一个乐章就是main乐章，剩下的都将遵守μdown语法被编译。限于篇幅，具体细节就不展开了。
2.2 行（声部）
我们推荐使用行这个更直观的方式来代替声部一词。
⚠请注意这里的行（声部）是不同于排版打印意义上的行的。
我们可以看到经常有大括号括起来若干声部的情况，这在钢琴（左右手）以及交响乐总谱中是十分常见的。
同样，具体的语法细节不会展开详细说明。
2.3 include函数
include函数允许你引入一个文件在当前文件的特定位置，这在编写很长的乐谱时会十分有用。它等效于插入这个文件中所有的字符在该函数被引用的位置。
一个示例：(include 'file/path/filename')
请注意，include函数是唯一的非修饰函数，且请不要忘记文件名的后缀
2.4 一个伪代码示例
// example.mud
meta:
meta_info_a: xxxx
meta_info_b: xxxx
(include 'includes/metainfos.yml')
main:
line_a start:
(func) [line_a_notes]
line_b start:
1 1 4 5 1 4 // line b notes
main2:
(include 'main2.mud')
我们不会在这里展开叙述其中的语法细节，这个伪代码只是为了让你了解文件 > 乐章 > 行的结构。
3 协议和一些话
本项目采用MIT协议。
我的乐理知识很有限，技术也同样很差，但还是希望可以受到指导，并且，我们衷心期望您可以加入我们的项目做出贡献。
虽然这个团队还是一个爱丽丝幻乐团式只有一个人的团队
Koumakan Maid Corporation of the Scarlettes
本项目的repo在这里
谢谢。