35. MIDI 说明资料

结合我们在音频引擎上的工作，Ableton 花费了大量额外的精力来分析 Live 的 MIDI 定时问题，并在必要时对其进行改进。 我们之所以编写了这个参考资料，是因为我们发现在创建可靠且准确的计算机 MIDI 环境时，许多用户会遇到诸多问题。 我们想用这个说明书来帮助这些用户理解上述可能遇到的问题，并解释 Live 在解决这些问题时用到的方法。

注意：本文讨论的 MIDI 定时问题通常不适用于具有高质量音频和 MIDI 硬件设备的用户。 如果你已经花费了时间和金钱来优化工作室中的这些潜在因素，并且没有遇到 MIDI 时钟问题，则可能不需要这部分的信息。

35.1 理想的 MIDI 运行状态。

为了了解 MIDI 在数字音频工作站（DAW）中的工作方式，我们应当介绍一些常用术语和概念。 一个 DAW 必须能够应对三个与 MIDI 相关的场景：

1. 【录音】是指将 MIDI 音符和控制器信息从硬件设备（例如 MIDI 键盘）发送到 DAW 中进行储存。 理想的录音环境应当保证传入信息的时间定位相对与歌曲的时间线来说是完美匹配的，就像录制音频一样精准。
2. 【播放】指的是在 DAW 当中进行处理时用到的两种相关场景。 第一点就是从 DAW 中向诸如合成器之类的硬件设备中发送 MIDI 音符和控制器信息。 第二点是在计算机内部将存储的 MIDI 信息转换为音频数据，比如将诸如 Operator 合成器的插件装置播放出来。 一个理想的回放环境在这两种情况下都能够保证输出的储存信息可以完美再现。
3. 【播放流】指的是将 MIDI 音符和控制器信息从硬件设备（如 MIDI 键盘）发送到 DAW 中，然后实时地发送回硬件合成器或 DAW 的插件中。 理想的播放流环境会感觉像演奏物理乐器（如钢琴）一样准确且响应迅速。

35.2 MIDI 时钟问题

事实上，基于计算机的 MIDI 实现起来是很复杂的，并且涉及到许多变量，因此上述理想的情况不可能实现。 这里存在两个最基本的问题：

1. 【延迟】是指系统中持续且统一的延迟。 这是 DAW 中的一个典型问题，因为数字音频无法实时传输到音频接口或从音频接口传出，必须进行缓冲才可以进行传输。 但是，即使是声学乐器也会表现出一定程度的延迟。 例如，在演奏钢琴时，按下琴键的时间和锤击弦的时间之间一定会有一定的延迟。 从性能的角度来看，较小的延迟通常不是问题，因为演奏者通常可以适应这个延迟量，并且下意识调整以补偿延迟 — 只要延迟保持一致即可。
2. 【时基抖动】是指系统中不一致或随机的延迟。 在 DAW 中，这是一个很典型的问题，因为系统中的不同功能（例如 MIDI、音频和用户界面）是分别进行处理的。 而信息通常都需要从一个处理转移到另一个上，例如，将 MIDI 数据转换为插件播放。 无时基抖动的 MIDI 定时可以保证在系统组件（MIDI 接口、音频接口和 DAW 本身）内，不同时钟之间能够进行精准的切换。 这种转换的准确性取决于多种因素，包括所使用的操作系统和驱动程序的体系结构。 时基抖动比延迟要糟糕的多，它会让人感到 MIDI 定时非常的 “混乱” 或 “松散”。

35.3 Live 的 MIDI 解决方案

Ableton 的定时方法基于了两个关键的设想：

1. 在所有情况下，延迟都要优于时基抖动。 因为延迟具备一致性并且可以被预测，计算机和人们都可以更加轻松地处理它。
2. 如果你在录音的时候使用播放流，那么你会更想要录制到自己听到的内容 — 即使由于延迟的影响，你所听到的可能会稍微晚于你所演奏的内容。

