Disabling processing when input is silent. Worth it?

[tony tony chopper]

I THINK the CPU probably can work more efficiently with everything loaded

Now that's really huge BS coming from a programmer.

I understand you don't want to implement a bypass - and as you say, not many do. But how can you keep defending this 'constant CPU load is better'? It's total nonsense.

[Zaphod (giancarlo)]

"It's total nonsense"
A real-time system is stable when there are not many peaks.
Better something constant that something with spikes, because it isn't reliable. It 'seems' to work, but suddently it could slow down or halt.

[tony tony chopper]

A real-time system is stable when there are not many peaks

Ok let's consider that the peaking CPU usage of your 5 loaded effects is a problem. If those plugins had a constant CPU load, instead of having a problem when they peak, you'd have a.. constant problem. Is this any better??

Your peaks will never exceed the total of a constant CPU usage, and in most cases they will be a lot lower (since you don't use every plugin at the same time). It just can't be any worse.

[Zaphod (giancarlo)]

Yes, but it is reliable... Plug can't depend on the AUDIO SOURCE content, this is a violation to a basic rule in a real time system. Now, since a daw is not a pre-emptive environment, I prefer something reliable and constant. If it loads it works, if it can't load it doesn't work. It's is a simple flow.
Loading more plug just because there is a silence-optimization, but suddently host hangs is not useful on my opinion. Those peaks are the cause of drops-out also

[tony tony chopper]

So you prefer 'doesn't work right now' than 'is very likely to work, but maybe you'll get peaks'?

Then you shouldn't be using Windows because it's a multitasking environment - not very reliable by definition, as you have other processes running (fortunately not under a constant CPU load).

[Zaphod (giancarlo)]

Exactly. This is my opinion. As user, because I'm a user, and as developer (but I'm a musician first). But I worked a lot with real-time systems, operating systems and processors (I projected a math co-processor too in a previous job).

Windows had a lot of troubles in the first releases. But remember it is pre-emptive, so it is right. Now, since daws are too simple, plugs should be simple too and be as more constant as possible.

And remember windows was very worse with daws initially. Remember a lot of people today have clicks and dropouts, because not all asio drivers implement the resultoutput method as workaround of some old mistake.

[tony tony chopper]

At least now he's not alone with his logic.

So how do you handle this for synthesizers? You only use 1 single synth in your projects and limit it to 16 voices?

[Zaphod (giancarlo)]

I don't care a lot about them, I bounce a lot because (I don't know exactly the reason), a lot of them sound a bit better when rendered (more accurate imho)
But yes, an optimization like a voice stealer is ok. Better if user could set the number of active voices. That's all for me.

Here anywayt I'm speaking about plug-ins, not about virtual instruments. We are speaking about a 'silence optimization', not a 'midi silence optimization'

[BarendB]

Yes, but it is reliable... Plug can't depend on the AUDIO SOURCE content, this is a violation to a basic rule in a real time system. Now, since a daw is not a pre-emptive environment, I prefer something reliable and constant. If it loads it works, if it can't load it doesn't work. It's is a simple flow.
Loading more plug just because there is a silence-optimization, but suddently host hangs is not useful on my opinion. Those peaks are the cause of drops-out also

Personally I'd much rather go with "it might work" than "it definately will NOT work". I don't see the problem with it really, if you want to be absolutely sure that it will work, just put some audio on all tracks to test it. If that runs fine, everything will.

[Zaphod (giancarlo)]

Ok!


Just to point that what I've written is an opinion. I know there are plenty of guys who have a different vision. Anyway, in these days, when 500% cpus are announced I prefer a reliable and accurate system: I don't want crash and don't wont drop-outs at all.
In my opinion we WANT too much, so we get a bad working environment. If cpu can manipulate 20Mflops we need 30Mflops, if actual cpu can load 100plugs we need 300 plugs. Men are unsatisfied.
Simple and working. Btw I implement a bypass function in plugs, but this is a different story.

[BarendB]

Anyway, in these days, when 500% cpus are announced I prefer a reliable and accurate system: I don't want crash and don't wont drop-outs at all.

Nobody wants crashes ofcourse. If your host crashes when cpu usage gets too high, you have a bad host IMO.

Concerning dropouts, if CPU usage gets close to it's limit you'll get dropouts anyway, even if plugins don't use silence-optimization, since CPU usage is never perfectly constant. However, there's a fair chance you could play that same project without any dropouts at all if the plugins did stop processing silence.

[AdmiralQuality]

I THINK the CPU probably can work more efficiently with everything loaded

Now that's really huge BS coming from a programmer.

I understand you don't want to implement a bypass - and as you say, not many do. But how can you keep defending this 'constant CPU load is better'? It's total nonsense.

The idea here is that the CPU's instruction cache works better if chunks of code aren't popping in and out of it constantly. But like I said, that's just a gut feeling guess. Don't quote me on it (though of course, you did.)

And then there's the stuff that happens in resume() too. For some plugs, that's a LOT.

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

Oh, and as I've tried to say about 100 times here, NOT TALKING ABOUT SYNTHS. The synth I'm building does kill silent voices... that's just the obvious way to do it for a synth. Though I'm so strongly in favour of constant load that I am seriously considering making this an option for the synth.

I really don't think the all industry leaders are doing this because they're, as someone suggested, "lazy". It's a paradigm thing. I AM frankly very surprised at the number of people posting in the bypass camp though, so you're certainly not alone in your opinion tony. And I AM listening. I WILL consider adding it on future plug-ins where it's not obviously a waste or an overcomplication.

[Jason Brian Merrill]

haha...

admiral quality - coding on "gut" feelings

[tony tony chopper]

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.

[tony tony chopper]

The idea here is that the CPU's instruction cache works better if chunks of code aren't popping in and out of it constantly

Even if it was true (and it's not for instruction cache, but may be for data cache if you don't have many plugins), that would be one more reason NOT to process silence. By not doing anything, you would then not be polluting the cache.