Related
Good day!
Problem definition:
Current implementations of Bluetooth does not allow to simply support good quality of Audio(Earphones mode) and 2-way audio transition (Headset mode).
Also, even if one would manage to set this configuration up, which have huge limitations on the hardware/software used, there is no way to handle sound input from 2 different audio devices simultaneously.
So, technically - one cannot just play the Game, communicate on the Discord, and optionally listen to some music, unless he is bound to some USB-bundled earphones. Which are usually really crappy, or really expensive. Or both.
Solution sketch:
So, I came up with an idea that one can actually build such device, using Raspberry Pi, Arduino, or even barebone-component-based stacks.
Theoretical layout of connections per-se would look somehow like that:
Idea is to create 2 "simple" devices
One, not-so-portable, that would handle several analog inputs, and one analog output
One, portable, that would handle single analog Input and Output, and could be used with any analog earphones.
"Requirements" to such system would be quite simple:
This bundle have to handle Data Transition on some distance, preferably up to 10 meters, or more.
The "Inlet" device should be portable enough to keep it in the pocket, or in an arm band, or something
Sound Quality should be at the very least on the level of Bluetooth headphones profile, or if possible - even better
If possible - it would be nice to keep the price of the Solution under 500 Euros, but I'm so tired of current state of things that I might consider raising the budget...
Don't mind the yellow buttons on the Outlet device. Those are optional, and will depend on the implementation stack :)
Question:
Can anyone advice me which component-base would be a better solution to making such a tool, and why?
And maybe someone actually knows of similar systems already existing?
Personally I would prefer anything but the barebone-components-based solution, just because I'm really rusty with that area, and it requires quite the amount of tools, to handle it properly.
While using pre-built modules can save me from buying most of the hardware tools, minifying my "hardware customization" part of this solution, leaving only software part to handle (which is my main area of expertise).
But then again, if there are some experts here, that would consider other stacks non-viable - I would really appreciate to see their reasonings.
P.S. Just to be clear: If this project will prove viable - I will implement it, and share the implementation details with the communities. I am not the first one who needs such system, and unfortunately it seems that Hardware/Software vendors are not really interested in designing similar solutions...
I happen to find a "temporary" solution.
I've came across a wireless headset, that allows to simultaneously support Wireless USB Bundle connection, and Bluetooth connection to different devices, and provide nice way of controlling sound input/output with both connections.
This was almost a pure luck, as this "feature" was not described anywhere in the specs...
Actual headset name is:
JBL Quantum 800
This does not closes the question per-se, as I still plan to implement this "Summer Project" at some point, but I believe this information might be useful to those searching for similar solutions.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
There are many alternative keyboards to the standard US keyboard layout (called QWERTY).
Some examples include Dvorak, (and variants like Programmer Dvorak), Colemak, AZERTY, Workman layout, etc.
Do any of these confer a benefit to typing speed, accuracy or hand/wrist-health?
And, if so, which one of these should I choose as a touch typist if I am regularly programming?
Short answer:
If you are happy with your keyboard layout, stick with it.
Long answer:
I will try and aim to make this as definitive and explanatory an answer as possible. To understand a bit where I am coming from, allow me to express my own journey through this jungle:
I am a computer science student who started out with the German QWERTZ keyboard, typing at about 100 WPM (words per minute). When that turned out to be horrendous for programming, I moved to QWERTY. Then, I got taken in by the hype and turned to Colemak. After mastering it, I discovered there was a layout optimized for programming, and switched to Programmer Dvorak. Finally, still not happy, I tried to design my own keyboard layout semi-scientifically. And finally, now, I am typing these lines on QWERTY. (To save others the trouble and pain I went through).
Therefore, I will try to argue in my answer both from personal experience as well as from scientific published data.
The main arguments for all the alternative keyboard layout hype can be summarized to three major points:
The QWERTY keyboard is slow and was designed to slow typists down.
Excessive use of QWERTY causes Carpal Tunnel syndrome and is bad for your health.
Dvorak/Colemak/< Insert alternative layout here > was optimized to increase speed/accuracy/health
Let's go through this one by one:
First, the argument that the QWERTY keyboard was designed to slow typists down is simply not true. It was nicely debunked in this question. The QWERTY keyboard was designed to stop the keys from a certain model of typewriter to stop jamming. Rest assured, we will discuss the "QWERTY is slow" myth in a minute.
Second, the ultimate argument that advocates of alternative keyboards love to use is that QWERTY causes Carpal Tunnel syndrome, because it strains the fingers.
What's amazing here is that this is actually an Urban legend which has persisted despite it being discredited. See this question here. To quote from the answer by Graeme Perrow: "It seems that using computers in general does not cause carpal tunnel syndrome, regardless of the type of keyboard."
Finally: If QWERTY wasn't made to slow typists down and doesn't cause any illness, why use another keyboard? The answer usually offered is because other layouts are faster and have the keys aligned in a "smarter" way.
We are told how much faster typists can be when they use Dvorak instead of QWERTY and how the home row of colemak offers great benefits to productivity and speed.
We are treated to an avalanche of impressive-looking percentages, of how much faster and accurate you can be on an alternate keyboard, rather than a humble QWERTY.
However, if you look at hard, scientific evidence, you find... nothing worth writing home about. Indeed, there are two very interesting posts here and here: It turns out that the (very hard to objectively measure) speed gains are a measly 2% to 4%.
This mimics what I myself have experienced: If you are a trained typist, then switching doesn't give much of an improvement. After I had finally finished my switch to Dvorak, I was still typing at roughly 100WPM. If you want to go beyond that, you have to type a lot during your day.
I believe that the reason people observe a speed-boost when they switch is that they have to retrain their muscle memory from scratch. Which, if they do diligently, is rewarded with a faster typing speed. The irony is: I conjecture that if they had "retrained" QWERTY from scratch, they would have obtained the same speed increase.
Additionally, my own error rate didn't go down with Dvorak or Colemak. It stayed around the same level. Which, again, is not dictated by the layout but by the accuracy with which one has trained their muscle memory.
Lastly, on the note of programming: It is true that for programming languages, on QWERTY the keys used often, such as {}, [], ', =, +, -, _, etc., are all to be reached with the right pinky, which drags performance down. This still is not worth the switch to something like Programmer Dvorak, however, since, especially in programming, the limiting factor is rarely typing speed (once you get above 60WPM, that is).
So given all this, there are also a few downsides to switching that I wish to elaborate:
Dvorak suffers from the huge disadvantage that all computers use shortcuts (such as the famous CTRL+C and CTRL+V) which, on the Dvorak, are in different and hard-to-reach positions. Colemak doesn't suffer from this as much, since it kept the C, V and B key positions from QWERTY. However, even with Colemak, using programs which rely heavily on shortcut use (the most notorious of these being software like vim and emacs), has to be relearned from scratch.
Switching takes a very long time. Let nobody fool you. If you were typing at >80WPM, I can tell you from personal experience that it takes months to achieve this speed again. Even if you swap only a few keys (like Colemak), it is still a painful and long process.
When you successfully switch, you will be unable to type fast on regular QWERTY keyboards anymore (take my word for it). You will still be faster than someone who doesn't use touch typing, but if you ever have to type on a QWERTY computer as an alternative typist, you will be in for some embarrassment. This can get especially hairy if it is work related.
Many alternative layouts are not nearly as standardized as QWERTY. In other words: If you use an older machine, for instance, you may find your preferred layout not installed. This is a further hassle, because then you have to get around that problem by downloading and installing the layout you chose, meanwhile having to work in a layout you can no longer use.
Thus, in conclusion, my advice is: If you are happy with your current layout, keep it. The benefits of changing are much too small to consider. Especially if you are a QWERTY typist, I recommend staying with it. It will save you a lot of hassle and annoyances.
Long story short: QWERTY was not designed for touch typing. When compared with nine other layouts, QWERTY comes in dead last in typing effort. Give other layouts a try and experience the difference.
Whether the QWERTY layout was intentionally designed to slow typists is irrelevant. QWERTY is inherently slow by design.
The ultimate argument made by alternative keyboard advocates is that QWERTY is an inefficient, sub-optimal keyboard layout and that better layouts exist that suit modern touch typing technique. Whether one subscribes to the belief that QWERTY is a contributor to carpal tunnel is another story, yet many anecdotal stories exist of people who have reduced RSI by switching.
You should use a non-QWERTY keyboard layout because a non-QWERTY keyboard layout is easier to use. Switching to Dvorak or Colemak reduces distance traveled, reduces same finger typing, increases hand alternation, increases hand balance, and optimizes performance according to finger strength. Switching to Dvorak alone reduces effort by 30% (i.e not 4% as suggested, see first link). Note that these benefits accrue over time with use. The idea that there is no benefit to switching is simply untrue. And with newer layouts such as Colemak, typists don’t have to relearn to type. 48% of the Colemak keyboard layout is identical to QWERTY. Even if one’s error rate doesn’t fall (highly unlikely), alternative keyboard layouts like Colemak remap backspace to an easier to reach spot.
Regarding said downsides:
Windows and Mac offer the ability to use familiar QWERTY shortcuts while pressing Ctrl/Cmd. Many people have devised ways for using emacs/vim while switching.
Switching can be very painless and easy considering there are websites such as keybr.com that teach how to master touch typing using Dvorak or Colemak.
Whether you can type as fast with QWERTY after switching is irrelevant. Once you switch, you are set and won't have to go back to QWERTY on your own device. Dvorak and Colemak are standards or can be easily installed on to all major operating platforms. If you are going to use others keyboards and aren’t able to switch the layouts, there are numerous online keyboard simulators.
The hassle of switching the layout on the computer is very minimal if nonexistent compared to the hassle of typing on QWERTY.
Advice: The benefits of switching are too large not to consider. You have nothing to lose by trying; if it doesn’t work out, you will always have QWERTY to fall back on. Let your keyboard work for you, not the other way around.
My two cents worth...
I switched from QWERTY to Colemak a few years back, mostly because I like to try out new things but also because I was getting a bit of RSI from all the typing I do.
I found the transition took a few months, with the first few weeks being most painful -- I took a lot of handwritten notes in meetings in this period! But perseverance paid off, I'm now typing at about 60-70 wpm, which is faster than my old QWERTY speed, and I can touch type properly, plus I don't get the RSI pains any more.
Now, much of this might be because I learned to type properly in Colemak (using programs such as GNU Typist) whereas I don't recall ever learning QWERTY properly. But I would say that Colemak definitely feels nicer on the fingers, with less movement around the keyboard for most words.
I'd also add that Colemak is supported as part of the base OS on Mac and popular GNU/Linuxs (e.g. Debian and Ubuntu), and easy to install on Windows, so would consider it fairly mainstream.
I agree with #mark-anderson I am typing on dvorak and the worst part is that shortcut keys are a pain - I use a tool for that (see my answer at https://stackoverflow.com/a/22945703/18132). Using someone else's keyboard is also a pain.
On the plus side, I can touch type and never have to look at the keyboard. actually if I look at the keyboard I get confused since the keys are in the wrong place.
Was it worth it? Not really sure. I like that I can touch type. I like that I can use qwerty shortcuts but my hand still hurts and I think I might be faster - not really sure. But I am considering switching back to qwerty - I have been dvorak for 2+ years now, so I don't really have a good reason to switch back other than to "conform" :)
Closed. This question is off-topic. It is not currently accepting answers.
Closed 9 years ago.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
I have RSI problems and have tried 30 different computer keyboards which all caused me pain. Playing piano does not cause me pain. I have played piano for around 20 years without any pain issues. I would like to know if there is a way to capture MIDI from a MIDI keyboard and output keyboard strokes. I know nothing at all about MIDI but I would like some guidance on how to convert this signal into a keystroke.
I haven't done any MIDI programming in years, but your fundamental idea is very sound (no pun).
MIDI is a stream of "events" (or "messages"), two of the most fundamental being "note on" and "note off" which carry with them the note number (0 = C five octaves below middle C, through 127 = G five octaves above the G above middle C, in semi-tones). These events carry a "velocity" number on keyboards that are velocity sensitive ("touch sensitive"), with a force of (you guessed it) between 0 and 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?)
To do this, the fundamental pieces are:
Receiving MIDI input. Don't try to do this yourself, use a library. Edit: Apparently, the Java Sound API supports MIDI, including receiving events from MIDI controllers. Cool. This page may also be useful.
Converting that data into the keystrokes you want to send, e.g. via the dictionary I mentioned above.
Outputting the keystrokes to the computer.
To be most broadly-compatible with software, you'd have to write this as a keyboard device driver. This is a plug-in to the operating system that serves as a source for keyboard events, talking to the underlying hardware (in your case, the piano keyboard). For Windows and Linux, you're probably going to want to use C for that.
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.)
Update: More about the "dictionary" of chords to keystrokes:
Basically, the dictionary is a trie (thanks, #Adam) that we search with longest-prefix matching. Details:
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
(Those letters aren't meant to be musical notes, just abstract markers.)
Note that A starts multiple entries, and also note that how you translate a C stroke depends on whether you've previously seen an A, a B, or you're starting fresh.
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.
So with the dictionary above, suppose we saw this sequence:
A C B B C A B C A B D
Here's how we'd translate it:
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.
Aspects of the above to note:
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"
Consider doing something in hardware that emulates a usb (or ps/2?) keyboard. You will no longer be dependent on a specific OS, or specific OS API. A hardware solution will stand the test of time. Don't be stuck using an old API in Windows 7 when everyone else is running Windows 11! Arduino is pretty easy to learn.
Arduino MIDI hardware is available off of the shelf
Arduinos have been used to emulate keyboard devices
There is a ton of info and help out there for Arduino. It is a hardware hacking platform built for newbies. It will only get bigger now that Google is pushing Arduino.
EDIT: Virtual USB Keyboard software and hardware
It sounds to me like you're looking less for advice on how to build this yourself and more asking what resources are already out there to accomplish what you want. Depending on your OS, there are many ways to accomplish this without having to write your own program from scratch:
MIDI Stroke
Free. For Mac OS X 10.3 and up. This one specifically comes with "the ability to use any MIDI keyboard as a full blown computer keyboard replacement."
Bome's MIDI Translator
Free/Postcardware (it's a bit odd). For Windows 2000 and up, and Mac OS X. It initially appears to be more geared towards AutoHotkey-type usage, but on further looking I think it could do what you want nicely.
Max and aka.keyboard
Free. For Mac OS X. Not exactly a "ready out of the box" solution, but if you are comfortable with basic device configuration, it shouldn't be too bad.
You can access the hardware with source code samples in .NET in MIDI DotNet.
A complete working sample as sourcecode to create MIDI notes data stream is in VB 5/6-Tipp 0521: MIDI-Töne erzeugen (Visual Basic 6.0, somewhere is .NET version too)
A way to simulate keyboard strokes is in VB 5/6-Tipp 0155: Tastaturereignisse simulieren (Visual Basic 6.0, somewhere is .NET version too)
And recognize keystrokes is describedin Tipp-Upload: VB.NET 0266: Globaler KeyHook.
Then, just use a good working matrix for a piano player
On piano and when you're a good player, you can have 10 fingers on the keyboard and if the matrix is usable you can be much more quickly that any computer keyboard user I think. :-)
In that case, if I understand your question right, it should not be a big thing.
I studied piano performance in college and then got into interaction design, programming, and using Vim, so I have actually spent a lot of time prototyping things like this.
You can get this working pretty quick in Linux by using the graphical programming language for multimedia artists, "Pure Data," along with the x11key external by Alex Andre.
On Mac, you can use MidiStroke. I believe a method on Windows involved the MidiOx and AutoHotKey tools. At another time I had a version going using the Java plugin for Max/MSP. I believe Patrice Colet made a windows external for Pure Data that worked as well, but I can't seem to locate it anymore. Also, there's an external for MaxMSP that can do this on Windows. Finally, the non-free but awesome Osculator can do what you want - see the features page.
When I got it working, I never stuck with it, because I couldn't stop tooling with the layout. It was cool just having my monitor on my electric keyboard, though! Good luck.
About MIDI
You stated that you "know nothing at all about MIDI". MIDI technology is fairly straight-forward once you grasp it, but it can be confusing at the outset. One of the resources that has been tremendously helpful for me in understanding the foundations for MIDI (which are certainly necessary if you want to program MIDI interactions), is a book called MIDI for the Technophobe. It's an easy book to read and is very helpful.
Pure Data & Max
In my experience developing interactive multimedia, there are two very similar programs I have encountered that facilitate connecting and mapping signals/inputs from any device.
These are Max for a Mac environment and Pure Data for a PC environment. Both have a plethora of online documentation and YouTube tutorials. The video Max/MSP Tutorial 1 - using your computer keyboard as midikeyboard (ableton style) demonstrates a program built in Max that maps a computer keyboard to a MIDI keyboard's inputs (which is basically the exact opposite of what you are trying to do). You could get your intended results by using the same pattern, but reversing the signals/mappings.
AutoHotKey
AutoHotKey is a free open source utility for Windows that allows you to remap keys and buttons on your devices to macros. It natively supports QWERTY keyboards, joysticks and mouse macros.
However, I was able to find an implementation supporting the specific mapping you are looking for. These two threads explain the process:
MIDI IN support in AutoHotkey , the discussion of the use case. The author was looking for a program that could detect MIDI IN input and translate that to keypresses.
MIDI input library , the solution to the author's problem and the posted code/patch to AutoHotKey which actually implements your intended result.
Basically, it looks like AutoHotKey, along with this user's custom patch, will provide exactly what you need to create a mapping from a MIDI keyboard to a QWERTY keyboard's input signal. All you would have to do is install, configure and define your mappings.
Anything else?
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?
You could hack your own USB keyboard pretty quickly using a Teenys micro controller.
In fact, they have example code for how to make a USB keyboard.
You could approach this two ways:
Get an old piano and wire up switches directly to the teensy
Add the additional logic to connect to the MIDI port and necessary decoding.
Actually, I worked on this a while ago, trying to capture Rock Band drum inputs into my computer (making a little Java homemade drum emulator) Anyway, I asked a question on here about that, Time delay problem (there is polling code in there, along with what I was attempting to do.). And if I can find my program I can give you the code, it uses a third-party API (JInput).
Good luck either way.
Try Bome's MIDI translator.
It works cross platform, can convert any MIDI input to a keystoke easily, quick to setup and configure, plus it's free for personal use.
There is a tutorial, Quick Tip: MIDI Translation – MIDI to Keystrokes, of how to easily set it up:
Basically, there are infinite possibilities of what you can do, including chording and modifier keys. I use it for my live audio rig to control my DAW using my piano and have never had an issue.
In Java, you can use JMF (Java Media framework) to convert MIDI signals.
Basic of keyboard design is easy to use, that is, the user interface; and place frequently used charcter/symbol handy.
The sample code and API in Java Sound Resources: Examples: Digital Signal Processing (DSP) help to understand how to process the signal.
Some more references:
Processing Audio with Controls
Digital Audio Signal Processing, 2nd Edition
A good library in .NET with full midi support (BASS), go to http://www.un4seen.com.
And for the other part, translating keyboard midi notes to keys and more, I would go for AutoItX, the ActiveX/COM and DLL interface to autoIt. Info and download, go to http://www.autoitscript.com/site/autoit/
No need to write keyboard driver.
There is a program called GlovePIE. You can program it in a simple scripting language, and I believe it supports MIDI. I'm not sure if this fits under the "Java" category, but still, it is a great program. I've used it to control robots using PS3 controllers. It's very powerful.
Many keyboards have a serial port (RS-232) connector to send MIDI signals to the computer. I use a program called Girder to convert serial port communication into keyboard strokes.
Girder has a "mapping" feature that lets you map each key, one by one, to the corresponding keystroke.
This might be the simple solution you're looking for!
Just learn stenography!
It's clear from all the discussion on your part. You don't want to re-invent any wheels, from a technical standpoint. But once you have a connection made (what this question is asking) and up and working, you still have most of the work ahead of you: You have to train your brain. You also have to invent the cleverest, most efficient way to do that - a design issue totally out of the rhealm of computer techies. You or any of us would fall short.
Fortunately, the problem has been solved and honed though centuries of maturing...
Learn stenography!
Yes, this will set you back some jack. But what are hundreds of hours of your own time worth, with at the end, a less favorable result? Besides, the stenography Wikipedia article says, 'it looks more like a piano keyboard'.
Unless, of course, you want to have a sideshow effect going. I would have to admit, I never thought of this possibility, it it would be really entertaining to see somebody bust out a text from a piano keyboard!
You could start with a USB keyboard with touchpad (or a pointing stick would be more ergonomic?), use Plover to translate it (I'm sure it can be configured to let the non-letter keys retain their functionality as they are critical for programming), or, follow the thread Re: Plover keyboard to roll your own USB stenography keyboard, or, buy a stenotype.
Good luck!
Take a look at MAME arcade gaming. They have built hardware devices to allow input from any number of different items. The iPac, for example, converts signals from input devices into USB that the computer can then use to emulate keys. You could use any combination of input devices arranged any way that seems comfortable with no crazy programming logic required--because the software to interpret input is already done and well tested.
I've seen flight simulator cockpit inputs, custom kiosks, and voting systems built in this method.....and the price is right!
To solve this you will need a few things:
A way to capture MIDI data from your keyboard. Depending upon the interface: MIDI interface (classic) or USB MIDI interface (modern) the most likely interface is to a computer as it provides the most options. USB host microcontrollers are not as simple as just using a computer.
A scheme to convert MIDI data into keystrokes. Like one user pointed out, chords are the way to go as the number of keys will not be dependent upon the number of piano keys.
A way to inject a key into the operating system. This will require a low-level driver to be accurate. I have played around with applications that inject keyboard and mouse data into applications in Windows 7, and it can be flaky and depend upon whether an application is currently in focus. This is hardest part of the interface. What may work is to create a HID USB keyboard microcontroller that also has a serial interface.
The serial interface would create a virtual serial port. The software that reads the MIDI data and produces the keystrokes could send a serial message to the virtual serial port. The microcontroller would send a keystroke so it would look like a standard keyboard input. This would allow interfacing both MIDI ports and USB MIDI keyboards.
Hmmm, with this type of interface you could also simulate a mouse and use some piano keys setup for the mouse axis and buttons. The pressure could be used to determine mouse pointer velocity. So you could eliminate the mouse as well. Another benefit of this approach is any type of input device you connect could talk to the virtual serial port to produce keyboard and mouse events. So if you wanted to add other hardware such as drum pedals or a joystick it would be a matter of adjusting the program that talks to the serial interface.
Another take on the above is like some posted above to use an Arduino, but also include USB Host Shield from Sparkfun to handle USB based music keyboards. This allows the Arduino to be programmed as a keyboard or keyboard mouse combo in the boot loader chip and allows the device to act a USB host for the USB based music keyboard. Then you are covered for both types. Although, I still think the virtual serial port method is more flexible and would be easier to program in the long run. The Arduino device will be harder to change than a desktop program or service.
There is another possibility:
Chorded one handed keyboards already exist. I have seen videos on them, but you would have to determine if those hurt your hands or not.
It should be fairly easy using something like the .NET DirectSound interface to hook into an MIDI device. You will need to identify your target MIDI device and then get the code to listen in on the incoming messages (there are articles about doing this via Google).
Since you are using the MIDI in as a keyboard there are basically only two MIDI messages that you need to detect, namely note on and note off. The MIDI message is three data bytes specifying the command, the note and the velocity. The note off is just the note number (sometimes 'bad' MIDI stacks send a note on with zero velocity which you also have to expect).
Once you have the messages translating them the keyboard output should be fairly simple from .NET.
There is plenty of advice in the other answers about the technicalities; I just wanted to give you an idea of the actual MIDI messages. Good luck!
You'll get better and happier results (regardless what operating system and/or DAW program you like to use) by playing any external MIDI keyboard as a controller through your sound card. Then route that into your GB software (or whatever) and tone generate the many sounds they have supplied you that way in real-time.
If your sound card does not support MIDI I/O's (ins / outs /thrus), that's not a problem. You can consider researching and investing in an external MIDI table top converter. Many are equipped to further convert MIDI outs to USB 2.0 (by- passing an existing sound card altogether).
For example: it's pretty tough getting "human like" grace note results via a Z and X change key option using a computer keyboard and pencil tool. When, instead, your own fingers can just play that with a MIDI keyboard from its own physical octave register ranges—immediately!
I realize budgetary constraints may be involved. But, some of these seemingly cheap "Casio" type 5 octave keyboards sold at Radio Shack for under $100.00 U.S. Dollars (*or less) is all you would need (plus, some of their on-board sound patches and sequencer modules sound and handle amazingly well for other things too).
RadioShack MIDI keyboard options.
As for external MIDI converters for existing sound cards, I've run some Google searches for you as follows with Mac platforms specifically in mind:
A lot of this external MIDI conversion information may be cumbersome to you at first, so I've broken down things more as "user friendly" for your considerations & budget:
MIDI sound cards
There's nothing wrong with facilitating virtual keyboards as VST's when using DAW. They have their place.
But, you sound like an accomplished keyboardist. So, why not consider the external MIDI conversion / keyboard options I just mentioned for yourself?
Good luck and I hope this gave you some ideas that can and will work for you!
If you don't want to do any programming yourself but just want the problem solved you can just buy a USB-MIDI-keyboard where you can re-assign any key to send a QWERTY keyboard output signal instead of a MIDI-output, for example M-Audio Axiom Pro
This method will work with any OS and any computer that supports standard USB-keyboards since the MIDI-keyboard will identify itself as a standard QWERTY keyboard.
You can use a simple AutoIt script to both read MIDI events, see MIDI Input.
You'll also need MIDI UDF and simulate key presses.
Reading MIDI events should be easy, but different MIDI controllers (instruments) have different features. Try to find out what your MIDI piano can do first, then see how you can best map those features to simulated QWERTY-keyboard presses.
If you want, you could have something on screen or in the tray to help you see what you are doing (that is, for Shift, Ctrl and Alt simulation).
You might take a look at chorded keyboards. They have the advantage that you don't need to write a driver for them before you can use them, and some are similar to the layout of a piano keyboard.
If you know coding in Java, you could use this way:
First, implement a javax.sound.midi.Receiver with a send(..) method that is mapping the 'Note on' events to keystrokes like you want.
You would need to get the MidiMessage's content with its getMessage method and intepret it in your fashion. The meaning of the message bytes can be found in MIDI Messages.
After receiving a 'note on' or 'note off' for a certain keyboard key, you may map that to a key you like by assigning it a constant of the KeyEvent class, something like C#4 -> KeyEvent.VK_A and so on. This key code can then be used by java.awt.Robot's keyPress and keyRelease methods to actually send the keystroke to the OS and thus to other applications.
I agree with Brian O'Dell's answer - if this were my project, I'd do it in hardware. It has the advantage of being platform and hardware independent - your box replaces the need for a MIDI-USB interface and a PC API.
mbed is a fast-prototyping platform that is very easy to learn, and has multiple advantages over Arduino IMHO (online compiler, 512 KB flash, 96 MHz, C++ language). It has a USB keyboard interface and a USB Midi interface pre-written for you.
The community is very friendly and willing to help, and there are a lot of existing projects using both MIDI and USB hid emulation - search Youtube for "mbed MIDI" or similar.
If you use Linux have a take at Footware.
It should be exactly what you're looking for - if you adjust the MIDI pitches to a keymapping of your liking...
I never thought this could be useful for anyone but me ;o)
Try using a microcontroller-based system, like Arduino.
This wouldn't be too tough.
I'm assuming you're on Windows, not sure about that though. I've written a MIDI sequencer, http://pianocheetah.com, in plain old C++, and it lets you use the piano keyboard to run commands. There isn't any reason you couldn't do the same thing to push keys
into the keyboard input stream.
But come on now. You remember how long it took you to learn
the keyboard in the first place, right?
Are you willing to go through that again?
And are you willing to pollute your blessed keyboard with
a bunch of stupid looking key symbols all over it?
You'll need to use at least 26 alpha, 10 numeric, 11 punctuation,
and at least 12 function keys AND their shifted states.
So that's 60 keys plus shifted states.
That'll burn up a full 5 octaves of keys.
You will be doing piano "hops" =all= the time.
Say goodbye to touch typing.
You may save yourself from RSI, but you've created another
different type of nightmare for yourself.
And good luck getting your boss to buy you a MIDI keyboard at work.
If you've learned to truly play piano, you've learned
how to play stress free. Do that on the QWERTY keyboard.
No tension. Start slow.
I recently broke my finger and can now only type with my right hand. This has seriously impacted my typing speed. Since I write software for a living, this is a serious problem.
I have been doing some research, but haven't found a great solution yet. Here's what I've come up with:
Wacom tablet + hand writing recognition software. Is it possible to write code with hand writing recognition software?
one handed keyboards -- I have only found expensive (> $100) keyboards. These look like they have a steep learning curve.
one handed typing instructions: http://www.aboutonehandtyping.com/manualcompare.html. Does this really work?
What do the one handed coders out there use?
If you're a two-hand touch typist, the answer is a "mirrored" layout.
Mirroring lets you begin touch-typing with one hand almost immediately. Pretty crazy how easy it is. Based on the muscle memory you already have.
If you're typing with your right hand:
Type all right-hand keys normally.
Don't type left hand keys. Instead type the same motion (but mirrored) with your right hand.
So if you want to type:
"D" -> type "K" instead.
"W" -> type "O" instead.
"S" -> type "L" instead.
Same row of keyboard, same finger, same motion. Your muscle memory can already do this... kind of like how you're unable to pat your head and rub your belly at the same time. The wires in your brain are crossing somewhere.
Software to mirror the keyboard as described above:
Hold Spacebar to mirror:
Linux - MirrorBoard
Mac - Mirror-QWERTY
Windows - AutoHotkey version of Half-QWERTY Half-Keyboard
Predictive Text; Automatic Mirroring
Mac - One-Hand Keyboard
Windows - One-Hand Keyboard
Regarding one-handed keyboards, I've tried using a frogpad and found it ok for typing text, but unusable for coding. The symbols require several consecutive key presses and I found it impossible to use shortcuts reliably. It was too easy to hit the wrong key and get it stuck in the wrong mode.
Nobody has mentioned ENTI-key aka Coffee++ Layout yet? It is exactly designed for programming with one hand (left). And unlike qwerty, it is even optimized for speed and ergonomics. I used it some years ago for a short while and I don't know if it still works on newer systems. I think I used it for writing CSS: Typing the words with left, typing all those numbers on the numpad with right.
I can not recommend pen+handwriting. I usually use a tablet PC and handwriting code is terrible. I tried it on Windows 8 and Linux with Cellwriter, and both are not bad programs, but I still switch to onscreen keyboard whenever I can. But maybe the problem is my scratchy writing :)
I also can tell from experience that learning a new layout is not as complicated as it sounds. Especially if the layout is more logical than qwerty. I use Neo Layout since 10 years and getting the hang of it went smoothly, I was able to write a blog article after an evening of training.
"But what if you have to use qwerty on another PC?" This, also, is no problem, really. My simple trick is to never look at the keyboard when using Neo, but glimpse at it when qwerty-ing.
Good luck to anyone who wants to or has to use one hand for typing!
Now, the time to heal a broken finger will be shorter than it takes to adapt to one handed coding, not to mention the time it takes afterwards to get back to two-handed coding
Also, the time it takes to learn the methods is time you could've spend on coding (read: making a living).
Knowing this, we need a quick-fix, short term solution.
First of all, A good IDE, with code completion and similar functionality will help you a lot.
Secondly, use the shortcuts of the IDE, remember, there are Shift, Altand Ctrl keys on both sides of your keyboard.
(you might want to create a cheatsheet for those shortcuts)
In addition to helping you during your time with your injury, learning the shortcuts will also improve your coding speed when you're back up again.
Now, my comments on your proposals:
Don't, simply, Don't, it'll take even more time to fix writos (typos) beacause recognition will be flaky.
That learing curve will slow you down even more.
Won't even comment on that one...
Mirrorboard
A friend of mine broke his wrist snowboarding, and he had reasonable luck using speech recognition software (Nuance Dragon Naturally Speaking). It worked quite well for email and documentation, which would solve a part of your problem.
Another colleague, Nils Klarlund of AT&T, developed a version of emacs hooked into speech recognition. He even had a home-brewed set of foot pedals for doing shift, control, etc. He used this exclusively for years (due to bad carpal tunnel syndrome).
And maybe your feet can take up some of the burden. This is part of a parallel discussion going on in this question.
And off-topic, but extremely interesting, T.V. Raman, who's been blind since the age of 14, wrote a version of emacs that works with keyboard input and audio output. There's a chapter on it in Beautiful Code. I've seen him use it, and it's completely awesome. And of course emacs is a great interface for more than just text editing.
If you anticipate that your left hand will be out of commission for a long while, and if it's worthwhile for you to learn a new layout, then there exist one-handed Dvorak layouts.
There's some information at PC Guide: Single-Handed Dvorak Alphanumeric Layouts.
There also once was software for Qwerty Half Keyboards that used the space bar as an extra shift key that reversed the keyboard.
Good luck with your injury!
We have a developer in the office that lost mobility in his right hand and probably won't gain back full use of it. He has mainly learned to type well with his left hand and kind of fill in for his right hand. Although he lets his right hand kind of peck for things. He has gained enough speed back for it not to affect his day too greatly from what i can tell.
Only thing i can think of that might let you speed up some while typing with one hand and maybe being able to get a key or two with the other hand might be to use an IDE instead of text editor if you already don't, so you can use tab completion. Kind of a lame solution if you don't like IDEs or just don't have that option in your work environment but might help out a bit.
The same thing happened to me (I destroyed my left pinky). At the time, I didn't touch type, so my only use for my pinky was left-control, left-shift, and caps-lock.
This sounds as if it just happened to you. I promise you'll quickly learn to compensate. Remember, it's quality, not speed, that counts most.
Perhaps you should seize the opportunity and read to improve yourself as a programmer. Or spend some time debugging.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
Pretty much every other editor that isn't a vi descendant (vim, cream, vi-emu) seems to use the emacs shortcuts (ctrl+w to delete back a word and so on)
Early software was often modal, but usability took a turn at some point, away from this style.
VI-based editors are total enigmas -- they're the only real surviving members of that order of software.
Modes are a no-no in usability and interaction design because we humans are fickle mammals who cannot be trusted to remember what mode the application is in.
If you think you are in one "mode" when you are actually in another, then all sorts of badness can ensue. What you believe to be a series of harmless keystrokes can (in the wrong mode) cause unlimited catastrophe. This is known as a "mode error".
To learn more, search for the term "modeless" (and "usability")
As mentioned in the comments below, a Modal interface in the hands of an experienced and non-fickle person can be extremely efficient.
Um... maybe there isn't much of a need for one, given that Vi/Vim is pretty much available everywhere and got the whole modal thing right? :)
I think that it's because vi (and its ilk) already occupies the ecological niche of modal editors.
The number of people who prefer modal and haven't yet been attracted to vi is probably 0, so the hypothetical vi competitor would have to be so great as to make a significant number of vi users switch. This isn't likely. The cost of switching editors is huge and the vi-s are probably already as good as modal editors go. Well, maybe a significant breakthrough could improve upon them, but I find this unlikely.
#Leon: Great answer.
#dbr: Modal editing is something that takes a while to get used to. If you were to build a new editor that fits this paradigm, how would you improve on VI/VIM/Emacs? I think that is, in part, an answer to the question. Getting it "right" is hard enough, competing agains the likes of VI/VIM/Emacs would be extremely tough -- most people who use these editors are "die hard" fans, and you'd have to give them a compelling reason to move to another editor. Those people who don't use them already are most likely going to stay in a non-modal editor. IMHO of course ;)
Modal editors have the huge advantage to touch typists that you can navigate around the screen without taking your hands off the home row. My wrists only hurt when I'm doing stuff that requires me to move my hand off the keyboard and onto the mouse or arrow keys and back constantly.
Remember that Notepad is a modal editor!
To see this, try typing E, D, I, T; now try typing Alt, E, D, I, T. In the second case the Alt key activates the "menu mode" so the results are different. :oP People seem to cope with that.
(Yes, this is a feature of Windows rather than specifically of Notepad. I think it's a bad feature because it is easy to hit Alt by mistake and I don't think you can turn it off.)
VIM and emacs make about as much user interface design sense as qwerty. We now have available modern computer optimized key layouts (see the colemak layout and the carpalx project); it's only a matter of time before someone does the same for text editors.
I believe Eclipse has Vi bindings and there is a Visual Studio plugin/extension, too (which is called Vi-Emu, or something).
It's worth noting that the vi input models survival is in part due it's adoption in the POSIX standard, so investing time in learning would mean your guarenteed to be able to work on any system complying to these standards. So, like English, theres power in ubiquity.
As far as alternatives go, I doubt an alternate model editor would survive a 30 day free trial period, so its the same reason more people drive automatics than fly jets.
Since this is a question already at odds with the "no subjective issues" mantra, allow me to face that head on in kind.
Non-Modal editing seeks to solve the problem caused by non-modal editing in the first place.
Simply put, with Modal editing I can do nearly everything without my hands leaving the keyboard, and without even tormenting my pinky with reaching for the control, or interrupting my finger placement by hunting for the arrow keys.
Reaching for mouse completely interrupts the train of thought. I have hated the intense reliance upon this with Intellij IDEA and Netbeans for many years. Even with vim-style addons.
Most of what you do has to do with fine-tuning with very small increments and changes within the same paragraph of code. Move up, move over, change character, etc., etc. These things are interrupted with control keys and arrows and mouse.
Though not really answering your question, there used to be a "modal like" way to write Japanese on cell phones before :
The first letter you hit was a conson let's say K, and then, and then the next key you would hit would have the role of a conson. (Having two conson in a row is impossible in Japanese)
Though it was main a few years ago, today it's only used by people who really want to hit fast.
I think the answer to the question is actually there are quite a few modal text editors that aren't forks of vi/vim. However they all use the vi key bindings. Vi users get the key bindings into their muscle memory so relearning a different set of key bindings would be really hard, so no-one would create a different set of key bindings.
But lots of different editors have re-implemented the vi key bindings from scratch. Just look at this question about IDEs with vi key bindings. At least half of the answers are editors built from scratch that implement vi key bindings, not versions of vi embedded.
I recently came across divascheme - an alternative set of key bindings for DrScheme. This is modal, and part of the justification is to do with RSI - specifically avoiding lots of wrist twisting to hit Ctrl-Alt-Shift-something. The coder has done an informal survey of fellow coders and found that emacs users suffered from more wrist pain than vi coders.
You can see him doing a short talk at LugRadio Live USA. (The video is a series of 5 minute talks and I can't remember how far through it is, sorry - if someone watches it and posts that here I'll edit this post to say when in the video it is).
Note I have not used divascheme.
The invention of the mouse took one mode and moved it to an input device, and context menus took another mode and moved it to a button. Ironically, the advent of touch devices has had the reverse effect, producing multi-modal interfaces:
aware multi-modal - touch and speech are aware of each other and intersect
unaware multi-modal - touch and speech are unaware of each other and conflict
The traditional WIMP interfaces have the basic premise that the information can flow in and out of the system through a single channel or an event stream. This event stream can be in the form of input (mouse, keyboard etc) where the user enters data to the system and expects feedback in the form of output (voice, vibration, visual, etc) when the system responds. But the channel maintains its singularity and can process information one source at a time. For example, in today’s interaction, the computer ignores typed information (through a keyboard) when a mouse button is depressed.
This is very much different from a multimodal interaction where the system has multiple event streams and channels and can process information coming through various input modes acting in parallel, such as those described above. For example, in an IVR system a user can either type or speak to navigate through the menu.
References
User Agent Accessibility Guidelines working group (UAWG): Keyboard Interface use cases
W3C Multimodal Standard Brings Web to More People, More Ways
Next steps for W3C work on Multimodal Standards
The Future of Interaction is Multimodal
Beyond Mouse and Keyboard: Expanding Design Considerations for Information Visualization Interactions - naturalinfovis_infovis2012.pdf
Setting the scope for light-weight Web-based applications
Jan. 26, 1983: Spreadsheet as Easy as 1-2-3
Multi-modal design: Gesture, Touch and Mobile devices...next big thing? | Experience Dynamics