随便说点啥

　　不想看废话的、查询GM标准音色表、MIDI信息状态表等资料的同僚们请 直奔附录 。
　　眼看2013就结束了，想着用啥来总结好呢。2013大半时间在路上，有空了小旅馆里开着网想一想，还是蛮有意思的一个东西。HTML5火爆了2013，图像、游戏、交互等等各个分支发展都很喜人。走马观花溜一遍，到了数字音乐领域，感觉有点像看春哥和曾哥对台唱歌一样从繁华喧闹的市集走到胡同脚里一片黯然收场。零零散散搜集到一些资料，算是给自己的2013一个交代。想做的事情越来越多，时间越来越少——希望自己2014年能在感兴趣的方面有一些收获。
　　其实之前也跟一些朋友聊起过这个话题，让我比较诧异的是MIDI这东西在很多人眼里还一直是极客手中的玩物——也难怪，这应当归咎于数字音乐在互联网的缓步发展。回顾2013年，有许多令人尖叫的音乐相关作品问世，例如google的 吉他doodle ， 多人游戏plink 等等无不令人啧啧称赞。
　　 社交化的数字音乐 仍然一如既往拥有很大的市场，受限于技术门槛和不完善的标准支持，这方面国内国外都鲜有建树，即便桌面领域或者基于flash的应用已经相当成熟——这是后话了。
　　受限于鄙人学识，以下内容部分纯属胡编滥造，如有误导烦请指正，或者你来打我啊。

虚拟MIDI环境简介

　　传统MIDI一系列设备，没有几年功夫和一定的存款，要想搭建一套可以自己谱谱曲的环境，不用烂几块键盘没几个几十G的雅马哈音色库恐怕很难搞定。许多专业录音棚出产的电子乐甚至可以媲美中端音乐厅水平。当然吾等屌丝不需要那么豪华的阵容，硬盘加右手就够了。
　　设想在一个只有浏览器的环境中创建可以实时播放的MIDI环境。最基本的，这套工具应该可以方便的让我这样不懂乐理的人也会点出声加点特效，钢琴二胡和隔壁王老坎家骡子拉磨的声音来个混响，最后还能允许我把这声音弄下来挂门上驱灾撵狗啥的。
　　为了实现这个简单的目的，我们需要一些基本的道具，包括可以敲的 输入设备 ，用于混响和播放声音的 通道 ，能够管理通道信息和状态的 合成器 ，装了各种声音的 音色库（软波表） ，其中应当有我想要的骡子声 乐器 ，一个正常的喇叭作为 输出设备 ，最后把这些所有东西集合起来可以打包输出文件的——几年前我们一伙人管这叫—— 数字音乐模拟系统 ，至今我仍然认为这是个好名字。

MIDI

　　MIDI实际上只是一个乐谱，只不过五线谱是给演奏家看的，MIDI是给合成器看的。MIDI文件中定义了在某一时刻用某种节奏的某个音量播放某种乐器，持续多长时间采用什么效果。除此之外还能记录诸如“幕布升起”、“扣钉骑士万岁万岁万万岁”等类似的文本信息和提示内容，提供给读乐谱的程序看。

输入设备

　　不赘述，我们有键盘，上百个键位和控制键，完全够用了。可能什么键对应啥操作需要好好想一想。

通道/Channel

　　通道是一系列互不干扰的音频流传输介质。MIDI标准中允许一个合成器同时管理16个通道，一个通道同一时间只能维护一种乐器状态。不过理论上来说一个MIDI乐谱中可以同时存在的乐器数无上限的，只是在超过通道限制时需要在乐谱中告诉合成器某某时刻应该切换乐器，合适的时候再切换回去云云。在非真实MIDI硬件设备的模拟环境中尤其对于浏览器环境而言，需要手动实现对于音频流的管理。

合成器/Synthesizer

　　简单来说就是一个音频流的管理程序，提供解读乐谱、混响、音效支持和通道控制等功能。合成器通过读取给定的音色库解析和播放MIDI乐谱。对于非人民币玩家，要想在浏览器环境中以原生的方式搞到这个神奇的东西，用代码写吧XD。好在目前HTML5中的 AudioAPI 提供的一系列音频流处理接口已经基本满足构造一个能跑的合成器的条件。

音色库/Sound Font/Sound Bank

　　我们所讨论的软波表，特指装载了一系列乐器音效的一个打包文件。该文件中存储了一系列基本的压缩音频采样，并定义了一套规范用于描述特定的乐器在给定 音调/Tone 和 音量/Voice 时应当被如何通过已有的采样信息进行混响。解析并执行这一套规范就是合成器的作用。广泛使用的音色库文件如 .sf2 ，几乎已成为MIDI音色库现行标准。好的音色库动辄十几张CD的存储量，这么大的容量得益于其未经压缩的采样率。雅马哈的一些特效音色库制作甚至耗时几年，从亚马逊河流域、阿尔卑斯山脉等地方录下最纯粹和原始的自然声音压制而成。上面这句纯属忽悠。
　　目前几乎所有的操作系统中默认装载了声卡里的音色库，例如WIndows下经典的"GS波表软件合成器"——这便是为何可以直接在windows中点击播放MIDI文件的原因——一个约3.4M大小带音色库的合成器，支持 GS/GM标准 ，该音色库存在"C:\Windows\System32\drivers\gm.dls"。好的声卡显而易见会提供更好的音色库，以便专业玩家创造出众的音乐体验。
　　 音色库文件 的解析，在HTML5规范中几乎是一片空白。不过国外有研究团队已经在这方面颇有建树， HTML5 MIDI API 的贡献者之一， 日本哥Toyoshim 的开源项目T'Sound System Library  已经实现 用js读取.sf2格式文件 。著名的HTML5音频研究团队的MIDI框架 MIDI.js 用了一套已经打包为 .mp3 格式的base64文件来模拟音色库，这也是目前几乎所有web音频类应用的通用做法并且仍然没有更好的策略。即便是大名鼎鼎的Java，对于音色库的支持也一直推迟到 JDK7的com.sun.media.sound 包中才得以完整实现。

乐器/Instrument

