Actually, this description might inadvertantly scare people off. While tin is arguably a power-user's tool, it is also extremely user-friendly. If you're comfortable with the Lynx navigation method (basically do everything with the arrow keys), then you'll feel right at home with tin.
Although everyone so far has answered the question in terms of being bored in class, it's usually much more of a problem in meetings, where attendance is often mandatory and content often entirely lacking.
Fortunately, meetings provide the perfect setting for playing buzzword bingo, which can be played alone or in groups.
Draw a 5x5 grid on a sheet of paper.
Write a different buzzword in each square:
"proactive", "rightsizing", etc, for marketing meetings
"XSLT", "Java Beans", etc, for engineering meetings
Keeping them up to date is half the fun.
Make sure that each person playing has a different grid.
Now whenever the person doing the presenting in the meeting (or anybody who's not playing) mentions one of the buzzwords, check it off on your chart.
First person to get five checkmarks in a straight line wins. (But saying "bingo" too loud could get you in trouble!)
It would be really nice if the competition site had such one-liner descriptions of all the entries, preferably by the authors themselves. It's too early for either XYZZY News or SPAG (interactive fiction web-magazines) to have reviewed them yet.
I'm in the middle of "Lost New York" now and am rather enjoying it, modulo a few annoying bugs in the inventory system. I'd recommend it as a nice example of how text adventures don't have to have anything to do with dungeons and monsters; this one is a mix of history, sightseeing, and puzzle solving.
Wow, a troll who's not anonymous? The ifarchive and competition pages both describe in great detail how to run the games. "z5" files are Z-machine bytecode version 5; they'll run in any Z-machine interpreter. A convenient example would be Frotz, freely available for the platform of your choice from the self-same link in the original post.
The most experenced users use a combination of mouse and keyboard. eg... highlight with mouse(right hand) and ctrl+c to copy(left hand).
And here, you hit upon the crucial point which everyone else appears to be missing... there are some tasks which are more efficiently handled with a mouse, and some which are more efficiently handled with a keyboard. For an experienced user, selecting items from a pulldown menu is invariably faster with the keyboard than the mouse. However, it doesn't take too much experience to see that freehand drawing in a paint program is not a very efficient task for the keyboard!
In short, the keyboard is full of symbols, and thus it is very good at accomplishing tasks which can be represented symbolically. The mouse is used in a spacial, visual manner, so it is better at accomplishing visual tasks.
Serious question here, not rhetorical: I thought the traditional advantage of Macs over Windows was the very fact that the pre-OS/X MacOS did not have preemptive multitasking. For general use, preemption is great, but for hard realtime (critical in professional audio), it's really useful for an application to be able to take over the whole machine. Do you lose this advantage in the "modern", preemptive OS/X?
Actually, I'm a Cakewalk user of many years, and I chose my words carefully. Since its early days as a MIDI-focussed product, the primary user interface elements of Cakewalk have been a track list, an event list, and a piano roll. Of course lots more has been added over the years, but these remain the core of the program. They're a modest goal to replicate (note, just the user interface, not the underlying realtime I/O), and the Linux projects are doing a reasonable job at it.
I'm personally very disappointed with Cakewalk, its commercial competitors, and its noncommercial immitators alike, specifically for sticking to this dated and limited user interface. True innovations in this field, such as a massively multidimentional equivalent of a piano roll, are needed in order to more accurately model the way real musicians (composers, arrangers, conductors, etc) think of musical control data. And no, I'm not just whining, I've been designing and coding attempted solutions to this problem on and off for several years; not yet ready for a release though.
There are indeed multiple sequencer projects for Linux which provide a similar user interface to Cakewalk. Many of them support LADSPA, which is a plugin interface similar though not compatible with the DirectX one which you mentioned. Most patent-free DSP algorithms in common use today have already been ported to LADSPA.
There are several, though not many professional multichannel audio cards supported under Linux under at least one of the three sound driver architectures (ALSA, OSS/Commercial, and OSS/Free).
Oh, and all of this is available and working today. Any other objections?
Re:Not to rain on anyone's parade...
on
Talking Palm
·
· Score: 1
Actually, speech synthesis (not recognition) doesn't require much processing power at all. My old Commodore 64 which had a slower processor and less memory than a Palm ran synthesis packages like "Sam Sayit" just fine. (I'm not sure of the exact history, but I believe Sayit was very similar in design to the traditional Unix speech synthesizer "Rsynth", which is available for Linux if you'd like to try it.) This was real formant synthesis, not playback of prerecorded soundbites.
Speech recognition is a much harder and computation intensive problem. Doing that on a Palm is the impressive feat.
Why are so many so-called implementations of Scheme incomplete when compared to the current spec? The only R5RS compliant implementation of Scheme for Java which I've found is SISC, yet the project seems to be largely unknown, even within the Scheme community. Have you had any experience with it?
Are you in touch with the current participants in the SRFI process? Do you know if any work is being done towards standardizing bidirectional FFIs between Scheme and other languages/runtimes (especially C and Java, but also CORBA, SOAP, and COM)?
FFIs are, of course, crucial for being able to use new libraries which are not designed specifically for your language. I'm convinced that the primary reason why C is so popular to this day is because it standardized its FFI very early on. I'm also of the opinion that this is why adoption of Scheme and Lisp lags so far behind single-implementation languages like Tcl, Perl, and Python, which have a "standardized" FFI by default.
(For the newcomers: SRFI = Scheme Request For Implementations, the current, informal "standards" process for adding features to Scheme; FFI = Foreign Function Interface.)
One of the primary reasons why Scheme and Lisp interest me is that they are well suited for making applications interactively programmable at runtime (Scheme especially, due to its small size). This is far more flexible and useful than applications which are only extensible through heavyweight, precompiled plugins. Since the Slashdot readership tends to be made up of people who are comfortable with programatic interfaces (unlike the general computer-using public), why do we not see more such applications?
This won't help with the issue of only knowing the melody rather than the title or band, but it will help with esoteric music. Believe it or not, that was the very reason why Amazon.com was started... to make it easy to find rare books that regular stores didn't stock. This still works for music. As a convenient bonus, they have short previews of at least a few songs from every album, so you know what you're getting. The only reason I go to a physical record store these days is if I'm too impatient to wait for mail order.
Research projects do exist to build databases of songs indexed by melodic fragments rather than title, but they're not yet ready for primetime.
The theremin was only arguably "futuristic" in the 1970s, considering the instrument was invented in the 1930s.
A theremin can vary in frequency from subsonic to supersonic range.
Although the simplest theremins produce a pure sine wave, the originals by Termin himself had a more complex timbre with multiple overtones. Modern ones, such as those from Big Briar (Robert Moog's current company) are adjustable.
A theremin was indeed the instrument used on Good Vibrations, but I can't vouch for the ST:TOS theme.
> The clunky joystick reminds me of how far we've come with peripherals.
As someone who grew up with the C64 / Atari 2600 joystick, I have yet to find anything better. I'm right handed, so I like to control direction with my right hand. Why has nearly every joystick or joypad since that time delegated directional control to the left hand?
(Yes, before someone suggests it, I do own a first-generation Gravis gamepad which has a "left-handed" mode that allows you to use your right hand for directional control.)
Actually, with the exception of the way they respectively handle skins/themes, AWT and Swing's core features are ripped directly out of Tk, particularly in terms of layout management. The Java implementations merely generalize the
same functionality (when you want something more than just the gridder and the packer, you can actually add it).
Not an answer for the original poster, since it is definitely not appropriate for the illiterate, but there is actually a whole genre of games which might match your interests, Strog.
These are the seemingly archaic text adventures, sometimes called interactive fiction. They certainly don't have the slideshow feel of games in the Myst series, but they involve the exact same type of exploring and puzzle solving. Although there are traditional hack-and-slash dungeon games in this genre, there are also lots of nonviolent ones, with various themes and settings.
Most of the games are freely available (see the link above), and run on a virtual machine, so you can play them on the OS of your choice.
(For those who are fortunate enough not to have been subjected to it, "hungarian coding" is a convention for naming variables and functions according to their types. The intention is good, but the effect is that it makes code utterly unreadable and harder to maintain. Half of this book is devoted to convincing you to use hungarian; the other half was not at all memorable.)
Slashdot Mirror
Actually, this description might inadvertantly scare people off. While tin is arguably a power-user's tool, it is also extremely user-friendly. If you're comfortable with the Lynx navigation method (basically do everything with the arrow keys), then you'll feel right at home with tin.
Read Verne online at Project Gutenberg.
Although everyone so far has answered the question in terms of being bored in class, it's usually much more of a problem in meetings, where attendance is often mandatory and content often entirely lacking.
Fortunately, meetings provide the perfect setting for playing buzzword bingo, which can be played alone or in groups.
It would be really nice if the competition site had such one-liner descriptions of all the entries, preferably by the authors themselves. It's too early for either XYZZY News or SPAG (interactive fiction web-magazines) to have reviewed them yet.
I'm in the middle of "Lost New York" now and am rather enjoying it, modulo a few annoying bugs in the inventory system. I'd recommend it as a nice example of how text adventures don't have to have anything to do with dungeons and monsters; this one is a mix of history, sightseeing, and puzzle solving.
Wow, a troll who's not anonymous? The ifarchive and competition pages both describe in great detail how to run the games. "z5" files are Z-machine bytecode version 5; they'll run in any Z-machine interpreter. A convenient example would be Frotz, freely available for the platform of your choice from the self-same link in the original post.
This is Lisp, after all. Shouldn't you have made it a lambda function passed to global-set-key? :-)
The most experenced users use a combination of mouse and keyboard. eg... highlight with mouse(right hand) and ctrl+c to copy(left hand).
And here, you hit upon the crucial point which everyone else appears to be missing... there are some tasks which are more efficiently handled with a mouse, and some which are more efficiently handled with a keyboard. For an experienced user, selecting items from a pulldown menu is invariably faster with the keyboard than the mouse. However, it doesn't take too much experience to see that freehand drawing in a paint program is not a very efficient task for the keyboard!
In short, the keyboard is full of symbols, and thus it is very good at accomplishing tasks which can be represented symbolically. The mouse is used in a spacial, visual manner, so it is better at accomplishing visual tasks.
Some synths, even digital ones, come standard with such a device. Do a search for "ribbon controller".
Serious question here, not rhetorical: I thought the traditional advantage of Macs over Windows was the very fact that the pre-OS/X MacOS did not have preemptive multitasking. For general use, preemption is great, but for hard realtime (critical in professional audio), it's really useful for an application to be able to take over the whole machine. Do you lose this advantage in the "modern", preemptive OS/X?
Actually, I'm a Cakewalk user of many years, and I chose my words carefully. Since its early days as a MIDI-focussed product, the primary user interface elements of Cakewalk have been a track list, an event list, and a piano roll. Of course lots more has been added over the years, but these remain the core of the program. They're a modest goal to replicate (note, just the user interface, not the underlying realtime I/O), and the Linux projects are doing a reasonable job at it.
I'm personally very disappointed with Cakewalk, its commercial competitors, and its noncommercial immitators alike, specifically for sticking to this dated and limited user interface. True innovations in this field, such as a massively multidimentional equivalent of a piano roll, are needed in order to more accurately model the way real musicians (composers, arrangers, conductors, etc) think of musical control data. And no, I'm not just whining, I've been designing and coding attempted solutions to this problem on and off for several years; not yet ready for a release though.
There are indeed multiple sequencer projects for Linux which provide a similar user interface to Cakewalk. Many of them support LADSPA, which is a plugin interface similar though not compatible with the DirectX one which you mentioned. Most patent-free DSP algorithms in common use today have already been ported to LADSPA.
There are several, though not many professional multichannel audio cards supported under Linux under at least one of the three sound driver architectures (ALSA, OSS/Commercial, and OSS/Free).
Oh, and all of this is available and working today. Any other objections?
Actually, speech synthesis (not recognition) doesn't require much processing power at all. My old Commodore 64 which had a slower processor and less memory than a Palm ran synthesis packages like "Sam Sayit" just fine. (I'm not sure of the exact history, but I believe Sayit was very similar in design to the traditional Unix speech synthesizer "Rsynth", which is available for Linux if you'd like to try it.) This was real formant synthesis, not playback of prerecorded soundbites.
Speech recognition is a much harder and computation intensive problem. Doing that on a Palm is the impressive feat.
Why are so many so-called implementations of Scheme incomplete when compared to the current spec? The only R5RS compliant implementation of Scheme for Java which I've found is SISC, yet the project seems to be largely unknown, even within the Scheme community. Have you had any experience with it?
Are you in touch with the current participants in the SRFI process? Do you know if any work is being done towards standardizing bidirectional FFIs between Scheme and other languages/runtimes (especially C and Java, but also CORBA, SOAP, and COM)?
FFIs are, of course, crucial for being able to use new libraries which are not designed specifically for your language. I'm convinced that the primary reason why C is so popular to this day is because it standardized its FFI very early on. I'm also of the opinion that this is why adoption of Scheme and Lisp lags so far behind single-implementation languages like Tcl, Perl, and Python, which have a "standardized" FFI by default.
(For the newcomers: SRFI = Scheme Request For Implementations, the current, informal "standards" process for adding features to Scheme; FFI = Foreign Function Interface.)
One of the primary reasons why Scheme and Lisp interest me is that they are well suited for making applications interactively programmable at runtime (Scheme especially, due to its small size). This is far more flexible and useful than applications which are only extensible through heavyweight, precompiled plugins. Since the Slashdot readership tends to be made up of people who are comfortable with programatic interfaces (unlike the general computer-using public), why do we not see more such applications?
I think you're looking for the language Dylan, which is largely inspired by Lisp, but with infix notation. I, however, rather like Lisp's notation.
Mod this up, please. Too few people get this right, especially the parenthetical, and this is a rather clear, accurate statement of the situation.
This won't help with the issue of only knowing the melody rather than the title or band, but it will help with esoteric music. Believe it or not, that was the very reason why Amazon.com was started... to make it easy to find rare books that regular stores didn't stock. This still works for music. As a convenient bonus, they have short previews of at least a few songs from every album, so you know what you're getting. The only reason I go to a physical record store these days is if I'm too impatient to wait for mail order.
Research projects do exist to build databases of songs indexed by melodic fragments rather than title, but they're not yet ready for primetime.
> The clunky joystick reminds me of how far we've come with peripherals.
As someone who grew up with the C64 / Atari 2600 joystick, I have yet to find anything better. I'm right handed, so I like to control direction with my right hand. Why has nearly every joystick or joypad since that time delegated directional control to the left hand?
(Yes, before someone suggests it, I do own a first-generation Gravis gamepad which has a "left-handed" mode that allows you to use your right hand for directional control.)
Actually, with the exception of the way they respectively handle skins/themes, AWT and Swing's core features are ripped directly out of Tk, particularly in terms of layout management. The Java implementations merely generalize the same functionality (when you want something more than just the gridder and the packer, you can actually add it).
They're both excellent games, written by the same authors. Robot Odyssey is sort of an expanded, more difficult versio of Rocky's Boots.
Not an answer for the original poster, since it is definitely not appropriate for the illiterate, but there is actually a whole genre of games which might match your interests, Strog.
These are the seemingly archaic text adventures, sometimes called interactive fiction. They certainly don't have the slideshow feel of games in the Myst series, but they involve the exact same type of exploring and puzzle solving. Although there are traditional hack-and-slash dungeon games in this genre, there are also lots of nonviolent ones, with various themes and settings.
Most of the games are freely available (see the link above), and run on a virtual machine, so you can play them on the OS of your choice.
No! Not the hungarian book!
(For those who are fortunate enough not to have been subjected to it, "hungarian coding" is a convention for naming variables and functions according to their types. The intention is good, but the effect is that it makes code utterly unreadable and harder to maintain. Half of this book is devoted to convincing you to use hungarian; the other half was not at all memorable.)
But my grandest creation, as history will tell,