VoiceCode looks pretty interesting. I haven't tried it yet, but it claims to knows enough about the language in which you are coding, and your existing code, to translate an utterance like "define method sort and arguments list" to def sort(self, list): (Python) and "compile symbols command set equals context sensitive command set without arguments" to command_set = CSCmdSet().
You say that MP3 playing slows it down. Any idea if that uses the DSP capabilities of the OMAP (which presumably would be more efficient than using vanilla ARM code)?
Re:Where are the Nigerian 419 spammers?
on
Real-time Spam Map
·
· Score: 2, Funny
Seen in Nigeria...
Subject: Ok, we admit it. It was all a scam. Sorry. IP address: 1.2.3.4 DNS Name: scammers.nigeria.com Location: Nigeria Emails: lots
My understanding (from seeing/hearing an In-Band-On-Channel demo a while back):
The receiver will use the digital portion of the signal whenever possible, but if there are problems decoding the digital it will fill in the gaps with audio from the traditional analog FM signal. The audio carried on the digital stream is several seconds ahead of the that on the analog signal, so that if you lose the digital going under a bridge, for example, you have a good chance of being able to fill in the gap a few seconds later when you're past it.
To answer others' questions about why anyone would care about this:
1. Most people will think it sound better simply because they know it's digital, even though regular analog FM generally sounds fine. 2. Radio stations can basically only increase market share by stealing listeners from other stations, and "digital sound" gives them this differentiator (until all stations adopt it).
Hmm, I remember reading a scifi novel in which one of the characters was always tattooing computer-generated images onto homeless people. Turned out that the image data actually a core-dump of an AI, and she was doing a sort of "distributed backup" from which the AI was later reconstructed, by rounding up all the homeless and scanning their tats.
Like you, I can't stand JBuilder. Or Forte. I use Eclipse on a daily basis on my P3/1GHz/256MB/Win2k laptop and I'm happy with the features and performance. Unfortunately, I haven't been as pleased with the Linux versions.
IntelliJ looks quite nice but I can't spend the money.
You're wrong about the lack of R&D. There are substantial efforts and tens or hundreds of millions of dollars expended in an effort to address everybody's fears (in the US, at least) about driver distraction. Just google for driver distraction and visit the first page or so of links. GM and Ford have recently spent or committed tens of millions each on things like driving simulators, university research projects, etc.
Some points off the top of my head:
Many manufacturer and customers outside the US simply feel that it's primarily the driver's responsibility to use a visual/manual (screen/buttons/knobs) system safely. It's up to you to wait until it's safe (i.e. you're not driving on a busy highway) before you spend 5 minutes typing in an address. The more cautious systems lock out any potentially dangerous feature while the vehicle is in motion.
The use of audio-only interfaces is not a panacea. The issue is not just "hands on the wheel, eyes on the road" but also "mind on the task of driving."
There are some tasks that are difficult of impossible to do via a speech interface, like selecting an item from a large list of candidates. Judicious use of a display may save substantial time and frustration for the driver.
Your ideal interface sounds great, but it's damn near impossible, perhaps at any cost, in a noisy vehicle. Excellent speech recognition has been "just around the corner" for several decades; we're still waiting. Practical systems must dramatically reduce the dialog scope, typically to a more rigid command-and-control format, to increase robustness.
Perhaps "deeply intervleaved" is more accurate. As I understand it, the information required for any one sample in the audio stream is spread out over many seconds of the received data, with some redundancy. Short dropouts in the received data will still allow complete reconstruction, or perhaps inoffensive degradation, of the audio. Longer dropouts will cause the audio to mute.
Some Carnegie Mellon University folks conducted this experiment (PDF format). A continuously-operating Bluetooth link in close proximity to an 802.11 link caused a few percent 802.11 packet loss, and sometimes caused the 802.11 link to fallback to lower data rates. This is even with one of the 802.11 nodes right between the BT nodes, which were 6 feet apart. Sounds tolerable to me...
Slashdot Mirror
VoiceCode looks pretty interesting. I haven't tried it yet, but it claims to knows enough about the language in which you are coding, and your existing code, to translate an utterance like "define method sort and arguments list" to def sort(self, list): (Python) and "compile symbols command set equals context sensitive command set without arguments" to command_set = CSCmdSet().
Demo videos here.
I don't have a Windows key, you insensitive clod! :)
(IBM Model M)
You say that MP3 playing slows it down. Any idea if that uses the DSP capabilities of the OMAP (which presumably would be more efficient than using vanilla ARM code)?
Subject: Ok, we admit it. It was all a scam. Sorry.
IP address: 1.2.3.4
DNS Name: scammers.nigeria.com
Location: Nigeria
Emails: lots
My understanding (from seeing/hearing an In-Band-On-Channel demo a while back):
The receiver will use the digital portion of the signal whenever possible, but if there are problems decoding the digital it will fill in the gaps with audio from the traditional analog FM signal. The audio carried on the digital stream is several seconds ahead of the that on the analog signal, so that if you lose the digital going under a bridge, for example, you have a good chance of being able to fill in the gap a few seconds later when you're past it.
To answer others' questions about why anyone would care about this:
1. Most people will think it sound better simply because they know it's digital, even though regular analog FM generally sounds fine.
2. Radio stations can basically only increase market share by stealing listeners from other stations, and "digital sound" gives them this differentiator (until all stations adopt it).
I, for one, welcome our new search engine overlords!
Apparently, it's out there, but getting it to work sounds even more painful than regular MPlayer... :)
I forget the title, though... anyone?
Like you, I can't stand JBuilder. Or Forte. I use Eclipse on a daily basis on my P3/1GHz/256MB/Win2k laptop and I'm happy with the features and performance. Unfortunately, I haven't been as pleased with the Linux versions.
IntelliJ looks quite nice but I can't spend the money.
Some points off the top of my head:
- Many manufacturer and customers outside the US simply feel that it's primarily the driver's responsibility to use a visual/manual (screen/buttons/knobs) system safely. It's up to you to wait until it's safe (i.e. you're not driving on a busy highway) before you spend 5 minutes typing in an address. The more cautious systems lock out any potentially dangerous feature while the vehicle is in motion.
- The use of audio-only interfaces is not a panacea. The issue is not just "hands on the wheel, eyes on the road" but also "mind on the task of driving."
- There are some tasks that are difficult of impossible to do via a speech interface, like selecting an item from a large list of candidates. Judicious use of a display may save substantial time and frustration for the driver.
- Your ideal interface sounds great, but it's damn near impossible, perhaps at any cost, in a noisy vehicle. Excellent speech recognition has been "just around the corner" for several decades; we're still waiting. Practical systems must dramatically reduce the dialog scope, typically to a more rigid command-and-control format, to increase robustness.
Disclaimer: I work for a US automaker.Maybe MS is targeting FreeBSD (and only FreeBSD) because it still powers Hotmail?
Perhaps "deeply intervleaved" is more accurate. As I understand it, the information required for any one sample in the audio stream is spread out over many seconds of the received data, with some redundancy. Short dropouts in the received data will still allow complete reconstruction, or perhaps inoffensive degradation, of the audio. Longer dropouts will cause the audio to mute.
Some Carnegie Mellon University folks conducted this experiment (PDF format). A continuously-operating Bluetooth link in close proximity to an 802.11 link caused a few percent 802.11 packet loss, and sometimes caused the 802.11 link to fallback to lower data rates. This is even with one of the 802.11 nodes right between the BT nodes, which were 6 feet apart. Sounds tolerable to me...