　　存储在音色库中的采样音频以及对该音频的预定义播放方式，展现在输出设备中就是乐器。GM音色库标准中定义了 128种标准乐器 ，但不同的音色库中包含的音色信息可能相差非常大，这也是为何 .midi 格式的文件在不同的系统下可能会播放出不同效果的原因。
　　正常情况下，通道 K 默认对应除了标准128中乐器中的第 K 个乐器，除非合成器告诉他需要切换乐器；特殊情况为作为打击乐保留通道的第Channel 10，其中的正常音符在默认情况下可能表现出不同的音色。

输出设备

　　声卡和音响设备。但凡是个电脑都有的东西，并且浏览器已经通过AudioApi封装了对输出设备的访问，所以不需要我们关心。

小霸王至尊8合1

　　事情到目前为止进展的似乎挺不错。我们只需要提供一个可以操作的界面，把这些东西全部打包装在一起，这就是个可以在浏览器端生成MIDI乐谱、可以导出为MP3的超级8合1至尊卡带了。不过等等，MIDI乐谱？

MIDI文件结构

　　看来我们遇到了一点小麻烦，在解决如何生成MIDI乐谱之前可能得复习复习MIDI文件结构。关于这方面已经有诸多文献可参考，例如鄙人本科时与好基友 大树阴凉儿 所著的 Bottom-up Digital Music Simulation System Under Program Control （百度貌似也能搜到免费版。。。）。这里有张图简要概括了MIDI文件结构：

音序/Sequence

　　我们称一个完整的MIDI乐谱为一条 音序 。一个音序中至少应当定义 MIDI文件类型 、 音轨 数、 节拍 （和节拍定义方式）等基本信息，这些信息被记录在 Header Chunk 中，即便该音序中不包含任何音符信息——那你要这条音序干嘛。。。

Header Chunk

/**
头部声明区                          | 数据长度声明区                      | 数据位
ASCII M  ASCII T  ASCII h  ASCII d  | Data Length: 6                      | MIDI type: 1     | Track Count: 1   | Division: mode0, 120 ticsks/second01010100 01101000 01100100   00000000 00000000 00000000 00000110   00000000 00000001  00000000 00000001  00000000 11110000*/

　　首部块内容如上所示，用于声明一条音序的基本信息，仅用于标注文件声明。其中，4字节ASCII数据“MThd”为Header Chunk标识位，data length值为当前Chunk中数据位的长度。数据位包括3部分内容：

文件类型

　　2字节数据，整数。合法的MIDI文件应当属于以下三种类型的一种：

• 0类MIDI：仅能容纳单一音轨；
• 1类MIDI：容纳多个音轨，所有音轨中的事件将按照既定时间戳同时播放——这也是应用最广泛的音序类型；
• 2类MIDI：容纳多个音轨，每个音轨中的事件将在上一条音轨结束之后开始播放。

音轨数

　　Header Chunk本身并不是音轨，其中以2字节记录除Header Chunk以外的其他类型Chunk（亦即 音轨 ）数量。

节拍定义/division

/**
|H|8-14bit 0-7bit
000 00000000*/

　　如上结构的2字节数据位，这是个麻烦的字段。节拍有两种表示方式，取决于字段最高位（H位置处）数据：

• 0类节拍定义：0-14bit数据为一个整数，表示一个1/4音符（测试结论貌似持续0.5秒？）中的时间戳数量，值以120居多，简单粗暴；
• 1类节拍定义：更精确的节拍定义方式。0-7bit表示每一 SMPTE（） 帧中的tick数；8-14bit表示每秒钟内的 SMPTE 帧数，详情可参考MTC Quarter Frame中的相关定义。这种定义方式应用不多。

Track Chunk

　　 音轨 定义区。这实际上是一个逻辑分区，区分头部和数据部分。

音轨/Track

/**
头部声明区                          | 数据长度声明区                      | 数据区            | 结束标记
ASCII M  ASCII T  ASCII r  ASCII k  | Data Length: unknown                | OOXX....          | Ending the track: FF 2F 0001010100 01110010 01101011 | OOOOOOOO XXXXXXXX OOOOOOOO XXXXXXXX | OOOOOOOO XXXXXXXX | 11111111 00101111 00000000*/

　　音轨是一系列数据的集合，每条音轨以声明ASCII“MTrk”开始。音轨是一个完全不受限制的数据定义区域，其中记录乐谱各种信息，包含但不仅限于：版权声明、文本信息、开启/关闭声音( Note On/Note Off )、改变乐器（ Program Change ）等等。MTrk类型Chunk必须有 结束标记 ，并且结束标记也应当计算入数据区总长度。
　　一个音序中通常包含至少1条音轨定义，并且仅在第一条音轨中保存类似版权信息、乐谱通用定义。非0类音轨也会通常将这些信息独立为一条音轨以方便维护。
　　音轨本身作为数据集合，与硬件载体并不存在任何关系。但是在实现过程中，通常建议一条包含Channel信息的Track仅对应一个Channel——亦即所保存的除公共信息（例如版权声明）之外的数据均应尽量操作同一个Channel。由于Channel总数不超过16个，因此一个MIDI乐谱中的Track数量通常也不会超过17条；更甚由于一个Channel同时只能维护一种乐器，因此通常情况下，一首MIDI乐谱也不会设计超过16种乐器混响。
　　下面我们聊一聊Track中的数据，以便解释一下上文这段话。啊，这将是个沉重的话题。

MIDI事件/Event

/*** 一则简单版权声明事件*
时间戳   | MIDI消息体
Tick     | Message Type      | Length   | Message Data11111111 00000010   00000010   01000110 01000101*/

　　简言之，存储于Track数据区的所有内容均为一则 事件 ，其结构如前文所示，主要包含两部分内容， 时间戳 和 MIDI消息 。事件是Track内容的基本组成单元，拥有时间戳是其固有属性。一则正确定义的事件将按照节拍的与定义方式（Header Chunk中的division）在合适的时间被合成器触发，并产生相应的效果。

时间戳/Tick

