Hi, I’m running scsynth as a process in part of a larger workflow (not using sclang).
Sometimes when I run a .osc score script it warns “File could not be opened: System error : No such file or directory.” e.g. when it’s trying to load a sample into a buffer.
This is my error, but in the flow of things it’s hard to catch that, as scsynth continues to run and produce output (just not exactly what was expected). Would love it if there were a setting to fail here rather than warn, so that the missing files can be detected and corrected quickly, rather than just getting slightly-wrong output. Is this already an option? Would it be possible to implement if not?
It’s a valid feature request, but I’d suggest you could validate your OSC before launching scsynth – loop over the messages, and for any /b_read or allocRead or readChannel messages, check that the file exists (and is in a supported audio format).
I can see the value of a command line flag to stop NRT processing upon any failure – but, you have control over the OSC messages being generated, so it’s possible for your code to check them first.
To be honest, I wouldn’t expect this to be a very high-priority request – but, if nobody requests the feature, then nobody would ever look at it.
With a server-client design, sometimes it’s hard to know which component should handle what. In general, SC makes it the client’s responsibility to generate correct OSC commands. The server is just a low-intelligence robot.
In RT usage, you can write a sequence b = Buffer.read(...); s.sync; a = { ... play the buffer... }.play and this will also stumble ahead to play the synth. If I were addressing this problem, I would create a wrapper method or object around the read operation. Buffer.read is a thin abstraction that just produces and sends an OSC message. I would put something on top of this to handle failure. I wouldn’t modify Buffer.read.
A similar argument could be made for NRT – if it’s happening often enough to annoy you that incorrect paths are getting into your OSC scores, then the problem is in the OSC generation.
Yes, it’s less incorrect path being generated and more a) is the correct external drive plugged in, or b) was this file sent to me by someone who generated it with a different name in the path. For a) it’s obviously a simple “duh” moment, and the b), ideally they should be sending me an osc-generating script and not the osc itself. But you’re totally right that I should be able to validate the osc before running.
)
