home *** CD-ROM | disk | FTP | other *** search
/ Club Amiga de Montreal - CAM / CAM_CD_1.iso / files / 244.lha / KeyClick / KeyClick.doc < prev    next >
Text File  |  1989-05-03  |  5KB  |  87 lines
  1. Note- a simplified version of this program (V1.0) can be found in the
  2. November 1988 issue of Amazing Computing.  The program as it appears in
  3. print statically allocates an audio channel, therefore preventing any other
  4. task in the system from allocating (stealing) it.  This version of the
  5. program dynamically allocates an audio channel at a priority of -90 each
  6. time a key is pressed, and works well with other tasks using the audio
  7. device (at least with my experiences).  This version also adds a toggle
  8. switch to enable the user to prevent the program from clicking if so
  9. desired.  If any problems are encountered in using this program, I'd like
  10. to know so I can upload updated versions. Thank you. -Mike
  11.  
  12.  
  13.                            Keyclick version 1.1
  14.  
  15. One thing I always missed about the Amiga was an audio click when the keys
  16. were pressed.  While the Amiga keyboard has the best feel of any I've typed
  17. on, it doesn't have a form of audio feedback, which aids in touch-typing.
  18. Thanks to the multitasking operating system however, the addition of such a
  19. feature is relatively painless, both from a user's and a programmer's
  20. standpoint.
  21.  
  22. Upon running the program, a window will be presented which contains two
  23. gadgets.  The slider is used for adjusting the volume of the click.  The
  24. toggle switch can be "pressed" to turn the sound on or off.  After the
  25. program is up and running, an audio click will be produced at each press of
  26. a key on the keyboard or a mouse button.  You cannot run more than one key
  27. clicker at a time; the second clicker that you run will indicate that a
  28. key-clicker is already active in the system.  Simply close the window to
  29. end the program.  That's about all you have to know as a user.
  30.  
  31. For you programmers out there...  This program demonstrates custom input
  32. handlers and effectively sharing the complicated audio device; two concepts
  33. that can be put to great use.
  34.  
  35. The center of activity revolves around a custom input handler, which simply
  36. signals the waiting task when a key or mouse button event arrives in the
  37. input stream.  Once the task is awakened, it sends a command to the audio
  38. device to initiate the click and goes back to sleep. Therefore, this
  39. program only uses a significant amount of processor time when a key or
  40. mouse button is actually pressed.
  41.  
  42. I had the program set its own priority to fourty (this can be changed by
  43. assigning a different value to TASK_PRIORITY, defined at the beginning of
  44. the program) for better response.  At lower task priority values, the
  45. program tended to be sluggish on occasion (especially in a busy system).
  46. The input handler priority (defined by HANDLER_PRIORITY) is set at
  47. fifty-one.  This causes events from the input stream to be intercepted
  48. before Intuition gets ahold of them.  This is desirable because Intuition
  49. "swallows" some of the events.  That is, it removes some of them from the
  50. input stream, preventing the custom input handler from notifying the
  51. clicker task.
  52.  
  53. At each stroke of a key, an audio channel is allocated, a sound request is
  54. issued to the audio device, and the channel previously allocated is freed.
  55. All of this takes place within the click() routine.  After a channel is
  56. allocated (via a call to get_audio_channel()), the io_Unit parameter is
  57. checked to see if an allocation actually succeeded.  A zero in this
  58. parameter indicates that no channel could be allocated.  If this is the
  59. case, the click() routine returns immediately without attempting to ask the
  60. audio device to make a click sound.  Any other value in io_Unit denotes
  61. which channel has been allocated for use.  The IOAudio structure is
  62. prepared for a CMD_WRITE to issue a sound request to the audio device, and
  63. is executed with a call to BeginIO().  A WaitIO() call is immediately
  64. issued after the BeginIO() so the program waits until completion of the
  65. write request.  This is needed to delay freeing the channel until the click
  66. sound is completed playing (after WaitIO() returns, a call to
  67. free_audio_channel() frees the previously allocated audio channel).
  68.  
  69. An alternate method of audio manipulation would be to allocate an audio
  70. channel at the beginning of the program and set it to the highest possible
  71. priority (127) to prevent it from being stolen by other tasks requiring
  72. audio channels.  However, this method does not take full advantage of the
  73. audio device's sophistication; it must be remembered that in a multitasking
  74. environment you have to share resources.  Allocating and "holding on" to an
  75. audio channel is very uncooperative (and selfish!).
  76.  
  77. The in-line assembly language at the end of the C source code is an input
  78. handler interface, which is required for the system to "communicate" with
  79. the custom input handler.  In other words, it copies the appropriate system
  80. registers (A0 and A1) to the stack to conform with the input handler
  81. calling convention.  This is absolutely essential if the system is to work
  82. correctly with the custom input handler.
  83.  
  84. I would like to hear your comments on this program.  Feel free to E-Mail me
  85. on GEnie (MMD) or Delphi (MOCKO).
  86.  
  87.