关于MIDI

你说你“对迷笛一无所知”。一旦掌握了MIDI技术，它就相当简单，但在开始时可能会令人困惑。有一种资源对我理解MIDI的基础(如果你想编程MIDI交互，这当然是必要的)有极大的帮助，那就是为技术恐惧者写的一本叫做MIDI的书。这是一本容易读的书，非常有用。

Pure Data & Max

在我开发交互式多媒体的经验中，我遇到过两个非常相似的程序，它们有助于连接和映射来自任何设备的信号/输入。

这些是Mac环境下的Max和PC环境下的Pure Data。两者都有大量的在线文档和YouTube教程。视频Max/MSP教程1 -使用计算机键盘作为MIDI键盘(ableton风格)演示了Max内置的一个程序，该程序将计算机键盘映射到MIDI键盘的输入(这基本上与您正在尝试做的完全相反)。您可以通过使用相同的模式，但是反转信号/映射来获得预期的结果。

自动热键

AutoHotKey是一个免费的Windows开源实用程序，允许您将设备上的键和按钮重新映射到宏。它本机支持QWERTY键盘，操纵杆和鼠标宏。

但是，我能够找到支持您正在寻找的特定映射的实现。下面两个线程解释了这个过程:

MIDI IN支持AutoHotkey用例的讨论。作者正在寻找一个程序，可以检测MIDI输入并将其转换为按键。 MIDI输入库，作者的问题的解决方案和发布的代码/补丁AutoHotKey，它实际上实现了您预期的结果。

基本上，它看起来像AutoHotKey，以及这个用户的自定义补丁，将提供您所需要的创建从MIDI键盘到QWERTY键盘的输入信号的映射。您所要做的就是安装、配置和定义映射。

还有别的事吗?

Some of the other answers have given you much more extensive information on MIDI and MIDI programming, in general, but as your post states that doesn't seem to be quite what you are looking for. I would like to help you more if possible, but it would be easier if you could be more specific about the type of information you are looking for. For instance, are you more interested in how to convert a MIDI keyboard's input signals to a QWERTY keyboard's signals, or is your primary interest finding an out of the box solution to your specific problem? What are you looking for that has not yet been addressed?

实际上，我在这个工作了一段时间前，试图捕捉摇滚乐队鼓输入到我的计算机(做一个小Java自制鼓模拟器)无论如何，我问了一个问题在这里，时间延迟问题(有轮询代码在那里，以及我试图做的事情。)如果我能找到我的程序，我可以给你的代码，它使用第三方API (JInput)。

祝你好运。

如果你使用Linux，可以去Footware看看。

它应该正是你所寻找的-如果你调整MIDI音高到你喜欢的键映射…

我从没想过这对除了我以外的任何人都有用;

试试Bome的MIDI翻译器。

它可以跨平台工作，可以轻松地将任何MIDI输入转换为键盘，快速设置和配置，另外它是免费的个人使用。

有一个教程，快速提示:MIDI翻译- MIDI键击，如何轻松设置:

基本上，你可以做的事情有无限的可能性，包括和弦和修饰键。我用它作为我的现场音频设备来控制我的DAW使用我的钢琴，从来没有遇到过问题。

我已经很多年没有做过任何MIDI编程了，但是你的基本想法非常合理(没有双关语)。

MIDI是一连串的“事件”(或“信息”)，其中最基本的两个是“开启”和“关闭”，它们都带有音符号(0 = C中C低5个八度，到127 = G中C以上G高5个八度，为半音)。这些事件在速度敏感(“触摸敏感”)的键盘上携带一个“速度”数字，其力度(你猜对了)在0到127之间。

Between velocity, chording, and the pedals, I'd think you could come up with quite a good "typing" interface for the piano keyboard. Chording in particular could be a very powerful technique — as I mentioned in the comments, it's why rank-and-file stenographers can use a stenotype machine to keep up with people talking for hours in a row, when even top-flight typists wouldn't be able to for any length of time via normal typewriter-style keyboards. As with machine stenography, you'd need a "dictionary" of the meanings of chords and sequences of chords. (Can you tell I used to work in the software side of machine stenography?)