Live 解决了录音、播放和播放流中固有的问题，因此 MIDI 时钟就会变得灵敏、准确且始终可靠。 为了将输入的事件录制到 Live Set 时间轴中正确的位置，Live 需要准确知道何时从 MIDI 键盘中接收到这些事件。 但是 Live 无法直接接收它们 — 它们必须先要经过 MIDI 接口的驱动和操作系统处理。 为了解决这个问题，每当接口驱动接收到一个MIDI 事件时都会为其分配一个时间戳，它们会随着事件一起传递给 Live，以便 Live 可以确切的知道这些事件应该何时被添加在 Clip 中。

在播放流的过程中，由于固有的延迟和系统延迟，在过去，DAW 必须快速且不断地处理事件，这是不可避免的。 因此，我们必须做出一个抉择：应该在事件接收时就播放事件（如果在系统繁忙时恰好发生该事件，就可能导致时基抖动）还是应该将事件推迟（增加延迟）？ Ableton 的选择是增加延迟量，因为我们认为用户调整一致性的延迟会比调整随机的时基抖动更加容易。

在录制过程中启用监听功能后，Live 会根据音频硬件的缓冲区大小在事件的时间戳上添加额外的延迟。 如此增加延迟可以保证在你听到事件的时候就已经录在 Clip 中了 — 而不是你演奏它们的时候。

为了播放硬件设备，Live 也是生成了时间戳，之后尝试将其于 MIDI 接口的驱动程序进行通信，为了安排输出的 MIDI 事件。 Windows MME 驱动程序无法处理时间戳，但是为了处理使用了这种驱动的设备，Live 在自身的内部安排了输出事件。

即使在很高的系统负载以至于导致音频丢失的情况下，Live 仍将接收传入的 MIDI 事件。 如果出现音频丢失的情况，那么在播放流的过程中可能就会出现定时错误和音频失真，但是 Live 依然会正确地将 MIDI 事件记录在 Clip 中。 之后，当系统从中断中恢复后，这些已经被记录的事件就应该能够准确的播放了。

35.4 Live 无法控制的变量

通常情况，时间戳是处理 MIDI 事件定时问题的一种非常可靠的机制。 但是时间戳仅仅适用于计算机内部的数据。 计算机外部的 MIDI 数据无法使用此信息，因此，来自或发送至外部硬件的定时信息会在到达后立即由硬件进行处理，而不是按照顺序进行处理。 此外，MIDI 的线缆是以序列的形式发送信息，这意味着它们同一时间只能发送一条信息。 实际上，这也意味着同时演奏的多个音符其实并不能同时通过 MIDI 线缆进行传输，而是必须一个接一个地发送。 随着事件密度地上升，可能会产生 MIDI 时钟问题。

尤其在 MIDI 早期使用合成器工作时，可能会出现另一个问题：设备的扫描时间可能还会更慢。 扫描时间是定义了合成器多久检查一次自己的键盘输入。 如果这个速率太慢，时基抖动可能就会被引入。

当然，对于硬件而言，如果再在链条上增加其他的齿轮，那么此类的定时问题就有可能会成倍的增加。

即使在计算机内部，时间戳的准确性也可能变化巨大，这取决于 MIDI 硬件的质量、驱动程序编程中的错误等等。 Live 必须假设传入 MIDI 事件的任何时间戳都是准确的，并且外部硬件均对于传出事件做了适当的处理。 但是 Live 并无法验证这两种情况。

测试和结果

下图展示了我们测试传入 MIDI 事件定时问题的步骤：

将一个MIDI 源的输出（一个键盘，或是在其他 DAW 中播放一个长时间且随机的 MIDI 音序事件）馈入到一个零延迟的硬件MIDI 分配器中。 分配器的一部分输出会在 Live 中录制到一个新的 MIDI Clip 上。 另一部分馈入到一个MIDI-to-Audio 转换器中。 该设备可以将 MIDI 源的电信号转换为简单的音频噪声信号。 由于该设备无需对 MIDI 数据进行解析，所以在转换时是零延迟的。 然后将该转换器的输出再记录到 Live 新的音频 Clip 中。 在一个理想的系统中，MIDI Clip 中的每一个事件都能与音频 Clip 中的相应事件同时发生。 因此，只需测量两个 Clip 中的 MIDI 和音频事件之间的时间差，就可以确定 Live 的准确性。

