Touchscreens which can distinguish multiple simulataneous touches are highly sought after for building interfaces to music software. Using a conventional touchscreen for music is like telling a pianist he's only allowed to press one key at a time.
The only product on the market which does this right now is called the Lemur, and its price is out of range for many musicians. Apple's ability to target products at the mass-market bodes very well here.
I see great potential for interfaces which make use of whispered speech recognition (referred to in some papers as "non-audible murmurs"). Using a contact microphone that picks up vibrations transmitted through your jawbone rather than ones travelling through the air, you can have effective speech recognition without speaking out loud. This eliminates the problem of annoying your coworkers with loud dictation in a shared office, allows passwords to actually remain secret, and has even been documented to work well in environments full of background noise.
I see this as the perfect complement to tablet-based computers... add a bluetooth-based contact microphone to a keyboardless, touchscreen-based PC, and you finally have a computer suitable for word processing on the subway. The touchscreen means that you can use a stylus for navigation and widget manipulation, allowing the speech recognition software to be dedicated to text entry; this avoids the awkwardness of switching between command/control and continuous recognition modes.
A related benefit of whisper recognition is that it is algorithmically simple to differentiate between whispered speech and conventional vocalisations. As such, there would be no need for an additional interface to tell the computer that you are talking to it, versus pausing to speak to the person sitting next to you.
Searching around, I've only found a few papers on the subject of whisper recognition interfaces, and neither free nor commercial software which implements it. Why isn't this a hot topic, or am I just searching under the wrong name?
It's short-sighted to think of this solely as a gaming device. If it's hooked up to a computer, then it can be a user interface device for use with any piece of software. To me, a large touchscreen which can distinguish amongst multiple simultaneous touches is begging to be used for controlling software synthesizers. That's the market on which the very similar Lemur product focusses.
Something I've wondered about... occasionally you see a "making of" video where the documentary camera is running at the same time as the real camera. It's seeing things from a different angle, but it's pointed at the same scene under the same lighting. What is it about the process that makes the colors of the real film so much more saturated than the documentary?
You obviously didn't pay attention to the previous poster. He said qwerty was designed for a pre-1900 bucket layout typewriter and would still cause jams on a post-1900 typewriter like the Underwood you mentioned.
I'm not sure quite what the difference is between the "bucket" and the "arc"; maybe "bucket" is not a standard term for this concept, since it's not giving any useful Google hits. The Underwood I used (dating from right around 1900, and looking a lot like the one pictured here) had the strike bars arranged in an arc. I'm not sure whether the shape of the arc was a segment of a circle or some other curve. Either way, it was definitely prone to sticking.
Try "a within 5 b" or "a beforewithin 5 b" using an AltaVista advanced/boolean search.
Google is not a good choice of search engine if you want to specify your query using precision operators. Maybe someday they'll decide that the small number of users who want and know how to use such a feature are worth the large amount of effort to develop and support it, but it's unlikely.
(And yes, I'm both a former AltaVista developer and a Lexis/Nexis user.)
I learned to type on a traditional, mechanical Underwood typewriter with a QWERTY keyboard, and you know what? The bars got jammed all the time. Every time I hear this justification of QWERTY's design, I stop and wonder: if they were going to sacrifice a quick learning curve and (arguably) a faster typing speed just to prevent jams, couldn't they at least have done a better job?
Sibelius provides a GUI-based interface for complex music notation. Lilypond provides a non-GUI-based interface for similarly complex music notation. Different users respond better to different types of interfaces. That shouldn't imply any sort of value judgement.
(That said, I find Lilypond's syntax awkward and its list of dependencies excessive, but those issues have nothing to do with its level of power and sophistication when it comes to notation.)
Mind boggling. When was the last time any of you people have actually tried a Linux distro? Pretty much every recent desktop-oriented distribution has placed a high priority on getting really high quality font support.
They use the font engine Freetype to do the rendering, which uses a non-hint-based (and thus non-patent-infringing) algorithm to acheive much better antialiasing than is possible in even the most recent versions of Windows; it is reasonably equivalent to the quality in MacOS X.
They also configure all the modern apps with which they ship (Gnome, KDE, Mozilla, OpenOffice, etc.) to default to using good vector fonts, to make the most of Freetype's rendering abilities. Only the ancient Athena and Motif based tools which are included for backwards compatibility (xterm, xcalc, etc) are forced to use the outdated bitmap fonts, and these apps always come with proper, modern alternatives.
What year do you think this is, 1997?
P.S. The page linked to by the parent poster clearly explains the Freetype2 Autohinter, which is what produces such nice results without running afoul of patents.
Actually, if you really do want to have voice recognition to go along with your TTS, you can get that as an embedded hardware solution as well. I've not used these products myself, only read about them online, but supposedly they're already in use for applications like automotive GPS systems.
Kidding aside (since speaking in beeps is not a serious option for most people), a non-visual wearable computer has a lot of potential. It's not the point of the original poster's question, but it would be a neat project on its own. Text-to-speech (TTS) output through an unintrusive, inexpensive earbud; menu-style input from a small, similarly inexpensive, belt-mounted keypad. In fact, now that reasonable embedded TTS solutions are available, you could do the whole thing on the cheap, using a microcontroller. After that, it just becomes an exercise in interface design, since audio output is strictly one-dimentional, unlike a visual interface which lets you see multiple things at once.
Syntactic minimalism without sacrificing semantic richness. Examples would include the Lisp and Forth families. Anyone know of any others in the same spirit?
It's impressive how you can make so many mistakes in a single post. Scheme and Lisp are not functional languages and can well be programmed in an imperative or procedural style. QBasic, as distinct from Basic, makes little to no use of the GOTO construct, and is quite similar to Pascal in its use of functions and procedures. (Pascal, since it's not on your list, is in turn quite similar to C, but is much more often used as a teaching language.) While there may be other reasons to avoid PHP, its use is certainly not limited to web services, and it can run in a standalone interpreter just like your top choice, Python.
As it happens, I'm just getting started with AVRs myself (the ATmega8535), and am in the process of purchasing equipment. What is the inexpensive, parallel-port-based programmer of choice for users here? Someone recommended to buy one off Ebay instead of building your own, but the only ones there are from Bulgaria, and heaven knows if the company is reputable.
I built a theremin which never worked particularly well. Anybody who's reading this thread and feels like making their own should be forewarned: steer clear of any design based around inductors. They're far less stable and reliable than capacitors, and are harder to find in the right sizes.
As a kid, I built a few original instruments including my favorite, the "squeakaphone", which was a continuous-pitch, double-reed wind instrument. Based around the same concept as making a balloon squeak while letting the air escape, the squeakaphone used only the neck of a balloon stretched around a frame which you would blow through.
These days, my constructions tend to be MIDI-based. I've built a few controllers in hardware, such a sensor glove that recognizes tonic sol-fa hand signals. I've also built plenty of software-based MIDI controllers and translators, as well as realtime controllable software noisemakers (synths, samplers, etc).
After I already wrote a wordy response, it struck me that i_r_sensitive was missing a fundamental point. You're not supposed to read or write MusicXML directly. Of course no musician is going to stick a page of XML printout on his music stand! While it's theoretically possible to do such things, the intended mechanism is to use some GUI software for editing, then emit a conventional CMN printout or onscreen graphic when you're done.
"Music written on the staff", sometimes referred to as Common Music Notation (CMN*), is spacially sensitive in two dimensions and uses a set of symbols for which there is no single unambiguous ASCII representation. As such CMN itself cannot be considered a computer language or file format. To say that there's no need for a new notation file format because CMN already fills that niche is thus mistaken.
It would be valid to recommend using graphical image files containing pictures of CMN as a music notation file format. While this is perfectly useful for purposes of saving and transmitting notation data, it does make loading notation data into an editable data model an extremely difficult task, because Music Character Recognition (MCR, similar to OCR) would be required each and every time. MCR is not only computationally expensive, but is also a very young, imperfect technology, which is far from reliable.
Part of the reason why MCR is so difficult is that despite its long history, or maybe because of it, CMN is *not* a "robust, well designed language". It is an ambiguous, self-contradictory language which requires a huge amount of knowledge beyond what is printed on the page in order to correctly interpret the data. In a way, it is a lossy compression format similar to wavelet compression of graphics; a large database of extra information is needed for decompression.
As far as MIDI is concerned, there is indeed enough information in a Standard MIDI File (SMF) to notate many types of music. However, there is not enough information to convert reliably into CMN (as other posters have already described). Instead, MIDI is commonly notated in the form of a piano roll, or as a textual event list. While these are real and valid forms of music notation, most musicians cannot or will not read them. If your audience insists on CMN, then you need to give them CMN.
In any event, it might help to restate the problem more explicitly: MusicXML attempts to provide an easily loaded, lossless computer file format for an abstract representation (data model) of a piece of music optimized for editing and sufficient for converting into CMN. How well it meets these goals has yet to be seen.
* Note that the term "CMN" here should not be confused with the Lisp-based music notation language of the same name; I'm speaking solely of the typeset output.
If higher resolution screens became common, third party developers whose current apps don't scale well would find themselves compelled to fix them. Since we're talking about OS/X here, there's certainly enough precedent of Apple exerting pressure on third party developers to deal with a lack of backwards compatibility.
And yes, I do run pro audio software on a higher resolution laptop (15 inch diagonal, 1400 horizontal pixels), and have personally experienced the problems you describe when attempting to set the system's concept of DPI to match the actual one. But that wasn't on a more-or-less legacy free, new OS with pervasive support for applying vector transforms to bitmap images (i.e., Quartz).
The reason why so many people get confused by this is that the vendors are constantly trying to blur the line between different classes of software. Try to name a current product in each of the following distinct categories that doesn't cross the line into at least one of the others:
music typesetter
linear MIDI sequencer
pattern-based MIDI sequencer
tracker
stereo sample recorder / editor
non-realtime multitrack sample compositor
realtime audio sequencer or DAW
sample loop sequencer
software synthesizer
Convergence in not inherently good nor bad, but it helps to know what are the core strengths of any given program and what has been bolted on to the side.
Err, music notation programs are pretty much the textbook example of why the presence of a GUI does not automatically make a tool user friendly. Designing an interface for music notation is an extremely difficult task, and there are both good and bad GUIs, good and bad CLIs. Finale's unintuitive, overly modal GUI is one of the main reasons why they've lost so much market share to the newer competitor Sibelius.
While it's pretty unambiguous that a sequencer will usually do a better job of sequencing than will a notation program, and vice versa, it's wrong to say that the task of "composition" is more suited to one or the other. Different people compose in different ways. Some record their live improvisations and edit from there, so a sequencer may be a more appropriate interface for them. Some people construct a composition in a mathematical heirarchy, so a music programming language may be their interface of choice. Others create music by turning knobs on an algorithmic composition system; even there, their editorial input amounts to the act of composing. Notation programs certainly do not have a monopoly on interfaces for composing.
I've never understood this surprisingly popular opinion. Nobody complains that printers have too high resolution. Why do they look at high resolution in a monitor as a bad thing?
Scalable fonts and vector graphics (both of which are used pervasively in OS/X) work even better at higher resolutions than they do at low ones. In other words, when you have more pixels per inch, you don't have to keep drawing your fonts at 13 pixels tall, making them too tiny to see. Instead, draw them at the same 12 point (1/6 of an inch) tall, but with more detail.
To answer your question, a 12 inch diagonal, 1200 dpi screen would be sheer bliss for me, and far preferable to something larger but with lower resolution.
Slashdot Mirror
The only product on the market which does this right now is called the Lemur, and its price is out of range for many musicians. Apple's ability to target products at the mass-market bodes very well here.
I see great potential for interfaces which make use of whispered speech recognition (referred to in some papers as "non-audible murmurs"). Using a contact microphone that picks up vibrations transmitted through your jawbone rather than ones travelling through the air, you can have effective speech recognition without speaking out loud. This eliminates the problem of annoying your coworkers with loud dictation in a shared office, allows passwords to actually remain secret, and has even been documented to work well in environments full of background noise.
I see this as the perfect complement to tablet-based computers... add a bluetooth-based contact microphone to a keyboardless, touchscreen-based PC, and you finally have a computer suitable for word processing on the subway. The touchscreen means that you can use a stylus for navigation and widget manipulation, allowing the speech recognition software to be dedicated to text entry; this avoids the awkwardness of switching between command/control and continuous recognition modes.
A related benefit of whisper recognition is that it is algorithmically simple to differentiate between whispered speech and conventional vocalisations. As such, there would be no need for an additional interface to tell the computer that you are talking to it, versus pausing to speak to the person sitting next to you.
Searching around, I've only found a few papers on the subject of whisper recognition interfaces, and neither free nor commercial software which implements it. Why isn't this a hot topic, or am I just searching under the wrong name?
It's short-sighted to think of this solely as a gaming device. If it's hooked up to a computer, then it can be a user interface device for use with any piece of software. To me, a large touchscreen which can distinguish amongst multiple simultaneous touches is begging to be used for controlling software synthesizers. That's the market on which the very similar Lemur product focusses.
Something I've wondered about... occasionally you see a "making of" video where the documentary camera is running at the same time as the real camera. It's seeing things from a different angle, but it's pointed at the same scene under the same lighting. What is it about the process that makes the colors of the real film so much more saturated than the documentary?
Blech, Slashdot ate my less-than sign, even though I told it to use "Plain Old Text" posting mode. The upload example should read:
plink username@hostname "cat > remote-filename" < local-filename
Not relevant to the original poster's question, but if you need to download larger files than pscp supports, why not try the following:
:-)
plink username@hostname cat remote-filename > local-filename
For upload, use this instead:
plink username@hostname "cat > remote-filename" local-filename
Who needs a dedicated file transfer protocol?
(plink is the PuTTY package's equivalent of the standard command line SSH client, with no GUI nor terminal emulation)
You obviously didn't pay attention to the previous poster. He said qwerty was designed for a pre-1900 bucket layout typewriter and would still cause jams on a post-1900 typewriter like the Underwood you mentioned.
I'm not sure quite what the difference is between the "bucket" and the "arc"; maybe "bucket" is not a standard term for this concept, since it's not giving any useful Google hits. The Underwood I used (dating from right around 1900, and looking a lot like the one pictured here) had the strike bars arranged in an arc. I'm not sure whether the shape of the arc was a segment of a circle or some other curve. Either way, it was definitely prone to sticking.
Try "a within 5 b" or "a beforewithin 5 b" using an AltaVista advanced/boolean search.
Google is not a good choice of search engine if you want to specify your query using precision operators. Maybe someday they'll decide that the small number of users who want and know how to use such a feature are worth the large amount of effort to develop and support it, but it's unlikely.
(And yes, I'm both a former AltaVista developer and a Lexis/Nexis user.)
I learned to type on a traditional, mechanical Underwood typewriter with a QWERTY keyboard, and you know what? The bars got jammed all the time. Every time I hear this justification of QWERTY's design, I stop and wonder: if they were going to sacrifice a quick learning curve and (arguably) a faster typing speed just to prevent jams, couldn't they at least have done a better job?
Sibelius provides a GUI-based interface for complex music notation. Lilypond provides a non-GUI-based interface for similarly complex music notation. Different users respond better to different types of interfaces. That shouldn't imply any sort of value judgement.
(That said, I find Lilypond's syntax awkward and its list of dependencies excessive, but those issues have nothing to do with its level of power and sophistication when it comes to notation.)
Mind boggling. When was the last time any of you people have actually tried a Linux distro? Pretty much every recent desktop-oriented distribution has placed a high priority on getting really high quality font support.
They use the font engine Freetype to do the rendering, which uses a non-hint-based (and thus non-patent-infringing) algorithm to acheive much better antialiasing than is possible in even the most recent versions of Windows; it is reasonably equivalent to the quality in MacOS X.
They also configure all the modern apps with which they ship (Gnome, KDE, Mozilla, OpenOffice, etc.) to default to using good vector fonts, to make the most of Freetype's rendering abilities. Only the ancient Athena and Motif based tools which are included for backwards compatibility (xterm, xcalc, etc) are forced to use the outdated bitmap fonts, and these apps always come with proper, modern alternatives.
What year do you think this is, 1997?
P.S. The page linked to by the parent poster clearly explains the Freetype2 Autohinter, which is what produces such nice results without running afoul of patents.
Actually, if you really do want to have voice recognition to go along with your TTS, you can get that as an embedded hardware solution as well. I've not used these products myself, only read about them online, but supposedly they're already in use for applications like automotive GPS systems.
Kidding aside (since speaking in beeps is not a serious option for most people), a non-visual wearable computer has a lot of potential. It's not the point of the original poster's question, but it would be a neat project on its own. Text-to-speech (TTS) output through an unintrusive, inexpensive earbud; menu-style input from a small, similarly inexpensive, belt-mounted keypad. In fact, now that reasonable embedded TTS solutions are available, you could do the whole thing on the cheap, using a microcontroller. After that, it just becomes an exercise in interface design, since audio output is strictly one-dimentional, unlike a visual interface which lets you see multiple things at once.
Syntactic minimalism without sacrificing semantic richness.
Examples would include the Lisp and Forth families.
Anyone know of any others in the same spirit?
It's impressive how you can make so many mistakes in a single post. Scheme and Lisp are not functional languages and can well be programmed in an imperative or procedural style. QBasic, as distinct from Basic, makes little to no use of the GOTO construct, and is quite similar to Pascal in its use of functions and procedures. (Pascal, since it's not on your list, is in turn quite similar to C, but is much more often used as a teaching language.) While there may be other reasons to avoid PHP, its use is certainly not limited to web services, and it can run in a standalone interpreter just like your top choice, Python.
As it happens, I'm just getting started with AVRs myself (the ATmega8535), and am in the process of purchasing equipment. What is the inexpensive, parallel-port-based programmer of choice for users here? Someone recommended to buy one off Ebay instead of building your own, but the only ones there are from Bulgaria, and heaven knows if the company is reputable.
I built a theremin which never worked particularly well. Anybody who's reading this thread and feels like making their own should be forewarned: steer clear of any design based around inductors. They're far less stable and reliable than capacitors, and are harder to find in the right sizes.
As a kid, I built a few original instruments including my favorite, the "squeakaphone", which was a continuous-pitch, double-reed wind instrument. Based around the same concept as making a balloon squeak while letting the air escape, the squeakaphone used only the neck of a balloon stretched around a frame which you would blow through.
These days, my constructions tend to be MIDI-based. I've built a few controllers in hardware, such a sensor glove that recognizes tonic sol-fa hand signals. I've also built plenty of software-based MIDI controllers and translators, as well as realtime controllable software noisemakers (synths, samplers, etc).
After I already wrote a wordy response, it struck me that i_r_sensitive was missing a fundamental point. You're not supposed to read or write MusicXML directly. Of course no musician is going to stick a page of XML printout on his music stand! While it's theoretically possible to do such things, the intended mechanism is to use some GUI software for editing, then emit a conventional CMN printout or onscreen graphic when you're done.
"Music written on the staff", sometimes referred to as Common Music Notation (CMN*), is spacially sensitive in two dimensions and uses a set of symbols for which there is no single unambiguous ASCII representation. As such CMN itself cannot be considered a computer language or file format. To say that there's no need for a new notation file format because CMN already fills that niche is thus mistaken.
It would be valid to recommend using graphical image files containing pictures of CMN as a music notation file format. While this is perfectly useful for purposes of saving and transmitting notation data, it does make loading notation data into an editable data model an extremely difficult task, because Music Character Recognition (MCR, similar to OCR) would be required each and every time. MCR is not only computationally expensive, but is also a very young, imperfect technology, which is far from reliable.
Part of the reason why MCR is so difficult is that despite its long history, or maybe because of it, CMN is *not* a "robust, well designed language". It is an ambiguous, self-contradictory language which requires a huge amount of knowledge beyond what is printed on the page in order to correctly interpret the data. In a way, it is a lossy compression format similar to wavelet compression of graphics; a large database of extra information is needed for decompression.
As far as MIDI is concerned, there is indeed enough information in a Standard MIDI File (SMF) to notate many types of music. However, there is not enough information to convert reliably into CMN (as other posters have already described). Instead, MIDI is commonly notated in the form of a piano roll, or as a textual event list. While these are real and valid forms of music notation, most musicians cannot or will not read them. If your audience insists on CMN, then you need to give them CMN.
In any event, it might help to restate the problem more explicitly: MusicXML attempts to provide an easily loaded, lossless computer file format for an abstract representation (data model) of a piece of music optimized for editing and sufficient for converting into CMN. How well it meets these goals has yet to be seen.
* Note that the term "CMN" here should not be confused with the Lisp-based music notation language of the same name; I'm speaking solely of the typeset output.
If higher resolution screens became common, third party developers whose current apps don't scale well would find themselves compelled to fix them. Since we're talking about OS/X here, there's certainly enough precedent of Apple exerting pressure on third party developers to deal with a lack of backwards compatibility.
And yes, I do run pro audio software on a higher resolution laptop (15 inch diagonal, 1400 horizontal pixels), and have personally experienced the problems you describe when attempting to set the system's concept of DPI to match the actual one. But that wasn't on a more-or-less legacy free, new OS with pervasive support for applying vector transforms to bitmap images (i.e., Quartz).
The reason why so many people get confused by this is that the vendors are constantly trying to blur the line between different classes of software. Try to name a current product in each of the following distinct categories that doesn't cross the line into at least one of the others:
Convergence in not inherently good nor bad, but it helps to know what are the core strengths of any given program and what has been bolted on to the side.
Err, music notation programs are pretty much the textbook example of why the presence of a GUI does not automatically make a tool user friendly. Designing an interface for music notation is an extremely difficult task, and there are both good and bad GUIs, good and bad CLIs. Finale's unintuitive, overly modal GUI is one of the main reasons why they've lost so much market share to the newer competitor Sibelius.
While it's pretty unambiguous that a sequencer will usually do a better job of sequencing than will a notation program, and vice versa, it's wrong to say that the task of "composition" is more suited to one or the other. Different people compose in different ways. Some record their live improvisations and edit from there, so a sequencer may be a more appropriate interface for them. Some people construct a composition in a mathematical heirarchy, so a music programming language may be their interface of choice. Others create music by turning knobs on an algorithmic composition system; even there, their editorial input amounts to the act of composing. Notation programs certainly do not have a monopoly on interfaces for composing.
I've never understood this surprisingly popular opinion. Nobody complains that printers have too high resolution. Why do they look at high resolution in a monitor as a bad thing?
Scalable fonts and vector graphics (both of which are used pervasively in OS/X) work even better at higher resolutions than they do at low ones. In other words, when you have more pixels per inch, you don't have to keep drawing your fonts at 13 pixels tall, making them too tiny to see. Instead, draw them at the same 12 point (1/6 of an inch) tall, but with more detail.
To answer your question, a 12 inch diagonal, 1200 dpi screen would be sheer bliss for me, and far preferable to something larger but with lower resolution.
Potentially profitable for the person on whose property it landed, but it must be shipped off-planet for sale.