如题,从几周前就开始构思的。因为最先了解到的都是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在这里
谢谢。