Scripting 可编程；“实时”；MIDI处理

在我的乐队里，所有的音乐家在任何时候都忙得不可开交。然而，我们希望添加整个合成器和弦（1/4..整个音符长度），可能每次都由一个简单的脚踏开关触发（因为目前我们很难使用音序器）

不久前，我用C（MinGW）编写了一个（Windows）控制台应用程序，它将传入的MIDI事件转换为文本，将该文本传输到外部程序（AWK脚本），然后将该外部程序的文本输出重新转换回MIDI事件。 基本上每种过滤或事件生成都是可能的；实际上，我通过简单的控制信息产生了和弦；我在内存中保留了便笺，以便在发送新和弦时将其删除，等等。实际处理（执行）时间根本不是问题（！）

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

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

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

或者，我甚至在考虑（更“实时”）硬件——Raspi或类似的硬件——但是MIDI接口可能是一个额外的挑战

---

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

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

---

你可以用微控制器实时处理这个问题。好消息是，您甚至不必构建硬件。现成的控制器可用于此目的。例如：

只要没有其他东西在运行，多任务处理就不应该引入明显的延迟。我猜问题是应用程序中的计时器延迟，或者AWK解释器的启动时间。有趣但非常长，非常广泛，非常离题。在Windows或Linux上，uou不需要驱动程序，MIDI是UART串行协议。MIDI是一个相当简单的硬件接口，在MIDI输入端（您可能不需要）上需要一个光隔离器，而MIDI输出端只需要一个电阻。硬件接口的信号可以直接从UART以TTL（5v）逻辑电平和31.25波特驱动。许多微型计算机使用3.3v逻辑，这可能不符合严格要求，但可能会起作用——这是一个真正的问题。我不清楚从MIDI转换为文本然后再转换回来是为了什么。这可能是延迟的原因，如果整个过程都是在二进制MIDI消息级别用C完成的，我会很惊讶，除非PC忙于其他活动。MIDI是一个相当慢的uart接口，应该会有很多开销。请注意，raspberry pi并不比windows pc或其他计算机更具实时性，它只是另一台计算机，允许对裸机进行更容易的编程，并移除其中的一些层，但也可以使用微控制器来实现，这取决于您对数据的具体处理方式。转换为文本等是你的瓶颈的一部分，你认为你不能有一个好的用户界面，但调整处理的性能不容易编程。我希望这个问题很快得到解决，但你应该看看Max或PureData，这两者的存在正是因为这个原因。