[PD] detecting file error in readsf~

[matteo sisti sette]

Hi,

As everybody knows, [readsf~] outputs a bang on its last outlet when
the end of file is reached.

If you send it an [open xxx( message and then a [1(, where xxx is an
_invalid_ file name (i.e. a file that doesn't exist or cannot be
opened), I have observed the following behaviour:

After the [1( has been received (1.45 msec later logical time: is it
one signal block?), a bang is output through the last outlet, as if
the end of the file was reached.
That is, playing a file that does not exist is equivalent to playing a
zero-length file.

Do you consider this to be the correct behaviour?

It becomes a practical issue when for example you want to implement a
loop: when the end is reached, play again. If an invalid file name is
used (which cannot be detected in any way), this will generate a
dsp-block-rate loop.

In my ideal world, it would work like this:
-readsf would have one more outlet and would bang on this outlet in
case of error, and would _not_ bang the end-of-file outlet on error
-the error bang would be output when the invalid [open( is received,
not when the 1 is received (which is when the error message is
currently printed)

I think an invalid file name is a very common situation and it should
not be considered as an "exception" (i.e. error message on stderr + do
nothing), but rather as a detectable condition so that it can be
reacted upon (e.g. showing something on a GUI, inhibiting operations
that would generate error messages, etc).

On the other hand, while a file-error-bang outlet does not exist,
although strictly speaking I think "playing an unexisting file" is
more equivalent to "not playing" than "playing a zero-length file", I
do recognize that the current behaviour is practically better, since
it at least permits to detect the anomaly (e.g. by using a [timer] to
detect a too-early end of file), though it cannot be distinguished
from a too-short file.

I guess some kind of "serious" error/exception handling won't probably
be considered before a version 2 of PD, but I think this is an example
of "anomalies" that should not be considered errors/exceptions at all
(at a pd level) but rather special conditions to be handled by the
patch. In my opinion, trying to open a file that cannot be opened is
as "normal" as sending a 2-element list to a [list split 4].

-- 
Matteo Sisti Sette
matteosistisette at gmail.com
http://www.matteosistisette.com