home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Amiga Format 4
/
af004.adf
/
KeyClick
/
KEYCLICK.DOC
< prev
next >
Wrap
Text File
|
1988-11-13
|
5KB
|
153 lines
*****************************************************************************
Keyclick version 1.1
One thing I always missed about the Amiga was an audio click when the
keys were pressed. While the Amiga keyboard has the best feel of any I've
typed on, it doesn't have a form of audio feedback, which aids in
touch-typing. Thanks to the multitasking operating system however, the
addition of such a feature is relatively painless, both from a user's and a
programmer's standpoint.
Upon running the program, a window will be presented which contains
two gadgets. The slider is used for adjusting the volume of the click. The
toggle switch can be "pressed" to turn the sound on or off. After the
program is up and running, an audio click will be produced at each press of
a key on the keyboard or a mouse button. You cannot run more than one key
clicker at a time; the second clicker that you run will indicate that a
key-clicker is already active in the system. Simply close the window to
end the program. That's about all you have to know as a user.
For you programmers out there... This program demonstrates custom
input handlers and effectively sharing the complicated audio device; two
concepts that can be put to great use.
The center of activity revolves around a custom input handler, which
simply signals the waiting task when a key or mouse button event arrives in
the input stream. Once the task is awakened, it sends a command to the
audio device to initiate the click and goes back to sleep. Therefore, this
program only uses a significant amount of processor time when a key or
mouse button is actually pressed.
I had the program set its own priority to fourty (this can be changed
by assigning a different value to TASK_PRIORITY, defined at the beginning
of the program) for better response. At lower task priority values, the
program tended to be sluggish on occasion (especially in a busy system).
The input handler priority (defined by HANDLER_PRIORITY) is set at
fifty-one. This causes events from the input stream to be intercepted
before Intuition gets ahold of them. This is desirable because Intuition
"swallows" some of the events. That is, it removes some of them from the
input stream, preventing the custom input handler from notifying the
clicker task.
At each stroke of a key, an audio channel is allocated, a sound
request is issued to the audio device, and the channel previously allocated
is freed. All of this takes place within the click() routine. After a
channel is allocated (via a call to get_audio_channel()), the io_Unit
parameter is checked to see if an allocation actually succeeded. A zero in
this parameter indicates that no channel could be allocated. If this is
the case, the click() routine returns immediately without attempting to ask
the audio device to make a click sound. Any other value in io_Unit denotes
which channel has been allocated for use. The IOAudio structure is
prepared for a CMD_WRITE to issue a sound request to the audio device, and
is executed with a call to BeginIO(). A WaitIO() call is immediately
issued after the BeginIO() so the program waits until completion of the
write request. This is needed to delay freeing the channel until the click
sound is completed playing (after WaitIO() returns, a call to
free_audio_channel() frees the previously allocated audio channel).
An alternate method of audio manipulation would be to allocate an
audio channel at the beginning of the program and set it to the highest
possible priority (127) to prevent it from being stolen by other tasks
requiring audio channels. However, this method does not take full
advantage of the audio device's sophistication; it must be remembered that
in a multitasking environment you have to share resources. Allocating and
"holding on" to an audio channel is very uncooperative (and selfish!).
The in-line assembly language at the end of the C source code is an
input handler interface, which is required for the system to "communicate"
with the custom input handler. In other words, it copies the appropriate
system registers (A0 and A1) to the stack to conform with the input handler
calling convention. This is absolutely essential if the system is to work
correctly with the custom input handler.
I would like to hear your comments on this program. Feel free to
E-Mail me on GEnie (MMD) or Delphi (MOCKO).
Note- a simplified version of this program (V1.0) can be found in the
November 1988 issue of Amazing Computing. The program as it appears in
print statically allocates an audio channel, therefore preventing any other
task in the system from allocating (stealing) it. This version of the
program dynamically allocates an audio channel at a priority of -90 each
time a key is pressed, and works well with other tasks using the audio
device (at least with my experiences). This version also adds a toggle
switch to enable the user to prevent the program from clicking if so
desired. If any problems are encountered in using this program, I'd like
to know so I can upload updated versions. Thank you. -Mike
*****************************************************************************