Quote:
Quote:
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 just was trying to get clean sound, but with the Warm/Open preset, setting the speed down all the way makes the attack speed too slow. The bass kicks in very loud for a second, then the audio drops. Not sure if this is on purpose or not but it seems like the slider should make the attack speed faster, not slower.
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.
Naming it "Attack time" might fix both issues at once: A lower time is of course faster. And it kinda feels more natural as well to have faster attacks if the slider is on the left. But... maximum attack/release speed will then be working in the opposite direction. Meh.
I'll flip the direction of the sliders and change the names. And I can do the same thing for limit speeds.
Not sure what your remark about the processing itself means - the sound should be completely identical between the old and new GUI. For every beta build that we do, we run audio through hundreds of presets with the previous and new versions to make sure that nothing changed.
As a side note: We have started working on redesigning the compressors, and we made a quite large change to their behavior in BETA054. Much more is coming (among others we want to greatly simplify things, but that's not that easy). Because of that, we've started this by writing a design document and discussions with a number of people. One of them (Wes Keene) pointed at what he considered to be a flaw in the current behavior when using dynamic (content-dependent) attack/release speeds, and I think he is probablly right about it: When using dynamic attack/release speeds, the issue is that the attack behaves very differently depending on the content - and that makes it very hard to control. Not just that: It can start to attack slowly and then decide to speed up after some time. Which is exactly what the attack did before we added "Attack immediately", which improved the audio. So, there's a new setting now, which we've added everywhere where you can use dynamic speeds - in the AGC, both multiband compressors, and the wideband compressor: "Use fast speed for attack". Enable this and attack will (almost) always happen at the fastest speed (it still also depends on the "reduce fast movements" setting). I'm not sure yet if this makes sense, it's here for testing only now and might still be changed. Wes has done tests and really likes the new behavior.
Image below: Top: Old attadk behavior, bottom: New attack behavior. Note that this didn't always happen; it depends on the content. But if it happens it's probably bad.
Attachment:
OldNewSpeed.png [ 35.33 KiB | Viewed 1250 times ]
For example if the content is already well peak controlled, attack time could be slow. Or if content has high peak to average ratio, attack and release may be faster.