<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">hi Roman,</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">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...</div>
<div class="moz-cite-prefix">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).</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Hans<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">On 3/9/21 2:35 PM, Roman Haefeli wrote:<br>
</div>
<blockquote type="cite"
cite="mid:f44b0d8655a8e870b1c1d190ba641b940cb846fe.camel@gmail.com">
<pre class="moz-quote-pre" wrap="">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, <a class="moz-txt-link-abbreviated" href="mailto:info@hansroels.be">info@hansroels.be</a> wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
<a class="moz-txt-link-abbreviated" href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list
UNSUBSCRIBE and account-management -> <a class="moz-txt-link-freetext" href="https://lists.puredata.info/listinfo/pd-list">https://lists.puredata.info/listinfo/pd-list</a>
</pre>
</blockquote>
</blockquote>
<p><br>
</p>
<div class="moz-signature">-- <br>
<p><u><a class="moz-txt-link-abbreviated" href="http://www.hansroels.be">www.hansroels.be</a></u> <i>gsm:</i> <u>+32 474 707849 </u></p>
<p><u><a class="moz-txt-link-abbreviated" href="http://www.woeha.be">www.woeha.be</a></u> <i>audio voor podcasts en installaties</i>
</p>
</div>
</body>
</html>