在我的樂隊中，所有音樂家的雙手隨時都在忙碌。但是，我們要添加全合成和絃（1/4 ..全音符長度），也許是一個簡單的腳踏開關，每次觸發（因爲沿序打目前太難爲我們）。可編程「實時」MIDI處理
前段時間，我在C（MinGW）中編寫了一個（Windows）控制檯應用程序，它將傳入的MIDI事件轉換爲文本，將該文本傳送到外部程序（AWK腳本），並將外部程序的文本輸出重新轉換回到MIDI事件。基本上，每種過濾或事件生成都是可能的;我實際上創造了簡單的控制信息觸發的和絃;我一直音符打開在內存中，以便能夠- 關他們時，一個新的和絃被送往等 - 實際處理（執行）的時間是不是在所有問題
但我（！）必須明白，不僅延遲，而且衆所周知的不可靠（關於「何時」，「多長時間」）用戶應用程序OS多任務/切換使得這個概念實際上毫無價值，至少對於「實時」使用是毫無價值的。總是有明顯可感知的延遲，持續時間不可預知。 我閱讀了關於用戶模式驅動程序編程並下載了一些資源，但不知何故停止了在該項目上的工作，卻沒有得到真正的結果。
除此之外具體的項目，我甚至在寫小的「虛擬」的機器，讓整整表達變量，條件和數學，存儲爲標記的樹和非常快處理一些經驗。也許還有嵌入Lua，V8或類似的東西的選項。所以調用另一個（外部）程序的在這裏不一定是問題，因爲這是可以避免的。
剩下的是，該處理作爲一個整體仍然受到（用戶）應用所做的問題。所以我認爲在這種情況下，沒有辦法繞過（用戶模式）驅動程序。
另外，我即使考慮（更多的「實時」）硬件 - 一個Raspi或類似 - 但隨後的MIDI接口，可能是一個額外的挑戰。
是否有任何可用作此類_Generic MIDI過濾器/處理器_的基礎的硬件或軟件解決方案（或項目）？除了可預測的時間行爲，建立過濾器/規則時不需要（C）編譯環境，因爲這個「創意」步驟可能發生在我們的排練室（可用筆記本電腦），這當然不是「編程實驗室」。基於文本的「程序」很好 - 長期來說，我可能會建立一個用於佈線/生成規則的GUI。
只要沒有其他的東西正在運行，多任務應該不會引入明顯的延遲。我猜想問題是您的應用程序中的計時器延遲或AWK解釋器的啓動時間。 –
有趣但很長，非常廣泛和非常題外話的SO問題。在Windows或Linux上，你應該不需要驅動程序，MIDI是一個UART串行協議.MIDI是一個相當簡單的硬件接口，需要MIDI IN（你可能不需要）上的光隔離器，只需要MIDI OUT電阻。硬件接口的信號可以直接從TTL（5v）邏輯電平和31.25波特的UART驅動。許多微處理器使用3.3v邏輯，這不會嚴格遵守，但可能會起作用 - 這真是一個關於https://electronics.stackexchange.com/的問題。 – Clifford
我不清楚從MIDI到文本的轉換，然後回來。這可能是延遲的原因，如果整個事情都是在二進制MIDI消息級別的C中完成的，除非PC忙於其他活動，否則我會感到驚訝。 – Clifford