　　事件数据之间并不存在严格的边界，因此识别一条事件的依据便是消息体中严格定义的数据消息体长度和下一个事件的时间戳。在我们之前所定义的Header Chunk（1型MIDI，120tick/s）中，tick始终表示“当前事件的发生时刻”与“上一事件发生时刻”之间的时间刻度差值Delta Time。
　　在编程模拟方面，维护“一个事件基于其他事件的严格顺序”是一件相当蛋疼的事情，这意味着可能得使用链表来管理一个乃至十万数量级（一首5分钟高清音序中的事件数规模在万级）的数据结构。Java中将Delta Time存储为“从音序开始执行以来所经历的tick”作为哈希的键值来存储和管理这些事件，一定程度上改善了检索、修改等操作的执行效率。可以参考 JDK6中的Track类的 源码。
　　注意由于一首乐谱的时间刻度可能会在规范允许的范围内被定义的相当密集，因此tick的数值理论上可以达到无限大。这可怎么办，设想我们的骡子早上叫了一声晚上叫了一声，这时这两个事件发生的时间间隔恐怕8字节的256个tick无法表达我们对于骡子的热爱之情。
　　因此，时间戳必须是一个 可变长度数 。

可变长度数

　　可变长度数允许不通过单独的length标记位记录一个长度不固定的正整数。对于可以通过7位以内二进制数表示的数据，看起来跟普通的二进制数没啥区别：

/**
:*/

　　对于超过127的数据，可变长度数需要扩展高位字节，并遵循如下规则：

• 所有可变长度数中，每个字节最高位用作标记位；
• 除非是最末位8个字节，否则当前字节中的标记位记1；
• 最末位8个字节标记位记0，该可变长度数结束。

　　遵循对于以上规则，可变长度数中每个字节只能用来表示128个数。于是我们就有了以下奇葩的数据表示：

/**
:- 普通二进制:- 可变长度数:01111111- 普通二进制:11111111- 可变长度数:01111111- 普通二进制:00000000- 可变长度数:10000000 00000000*/

MIDI消息

　　作为MIDI Event的组成部分，MIDI消息才是这通篇的主角，其在MIDI系统中的地位就是北方的面南方的米沙漠里面边下的雨。
　　如MIDI事件一节所示，一个MIDI消息包含消息类型、数据长度、数据体三部分。一则乐谱中所有控制信息均存储于消息中，不同的资料会罗列不同的分类方式。通常按照存储消息解析方式的不同分其为四类： Meta消息 、 Sysex消息 、 控制消息 和 通道消息 。

Meta消息

　　虽然所有事件都应当被合成器识别，但Meta消息始终不会被响应为输出。Meta消息仅用于记录，如果一个音序是一页代码，Meta消息就是代码中的注释。
　　所有Meta消息的消息类型均以"FF"开头作为标志：

/*** 一则简单版权声明事件内的消息体*
Meta消息
消息类型: FF 02   | Length:2 | ASCII: F ASCII: E00000010   00000010   01000110 01000101*/

　　上图所示的消息类型为“FF 02”，标准中定义其为“版权声明”。比较重要的Meta消息类型有“版权声明”（FF 02）和Track结束标记（FF 2F 00），在任何音序中都会存在。
　　Meta消息由于可被用于记录不定长数据，因此其中的Length位也为 可变长度数 ；数据位可以为特定格式标记、ASCII字符或为空（结束标记长度0、数据位空）。例如你可以声明一则长度为4字节的文本消息，然后像个不太能喝的司机被人猛灌一顿之后开着车在32车道的公路上随意发挥，甚至把莎士比亚全集录进去也是允许的，这都取决于Meta消息类型。
　　更多Meta消息类型可参考 附录二：Meta消息类型表 。

专用系统消息“F0/F7”/Sysex Message（注：此处存疑）

/*** 系统专用信息结构*
Meta消息
消息类型 | 0iiiiiii | 任意数据                     | 结束标记00000100   10010000   01111111 01111111   11110111*/

　　一个系统专用信息如果以“F0”开始，则必须以“F7”作为结尾。因此，“F7”也被称作“End of Exclusive (EOX)”。
　　在多份同样的标准文档中，我看到多个关于此消息的不同解释，分别来自“ Standard MIDI-File Format Spec. 1.1 ”和“ Standard MIDI-File Format Spec. 1.1, updated ”。也希对此有深刻认识的同僚能够指出此文谬误。下文中给出两个不同的解释细则仅供参考，其中所列举的字节码亦并不保证正确性。
　　 释义一：特定厂商专用扩展信息
　　专用系统消息（Syntactic System Exclusive Message）的名字来由于其只会对特定的合成器系统起作用。该消息允许对某一事件进行“加密”，合成器在读到该事件时检测“密文”是否与自己所定义的“密文”相匹配。如果不匹配，则忽略该整个事件；否则对其进行解析。
　　Sysex消息可以被用作一个“加密包裹”用于包裹任何其他类型的所有事件，也可用作 保留字段 用于包裹合成器自身的自定义事件（例如当前合成器实现的标准范围外的 控制器 类型），当然更多是用作发送针对合成器的特殊指令。MIDI中定义了许多 保留字段 用于后续扩展或交由合成器厂商自己实现，使用Sysex事件修饰的 保留字段 可以避免该消息被其他合成器错误解析，该扩展方式被称作合成器的“Universal Exclusive Messages”。
　　在此类释义下，该信息结构中的 0iiiiiii 字段即提供给合成器用于鉴别的“密文”： MIDI设备生产商ID ，固定长度为8bit并且最高位为0。合成器在不能识别该密文时应当将其中的直至结束标记位置的数据字段全部忽略；否则，解析内部数据。
　　在上例中，这则Sysex消息包裹了一条 Note On 信息。其余任何数据也将被允许。
　　 释义二：系统高级信息
　　与释义一一样，该信息同样用于发送任意数据。在此类释义下，该信息结构中的 0iiiiiii 字段为包含结束标记在内的数据体长度，与所有其他消息的长度一样也为可变长度数。
　　虽然“F0”必须以“F7”作为结尾（此时作为标记位的F7并不会被识别为一条Event而被解析），但“F7”本身却可以独立使用，用于一条标准MIDI消息的承载。此时的“F7”被称作一个“escape”——实在不知道这术语翻译成中文应该叫啥，逃跑？跑的“F0”它娘都不认得？
　　这种设计的优势在于，可以允许分片发送大量数据。例如当多个“43 12 00”（据本人肤浅的视野目测，“43 12 00”不代表任何意义。。。）需要被发送时，可以使用如下的命令：

