[PD] messy situations: writesf~ feature request

[Roman Haefeli]

Hi Hans

I don't think [writesf~] is supposed to be or should become a
'batteries included'-recording facility. I think its usage is much more
flexible when it _does not_ report warning and errors under the
circumstances you propose. 

Pd - being a programming language - provides all the utilities to write
your own recorder that checks for things like DSP status and whether a
file was already openened or not. I totally understand how in messy
situations some mishaps easily happen. That's why I usually use a
recorder patch that has a single button for everything.

  * first press: open 'save file' dialog
  * second press: start recording
  * third press: stop recording

The button color represents current state. Dark means no file has been
selected. Flashing means a file has been selected and now it is ready
for recording. Light means it is currently recording. 

Your recorder might need different features. Anyway, I suggest to build
something that suits your needs.

Roman


On Tue, 2021-03-09 at 11:10 +0100, info at hansroels.be wrote:
> Hello,
> 
> I think it's a problem that in 'messy' situations you don't have
> feedback from writesf~ to know/see that the recording is happening.
> With 'messy' I mean situations where you aren't fully concentrated on
> recording, for example: simultaneously performing on stage and making
> a multichannel recording, moderating a meeting and at the same time
> recording it. I have noticed that after some of these messy
> situations, I didn't have a recording or a channel was
> missing/silent. I tested writesf~ and here are some observations:  
> 
> A) if you send a [stop( message to writesf~ after [open( the
> recording doesn't start but there is no error message (in the main Pd
> window); next, if you send [start( there is an error message and no
> recording.
> B) if you send [start( -and thus start the recording-, next switch
> off the DSP, switch it on again, the recording automatically
> continues (from the moment the DSP has been switched on again). No
> error message is printed.
> C) if during a recording, the DSP is switched off and the patch -with
> writesf~- is also closed, the recording stops of course but no panic:
> the recorded file is OK and available to be read. No error message is
> printed.
> D) If you send a second [start( message during the recording, an
> error message is printed but in fact the recording continues without
> any problems.
> 
> E) If you send [open(, next  [start( when the DSP is off, the
> recording doesn't start but no error message is printed. Next, when
> you switch on the DSP, the recording automatically starts.
> 
> F) If the signal connection going to writesf~ is broken, the
> recording starts without an error message, but the recorded file will
> be useless: it only has zeroes.
> 
> G) If no signal at all is connected to writesf~ it still records
> (zeroes) if the DSP is on. No error message or warning is printed.
> 
> B) & C) & E) are great ! I think D) & A) are a bit strange and in
> situation F) & G) it would be better that the recording wouldn't
> start or at least give some kind of error or warning message).
> 
> So here is my  feature request:
> 
> writesf~ has an output which displays if the recording is happening.
> writesf~ doesn't record or outputs a 'no input' warning message when
> the (upstream) signal leading to writesf~ is broken or missing
> Hans
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20210309/05cf2fa0/attachment.sig>