要做到这一点，基本的部分是:

接收MIDI输入。不要尝试自己去做，使用一个库。编辑:显然，Java Sound API支持MIDI，包括从MIDI控制器接收事件。酷。本页也可能有用。 将数据转换为你想要发送的击键，例如通过我上面提到的字典。 输出击键到计算机。

为了最广泛地与软件兼容，您必须将其作为键盘设备驱动程序编写。这是操作系统的一个插件，用作键盘事件的源，与底层硬件(在您的例子中是钢琴键盘)通信。对于Windows和Linux，你可能会想要使用C语言。

However, since you're just generating keystrokes (not trying to intercept them, which I was trying to do years ago), you may be able to use whatever features the operating system has for sending artificial keystrokes. Windows has an interface for doing that (probably several, the one I'm thinking of is SendInput but I know there's some "journal" interface that does something similar), and I'm sure other operating systems do as well. That may well be sufficient for your purposes — it's where I'd start, because the device driver route is going to be awkward and you'd probably have to use a different language for it than Java. (I'm a big fan of Java, but the interfaces that operating systems use to talk to device drivers tend to be more easily consumed via C and similar.)

更新:更多关于和弦到按键的“字典”:

基本上，字典是一个trie(谢谢，@Adam)，我们用最长前缀匹配进行搜索。细节:

In machine stenography, the stenographer writes by pressing multiple keys on the stenotype machine at the same time, then releasing them all. They call this a "stroke" of the keyboard; it's like playing a chord on the piano. Strokes frequently (but not always) correspond to a syllable of spoken language. Like syllables, sometimes one stroke (chord) has meaning all on its own, other times it only has meaning combined with following strokes. (Think "good" vs. "good" followed by "bye"). Although they'll be heavily influenced by the school at which they studied, each stenographer will have their own "dictionary" of what strokes they use to mean what, a dictionary they will continuously hone over the course of their working lives. The dictionary will have entries where the stenographic part ("steno", for short) is one stroke long, or multiple strokes long. Frequently, there will be several entries with the same starting stroke which are differentiated by their length and by the subsequent strokes. For instance (and I won't use real steno here, just placeholders), there may be these entries:

A     = alpha
A/B   = alphabet
A/B/C = alphabetic
A/C   = air conditioning
B     = bee
B/C   = because
C     = sea
D     = dog
D/D   = Dee Dee

(这些字母并不是音符，只是抽象的标记。)

请注意，A开始多个条目，还要注意如何转换C笔画取决于您之前是否看过A、B，或者您正在从头开始。

Also note that (although not shown in the very small sample above), there may be multiple ways to "play" the same word or phrase, rather than just one. Stenographers do that to make it easier to flow from a preceding word to the next depending on hand position. There's an obvious analogy to music there, and you could use that to make your typing flow more akin to playing music, in order to both prevent this from negatively affecting your piano playing and to maximize the likelihood of this actually helping with the RSI.

When translating steno into standard text, again we use a "longest-prefix match" search: The translation algorithm starts with the first stroke ever written, and looks for entries starting with that stroke. If there is only one entry, and it's one stroke long, then we can reliably say "that's the entry to use", output the corresponding text, and then start fresh with the next stroke. But more likely, that stroke starts multiple entries of varying lengths. So we look at the next stroke and see if there are entries that start with those two strokes in order; and so on until we get a match.

根据上面的字典，假设我们看到了这个序列:

A C B B C A B C A B D

我们是这样翻译的:

A is the start of three entries of varying lengths; look at next stroke: C A/C matches only one entry; output "air conditioning" and start fresh with next stroke: B B starts two entries; look at next stroke: B B/B doesn't start anything; take the longest previous match (B) and output that ("bee") Having output B = "bee", we still have a B stroke in our buffer. It starts two entries, so look at the next stroke: C B/C matches one entry; output "because" and start fresh with the next stroke: A A starts three entries; look at the next stroke: B A/B starts two entries; look at the next stroke: C A/B/C only matches one entry; output "alphabetic" and start fresh with the next stroke: A A starts three entries; look at next stroke: B A/B starts two entries; look at next stroke: D A/B/D doesn't match anything, so take the longest previous match (A/B) and use it to output "alphabet". That leaves us with D still in the buffer. D starts two entries, so we would normally look at the next stroke — but we've processed all the strokes, so consider it in isolation. In isolation, it translates as "dog" so output that.

以上各方面要注意:

You have a buffer of strokes you've read but haven't translated yet. You always want to match the most strokes against a single entry that you can. A/B should be translated as "alphabet", not "alpha" and "bee". (Not shown above) You may well have sequences of strokes that you can't translate, because they don't match anything in the dictionary. (Steno people use the noun "untranslate" -- e.g., with our dictionary, the strokes E would be an "untranslate".) (Not shown above) Some theories of steno allow the same set of strokes to mean more than one thing, based on a broader context. Steno people call these "conflicts". You probably want to disallow them in your project, and in fact when steno used to be translated manually by the stenographer, conflicts were fine because they'd know just by where in the sentence they were what the right choice was, but with the rise of machine translation, conflict-free theories of steno arose specifically to avoid having to go through the resulting translated text and "fix" conflicts. Translating in real time (which you'd be doing) means that if you receive a partial match, you'll want to hold onto it while waiting for the next chord — but probably only up to a timeout, at which point you'd translate what you have in the buffer as best you can. (Or maybe you don't want a timeout; it's your call.) Probably best to have a stroke that says "disregard the previous stroke" Probably best to have a stroke that says "completely clear the buffer without outputting anything"