为了评估各种条件下的 MIDI 性能，我们在三台不同价格的 Audio/MIDI 接口上进行了这个测试，这三台设备均来自知名厂商。 我们现在将这些接口成为 A，B 和 C。 所有测试均在 macOS 和 Windows 机器上以大约 50% 的 CPU 负载（44.1 和 96 kHz 以及三种不同的音频缓存区大小）来进行的，加起来一共 36 种离散测试配置组合。

Windows：

• 接口 A：最大时基抖动为 +/- 4ms，大多数时基抖动为 +/- 1 ms。
• 接口 B：大多数测试情况下，最大时基抖动为 +/- 3 或 4 ms。 在 96 kHz 和 1024 采样缓存下，有少量事件具有 +/- 5 ms 的时基抖动。 在 44.1 kHz 和 512 采样缓存下，偶尔会发生 +/- 6 ms 的事件。 在所有情况下，大多数都会发生 +/- 1 ms 的时基抖动。
• 接口 C：大多数测试情况下，最大时基抖动为 +/- 5 ms。 在 96 kHz 和 512 采样缓存下，有少量事件的时基抖动在 +/- 6 到 8 ms 之间。 在 44.1 kHz 和 1024 采样缓存下，有少量事件的时基抖动高达 +/- 10 ms。 在所有情况下，大多数都会发生 +/- 1 ms 的时基抖动。

macOS：

• 接口 A：在 44.1 kHz 和 1152 采样缓存下，时基抖动在 +/- 4 和 11 ms 之间均匀分布。 对于所有其他的测试，最大时基抖动为 +/- 5 ms。 在所有测试中，大多数都会发生 +/- 1 ms 的时基抖动。
• 接口B：大多数测试情况下，最大时基抖动为 +/- 4 或 5 ms。 在 44.1 kHz 和 1152 采样缓存下，时基抖动均匀分布在 +/- 2 和 11 ms 之间。 在所有情况下，大多数都会发生 +/- 1 ms 的时基抖动。
• 接口 C：在所有测试中，最大时基抖动为 +/- 1 ms，大多数的事件发生时没有时基抖动。

我们还执行了类似的过程来测试输出 MIDI 事件的定时问题，如下图所示：

在所有的情况下，输出测试的显示结果与输入测试的结果相匹配。

35.5 实现 MIDI 性能最佳化的技巧。

为了帮助用户在使用 Live 时可以将 MIDI 的性能最大化，我们列出了以下内容来展示我们推荐的做法和设置。

• 使用音频硬件上可选择的最小缓存区大小，从而将延迟降至最低。 可以在 Live 偏好设置中的【Audio】选项卡里找到音频缓存区的参数，其具体设置会因所使用的硬件类型而不同。 有关更多信息，请参见 “设置音频 I/O” 课程。
• 高质量的 MIDI 接口应当与最新的驱动程序配合使用，以确保 MIDI 时间戳的生成和处理环节都能尽可能准确。
• 如果你在录制 MIDI 的同时，还想要监听硬件的设备（如外部的合成器），不要激活轨道监听，正确的操作方式是通过 Live 的【External Instrument】装置将设备的音频馈入到 Live 中，从而监听其声音。 同样，在录制另一个 MIDI 设备（例如鼓机）生成的 MIDI 数据时，也要禁用轨道监听。 启用监听后，Live 会添加延迟来补偿回放时产生的时基抖动。 因此，只有在回放时才启用监听是非常重要的。

35.6 总结与结论

Ableton 撰写此章节是为了帮助用户理解一系列的相关话题：

• 基于计算机的 MIDI 系统中固有的问题；
• 我们在 Live 中解决这些问题的方法；
• 我们无法控制的各种变量。

如前所述，在录音棚中，解决 MIDI 定时问题最佳的方法就是尽可能使用最优质的硬件设备。 对于使用高质量设备的用户来说，所有软件 MIDI 系统都应该可以正常运行。 但是对于硬件性能欠佳的用户来说，Live 仍可以通过最大程度地减少时基抖动来提供更高的准确性，不过可能会产生少量额外的延迟。

如果你对我们所介绍的 MIDI 功能有任何疑问，请参考此手册。如果遇到其他问题，您也可以直接联系我们（查看 https://www.ableton.com/help/）{.footnote}。