I just recently started playing with supercollider and I’ve been following a bunch of tutorials.
Running the following code:
// WARNING: do not run this code with headphones on!!!
// read below
{ LPF.ar(WhiteNoise.ar(), MouseX.kr(10, 1000, 0).poll) }.scope;
I accidentally ended up feeding a negative value as the freq input of the low pass filter. This will cause an incredibly loud broken sound to come out of your output even with a single “tick” of volume on OSX. Way louder than I expected possible.
This is probably the consequence of a few bugs (e.g. MouseX returning values smaller than minval on multimonitor setups) but my question basically boils down to:
Is there a way to set a hard limit on the volume of the output of supercollider?
Some safety mechanism to protect my ears.
Any other noob safety tips, not to blow my ears off again are welcome.
Alberto DeCampo wrote a SafetyNet Quark that could be just what you need:
Or there is StageLimiter from BatLib:
And about MouseX, we should definitely look into it if there’s a bug! I have no time right now, but generally what it takes is to find a minimal way to reproduce the bug, and then file an issue on supercollider’s github page
Unless other software is affected it’s unlikely that you would have a good case. It would likely only backfire against “dangerous open-source” software.
Plus it would seem from the above linked issue that there is explicit code added to supercollider to make the other platforms safe. This would kind of put OSX into “the norm” and possibly put supercollider at fault, since it was clearly possible to prevent (other platforms were implemented). You just risk allowing Apple to make their platform even less “hackable”.
I think the problem is in in how mac implements the system volume
theright way to do master volume IMO is to convert from floating point to 24-bit int before scaling - so that 1 tick of volume can only hit the DAC with a max level of -40 or some such.
On Mac this is not what’s happening - even with only one segment of volume you can still hit the DAC with full 0db signal.
In a lot of analog signal chains the master volume controls the gain of an op-amp - so pratically limits the amount of volume you can get at the output - hit it too hard and you get input distortion.
By the time you figure out things aren’t working this way it may be too late.
Wow, I was personally not at all aware that anyone was ever hurt by using sc. Sorry to hear that, and yes, I agree with doing something about it. I don’t understand all the details, and I’m not a mac user, but I kind of agree with Nathan’s idea to first do a hard clip in mac’s scsynth… Anyway I’ll bring this up tonight at the dev meeting.
Sorry, but I don’t get the same conclusion, I read it a few times but to me it looks like it is indeed an issue with coreaudio on osx, and not like sc protected only other platforms.
My super evident dummy-method is to clip and bring it down to amplitudes smaller than 1 before every output. The harmonics/saturation/distortion will indicate if something’s to much.
I brought this up during the last dev meeting, and working to fix this dangerous behavior on macosx will be a priority for version 3.12, or anyway right after 3.11.1 comes out (which is imminent, so this work can’t be included in it).
@elgiano
Thank you very much for taking care of this!
In case the next release would take long, maybe we could at least temporarily add some warning on the download page with the suggestion to download SafetyNext for OSX users? Ear damage is not exactly something that goes away with a new release.
It definitely makes sense to me, let’s see what other people think.
Maybe something like this? Feel free to propose changes or another version altogether:
CAUTION: macOS system volume doesn’t effectively limit audio applications’ maximum volume. Extra care has to be put in working, especially with headphones, on this platform, because programs could produce unexpectedly loud sounds regardless of system volume settings. For an extra safety measure, it is recommended to use the SafetyNet quark.
point out the actual danger of ear damage otherwise people will skip it like “terms and conditions”
“extra safety measure” would suggest that there are other safety mechanisms, and thus that it’s not that important to do this
without instructions on how to install the quark (most beginners won’t even know what quarks are, let alone how to install one) they’ll simply skip it
Basically it boils down to making it clear that the default should be installing this quark and it’s not just some extra think few people might want to do.
How to ensure that users don’t defeat the mechanism accidentally by moving nodes or groups.
Should the server recorder capture the volume-limited signal or the dry signal? IIRC the general consensus was to record the dry signal – which complicates the implementation (we can’t simply fold it into the Volume synth).
Also remaining questions about the impact on client languages other than sclang.
The server produces signals within a given numeric range.
The audio system converts this numeric range into a range of air pressure.
Often this conversion is very loud. It doesn’t surprise me at all that 0.8 would be loud.
There are two solutions: 1. Reduce the volume in the audio system. (The problem in this thread is, though, that lowering macOS system volume doesn’t prevent over-loud signals from reaching the hardware!). 2. Reduce the volume in the software (e.g. by setting a low limit). This will cost a few bits of numeric precision in the digital-to-analog conversion stage (assuming the audio driver expects integer samples – if it takes floating point samples, it’s not a problem at all), but that shouldn’t be noticeable for casual headphone use.
TL;DR Just set the limiter where it’s comfortable and don’t worry