/*** F0-F7承载命令示例（16进制）*// start from tick 0F0 03 43 12 00             // start from F0// 200-tick delta timeF7 06 43 12 00 43 12 00    // F7 as an escape// 100-tick delta timeF7 04 43 12 00 F7          // F7 as an escape // together with the end of F0 while EOX is count into the last escape.*/

　　并且“F7”本身也可以作为独立消息使用：

/*** F7作为escape使用// start from tick 0
F7 01 FC                    // short message FC - pause// 48-tick dalta time
F7 01 FB                    // FB - start*/

　　关于该类型消息的更多解释，还可 点击此处参考更详细的字段拆解 。

控制消息

　　老实说苦于并未真正接触过硬件MIDI设备并且所见MIDI文件中大都不包含此类信息，鄙人对于此类消息的理解亦完全基于机翻的文字描述，难免会有所纰漏，同时也希望能有此领域专业人士批评指正。
　　非通道相关的控制类消息的部分工作已经被现今在诸多成熟的合成器默认实现了，例如“音调调整”被设计用于兼容老式可能存在音调不准的合成器，现在已经基本废弃。一些特殊的控制类消息可能并不会存在于MIDI文件中，而是被设计于输入设备上发往合成器（例如某个按钮）用于实时的播放控制。
系统专用消息是一类特殊的控制信息。
　　控制消息包括两部分，“系统通用消息”和“实时系统消息”。控制类消息均对合成器起作用，其效果可能表现于整个音序的播放阶段。在上文中的“FC”、“FB”即为两个控制消息，分别代表“暂停”和“开始”。更多关于控制消息的细节请移步 附录三：控制消息类型表 。

通道消息/Short Message

/*** 通道消息标准格式*
类型和通道 | 数据1    数据2ttt cccc   0xxxxxxx 0yyyyyyy0000   01111111 01111111*/

　　好吧，怀旧一下。Short Message其实是Java中的叫法，Java把控制消息和通道消息全部合并称为短消息。
　　顾名思义，这种类型消息与通道相关，这也是到目前为止唯一能跟通道和音轨之间的联系扯上点关系的数据了。一则通道消息包含2个或3个字节，并且没有长度标记。对于合成器而言，识别通道消息的标识就是高位字节首位为“1”并且紧邻1个或2个首位为“0”的低位字节（其他类型消息通过数据区长度或结束标记指定）。至于为何没有首位为0（状态位数值在128以下）的MIDI消息，鄙人目测也是为了防止消息数据区被数识别为另一则消息造成数据污染。
　　如上图所示，通道信息中的“ttt”为信息类型标识，“cccc”为“0~15”共计16个通道标识，这也是为何MIDI通道只有16个的原因——超出了就根本表示不出来么...“数据1”和“数据2”所指代的含义有异于不同的通道信息类型。
　　根据“ttt”的不同，通道类消息包括 Note Off 、 Note On 、 （触后）键力度调整/Polyphonic Key Pressure(After Touch) 、 控制器变化/Control Change 、 程序变化（切换乐器）/Program Change 、 （触后）通道压力调整/Channel Pressure(After Touch) 和 音轮调节/Pitch Wheel Change 共计7个。虽然数据格式通常是一定的，但是不同的合成器对于各类消息的几个字段解释可能有异。以下涉及实例部分均以使用最广泛的 GS波表软件合成器 为例讲解。
　　全部通道消息细节信息烦请查阅“ 附录四：通道消息类型表 ”。

• Note On(1001)/Note Off(1000)
  　　On/Off信息往往成对出现，开启和关闭音符，表现为发声和停止发声，在硬件设备上（例如钢琴）就是按下和松开一个按键。此时数据1表示发声音调，数据2表示按键力度（表现为音量，当然了敲键盘越重钢琴越响）。这类似于在一个有16条通道的排水管中，打开和关闭闸门，当“闸门”打开时音乐数据流便被允许通过该排水管，如果“闸门”没被关闭则此类型的水流（当前音调和力度）将会一直存在于该通道。指定了相同音调的“Note Off”信息将关闭信息流，“Note Off”中的力度信息将表示音符的松开力度。“附录六”中给出了完整的128个 Note Key 与音阶的对应关系。

  /*** 以最大力度在 Channel 0 按下C大调，并在持续240个tick单位后松开* C大调为从0到127号中的第60号，0x3C；中调64号为第四音阶E调，0x40。* GS波表软件合成器中每1/4个音符持续0.5秒，故该Note共持续5秒。*10010000 00111100 0111111101110000 10000000 00111100 01111111*/

  　　点此下载《24tick/秒的 Piano MIDI 样例》。

• 程序变化/Program Change（1100）
  　　由于较常用所以插个队~~Meta消息中的“FF 04”消息用于标注“乐器名称”。然而实际上，其仅用于标注，并不会对通道上的音频流产生实质影响。真正能产生影响的就是该 Program Change 消息，其中的数据1为128为音色号，数据2为空。在默认（未设定 Program Change 事件）情况下，除了第10号通道以外，其余通道均使用与当前通道号一致的音色；每个通道（包括10号通道）均会响应程序切换事件并对该事件之后的所有Note采用新设定的音色（Program Change 之前的事件不受设定音色影响）。

  /*** 切换 Channel 0 当前默认乐器“0-Piano”为“17-Percussive”；* 以最大力度在 Channel 0 按下C大调，并在持续240个tick单位后松开；*11000000 0001000110010000 00111100 0111111101110000 10000000 00111100 01111111*/

  　　点此下载《24tick/秒的 Percussive MIDI 样例》。

