Stereo Tool

Unquestionably this option is very useful, but as implemented, is not accurate and usable.

Mainly because we do not know the frequency and gain you are applying.

I think it might be more useful, use controls to configure this feature.

I would think something like Type Filter (LPF, HPF and Parametric), frequency (or center frequency for Parametric), db/octave (for LPF and HPF), Q for the parametric and gain in dB.

_________________
by GAP
"Less is More" (Bob Katz)

That option is VERY useful.. but true not user-frendly at all. It's there now only because of testing. Should be better later.

Will be MUCH better in the next beta.

@Brian: As I posted earlier, this thing is NOT optimized AT ALL because I'm still figuring out what it needs to do. Once it works well I'll optimize it.

When I merge this into a new multiband thing I will at the same time remove those unnecessary calculations for the new MB. On top of that it will have less bands. So if I can optimize the compressor enough (and I don't know that yet) it might use less than it does now.

Btw - I assume if you set it to peak level based it's not so bad?

Only marginally better. Generic load goes down to 65-70 instead of 75-80. Regular web preset is effectively still unusable. The audio does not stutter, but as the load is 92-98%, it is extraordinarily difficult to make changes while playing a track. Doing anything else on the computer while playing a track is an exercise in futility.

To be frank, my hearing is most likely just as good. These high CPU loads basically remove me from being able to contribute. I'm speculating that if just the unnecessary calculations were removed, it would give enough breathing room to be able to contribute.

My concern though is that you will end up binding the removal of the unnecessary calculations with the new features. If those new features are more demanding, then it ends up being a net increase.

Just like the old GUI was 6.xx and the new GUI is 7.xx, could you make the new GUI with the unnecessary calculations removed as the final 7.xx version and have this new singleband filter and other filters be version 8.xx?

Ah, I think the problem is in 'Knee'. Try setting it to 0 and check the performance again. It's not working properly yet anyway so I'm going to rewrite that part (probably tomorrow).

When this new filter is finished, and you're running it at peak mode, it shouldn't use much more processing power than the current compressor. But the current code is REALLY not optimized yet.

Btw - build running, will post new version in about an hour.

Stand alone: http://www.stereotool.com/download/ster ... 04-015.exe
Winamp DSP: http://www.stereotool.com/download/dsp_ ... 04-015.exe
VST: http://www.stereotool.com/download/vst_ ... 04-015.dll

Yes, using peak and "breaking the software's knee" settled things down a good bit. Still higher than the original filter, but...
OK. When you're done, would you please do the following, and forgive if this is a review / something you're already doing:

- Using whatever source code management tool you are using, add a label / tag for this code as version 7.04.

Just create the label / tag for now. This will provide a clean point to fall back to if whatever else you have planned (multiband and other stuff) turns out to require more processing power than you anticipate. This would allow you to have the capability of making a branch back to that label and then remove the unnecessary calculations back on the branch with the current code base. New development would happen in the trunk (mainline).

If you make version 7.05 and the multiband / unnecessary code removal isn't completed, but there hasn't been a substantial load increase, then label that as well.

Again, my concern is that the removal of the additional calculations will get intertwined with new code (dependency). If that all works fine, and the new multiband is the same load or less, then a branch isn't needed. However, labeling will allow branching if it turns out otherwise.

Interesting:
https://discussions.apple.com/thread/91 ... 0&tstart=0

Something is wrong with compressor. I Think knee. but it's connected with threshold.
I have non-flat release only with lower thresholds,around -6 - -8dB max. Also is strange that is same without using knee.
and that should be simple limiter (peek level depend only on threshould).