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
- info@hansroels.be info@hansroels.be [2021-03-09 11:28]:
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.
If you have DSP switched on and you have sent the open and then the start message to writesf~ it will record. So you can derive and display all your requested information from your own actions, it does not make sense to spit out error messages for that.
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.
The same is true for [osc~ 440]. No error message printed when DSP is off, and it automatically starts oscillating when you turn DSP on.
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.
Define "broken" signal. I wouldn't want an alert if I am recording silence for example as silence is part of music.
I know this may sound frustrating, but it is your own responsibility to have DSP switched on, the soundfile opened and signal cords connected I am afraid.
best, P
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
hi Roman,
Here is a patch that returns the recording status as good as possible. It checks the order of messages (to writesf~), the current dsp status and if the audio signal going to writesf~ is totally silent. I hope this patch should be an improvement in 'messy' situations... But I still think that the error messages (in the Pd main window) of writesf~ are a bit confusing and incomplete (and a simple output triggering a '1' or 'yes' would simplify its use).
Hans
On 3/9/21 2:35 PM, Roman Haefeli wrote:
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
-
info＠hansroels.be -
Peter P. -
Roman Haefeli