bitsafe~ and other protection?
It turns out that the massively loud bang I was getting occasionally when loading Omnisphere into my Max based VST hosting environment was (is) due to the [vst~] producing 'nan' signals when I load Omnisphere....sometimes!
The cycling74 folks suggested I use [bitsafe~], an object I had not realized existed until now. I'm going to try that but it occurs to me that if this is a bug in Omnisphere, it's possible that a couple of values "lower" than NAN get produced along the way and so the [bitsafe~] might not actually protect me (and particularly my ears).
I'm wondering if there's something else I should insert at the [vst~] outputs that would just always prevent the output value from getting too high but wouldn't impact normal use. This would probably go right after the [bitsafe~] object.
Any advice?
My original question here for reference:
https://cycling74.com/forums/anyone-seen-issues-with-omnisphere-in-max-6
if it only happens at loading, a simple gate would be a nice workaround.
generally, bitsafe~ or (a de-denormalize VST plug-in as next object) should be able to filter everything unwanted out.
about post processing, i dont think that you can do more than normalizing. it is, however, also a matter of the audio driver. some audio dirvers are able to ignore NaN, others are not.
Well, it only seems to happen sometimes when Omnisphere is initially loaded but since it's not yet clear WHY it happens, I can't be sure that some other set of events would not make it happen.
Unfortunately my design doesn't really lend itself to a "next object" as I'm using a matrix to chain arbitrary sequences of VSTs. More importantly, since I don't yet know whether the problem is a bug in Omnisphere or a bug in the [vst] external, there's no guarantee that the problem wouldn't happen with a de-denormalize plugin as well)
I built a little abstraction to capture the maximum (abs) value coming out of the VSTs and have noted that in my normal use, the value never gets much beyond 0.7 or so. I'm not much of a DSP person but I wondered whether just adding a couple of primitives that would just block any values higher than 1.0 from getting through (perhaps by using the gate suggestion) would be good enough to deal with the issue where a broken plugin (or [vst~]) starts emitting higher values on the way to NAN