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


                           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).