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, [email protected] 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 > >
signature.asc
Description: This is a digitally signed message part
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
