Closed baconpaul closed 1 year ago
And just to be clear - I mean an overload indicator for the output level of the module, like my comments for a couple of the VCO's. It would be a user cue to turn down the output level in the context menu. I could easily see it implemented nicely as a small red LED, right between the two output ports.
yeah i agree.
so the only question i have is: do you expect an overload on any channel or an overload on sum of channel
the second is way more likely to clip early but also what you would see as a problem if you routed into a mono thing which summed and i think it is the most correct.
of course the trick is do this as a general case and add it to all the modules with an output phase.
I guess overload on sum makes most sense, like you say.
that's what steve suggests and i like it
So here's the thing
The condition where the VCOs overload is all poly sum.
Take the sine oscillator. It is basically a +/-5V sin wave.
If you poly sum 8 of them you get +/- 40 or whatever (well a bit less if they are out of phase but you get my point)
So I'm at a bit of a loss as to what the overload meter should show. I can do the calculation of poly sum output. But it means the meter will go read when you go to poly 2. Or I can use a single wave. But that means the meter will never go red.
Any thoughts welcome.
It's true what you're saying Paul, mostly overload is because of poly summing. Here's my view, which might be a minority or controversial: I think people should get feedback about that. Ideally all modules (or cables?) would have a sign that now the user probably needs to do some gainstaging because the overload can cause problems down the chain. But I know that's not conventional wisdom in Rack land and that's fine. So for Surge modules to not have indicators just puts them in line with almost all other modules, but if they have an indicator it's just an added bit of user friendlines in my book. Anyway, I'm not religious about it and either way is fine.
Thinking about this a bit. A glowing overload light usually indicates: "hey, there is a problem right here."
So, if I saw a red light at the output of the VCOs or VCF, I'd intuitively think it's telling me the signal is overloading/clipping/whatever at the output. Which it won't be. Certainly not when each individual voice is in the +/-5v range, but even if a single voice were hitting +15v or whatever it wouldn't be clipped there.
Sending out 10 voices each at +/- 5v is not a problem in any way/shape/form if the next step in the chain is also polyphonic. It becomes a problem for a poly-sum-to-mono input, that's the right place for overload indicators IMO.
It's a good argument, for sure. Maybe just drop it.
yeah i agree you need to gainstage where you sum. but that's not the poly output of the vco indeed.
think about this. you are running a keyboard at 16 poly with the sine oscillator. the keyboard gates an EG. You play short staccato notes. No overload but the VCO - by virtue of continuous run 16 poly - would be in full overload output there.
So I think I'm going to not do this on the VCO; there's more odds of it being confusing than correct, but it is indeed a vexing problem. Perhaps the right thing to do is have the summing inputs have an overload meter. Then they know the poly
So the VCF with 16 x 5v would not show a light, since each channel is within bounds. But the reverb1 with 16 x 5 v would since it does a poly sum (well all the fx can also be polyphonic but you get the idea).
Thoughts on that?
Agreed!
The reverbs/delay are linear though, aren't they? So again, the trouble would appear in the next module. Or the one after that, or whichever doesn't have the headroom. You know what I mean. ;)
Yeah and the waveshaoers are fine with overloaded input
tricky
maybe I’ll write a BaconPlugs plugin which puts little vu meters in every cable instead. Lol
Hah! :)
But yeah maybe let's close this and reopen if we ever make a module with input clippers or such?
@rubyglow said in community
about the VCF. Record that here