• 触后键力度/Polyphonic Key Pressure（1010）
  　　弹钢琴时一屁股坐上琴键并一直坐在上面然后站起来，跟用手按下之后缓慢回弹——这两种情况发出的声音肯定是不一样的。触后键力度即用于表示上一个琴键被按下（Note On）之后，在松开之前该琴键的保持力度。
  　　由于是触后量，因此在此事件之前已经被关闭的音符将不会受到力度影响。注意，该事件将影响当前通道上所有处于播放状态或即将被打开的音符。

  /*** 以最大力度在 Channel 0 按下C大调，并在240个tick单位内让声音渐变至消失* 每个事件之间的tick间隔为1，* 约每2个tick单位压力降低1*11000000 00010001 // Program Change10010000 00111100 01111111 // Note On10100000 00111100 01111111 // PolyKey Pressure10100000 00111100 0111111010100000 00111100 01111110
  ...      // 剩余237个触后键力度调整10100000 00111100 0000000010000000 00111100 00111111 // Note Off*/

  　　需要注意的是，部分音色（经典例如钢琴）在一个时间足够长的 Note On 和 Note Off 之间，也即在该音调完整播放时本身就有音量衰减。甚至对于钢琴而言，标准音色在 Note Off 时声音并不会立即消失，而是以更快的速度将力度渐变至0。这是为了还原此类音色在真实乐器上的演奏效果，当然也存在多数音色将始终在 Note On 和 Note Off 之间保持同一播放效果。大部分合成器均能正确根据音色库的定义表现这些音色的特效，然而对于预先录制为.mp3格式的音色库而言，模拟的合成器对在 Note Off 上的处理将会变得相当尖锐和突兀。看看名噪一时的Color Piano，试着弹几个键就知道我在说什么了。这时合成器应当能够主动为特定音色添加触后量变化消息，以实现渐变的延音效果。
  　　在以上两则Midi示例中，《Piano MIDI 样例》属于会渐弱的音色，而《Percussive MIDI 样例》不存在该效果，其音色信息将会一只持续到对应的 Note Off 被解析或（如果没有被关闭）直至音轨末尾。
  　　注：由于成本原因，大多数MIDI键盘制造商并不单独为总数128的每个键提供触后压力变化输入。因此，该信息也并不能在所有合成器上被正确识别。要达到类似的效果，请使用第11号控制器。点此下载24tick/秒的 Percussive MIDI 声音渐弱样例，使用触后键力度变化；推荐尝试可被Windows默认合成器正确识别的11号-力度控制器版本。

• 控制器变化/Control Change（1011）
  　　控制器是MIDI创作的精髓所在。特殊音效例如颤音、混响声度、声相偏移等等操作都需要通过控制器完成，控制器的完整程度和功能强弱也一直是极客玩家们选择数字音乐产品的重要指标。可惜屌丝从来没玩过那么高端的玩意。。。对于附录五：控制器类型表中所罗列的控制器也就到了能认识那些字的程度。。。也欢迎能有高端玩家留下关于控制器的模拟实现细节的完善意见。控制器调整对当前通道中位于其后的所有音符起效。
  　　在总128个控制器中，

  /*** 以最大力度在 Channel 0 按下C大调，并在240个tick单位内让声音渐变至消失* 使用11号-力度控制器替代触后键力度实现渐变* 在第2.5秒单位时为音符添加最大力度颤音*11000000 00010001 // Program Change10010000 00111100 01111111 // Note On10110000 00001011 01111111 // 0xB0 0x11 0x7F - 11号控制器10110000 00001011 0111111110110000 00001011 01111110
  ...      // 中间117个11号控制器10110000 00000001 01111111 // 0xB0 0x01 0x7F - 1号控制器，120tick时最大力度颤音
  ...      // 中间120个11号控制器10110000 00001011 00000000 // 0xB0 0x11 0x00 - 11号控制器最小力度10000000 00111100 00111111 // Note Off*/

  　　点此下载《24tick/秒的 Percussive 颤音渐弱样例》

• 通道压力调整/Channel Pressure（1101）
  　　与 Program Change 类似，该消息仅包含一个数据位。其作用与“触后按键力度调整消息”类似，但该事件被设计用于某些不能正确响应和弦（触后）键力度的合成器，将对当前所指定的音轨中所有正在播放的Note里拥有最高力度的Note执行压力变化（一说将对通道内所有音符执行压力变化——鬼特么知道，GS不支持，所以还是继续用11号全通道吧...）。为了避免混响时出现意想不到的情况，通常建议使用单通道的Mono模式（参考附件四中关于通道模式信息中的描述）。
• 音调轮变化/Pitch Wheel Change（1110）
  　　“触后键压力调整”用于调整按键的保持力度，与之对应，音调轮则用于处理音符播放时的音调偏移，不过该偏移对当前通道中所有正在播放的音符生效，数据1和数据2共组成14位二进制数表示音调偏移量，比较诡异的是此处数据1为低位字段，即可用于微调；数据2为高位字段。该可用于产生音调的渐变，实现圆润的滑音效果。在GS波表软件合成器中，只能实现粗调——消息数据1无意义，数据2表示精度为127的调音轮变化，其中值为0x40，十进制64，也即二进制01000000。与触后键力度一致，该变化也属于触后量。

  /*** 以最大力度在 Channel 0 按下C大调，并在240个tick单位内让声音渐变至消失* 在第2.5秒单位时为音符添加最大力度颤音* 在 240 tick 内，仅使用粗调将音符提升一个音阶* 约每3个tick单位音调提升1*11000000 00010001 // Program Change10010000 00111100 01111111 // Note On10110000 00001011 01111111 // 0xB0 0x11 0x7F - 11号控制器11100000 00000000 01000000 // 0xE0 0x00 0x40 - 音调轮中值10110000 00001011 0111111111100000 00000000 0100000010110000 00001011 0111111011100000 00000000 01000001 // 0xE0 0x00 0x41
  ...      // 117个11号控制器和音调轮变化10110000 00000001 01111111 // 0xB0 0x01 0x7F - 1号控制器，120tick时最大力度颤音
  ...      // 120个11号控制器和音调轮变化10110000 00001011 00000000 // 0xB0 0x11 0x00 - 11号控制器最小力度11100000 00000000 01111111 // 0xE0 0x00 0x7F - 音调最高偏移10000000 00111100 00111111 // Note Off*/

  　　点此下载《24tick/秒的 Mono 模式 Channel 0 下 Percussive 颤音渐弱音调渐变样例》，或者看看残忍之快速的巨神之刃放松放松。

js生成数字音乐

