Stereo Tool

Glad that you found something.

I still wish you'd go ahead and make the changes to remove the extra processing steps. The thing is, while you wouldn't normally see any difference, less capable systems might. This sometimes happens in reverse, where you say that such-and-such only showed a few percent increase on your system, while on my system I'm seeing 10% or more. Given that I can run everything that I normally use for loudness-enabled work, except for loudness itself, and have the CPU load be as low as it is, then my guess is that my system is just barely being overloaded, and if that's the case, even small decreases may be of great benefit.

That said though, for me, if nothing can be done, then I'll just stop preset work for loudness-enabled presets. I can get enough volume without loudness, and the CPU load is half that of trying to use loudness.

I think it's solved now. At least for the debug version, running on a single core, I had to kill it before I made the change I just made and now it responds - sometimes a bit slow (I've seen 2 or 3 seconds with the presets list open) but this is the debug version and I'm *really* pushing it (playback stutters horribly).

What I did (in case anyone is interested):
Old situation: Program sends an event to request a GUI update, this ends up in a thread that listens for this event and then fires a WM_PAINT request to Windows, which in turn asks my program to draw something.

New situation: The thread that listens, after posting the WM_PAINT waits for a 2nd event telling it that the paint has started. So at no time more than one WM_PAINT request can be waiting. And when this thread receives the next event, it clears the whole list of these events so it only handles one. So it doesn't build up a queue.

Responsiveness should really be a lot better now - but I'll test the release version before uploading it tomorrow morning.

Stand alone: http://www.stereotool.com/download/ster ... 33-054.exe
Winamp DSP: http://www.stereotool.com/download/dsp_ ... 33-054.exe
VST: http://www.stereotool.com/download/vst_ ... 33-054.dll
Command line: http://www.stereotool.com/download/ster ... 33-054.exe

For web interface, you can still use Bojcha's skin:
http://85.25.73.243/stereotool_skin_b2/

Done:
- Check GUI hangups reported by Brian and DJ_DOGGY. I hope it's gone now - please let me know your experiences!
- Fix loading Loudness settings

TODO:
- Check Iconify behavior (Brian)
- Remove MUSTBEFREED stuff that causes a small memory allocation and release for each mouse move.
- Singleband RMS style display broken
- Add warning when someone enables FM sync.
- Fix AGC startup on preset loading
- Red bar doesn't get back to green Not reproduced so far but I put a force redraw on color changes.
- Check STS file saving
- Limit Post Amp to 1
- Mouse lock doesn't work on some systems
- De-emphasis doesn't seem to switch between 50 and 75 us To be tested
- Right click for default value
- Wrong last loaded preset shown on startup (the previous one); saved presets are not added to recent presets
- Fix MB clipper sliders to 0 error.

Less urgent for usability:
- Design (several people are working on something)

For later:
- Add 'purpose based' view on settings (for example all settings that affect bass combined).
- Multi-language support
- Add basic/advanced modes
- Add '-6' '-12' etc. beside output bars where possible.
- Context sensitive Help (help button should be next to the preset buttons)
- Drag (resize window parts) lines, also between to/bottom part (scopes/meters).
- Confirm on close (stand alone version)

So far, with loudness enabled, I can no longer replicate the preset list issue. I can, however, replicate the close to tray issue. GUI updates seem a little bit more "skippy" as the CPU load is still 80-90%.

Non-loudness performance is unchanged. CPU load is 38-50%. No preset list issue and no close to tray issue.

What do you mean by 'skippy' - less smooth?

I'm unable to reproduce the to-tray issue, will check the code to see if I can make any sense out of it.

Skippy = choppy = less smooth.

Might be my imagination though. I haven't gone back to the previous beta and checked for more or less GUI update pauses. I'll do that, but for now, I haven't seen the preset list issue.

As for to-tray, when I click the X there are some disk writes that happen per Task Manager. This is without a track even playing. Related to that, when I try to save / export preset settings, that process has also seemed to take more time and be generally more sluggish than what it used to be.

So, you might try looking into the disk writes.

@Brian: Looks like I was *always* redrawing the screen, even if it was iconified. That at least explains why you kept seeing screen updates. So the CPU load when iconified should be lower in the next version...

I still need to figure out why the window itself doesn't disappear on your system.

Edit: That just shouldn't happen. But I made some changes to make things a bit better and let it respond faster (among others, it now FIRST hides the window and THEN writes data to disk), this might help...

Meanwhile, a horse walked through our building this afternoon ... My office is behind the door on the right on the first photo.






Anyway, just in case you wonder, no, it's NOT normal that a guy walks though an office building with a horse.
This is Sinterklaas (aka. Sint Nicolaas; the Dutch and original version of Santa Clause), with his horse and a few Zwarte Pieten ("Black Petes"?).

What the hell............

I more wonder how that plant grows in so small flowerpot and so it does not fall.