可编程“实时”MIDI处理

Posted 2023-02-25

【中文标题】可编程“实时”MIDI处理

【英文标题】：Programmable "real-time" MIDI processing

【发布时间】：2017-10-15 08:50:58

【问题描述】：

在我的乐队里，所有的音乐家随时都在忙。但是，我们想要添加整个合成器和弦（1/4 .. 整个音符长度），可能每次都由一个简单的脚踏开关触发（因为目前沿着 音序器 演奏对我们来说太难了）。

前段时间，我用 C (MinGW) 编写了一个 (Windows) 控制台应用程序，它将传入的 MIDI 事件转换为文本，将该文本通过管道传输到外部程序（AWK 脚本），然后将该外部程序的文本输出重新转换回MIDI 事件。 基本上每一种过滤或事件生成都是可能的；我实际上制作了由简单的控制信息触发的和弦；我将 note-ONs 保存在内存中，以便能够在发送新和弦时 -OFF 它们等 - 实际处理（执行）时间不是问题全部（！）

但我必须明白，不仅延迟，而且臭名昭著的不可靠（关于“何时”、“多长时间”）用户应用程序操作系统多任务/切换使这个概念实际上毫无价值，至少对于“实时”而言“ 采用。有总是明显可察觉的延迟，持续时间不可预测。 我阅读了有关用户模式驱动程序编程的内容并下载了一些资源，但不知何故停止了该项目的工作而没有真正的结果。

除了那个特定项目之外，我什至在编写小型“虚拟”机器方面也有一些经验，这些机器允许准确表达变量、条件和数学，存储为令牌树并且处理速度非常快。也许还可以选择嵌入 Lua、V8 或类似的东西。所以调用另一个（外部）程序不一定是这里的问题，因为这是可以避免的。

剩下的问题是整个处理仍然由（用户）应用程序完成。所以我认为在这种情况下没有办法绕过（用户模式）驱动程序。

另外，我什至考虑过（更“实时”）硬件——Raspi 之类的——但是 MIDI 接口可能是一个额外的挑战。

是否有任何可用的硬件或软件解决方案（或项目）可以作为此类_通用 MIDI 过滤器/处理器_的基础？ 除了可预测的时序行为之外，最好不需要(C) 构建过滤器/规则时的编译环境，因为那个“创造性”步骤可能会发生在我们的排练室（笔记本电脑可用），这当然不是“编程实验室”。基于文本的“程序”很好——从长远来看，我可能会构建一个用于连接/生成规则的 GUI。

【问题讨论】：

只要没有其他东西在运行，多任务处理不应该引入明显的延迟。我猜问题是您的应用程序中的计时器延迟，或者您的 AWK 解释器的启动时间。

这个问题很有趣，但很长、很宽泛、很离题。在 Windows 或 Linux 上，你应该不需要驱动程序，MIDI 是一个 UART 串​​行协议。MIDI 是一个相当简单的硬件接口，需要 MIDI IN 上的光隔离器（您可能不需要）和 MIDI OUT 的电阻器。硬件接口的信号可以直接从 UART 以 TTL (5v) 逻辑电平和 31.25 波特驱动。许多 micros 使用 3.3v 逻辑，这不会严格遵守，但可能会工作 - 真的是electronics.stackexchange.com 的一个问题。

我不清楚从 MIDI 到文本然后再返回的转换是什么。这可能是延迟的原因，如果整个事情都是在 C 中以二进制 MIDI 消息级别完成的，除非 PC 正忙于其他活动，否则如果您遇到此类问题，我会感到惊讶。

midi 是一个相当慢的 uart 接口，应该有很多开销。注意树莓派并不比windows pc或其他更实时，它只是另一台计算机，被授予更容易编程裸机，并删除其中一些层，但也可以用微控制器做到这一点，这取决于究竟是什么你想处理数据。转换为文本等是你的瓶颈的一部分，你认为你不能有一个好的用户界面，但调整处理以提高性能而不是便于编程。

我希望这个问题很快就会结束，但你应该看看 Max 或 PureData，这两者的存在正是出于这个原因。

【参考方案1】：

MIDI 在 Windows 中处理得很好。我不确定您最初遇到的问题的根源。不过毫无疑问会有一些延迟。

您可以使用微控制器实时处理此问题。好消息是您甚至不必构建硬件。现成的控制器可用于此。例如：http://www.midisolutions.com/prodevp.htm