　　啧啧。。。目前看起来，为了能把我们想要的骡子声用来挂门上辟邪，我们的至尊8合1小霸王可能得加点位宽才顶得住。不过好歹也算是有些眉目了，我们已经生成了一串串可以出声的字节，接下来只需要把这一坨东西写出为一个".mid"文件就行。
　　因此，“Js生成数字音乐”步骤中一个亟待解决的问题是： 用Javascript抽象Midi文件结构 。
　　浏览一下关于MIDI文件格式的定义，在“音调轮变化”一节实例《残忍之快速的巨神之刃》中的二进制串已经包含了一首完整Midi所需要的大部分数据，让我们补充一些组成一首完整Midi文件所需的细节内容：一个 Header Chunk，Track Chunk 头和结束标记（0xFF 0x2F 0x00），上文中提到的通道模式调整和版权声明。差不多够了，所以最后这坨东西看起来可能像下面这样——这将是一个拥有2001字节的数据串。

/*** 完整版“残忍之快速的巨神之刃”*01010100 01101000 01100100 // MThd00000000 00000000 00000110 // header lentgh: 6 bytes00000001                   // Midi Type: 100000001                   // Track count: 100011000                   // Division: 48 ticks / second01010100 01110010 01101011 // MTrk00000000 00000111 10111011 // Track Length: 955 bytes - length-fixable data11111111 00000010 00011100 // tick 0, 0xFF 0x02 0x1C - CopyRight, length: 28 bytes01100011 00101001 00110010 // CopyRight Contents in 28 bytes.00110001 00110011 0010000001111001 00100000 0111100101110010 01101101 0111100101110010 01100011 0110100001101100 01101001 0111011000101110 01100011 0110111011000000 00010001          // Program Change10010000 00111100 01111111 // Note On10110000 00001011 01111111 // 0xB0 0x11 0x7F11100000 00000000 01000000 // 0xE0 0x00 0x4010110000 00001011 0111111111100000 00000000 0100000010110000 00001011 0111111011100000 00000000 01000001 // 0xE0 0x00 0x41// 117 No.11 Controller10110000 00000001 01111111 // 0xB0 0x01 0x7F// 120 No.11 Controller10110000 00001011 00000000 // 0xB0 0x11 0x0011100000 00000000 01111111 // 0xE0 0x00 0x7F10000000 00111100 00111111 // Note Off11111111 00101111 00000000 // tick 0, 0xFF 0x2F 0x00 - End of Track Chunk*/

　　有兴趣的同僚们可以用二进制文件编辑器，例如UltraEditor之类的打开《残忍之轻快的巨神之刃》，对照以上二进制数据。如果发现有些不一样的地方——不要在意那些细节啦——这文件打开之后看起来大概像这样：

　　我们差不多得到了它。由于这是一组显而易见的二进制数据，我们总能找到方法将其写出文件，尤其是在HTML5的支持下。

Blob写出文件/Midi数据序列化

　　 Html5的 File API 绝逼是个臣诚惶诚恐死罪死罪的伟大发明，尤其是Blob这样的变态玩意——允许将任意数据序列化出为可被传输的二进制数据。啊，骡子出头有望，我们可以把上面一系列数据改造成一个Unit8数组，再通过Blob写出即可实现挂墙上的宏伟目标。

var dataString = "", // contents of the midi given abovedataArray = dataString.split(/\D/).map(function(str) {return parseInt(str, 2);}),blob = new Blob([new Uint8Array(dataArray)], {type:"audio/midi"});

　　有了Blob事情就好办多了，该文件在内存中创建完毕，已经可以通过DataUrl提供访问了。设想我们让用户点击直接下载：

var url = URL.createObjectURL(blob);
document.body.onclick = function() {window.open(url);document.body.onclick = "";
}

类组织结构

　　当然我们不能总是用二进制说话，骡子肯定是听不懂的。我们倒是可以把Midi文件结构中的数据部分按类别划分出来，并创建一系列便于访问并且兼顾性能的接口用于操纵文件数据。UML图就不画了，直接贴5年前的——吐槽一下，这领域的更新足见有多让人捉襟见肘，数年前的资料放在如今仍然适用，没准还会一直适用下去。。。

　　对于这个结构鄙人思索良久。对于大量事件中的特定事件进行增删改查操作是一件相当蛋疼的事，以至于最初在Java中我们只能采用遍历来实现。或许我们仍然可以沿用Java中关于时间戳的天才设计—— 事件tick表示从Sequence开始播放时到当前事件发生时的偏移量 。在这种设计下，可以基于时间戳哈希事件，提供高性能操作的可能性。
　　通过基于tick哈希的设计对上述UML图进行优化，我们可以很容易整理出如下的一些基本类，其核心为三个数据层： Message 、 Track 和 Sequence 。

Message

　　Midi音序的基本数据单元，维护 type 和 data 两个字段并提供相应的增改功能，同时提供序列化支持。需要注意的是对于除通道类消息之外的消息类型，序列化时需要在type和data之间添加可变长度数表示的数据字段长度。

Track

　　基于tick哈希设计的Message容器。此处由于需要对tick进行直接管理，因此在Message类和Track类中间省略MidiEvent层。作为容器对象，提供基本的容器操作，并提供序列化的支持。
　　通过以上简单探讨，Track作为容器应当具备以下一些特性：

• 事件允许重复。即在相同时间戳里允许产生在字节范围内完全一致的多个消息；
• 事件严格有序。同一个时间戳内，Program Change 和 Note On 位置的调换会完全改变输出音符的音色，因此事件之间必须有序；
• 提供尽量高效的访问。单一Track可维护的事件最多为四个字节表示的可变长度数：01111111 01111111 01111111 11111111——即268435455个，这是个相当可观的数据。设想在一个节奏一定的音序中，混响音符的节拍之间的间隔往往是固定的，这也意味着表示这些音符的Midi事件之间 Delta Tick 将会是一些固定的整数。这也是以初始偏移量作为 tick 并哈希的主要原因所在。
• 序列化时进行时间戳转换。将从音序初始的时间戳数值转换为当前事件与上一事件之间的时间戳差值。
• 为了提供尽量还原Midi标准的自由度，Track将不对Channel和Instrument做任何限制，亦即允许该类的使用者只有设定当前Track与Channel和Instrument的映射关系，而无需遵循之前所描述（为了便于维护和管理而采用Mono模式、单一Track使用一种音色）的种种约束条件。

　　在以上规则和约束下，鄙人只能想到哈希+数组的存储方式。该解决方案的局限性也很明显，同一tick下存在的消息过多时也伴随性能将明显下滑。

