Stereo Tool

This is weird, but in the web interface, when adjusting the attack/release speeds, the slider allows down to 0.12 and the edit box allows only down to 0.13.
Shouldn't they match? Maybe you can allow 0.01 to get uncompressed sound.

Also, in most of the edit boxes, the number isn't automatically selected, so I have to hit the delete key several times usually. But in the attack/release box it's selected so I can just type in the new number... Can all the fields automatically have the contents selected when first entering them?

Well yes there is, but what I was saying is that your interface doesn't fit properly in the plugin window upon opening if I have my Win10 display setting above 100%, unless I resize the plugin window, then your interface resizes itself to fit. Fortunately this doesn't effect the audio. Unfortunately Adobe doesn't accommodate oversized plugins too well.

KevGP- Do you mean that literally? Are you saying the numerical value on the slider should correspond to gain reduction time or speed? Attack and release time of nearly zero is effectively a clipper. Attack speed of zero means no gain reduction is created, and if no gain reduction is created release speed is moot, don't you agree?

Note to Stereo Tool developers- I know this is an international product, but a clear and consistent syntax and definitions of terminology is important.

KevGP- The fundamental function of audio processing is manipulation and control of peak and average level across the audio spectrum, to achieve a subjective and objective goal. If you truly want an uncompressed sound, don't use processing.

KevGP, If you want a basic uncompressed sound with a rudimentary single band gain reduction stage, I suggest attack time 10 to 50 milliseconds, recovery time 200 to 900 milliseconds and compression ratio between 3 to 1 and 5 to 1. Adjust to taste. Have fun, and sleep on it. Be aware that peaks with be flying through, uncontrolled. Note those time values are based on the traditional R/C time constant and slope, and modern processors work with multiple detectors, interactive layers and variable slopes, even in a single band. This basic example has been known for over 50 years.

Another approach is attack and release time per dB of gain change, or attack and release time from or to a given audio input level, which may be different from the threshold level where gain change commenced. And as mentioned, there can be adjustments of the slope (over time) of the gain change.

Developers- consider attack and release user adjustment with a GUI graphic similar to the programmable EQ, with gain change on the vertical axis and time on horizontal axis. This way users can see the gain, time and slope components. This could reduce language, terminology and syntax misunderstandings.

Because of the fascinating complexity of audio processing, I think clear and consistent labeling of controls to their underlying action is important. GUI "front panel" control labeling and internal circuit action (DSP engine) are two different things. They must remain in alignment. That is, a new GUI (front panel) should not change the underlying circuit function, or sound of a pre-existing user preset. If it does, there should be full disclosure to customers. Otherwise, the manufacturer has disrespected and destroyed the end result the user created with the product they purchased.

This user is dismayed with the apparent obsession with cosmetic aspects of the GUI (apart from the labeling). I see constant work on the underlying processing engine metrics such as CPU load and bugs. That is excellent. I see little indication of work on improving the underlying processing structure and action. It is a very good processor right now, but I assume you are always thinking of new approaches, and not just cosmetic GUI matters such as scaling, color, making it easy, etc.

I don't know how to word this GUI request, but I'll try a few times if I need to.

I think I want the GUI to read from the ini when populating the number box upon trying to manually change the value by typing.

The issue is that it rounds the display to a couple of digits after entering a specific value. (ie entering 0.667 returns a rounded value of 0.7, even though it writes the more accurate value correctly to the ini) It should return to 0.667 upon clicking to enter a value manually (instead of 0.7) because this information is what the ini says and is the more accurate specific value.

I don't mind it showing a rounded value in the GUI normally. It just needs to return the info from the ini when editing values (or from the memory of the app if it's processing that accurately, in case reading from ini would cause any performance hitch --- heck if I know)

I realize this may be non-trivial. Please brainstorm alternate approaches. This would be a QOL improvement to power users

Neither, it will run as a plugin inside LiquidSoap. More info here: https://www.liquidsoap.info/doc-dev/stereotool.html ; our downloads are here: https://www.thimeo.com/stereo-tool/download/

Currently you'll get a big file with all the available binaries; Windows, Linux, macOS, iOS, 32 and 64 bit, Intel/AMD and ARM. We'll fix that when the next version comes out; LiquidSoap 2.2 isn't officially available yet either.

Steinberg Wavelab's host doesn't seem to think the VST3 64bit version of ST is a proper plugin upon pressing the render button. It plays back perfectly, but the render option makes Wavelab give an error that Stereo Tool doesn't catch.

More in this thread: viewtopic.php?f=4&t=33556

Also I'm getting the DPI scaling curse on different monitors again. It keeps wanting to shrink the window when swapping between.

Since this is an official Steinberg VST Host, maybe it would be prudent to make it as functionally compatible to its requirements as possible? Surely this would make it more compatible across the board as a side effect. /shrug

I see it here. So I think you may have just overlooked it. By the way, in the next update (057) the preset window will *partially* work with screen readers. Turns out that there was a specific field called "ARIA" (Accessible Rich Internet Applications) which was set to hidden. It's not fully working yet; at some point when using this there will be multiple popups open, and the ARIA for the lower popups still need to be disabled etc. But it's coming.

There a big VST size fix from Tom coming, which appears to work fine now on all the hosts that both I and Tom have on our pc's. VST development is hell... For the VST3 issue: Do you have a screenshot or the exact error message? And I assume that the host is 64 bit? Because otherwise if multiple copies are loaded it might at some point be out of memory (a 32 bit application can never use more than 2 GB in total, so that's with all the different plugins loaded). It seems VERY weird that it can load the VST for editing/live processing but not for rendering, inside Stereo Tool we cannot even see the difference between those two - that's why I was thinking about memory issues.
Please try this new beta when it's available (tomorrow) and let me know if it's ok.

The info is not very informative so I didn't include a screenshot before.

I'm excited for the sizing fix. The host and VST3 are indeed 64bit. Very weird indeed. I'm running the trial right now for Wavelab Cast on win10.

I just figured out why I was getting horrible sound from the AGC.
It is 100% miscommunication.....

The one setting I never messed with/changed was the attack and release speeds on the AGC.
I changed it and it instantly SOUNDS SO GOOD. It went from a shitty sound to something good.

I don't know about others though...

I thought the defaults were okay because I didn't want the AGC to overreact.
This was due to the description of the attack speeds of the AGC... I didn't want the AGC to overreact.
Changing the speeds doesn't mean it will overreact because 'window' or 'tight mode' exists!!

EDIT: never mind!!! it fixes it some causes but not all songs..