home *** CD-ROM | disk | FTP | other *** search
/ Audio Version 4.94 / audioversion4.94knowledgemediaresourcelibraryoctober1994.iso / next / misc / rcrdpp-4.txt < prev    next >
Text File  |  1990-02-04  |  6KB  |  156 lines
  1. Modification History:
  2. =====================
  3.  
  4. Version 4: Feb 4, 1990
  5.  
  6. Added fix_snddriver_timeout patch to work around the timeout problems observed.
  7.  
  8. Simplified the API for the recorder object (in preparation for merging with a playback object).
  9.  
  10. Version 3: Dec 12, 1989
  11.  
  12. Added a Play button to play back the sound file just recorded.  It took about ten minutes to make all the changes.  What a nice machine...
  13.  
  14. Version 2: Dec 5, 1989
  15.  
  16. Changes within the Transport object:
  17.  
  18. The DSP code is now bundled in a MachO segment and loaded via a call to
  19. newFromMachO.  This means that RecordApp no longer cares where it's launched
  20. from.
  21.  
  22. Transport now uses a SavePanel to specify the output filename, and adds
  23. new menu items, File->Open and File->Close to specify the filename.
  24.  
  25. Stereo input data can be saved as Stereo, Mono Mix, Mono Left, or Mono
  26. Right.
  27.  
  28. 44.1KHz input data can be saved as a 44.1KHz data, or sample-rate reduced
  29. (by simple decimation) to 22.05KHz data.  Not recommended for critical
  30. applications.
  31.  
  32. Observed problems:
  33.     Call to await stream failed: unknown error(108)
  34.     Cannot enqueue read request: timed out(-203)
  35.  
  36. About RecordApp:
  37. ================
  38.  
  39. RecordApp is a simple program that demonstrates how to record data
  40. from the DSP chip on the NeXT computer.  It receives samples at
  41. 44.1Khz and writes them to disk.  
  42.  
  43. RecordApp is somewhat akin to the 'sndrecord' command-line program
  44. that is distributed on every NeXT machine, with the following
  45. differences:
  46.  
  47. * RecordApp only knows how to record from the DSP; it does not record
  48.   from the CODEC microphone input.
  49. * RecordApp is a true application and not just a command-line program.
  50. * RecordApp is distributed in source form, and implements some AppKit
  51.   objects that can be used in (and modified for) other applications.
  52.  
  53. The RecordApp example may be used, distributed, and modified freely.
  54. However, NeXT cannot assume responsibility nor offer support for this
  55. code.
  56.  
  57. The Big Picture:
  58. ================
  59.  
  60. The RecordApp program implements three AppKit objects.  They work as
  61. follows:
  62.  
  63. The Recorder object handles basic stop/pause/record messages.  It
  64. needs to be subclassed by some more specific recorder object such as a
  65. DSP recorder object or a CODEC recorder object (the latter is not
  66. implemented).  The Recorder object simply keeps track of the current
  67. state of recording (stopped, paused, recording), and sends one or more
  68. of the following messages to the subclass when various buttons are
  69. pushed:
  70.  
  71.   recorderPrepare  (set up to record, state => paused)
  72.   recorderPause       (pause the recording, state => paused)
  73.   recorderStop       (stop the recording, state => stopped)
  74.   recorderResume   (continue or start recording, state => recording)
  75.  
  76. The DSPRecorder object implements the above four methods.  It handles
  77. the grubby task of grabbing the requisite system resources, setting up
  78. the mach ports, downloading the DSP code.  Left to its own, the
  79. DSPRecorder object doesn't do anything with the data it records; it
  80. depends on a delegate to do something intelligent with the data.  The
  81. delegate methods that the DSPRecorder will call are:
  82.  
  83.   willRecord :recorder;
  84.   didRecord :recorder;
  85.   recordData :recorder :(char *)data :(int)nbytes;
  86.  
  87. The DSP recorder calls willRecord at the onset of any recording.  The
  88. didRecord method is called whenever recording stops.  While recording
  89. is actually happening, the DSP recorder will call hasRecorded every
  90. time it receives a packet of data from the DSP.
  91.  
  92. The Transport object is a "dime store" controller for the DSP recorder
  93. object.  (For those not familiar with professional tape decks, the
  94. "transport" is the mechanical part of the tape deck that moves the
  95. tape as opposed to the "electronics".)  The Transport provides the
  96. user with three buttons (start, pause, stop), and a filename to store
  97. the sound into.  It also displays a running update of the state of the
  98. recorder and how many bytes have been recorded.
  99.  
  100. The Transport object establishes itself as the DSPRecorder's delegate.
  101. It uses the willRecord method to open a sound file, the hasRecorded
  102. method to write data to the file, and the didRecord method to put a
  103. header on the file and to close it.
  104.  
  105. Hardware and Software Requirements:
  106. ===================================
  107.  
  108. As written, here's what you need to run the RecorderApp:
  109.  
  110. * You must have a Digital Ears A/D converter from MetaResearch or
  111.   functional equivalent.  Other input devices could be supported with
  112.   appropriate changes to the dsp code (see Other Directions below).
  113. * You must have a hard disk.  The optical disk has a three-pass write
  114.   cycle (erase/write/verify), and can't sustain the 176.4 Kb/sec data
  115.   rate coming out of the DSP.
  116. * You must be running Release 1.0 of the operating system.
  117.  
  118. To create a fresh RecorderApp, start a shell buffer, connect to the
  119. directory with these files in it, and type 'make'.  This will create
  120. an executable RecorderApp that can be launched from the shell or from
  121. the Workspace Manager.
  122.  
  123. Other Directions:
  124. =================
  125.  
  126. The RecordApp was written as a programming example; is intentionally
  127. simplistic.  There are many ways that an ambitious programmer might
  128. want to modify or extend the program:
  129.  
  130. * Add VU Meters: You probably wouldn't want to update the VU meter at
  131.   every call to hasRecorded; the postcript overhead could become
  132.   excessive and cause the RecordApp to drop buffers.  However, there
  133.   probably is enough time to run through the buffers of recorded data
  134.   and compute the average and peak levels.  Then, once every second, you
  135.   could update the VU meters.
  136. * Implement Pause/Resume differently: Currently, pause and resume
  137.   sends messages to the driver to stop and restart the data streams.  If
  138.   you had VU meters on screen, you might want them to continue to update
  139.   even when the recorder was "paused".  In this case, you should not
  140.   actually pause the data streams.  Rather, you would simply stop
  141.   writing the data to disk, but allow the VU meter calculations to
  142.   continue.
  143. * Write .asm code for other devices.  The .asm code provided with the
  144.   RecordApp was written to work with the MetaResearch Digital Ears.
  145.   Other external devices may require different logic for the serial IO
  146.   ports.
  147. * Implement a CODECRecorder object to record from the CODEC rather
  148.   than from the DSP.
  149.  
  150. Above all, enjoy.
  151.  
  152. - R Dunbar Poor
  153.   NeXT Technical Support
  154.   September, 1989
  155.  
  156.