关于MIDI

你说你“对迷笛一无所知”。一旦掌握了MIDI技术，它就相当简单，但在开始时可能会令人困惑。有一种资源对我理解MIDI的基础(如果你想编程MIDI交互，这当然是必要的)有极大的帮助，那就是为技术恐惧者写的一本叫做MIDI的书。这是一本容易读的书，非常有用。

Pure Data & Max

在我开发交互式多媒体的经验中，我遇到过两个非常相似的程序，它们有助于连接和映射来自任何设备的信号/输入。

这些是Mac环境下的Max和PC环境下的Pure Data。两者都有大量的在线文档和YouTube教程。视频Max/MSP教程1 -使用计算机键盘作为MIDI键盘(ableton风格)演示了Max内置的一个程序，该程序将计算机键盘映射到MIDI键盘的输入(这基本上与您正在尝试做的完全相反)。您可以通过使用相同的模式，但是反转信号/映射来获得预期的结果。

自动热键

AutoHotKey是一个免费的Windows开源实用程序，允许您将设备上的键和按钮重新映射到宏。它本机支持QWERTY键盘，操纵杆和鼠标宏。

但是，我能够找到支持您正在寻找的特定映射的实现。下面两个线程解释了这个过程:

MIDI IN支持AutoHotkey用例的讨论。作者正在寻找一个程序，可以检测MIDI输入并将其转换为按键。 MIDI输入库，作者的问题的解决方案和发布的代码/补丁AutoHotKey，它实际上实现了您预期的结果。

基本上，它看起来像AutoHotKey，以及这个用户的自定义补丁，将提供您所需要的创建从MIDI键盘到QWERTY键盘的输入信号的映射。您所要做的就是安装、配置和定义映射。

还有别的事吗?

Some of the other answers have given you much more extensive information on MIDI and MIDI programming, in general, but as your post states that doesn't seem to be quite what you are looking for. I would like to help you more if possible, but it would be easier if you could be more specific about the type of information you are looking for. For instance, are you more interested in how to convert a MIDI keyboard's input signals to a QWERTY keyboard's signals, or is your primary interest finding an out of the box solution to your specific problem? What are you looking for that has not yet been addressed?