Disabling processing when input is silent. Worth it?

[stefancrs]

i cant believe you guys are still on about this. i said the issue is simple, the implementation is often complex,

Just check in- and output signals. If the output is silent for a period longer than the longest feedback buffer and the input is silent too, you can turn it off safely. How is that complex?

Unless, ofcourse, there are internal generators, which there often is in effects. Automation input is also be considered as a input signal which sometimes will play a role in whether there will be a need to run the effects process loop or not, but only if there's also internal generators (like LFO's or other types of oscillators, filters or other delay based effects with the ability to resonate to the point of oscillation etc).

[JonasNorberg]

Of course in audio, much of the data is constantly new so the cache can't help much at all there.

I'm not an expert on caches or hosts, and I am sure there are developers with more experience in those fields. The below is just a little reflection from my side.

I tend to imagine an audio stream in another way.

Last time I looked... like 5 years ago, Cubase used the same buffer for in and out when processReplacing.

This way, if several insert plugins are connected in series (common case of dynamics and EQ), the buffer will stay the same through out the processing of those inserts.

Point being that the data-cache could help in this pretty common case. (plug canReplacing + host reuse buffer)

[BarendB]

Unless, ofcourse, there are internal generators, which there often is in effects. Automation input is also be considered as a input signal which sometimes will play a role in whether there will be a need to run the effects process loop or not, but only if there's also internal generators (like LFO's or other types of oscillators, filters or other delay based effects with the ability to resonate to the point of oscillation etc).

As long as the plugin can not generate audio output by itself (thus without any audio input), there will be no problems in general. Resonating filters, delays, reverbs or whatever can all be turned of safely. A self-oscillating filter for example can only self-oscillate if there has been some audio input before.

Ofcourse it entirely depends on what your plugin does exactly if you can turn of processing silence, but in most cases there won't be any problems at all if you ask me.

[AdmiralQuality]

A self-oscillating filter for example can only self-oscillate if there has been some audio input before.

Ofcourse it entirely depends on what your plugin does exactly if you can turn of processing silence, but in most cases there won't be any problems at all if you ask me.

Not if you model your self-oscillating filter after real analog ones, where the noise floor of the circuit itself is enough to get it going.

stefancrs is right, automation and MIDI CCs complicate the issue even further.

Again, I'm not trying to say it's impossible to do or to come up with a workaround. Just impractical and of questionable value.

Still listening though! And thanks to those contributing their understandings on the low level mechanics of the CPU cache.

[BarendB]

Not if you model your self-oscillating filter after real analog ones, where the noise floor of the circuit itself is enough to get it going.

In that case you need to feed the filter with noise yourself (so your plugin CAN generate sound output without any input), otherwise it won't oscillate. If that's what you want, you shouldn't turn it off indeed.

stefancrs is right, automation and MIDI CCs complicate the issue even further.

Again, I'm not trying to say it's impossible to do or to come up with a workaround. Just impractical and of questionable value.

Still listening though! And thanks to those contributing their understandings on the low level mechanics of the CPU cache.

For automation/parameter changes you don't need to run the whole audio processing loop. Just change the values and do what's needed. LFO's can also be kept running if needed.

[Zaphod (giancarlo)]

Now I'm walking under cross-fire. But I'll try to be honest

But to defend again... I want the peak ALL the time. Then I know where I'm at. ( Hi-5 to Zaphod! )

yes I agree with everything you have written here. Not with the personal fight you have with IL guys, not with the violence of the attacks (even if here you are defending you). Sorry but I don't agree. But as you have said, probably you are a bit tired because you felt yourself under attack when IL posted those examples in their forum. Anyway too much verbal violence for this little thing.

there's a good reason for 'leaders' to waste your CPU, it's the same as for giant UI's: if it looks big, eats a lot of CPU, then its high price is almost already justified. It sucks that it works, but it does.

