#import <SndRecorder.h>
Public Member Functions | |
(BOOL) | - startRecording |
(id) | - stopRecordingWait:disconnectFromStream: |
Sets up the record file amd. |
We want to be able to extend an existing sound as recording progresses. Subclass of Snd (SndDirectToDisk) could then be a write to disk approach. SndPlayer naturally works with an existing Snd with existing state (audio data). A SndRecorder may be tempting to be seen as a factory, however this is wrong, since we may well wish to work with an expanding Snd that is being recorded into. i.e. We don't want to wait until recording is finished before we work with the Snd. So instances of SndRecorder could hold the recording state (maximum/peak amplitude), number of seconds of recording etc, or that could be held in a separate class SndCapture or perhaps SndRecordingSession. A SndRecorder should be initialised to start recording, at a certain time, and then instructed to stop. In addition we should allow connection of an SndAudioProcessorChain so that we can capture a signal processed input, faded up or down etc as it's recorded. In Snd playing, the SndAudioProcessorChain is held by the SndPerformance, here it would be held by the SndCapture or the SndRecorder.
This supposes a different approach to the Singleton paradigm of SndPlayer, i.e. SndRecorder instances do recording and hold recording state. They encapsulate a reference to the Snd being recorded into. Therefore SndRecorder recordSnd: should be class method.
Could have a number of inputs all mixing into a single Snd. I.e. 6 channels recording as a single Snd instance.
For further info, see the base class: SndStreamClient
- (BOOL) startRecording |
- (id) stopRecordingWait: | (BOOL) | bWait | ||
disconnectFromStream: | (BOOL) | bDisconnectFromStream | ||
Sets up the record file amd.
For internal use - you shouldn't have to call this.
bWait | TRUE if the recorder should wait for intermediate buffers to be flushed to disk. |
bDisconnectFromStream | TRUE if you want the client to disconnect from the stream manager, FALSE otherwise. Leaving the client connected ensures the audio streams stay open, and minimizes start-recording set-up time. Downside is a slight CPU hit from the background streaming going on. |