Stereo Tool

Beta58 is better. However with coupling, even at 1% and limiters only (preset posted) compressors are still doing something - which is not case in beta55.
Also, to achive some good frequency flatness with limiters, i need to set coupling to about 60%. In same time i don't want so much coupling, or not at all, with compressors, since thay are more flat (tuned with crossover).

This is really a display issue, if you compare the audio you'll see that the compressors are inactive. I've also checked what happens if I increase the release and release hold times to their maxima, and nothing changes.
This is true, I'm now taking the total reduction per band and merging those values. Other solutions may be possible but they are a bit more difficult to implement (for example, I would have to split the amount of compression and amount of limiting, and allow different coupling values for each. But that's not enough yet: If one band has a lot of compression and the next has a lot of limiting, both should not increase the effect of the other or you'll get too big drops).

Do you really need so much limiting that this is important for the sound? I intended limiting to be there as a sort of 'safety measure', similar to clipping in the old multiband.... Not to be used continuously, just for spikes.

I have posted an update to Cobalt in the preset section. Please update the built-in preset with this, as the current built-in is at least 4 versions old and produces a significantly different sound, especially in generic mode.

Other observations:

- Median display still not available for classic multiband. Classic functionality will still be used by at least myself, and possibly numerous others that have systems with 1MB L2 cache per core, as an extremely similar sound to the new functionality can be had for a non-trivial amount of reduction in CPU load. See the following post for a comparison preset. When considering this, also consider that whenever I have the income, I intend to donate to compensate for the generosity shown me and work you do. Because I'm voicing concerns doesn't mean I'm not appreciative or don't like the product.

- A significant portion of the presets in the "web" section are derived from FM presets that have a LPF in/around 15-16k instead of 17-20k (my own is 18.6k).

Edit: Forgot a couple things.

- Writing of presets (save / export) takes significantly more time with the new GUI vs. the old.

- I still don't feel that the DSP version should write data to disk on minimize to tray. The program is not being closed by clicking the X, only sent to tray. If the issue with the speed of writing information to disk can be addressed, possibly this would be less of an issue or a non-issue.

Comparison preset for classic vs. new. Only observation I have at the moment is that I can hear some minor distortion remaining in the classic preset, but that should be correctable with a little more time. CPU load is lower, which is the important point of this.

True, there are a lot more settings to save now. Which explains the increased time. I do want to improve this (and I need to to be able to support Linux again; the current saving method uses Windows API's which explains the slowness). But this won't be for the next version.

The reason for saving on minimize in Winamp is this: Normally, if you edit a preset and then close Winamp the settings are saved, which is good (you should get them back when you re-start Winamp). Now, if you're done with editing, often you'll minimize the window to keep it running, and forget about it.... The problem with this is that if you shut down your system, or get a power loss etc, the settings would be lost. That's why I'm saving them on minimize as well. In fact, in very early versions I saved it on every change you made in the GUI, but I had to stop doing that because it slowed things down too much when the number of parameters increased.

To me, the new MB version really sounds much more natural and - don't know how else to describe it - 'musical'. If I switch to the old MB it sounds 'restrained', 'held back'. Not for everything - many tracks sound very similar - but exactly the tracks that I could never get to sound right with the old MB really sound better with the new one.

Btw - for a closer approximation I lowered the new MB output level to -2 dB, but even then this difference was still there.

One track for everyone to test presets:
http://www40.zippyshare.com/v/22535547/file.html

Whatever method you're using, it is hideously slow. Even when idle, it took 1m 6s to write out 45000 bytes. This translates to 45000/66 = 681.82 bytes / second. With the old GUI, it took 1-3 seconds to write out 14971 bytes. This translates to, at the slowest, 14971 / 3 = 4990.33 bytes / second.
You don't save on a true minimize of the GUI. You only save when the X is clicked. You should be able to get some sort of event or state-change information that tells you when your DLL is unloading from memory rather than being minimized or trayed.

Also, and don't take this too badly, but given that you have consistently indicated a strong preference to lockups vs. exception handling, the idea of assisting an end user for a power outage seems to be a contradictory line of thinking when contrasting those situations.

At any rate, if the speed can be improved, it would not be an issue.

Might be a confirmation bias, meaning you believe that the new stuff is better, thus you "hear" that it's "better".

I can likely mimic other presets, and as for what I posted for comparison, I did not spend enough time with it. What I was truly trying to indicate was that a reasonably close approximation can be had for less CPU load. Given that it sounds good enough for me, why MUST I choose the new stuff over the old stuff? Because it's no longer the preferred choice? I've tried objectively listening to both, and if there is a difference, it is not significant enough to justify a 20% relative increase in CPU usage.

The choices you're making with your product are strikingly similar to Intel's removal of optimized SSE2 code and SSE3 options for the compiler and IPP. In both situations, end users are expected to either upgrade, or lag behind.

Now, it's been a real struggle to try to investigate the SSE levels. I felt that was easier to try rather than the other possibility, which centers around how you test filters - by using "best case scenario" type of unit testing, optimizing a specific section of code in isolation. When you do it that way, an implementation that uses more memory might test as the optimal choice, but it doesn't factor in what happens when all of the pieces of the product interact with each other in a more memory-sensitive environment, where the amount of available cache memory may be the limiting factor, and the "sub-optimal" implementation at the unit test level may be the optimal implementation for the software package as a whole.

It bears repeating that the performance issues are seen with 1MB L2 systems. That crosses between AMD and Intel, with the Intel systems being the early Core-based laptops. The problem here is if that's what's going on, that it's not the SIMD / SSE level, but the actual implementation, then that is a procedural issue that would need a change in perspective / approach.

I'll post something over the next day or so in another thread about best vs. worst case testing.

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

Updated some presets, no further changes.

Question: Is anyone else seeing insanely slow preset save speeds like Brian reported?!



TODO:
- Crash reported by Christian Steifen: If you change to a different category and quickly change something it crashes (VST version). Unable to reproduce, waiting for feedback - was this with BETA054?
- LPF before MB if there's an LPF anyway. Never below 16 kHz, set 0.25 kHz above actual LPF freq.
- Multiband compressor: Make frequencies non-editable (view only) in all but Bands section
- Multiband compressor: Differentiate between Basic/Advanced/Extreme... modes
- Singleband Compressor: Differentiate between Basic/Advanced/Extreme... modes
- Update "main" processing window
- Update/Order presets
- Change version number
- Release