Ok,apparently you are good here, but you are attacking him again. AD is making quality plugs that 'claims' to be cpu-wasting. This is a minus, but can't prevent someone to buy their plugs, and to use them successfully. IMHO there are too many bad sounding toys, so if something wasting but good sounding is available I try it. And I'm not the only one I suppose. I know this is NOT your philosophy, but you can't blame someone for a different strategy. Just say 'I don't agree with your strategy'. And period.
Posting this sentence in this way obviously war starts again.
And sorry for my english, I'm trying to tell everyone something is wrong in this thread, probably now you'll both attack me. But it is life, I'll accept it.

[BarendB]

I know this is NOT your philosophy, but you can't blame someone for a different strategy. Just say 'I don't agree with your strategy'. And period.

Exactly, everyone should do whatever he thinks fits best. It is actually a good thing that not every developer agrees on every point, because everyone would then be making the same stuff..

[AdmiralQuality]

Like I said, the guy's been baiting me. Anyway, I'm done with it, even though he and now JBM are following me around wherever I post and insulting me -- JBM's even quoted something I meant to be intentionally funny in his signature!

AM interested in this topic though. And I point out again that this topic started in another thread, when tony claimed that my SCAMP plug-in was inadequate because it didn't notice that channels 3 to 6 had no audio input and didn't automatically disable processing on them (which we've established, almost NOBODY'S plug-ins do). All this despite the fact that it's actually the fault of the host HE developed, for not negotiating the number of connected channels correctly (to be fair, most hosts other than Cubase screw this up too). But my product's docs clearly describe this issue, and point out that there are 2 very easy workarounds. But does he try that? No... instead he publishes an exaggerated CPU usage figure for my plug-in, publishes a bad sounding MP3 demo on his company's website (as if you couldn't make a bad sounding song in FLstudio!) and won't correct himself even after I explain what he's doing wrong.

And yes, according to tony's conspiracy theory, I'd already be getting rich at this stuff. The good news is that my upcoming Poly-Ana has a HUGE interface and is currently quite the CPU hog... so maybe I should release it now and not bother to optimize it at all... wouldn't want to lose any customers by making it too efficient!

Again, the guy's got the audacity to suggest that every company I mentioned are intentionally making their plug-ins use more CPU than they need to, just to fool the customers! EVERYONE! Only HE is better! A statement on par with his filter-mod comments that deny the entire history of analog synthesis, and where I made the original mistake of trying to educate him to the contrary. I started out friendly, I started out patient, but... oh just read that thread.

More illustration of how that fellow's mind works. But yes, of course I agree, he's free to use whatever strategies and philosophies he feels are best in the product HE develops. But from my end this has all been in defense to unwarranted attacks of MY product.

So here I am, asking everyone, if what tony says my product should do is a good idea. Trying to turn a stupid fight into a debate where we all might actually learn something. Not going to apologize for it.

Cheers.

[Zaphod (giancarlo)]

Yes AQ, before posting this thing today I've printed (*printed!!!!!!!* on paper) the whole topic. And something else. You have explained well again what is written here. And you are right to protect your products, because they are good and, after all, they are coherent with your choices. A stranger could agree, not agree, but all makes sense here. I'm talking now only about the violence of the reaction, justified for someone because you are protecting your work and your money, but not always easy to comprehend for foreign customers. Now I'm a developer, I'm curious and I've read carefully everything, but I seriously dubt anyone else will be so careful in judge a violent reaction. Even if you are right. Even if you are making good tools or your are right. Bus as said before, I'm not attacking. And I'm not speaking only about your reaction. I think even tony is guilty, because he is opening the window while the house is burning. And he is clever and he is subtle, in this topic it seems he is completely right and you completely wrong.

For this reason yesterday I wrote "slow down". Here we are making a discussion, not a war, and this discussion could be useful for many guys, because you are a GOOD new developer and tony, tony is a GREAT and TALENTED developer. Yes, the original mistake is exactly what you have written, you tried to educate someone, and it is the same mistake of Tony who says "I'm better". You both made the same mistake.

[AdmiralQuality]

You are right Zaphod. I overreacted. I should have given up as soon as I realized how tony was working. But by then he was already trashing my stuff in public. Still, no excuse for name calling. Some truths are sufficiently self-evident.

