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@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

_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list