To mirror capture_continuous we should have a record_continuous. Similar calling convention (filename_or_obj for first parameter and filenames are format() based substitution templates), but first iteration of loop calls start_recording, subsequent iterations call split_recording, and terminating the iterator calls stop_recording (need to check the last bit always works under all circumstances).
The text was updated successfully, but these errors were encountered:
After some experimentation and deliberation, I'm going for a record_sequence implementation to mirror capture_sequence with the difference that it returns an iterator like capture_continuous. It turns out implementing record_continuous in a manner analogous to capture_continuous isn't useful in the case of file-like-object output: because recording is active during the calling loop body nothing can manipulate the file-like-object output.
However, a system analogous to capture_sequence permits multiple outputs (and even infinite sequences given a few simple tricks from itertools) solving the problem neatly. We can't exactly replicate the calling convention of capture_sequence as then there'd be no loop body to determine when to split to the next output, hence the eventual solution of combining the iterator convention from capture_continuous with the parameters of capture_sequence.
Having had a play with this new setup, it's occurred to me it'd be much more flexible to combine capture_continuous and capture_sequence in the same manner (it would also simplify use of file-like-objects in capture_continuous). However, this would be a backwards incompatible change (it would break existing uses of capture_sequence and capture_continuous) so it'll have to wait until 2.0 - ticket #69 has been opened to track the idea though.