/*** key: tick count from the start of the sequence.* value: msgArr {Array<Message>} messages that're sharing the same tick which should *     be contributed by type and data, and they could be serialized.*/
events = {: [
x903F7F,// other messages in tick 0],: [
x803F7F,// other messages in tick 120]
}

Sequence

　　我们直接跳过了作为逻辑结构的“Chunk”。同时 Header Chunk 作为一个Midi乐谱的必备数据，因此可以直接拆解为音序的一系列属性，甚至可以写入构造函数。从这个角度看，Sequence是一个纯粹的Track容器，提供基本容器方法和对 Header Chunk 属性的访问，并允许序列化。

扩展和封装

　　我一直怀疑自己是不是点错了技能树。讨论了大半篇幅到太阳都快落山了的Midi文件数据，三个基本类就已全部囊括。如果我们再提供一些对于动态加载、二进制/十六进制数据运算、用于传递数据用的Base64编码和Blob支持，就几乎得到了一个比较完善的 数字音乐模拟系统 ——的数据部分，亦即上文中UML图的Sequencer以下的部分。
　　当然我在 这里 已经做了一部分工作，也欢迎大家前去围观批评。对于我们在今天早些时候提到的“《残忍之轻快的巨神之刃》”，代码就可以这样写了：

var seq = new Midi.Sequence(1, 24),track = seq.getTrack(0);track.addEvent(0, new Midi.Message(0xc0, 0x11));        // Program Change to No.17
track.addEvent(0, new Midi.Message(0xB0, [124,0]));     // omni on
track.addEvent(0, new Midi.Message(0xB0, [126,1]));     // mono on & omni on
track.addEvent(0, new Midi.Message(0x90, [60,127]));    // Note On Key 0x3C
track.addEvent(120, new Midi.Message(0xB0, [1,127]));   // Vibrato Controller
track.addEvent(240, new Midi.Message(0x80, [60,127]));  // Note Off// Apply Voice Change and Pitch Wheel Change
for (var i = 1; i <= 240; ++i) {track.addEvent(i, new Midi.Message(0xB0, [11, 127 - ~~((127 / 240) * i)]));track.addEvent(i, new Midi.Message(0xE0, [0, 64 + ~~((63 / 240) * i)]));
}// Click & Download
var blob = new Blob([seq.toByteArray(1)], {type:"audio/midi"});
var url = URL.createObjectURL(blob);
document.body.onclick = function() {window.open(url);document.body.onclick = "";
}

　　你也可以 到这里来现场玩一玩 ，或者 点击这里查看源码 。

MIDI实时播放

　　当然把一个Midi乐谱下载到本地用GS波表软件合成器播放肯定是不存在问题的。但是对于一个存在实时交互的系统，合成器应当能够对用户输入做出反应，这是“下载文件并交由本地合成器播放”策略所不能解决的问题。
　　设想我们希望在浏览器端创建最初所提到的完整数字音乐模拟系统，允许用户自由创作音符并实时对以创作的内容进行修改，该模拟应当可以对用户的输入进行反馈，即提供按键或操作的声音预览。前文中我们致力于并成功解决了 用Javascript解析和封装Midi乐谱 的问题，下一个问题是： 产生的Midi序列如何实时播放？
　　浏览器不能直接解析Midi文件，因为浏览器中并不集成音色库，也没有合成器。访问声卡合成器的功能就别想了，几年内是出不来的，看看使用显卡的硬件加速进程就知道。不过仍然有多种方法可供选择。

• MP插件：一种方法是，把GS波表软件合成器搬到浏览器中来。通过给浏览器安装 Media Player 插件即可实现，输入文件Url播放；
• Flash插件：Flash中已经有多个版本成熟的合成器可以使用，例如大名鼎鼎的AudioTool。鉴于鄙人浅薄的乐理知识，这么高端的东西还是不去碰了。。。
• Java插件：Java真是一门伟大的语言，JDK从7.0开始提供了从Midi文件系统到合成器的全部实现。
• 预处理的音色库：前文中提到过的MIDI.js就采用了这种方法，他们将完整的音色库定义转换成Ogg文件并使用base64编码，以便浏览器可以直接播放。Udcobe团队创造了一种非常靠谱的声音转换算法，用于将Midi乐谱通过音色库渲染成Ogg，再转换为压缩音频。旧式的录音棚使用高保真录音来实现从Midi到压缩音频的转换，相比之下Udcube的算法更具优越性，免去了对高端声卡的需求和不必要的干扰。

　　以上几种方法或多或少都会存在各种问题。在flash淘汰声一浪高过一浪的今天，使用插件不会是什么明知的选择。借助  Html5 Audio API ，预处理的压缩音频音色库能解决许多问题，但其欠缺对于音色播放的完全控制，也缺乏必要的扩展性和操作难度。为了能够使用当前已不可计数的各种优秀音色库和实时播放Midi乐谱，我们需要一个工具，该工具能够解析音色库文件，以允许用户使用本地音色库而不用消耗漫长的时间下载预定义的数据，因为Midi本身应当是很优雅和简约的存在；同时能够提供对Midi乐谱文件的解析功能，能够响应合理的通道事件并在输出设备上产生效果。
　　也就是说，我们需要在浏览器端使用  Html5 Audio API 编码一个浏览器端的 合成器 。

浏览器端的合成器

　　这是另一个话题，该话题的含量甚至已经超过了这篇文章到目前为止加上附录的所有内容长度，现在也还没有这方面案例可以参考。这也是鄙人今后相当长一段时间内的调研方向，FML...
　　基于以上原因此处不对合成器的模拟实现做过多讨论，因为......我TM也不懂啊！玩蛋去。。。下面是一些可用的参考，制作列举不做评论。

• Java 7.0 中关于sf2文件的解析源码；
• 日本哥Toyoshim的开源项目 T'Sound System Library 中音色库文件的js解析源码。

　　先就这么多吧，就这俩已经够让人喝一壶了。各位同僚们如果有什么好的建议也烦请不吝赐教。

现状&将来

　　总的来说 Web MIDI 的发展势头还是很强劲的，无奈专业设备的准入门槛实在不在鄙人这样的资深屌丝能承受之范围，各种高大上合成器应用也非我这五音不识的认知所能理解。不过可惜的是， HTML5 MIDI API  对合成器和模拟方面似乎并没有什么兴趣，该草案2013年的主要进展仍然是尝试在浏览器中添加MIDI硬件设备接口——这也基本上宣布了该草案在成型之内一两年里的缓步发展状况，因为目前还未有纯粹基于浏览器的合成器面世，键盘接进浏览器也暂时还处于只能玩蛋的状态——兴许后续的扩展中会有浏览器厂商愿意解决合成器的问题，即便这意味着得招一帮既懂音乐又会写内核的人来开发这一系列API的实现——不过谁知道呢，在那之前我们可能还得继续关注并着手解决如何才能够实现让挂在浏览器里的骡子音色可以用来驱灾撵鬼的问题。
　　最后附上 大树阴凉儿 的成名曲 猴子.mid 。这首曲子虽然看起来做得很粗糙，但却有其之所以值得铭记的独到原因——它是数年前由好基友一个字节一个字节敲出来的。

　　谢谢观赏，后会有期。

http://ju.outofmemory.cn/entry/79263

http://yarmyarch.com/archives/141

附录

附录一：GS波表软件合成器音色表（GM2标准）

附录二：Meta消息类型表

附录三：控制消息类型表

附录四：通道消息类型表

附录五：控制器类型表

附录六：Note Key 与音阶的对应关系

参考列表太长，就算了吧，所有引用已在原文中注明出处，若存在版权问题烦请与博主联系。谢谢。

MIDI in HTML5相关推荐

1. html5音乐播放器格式midi,HTML5 Audio時代的MIDI音樂文件播放

   大家都知道,HTML5 Audio標簽能夠支持wav, webm, mp3, ogg, acc等格式,但是有個很重要的音樂文件格式midi(擴展名mid)卻在各大瀏覽器中都沒有內置的支持,因為mid文 ...

2. html5 midi,源码：MIDI 文件生成音乐乐谱(Midi To Sheet Music)

   MIDI 文件生成音乐乐谱 资源下载此资源下载价格为2D币,请先登录 资源文件列表 MidiToSheetMusic-master/LICENSE.txt , 18520 MidiToSheetMus ...

3. html页面视频标签,html5基础标签(html5视频标签 html5新标签用法)

   点评:html5基础,包括html5视频标签和html5新标签等标签用法,大家参考使用吧 1.  声明的变化 2.  指定字符编码的变化,html5中建议使用utf-8 3.  Html5中允许 没有 ...

4. ewebeditor下利用ckplayer增加html5 （mp4）全平台的支持

   学校数字化平台富文本编辑器一直用的ewebeditor,应该说非常的好,支持常用office文档的直接导入,极大的方便了老师们资料的上传,最近在规划整个数字化校园向全平台改版,框架采用bootstra ...

5. html5的新增的标签和废除的标签

   新增的结构标签 section元素  表示页面中的一个内容区块,比如章节.页眉.页脚或页面的其他部分.可以和h1. h2--等元素结合起来使用,表示文档结构.例:HTML5中<section&g ...

6. html支持的语音文件格式,html5中如何设置audio支持音频格式

   html5中如何设置audio支持音频格式 发布时间:2020-04-15 10:24:37 来源:亿速云 阅读:367 作者:小新 今天小编给大家分享的是html5中如何设置audio支持音频格式, ...

7. 《HTML5多媒体应用开发》——第2章　HTML5多媒体元素2.1　Web多媒体历史

   本节书摘来自异步社区<HTML5多媒体应用开发>一书中的第2章,第2.1节,作者: [爱]Ian Devlin 更多章节内容可以访问云栖社区"异步社区"公众号查看. 第 ...

8. （一）html5中的新增元素和废除元素

   //刘梦冰发表于2015-6-29 1.新增的结构元素 (1)section元素 section元素表示页面中的一个内容区块,比如章节.页眉.页脚或者页面中的其他部分,它可以与h1.h2.h3等元素结 ...

9. Silverlight/Windows8/WPF/WP7/HTML5周学习导读(7月30日-8月5日)

   Silverlight/Windows8/WPF/WP7/HTML5周学习导读(7月30日-8月5日) 本周Silverlight学习资源更新 Silverlight 之Control and Use ...

最新文章

1. 有上下界网络流 ---- P4843 清理雪道(DAG图上最小路径重复边覆盖)【模板】有源汇上下界最小流
2. 成功解决Exception unhandled AttributeError 'MainWindow' object has no attribute 'setDaemon'
3. 弹出显示多条的message对话框
4. python在abaqus中的应用代码下载_Python-(source-code)-in--Abaqus Python语言在Abaqus中的应用(源码） - 下载 - 搜珍网...
5. html图片爆炸效果,利用CSS3制作3D图片爆炸效果
6. [转]张孟苏考上的不是大学
7. mysql怎么修改表中的文字_mysql表中怎么修改字段？
8. 树莓派之安装docker
9. c++11支持类数据成员的初始化
10. 3dmaxvray的使用方法有哪些?
11. 基于自抗扰控制的高速列车自动驾驶速度控制
12. 计算机网络介绍，TCP协议，Socket网络编程
13. poi excel 插入批注
14. 中国“中产阶级”只赚钱不读书 被指精神荒芜
15. 【006】- Django模型数据操作(二)
16. 弘辽科技：淘宝提升销量怎么越提升越没流量？是什么原因？
17. 高感性时代--全新思维：决胜未来的6大能力
18. 土鸡和土鸡蛋价格一直很高，为何农民说养土鸡不赚钱？
19. oracle导出表为excel文件路径,Oracle导出数据为excel或文本文件
20. 人工智能技术在银行客服中心的应用风险-笔记

热门文章

1. 【斩获7枚offer，入职阿里平台事业部】横扫阿里、美团、京东、 去哪儿之后，写下了这篇面经！...
2. Webmagic网易云音乐爬虫
3. 微软Power BI 每月功能更新系列——9月Power BI 新功能学习
4. 写给现在的自己一封反思信
5. 自动化测试之数据库初始化
6. 钢之炼金术师之等价交换铃声 钢之炼金术师之等价交换手机铃声...
7. 浅谈sleep()和wait()
8. c++高级游戏集游戏
9. drf-----序列化组件----source的使用
10. 电脑程序出问题，导致输入法切换不出来