Again, trying to discuss one of the actual issues in here rather than "I'm better". In fact, this thread has even somewhat swayed my opinion (though as a self-resonant IIR, SCAMP still isn't a good candidate for this technique... but I'll consider it in the future, for effects where it makes sense. Probably as an option.)

Thanks man.

[aciddose]

for a simple iir filter, you might actually want to do the same thing i suggested for the input, and then combine (max(in,out)) that envelope follower result with the envelope followed from the output before checking the threshold value to enable/disable processing. it would probably work fine if you set the threshold low enough. it only really becomes a problem for more complex things like a reverb with pre/post delay/echo going on. i said it isnt reallyt possible for xhip reverb because of that, although, if you allow for some time after silence is detected, you might be fairly safe in those situations too.

mostly i was just saying to those 'for' dynamic bypass, why rant and rave about how it 'should' be without having experiance doing it yourself. people should write the code and then say 'you should do it this way' when it can be demonstrated to work.

i want to apply dynamic bypass to some of my effects now, since it will be possible to save a lot of cpu power while things are silent. i always did plan on it, but this thread reminded me of what is involved and started me thinking about what i would need to do to get it working with the more tricky effects.

[AdmiralQuality]

Yeah AD, but in SCAMP's case, it's self-resonant. It can be an oscillator all by itself. In fact, if you set it JUST right, you can even get tails that take several seconds to decay. Even minutes.

Incidentally, does anyone know when getTailSize() is called? Seems to me that most every time based effect would have a variable tail size (for example, reverb time is usually variable in a reverb plug-in). Is getTailSize() supposed to reflect the maximum tail length? Is it called after every time a knob is moved? (Well, I know it's not but it would have to be.) It's probably for these reasons that (almost?) nobody implements it.

From the VST "docs":

getGetTailSize (->plug)

virtual long getGetTailSize ();

Return after what time the response to an input sample will have die to zero. For instance, a reverb will have a tail somewhat similar to its reverbaration time, an IIR will 'never' die, and an FIR will usually die after a short amount of samples, but many plugs will have no tail at all. The application may decide to not call the plug's process method after it sounded out, and no input data will be applied (silence).

return 0 : Not supported, continuous calls to the process methods are required.
1 : No tail at all.
other : The duration, in samples, the plug needs to 'sound out'.

More half-baked VST fun.

[AdmiralQuality]

Oh and as far as: you have to be a coder to have an opinion or STFU... I wouldn't necessarily agree with that (though, this IS the dev board and if I had REALLY wanted the opinion of the general populace I'd have posted in the FX board).

I AM interested in everyone's opinion though, but as developers it's part of our job to help educate the masses as to WHY some things like this that at first glance might seem like simple features to add, sometimes aren't. It's really not a conspiracy as tony would suggest (except maybe a conspiracy of common sense.)

Cheers.

[aciddose]

aq, read what i said again. the method i discribed would work fine with 'self oscillating' or dynamic length tails, so long as the signal can not return once it has already faded out while no input is present. i even suggested that if that were the case, you could simply adjust the release time on the envelope follower to eliminate the problem. read my original post discribing the required code as well and you might know what i'm talking about. it is easy to implement and should work for any type of linear filter (even if modulated)

[AdmiralQuality]

aq, read what i said again. the method i discribed would work fine with 'self oscillating' or dynamic length tails, so long as the signal can not return once it has already faded out while no input is present. i even suggested that if that were the case, you could simply adjust the release time on the envelope follower to eliminate the problem. read my original post discribing the required code as well and you might know what i'm talking about. it is easy to implement and should work for any type of linear filter (even if modulated)

I did read it AD, I read all your posts in their entirety, and as I said, it CAN oscillate from no input. The signal CAN return once it has faded out -- well, by moving a knob... oh wait, the LFO could also interplay in such a way as to cause this with no user intervention. I've even had it surprise me by starting to self-oscillate minutes after I last touched it.

Yes, of course I could write a pile of code to try to predict when this was going to happen. Like I keep saying, there's nothing impossible about doing this, for any form of effect. But, IMHO, for some, it's impractical.