Even the original article did not stick to one topic. It started out talking about digital recording systems, like the one being used to edit already-recorded tracks offline while on an airplane. Then it suddenly started talking about Berklee students purchasing Reason, a synthesis and control package which is designed to be played in realtime like an instrument. One has almost nothing in common with the other. It's no surprise that the ensuing comments here are lacking in focus, and I pity the novice trying to make sense of it all!
I actually have done the reverse before, with a fair degree of success. My little hack "xmidiqwerty" takes incoming MIDI messages from a piano-style keyboard and translates them into X11 keypress pseudo-events (which work with the majority of X11 software, although "xev" can tell the difference between them and your real keyboard). Making chorded mappings for such a system is rather easy, and the hardware supports it without breaking a sweat.
As a model M enthusiast (I have five or six of them at this point, and am posting from one now), I can definitely say that I type at least half again as fast on one of them than on a membrane keyboard.
Unfortunately, no it's not. Conventional keyboards, even high quality ones like the classic IBM model M, use scanning hardware that can only recognize a limited number of simultaneous keypresses, and only in certain combinations. This has frequently been an issue for me, as I often use (and have written, for what it's worth) software that maps a conventional keyboard into a music keyboard, and play musical chords on that.
Wow, I'm quite surprised that Matias went after you. Isn't the patent extremely shaky on the grounds that it's merely similarity of interface rather than implementation, just like any piece of software with a cloned UI?
I also was impressed by Matias' idea but disgusted by the ridiculous overpricing of their software implementation, so wrote my own. Granted, mine never made it to release stage, but I can definitely sympathize with the work you did.
For those using Linux, there's still the five line kernel patch which implements the half-keyboard concept for the console. (Just search for it if you're interested.) The simplicity of that patch further underlines the inappropriateness of Matias' pricing.
I haven't tried it myself, but it seems to me that you could compile the Freenet client down to native object code (not bytecode) using GCC's Java compiler, GCJ. You could do this on a larger machine which had room for the compiler, then copy the resulting native executable to your tiny headless box and run it without needing the large Java runtime.
You're going about this all wrong... the data in question doesn't need an email-based interface; the visualizations should be interactive, using Quake!:-)
Re:Two decades of VR Gloves, with nothing to show
on
Sign Language Out Loud
·
· Score: 2, Informative
Actually those old, originally inexpensive Power Gloves now fetch fairly high prices on the used market because they are in such high demand for projects like these, and there is no current off-the-shelf product at the same price point. I ended up having to build my own out of a bicycling glove, some accelerometers, and switches. You're right that they never caught on in the mass market, but they're great for academics and hobbyists.
Ah, the memories... I did a similar project in college, building a sensor glove which translated tonic sol-fa (music sign language) into MIDI using a Basic Stamp embedded processor. Worked rather well, actually.
The other half of my project was to do the same thing using video recognition, which is also mentioned in the linked article. I used the built-in camera of an SGI, and a nice fuzzy logic matching algorithm.
> I don't know of other plain-text formats, which to my mind is crucial.
What about the roff family? Text-based, non-SGML. You might know that nroff is used for man pages, but there is a related system called troff which is a full-featured print typesetter.
Not to put words in the poster's mouth, but the reason many people find NFS to be somewhat complex is that the protocol requires user and group ids to be synchronized between the client and the server. If you're talking about two Unix systems, this generally means running NIS, NIS+, or LDAP, each of which is more complex than a standalone/etc/passwd file. If you're talking about a Unix system and a Windows system, this requires an extra mapping facility such as PCNFS, since Windows does not provide compatible user and group ids (small integers) at all.
I should add that in addition to these basic mechanics of Halo's cooperative mode, many of the levels, weapons, and vehicles lend themselves very well to cooperative strategies.
I've spent quite a lot of time playing Halo in cooperative mode. You follow through the exact same campaign as the single player game, but there are two of you running around on the level. Between checkpoints, the two players can travel as far away from one another as they want. When one player reaches a checkpoint, the other is teleported to catch up with him.
If one player dies, then he regenerates standing next to the surviving one rather than at the previous checkpoint. (Very useful for the "I'll hang back while you play kamakaze" approach!) If the surviving player is in combat, the dead one doesn't regenerate immediately, so as to reduce the likelihood of both players being killed at once.
Halo also supports lots of fun team-based cooperation in its competitive multiplayer modes, but that's not what the original poster was asking about.
Hmm, remarkably few community theater folks have spoken up so far. I act, sing, music direct, and compose for theater, primarily with a small group called Theatre III.
I also spend a lot of time socializing feral cats as a volunteer at the Buddy Dog Humane Society.
Taken together, I guess that should explain my sig.:-)
Thanks for the convenient instructions! I recently bought an HP laptop, and the fact that it claimed to support both IEEE 1394 and USB 2.0 was a major factor in my decision to purchase it (going under the theory that laptops are difficult to upgrade internally, so high speed external busses are critical). I would be seriously peaved if it was not real USB-480, but fortunately it is. Whew!
There have been many, many "robot programming" games written for just about every platform. Some use their own mini languages, some use real world languages. Some, like Core Wars, are even portable and semi-standardized. As a category, these are definitely a great introduction to programming.
This is a bit of a departure from the original topic, but since you raised the point, I'll continue with it. If you want "xterm mousing" in a high quality, free terminal app on Windows, and you want a more native-feeling application than a cygwin port of rxvt, you might want to try PuTTY.
PuTTY is best known for its solid SSH capabilities, but it can also be used for telnet, rlogin, and raw TCP connections. It is not a truly generic terminal, since it cannot act as a display for arbitrary local programs, but that's very rarely an issue on Windows.
They're getting closer. A current generation mainstream laptop with a 15 inch SXGA+ (1400 x 1050 pixel) LCD has a resolution of 117 DPI. A slightly less mainstream but not prohibitively expensive 15 inch UXGA (1600 x 1200 pixel) LCD has a resolution of 133 DPI. Thanks, Pythagorus.
TNC sounds very academically interesting, but I can't find any info on it. It doesn't look like it ever became an RFC, for example. Can you provide any pointers?
Really, there's nothing wrong with simple password based authentication as long as it's not sent in the clear. Use SSL to encrypt the connection, then use htaccess to authenticate. Nothing fancy required.
For what it's worth, this kind of setup (auth by simple password, but over an encrypted connection) is the most common way to run SSH as well.
Kudos are definitely in order for Paul and the others working on Ardour. However, I'm not sure where people are getting the idea that ProTools is an unreachably expensive system. ProTools comes in multiple versions which have different levels of hardware acceleration. The more hardware acceleration, the more expensive the version.
ProTools Free runs purely in software, using off-the-rack, home sound cards, and is free (beer, not speech). Nobody uses it for real work, but it makes for an okay functional demo.
ProTools LE is targetted at home and small studios, and uses generic pro-level audio adapters. The software and hardware together come out in the $500 to $1000 range.
ProTools TDM is what the big studios use. It requires proprietary hardware with extensive use of onboard DSP and dedicated control surfaces. This is the one for which the hardware and software together fall in the $10000 to $15000 range.
The mid-level LE version is not a toy... many professional albums are made on it. It competes directly with the likes of MOTU Performer, Emagic Logic, Steinberg Cubase, and Cakewalk Sonar.
Turbovision was an old Borland library for DOS, with C and Pascal bindings, which addressed the niche you're looking for. There's supposedly a free port to Unix. I can't vouch for it personally, but check out this Freshmeat project page.
Yes indeed, a Polaroid is perfect for the task. The base models are very inexpensive, simple to use, and can handle more abuse than a delicate electronic device. They instantly develop a single shot at a time, so there's never any waste. The film cartridges are cheap and readily available.
Slashdot Mirror
See here (the source of the quote).
Of course, you know, you can record at double speed and do a non-pitch-preserving time stretch in digital too. :-)
Even the original article did not stick to one topic. It started out talking about digital recording systems, like the one being used to edit already-recorded tracks offline while on an airplane. Then it suddenly started talking about Berklee students purchasing Reason, a synthesis and control package which is designed to be played in realtime like an instrument. One has almost nothing in common with the other. It's no surprise that the ensuing comments here are lacking in focus, and I pity the novice trying to make sense of it all!
I actually have done the reverse before, with a fair degree of success. My little hack "xmidiqwerty" takes incoming MIDI messages from a piano-style keyboard and translates them into X11 keypress pseudo-events (which work with the majority of X11 software, although "xev" can tell the difference between them and your real keyboard). Making chorded mappings for such a system is rather easy, and the hardware supports it without breaking a sweat.
As a model M enthusiast (I have five or six of them at this point, and am posting from one now), I can definitely say that I type at least half again as fast on one of them than on a membrane keyboard.
Unfortunately, no it's not. Conventional keyboards, even high quality ones like the classic IBM model M, use scanning hardware that can only recognize a limited number of simultaneous keypresses, and only in certain combinations. This has frequently been an issue for me, as I often use (and have written, for what it's worth) software that maps a conventional keyboard into a music keyboard, and play musical chords on that.
Wow, I'm quite surprised that Matias went after you. Isn't the patent extremely shaky on the grounds that it's merely similarity of interface rather than implementation, just like any piece of software with a cloned UI?
I also was impressed by Matias' idea but disgusted by the ridiculous overpricing of their software implementation, so wrote my own. Granted, mine never made it to release stage, but I can definitely sympathize with the work you did.
For those using Linux, there's still the five line kernel patch which implements the half-keyboard concept for the console. (Just search for it if you're interested.) The simplicity of that patch further underlines the inappropriateness of Matias' pricing.
I haven't tried it myself, but it seems to me that you could compile the Freenet client down to native object code (not bytecode) using GCC's Java compiler, GCJ. You could do this on a larger machine which had room for the compiler, then copy the resulting native executable to your tiny headless box and run it without needing the large Java runtime.
You're going about this all wrong... the data in question doesn't need an email-based interface; the visualizations should be interactive, using Quake! :-)
Actually those old, originally inexpensive Power Gloves now fetch fairly high prices on the used market because they are in such high demand for projects like these, and there is no current off-the-shelf product at the same price point. I ended up having to build my own out of a bicycling glove, some accelerometers, and switches. You're right that they never caught on in the mass market, but they're great for academics and hobbyists.
Ah, the memories... I did a similar project in college, building a sensor glove which translated tonic sol-fa (music sign language) into MIDI using a Basic Stamp embedded processor. Worked rather well, actually.
The other half of my project was to do the same thing using video recognition, which is also mentioned in the linked article. I used the built-in camera of an SGI, and a nice fuzzy logic matching algorithm.
> I don't know of other plain-text formats, which to my mind is crucial.
What about the roff family? Text-based, non-SGML. You might know that nroff is used for man pages, but there is a related system called troff which is a full-featured print typesetter.
Not to put words in the poster's mouth, but the reason many people find NFS to be somewhat complex is that the protocol requires user and group ids to be synchronized between the client and the server. If you're talking about two Unix systems, this generally means running NIS, NIS+, or LDAP, each of which is more complex than a standalone /etc/passwd file. If you're talking about a Unix system and a Windows system, this requires an extra mapping facility such as PCNFS, since Windows does not provide compatible user and group ids (small integers) at all.
I should add that in addition to these basic mechanics of Halo's cooperative mode, many of the levels, weapons, and vehicles lend themselves very well to cooperative strategies.
I've spent quite a lot of time playing Halo in cooperative mode. You follow through the exact same campaign as the single player game, but there are two of you running around on the level. Between checkpoints, the two players can travel as far away from one another as they want. When one player reaches a checkpoint, the other is teleported to catch up with him.
If one player dies, then he regenerates standing next to the surviving one rather than at the previous checkpoint. (Very useful for the "I'll hang back while you play kamakaze" approach!) If the surviving player is in combat, the dead one doesn't regenerate immediately, so as to reduce the likelihood of both players being killed at once.
Halo also supports lots of fun team-based cooperation in its competitive multiplayer modes, but that's not what the original poster was asking about.
Hmm, remarkably few community theater folks have spoken up so far. I act, sing, music direct, and compose for theater, primarily with a small group called Theatre III.
I also spend a lot of time socializing feral cats as a volunteer at the Buddy Dog Humane Society.
Taken together, I guess that should explain my sig. :-)
Thanks for the convenient instructions! I recently bought an HP laptop, and the fact that it claimed to support both IEEE 1394 and USB 2.0 was a major factor in my decision to purchase it (going under the theory that laptops are difficult to upgrade internally, so high speed external busses are critical). I would be seriously peaved if it was not real USB-480, but fortunately it is. Whew!
There have been many, many "robot programming" games written for just about every platform. Some use their own mini languages, some use real world languages. Some, like Core Wars, are even portable and semi-standardized. As a category, these are definitely a great introduction to programming.
This is a bit of a departure from the original topic, but since you raised the point, I'll continue with it. If you want "xterm mousing" in a high quality, free terminal app on Windows, and you want a more native-feeling application than a cygwin port of rxvt, you might want to try PuTTY. PuTTY is best known for its solid SSH capabilities, but it can also be used for telnet, rlogin, and raw TCP connections. It is not a truly generic terminal, since it cannot act as a display for arbitrary local programs, but that's very rarely an issue on Windows.
They're getting closer. A current generation mainstream laptop with a 15 inch SXGA+ (1400 x 1050 pixel) LCD has a resolution of 117 DPI. A slightly less mainstream but not prohibitively expensive 15 inch UXGA (1600 x 1200 pixel) LCD has a resolution of 133 DPI. Thanks, Pythagorus.
TNC sounds very academically interesting, but I can't find any info on it. It doesn't look like it ever became an RFC, for example. Can you provide any pointers?
Really, there's nothing wrong with simple password based authentication as long as it's not sent in the clear. Use SSL to encrypt the connection, then use htaccess to authenticate. Nothing fancy required.
For what it's worth, this kind of setup (auth by simple password, but over an encrypted connection) is the most common way to run SSH as well.
Kudos are definitely in order for Paul and the others working on Ardour. However, I'm not sure where people are getting the idea that ProTools is an unreachably expensive system. ProTools comes in multiple versions which have different levels of hardware acceleration. The more hardware acceleration, the more expensive the version.
... many professional albums are made on it. It competes directly with the likes of MOTU Performer, Emagic Logic, Steinberg Cubase, and Cakewalk Sonar.
ProTools Free runs purely in software, using off-the-rack, home sound cards, and is free (beer, not speech). Nobody uses it for real work, but it makes for an okay functional demo.
ProTools LE is targetted at home and small studios, and uses generic pro-level audio adapters. The software and hardware together come out in the $500 to $1000 range.
ProTools TDM is what the big studios use. It requires proprietary hardware with extensive use of onboard DSP and dedicated control surfaces. This is the one for which the hardware and software together fall in the $10000 to $15000 range.
The mid-level LE version is not a toy
Turbovision was an old Borland library for DOS, with C and Pascal bindings, which addressed the niche you're looking for. There's supposedly a free port to Unix. I can't vouch for it personally, but check out this Freshmeat project page.
Yes indeed, a Polaroid is perfect for the task. The base models are very inexpensive, simple to use, and can handle more abuse than a delicate electronic device. They instantly develop a single shot at a time, so there's never any waste. The film cartridges are cheap and readily available.