All times are UTC+01:00




Post new topic  Reply to topic  [ 707 posts ]  Go to page Previous 135 36 37 38 3971 Next
Author Message
PostPosted: Sat Mar 25, 2023 2:08 pm 

Joined: Mon Apr 25, 2022 11:19 pm
Posts: 92
Quote:
Quote:
I still use ALSA purely because I could never get jack to work correctly.
Then PipeWire might be a welcome new solution. Is going to replace PulseAudio et al. on newer Ubuntus.
I think it's coming on Raspberry Pi OS as well (if it hasn't already), I use the 64-bit GUI version for my ST box.


Top
   
PostPosted: Sat Mar 25, 2023 9:29 pm 
User avatar

Joined: Sun Dec 23, 2018 7:44 pm
Posts: 792
Location: Texas, USA
weird sizing behavior when swapping between monitors
monitor 1 4k @ 200% dpi and monitor 2 1080p %100% dpi
wavelab cast x64 vst3x64 beta058 10.02

https://cdn.discordapp.com/attachments/ ... 14-758.mp4


Top
   
PostPosted: Sat Mar 25, 2023 9:45 pm 
Site Admin
User avatar

Joined: Mon Mar 17, 2008 1:40 am
Posts: 11185
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.
Hm. About the naming time vs speed: The way the slider works is that if you move it to the right, the attack is faster. But the displayed value is smaller. Hence the name attack speed: Higher (which corresponds to further to the right) means that it attacks faster. This has always felt weird, but given the name "attack speed" it did have to behave like this.

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
OldNewSpeed.png [ 35.33 KiB | Viewed 1166 times ]
Since always using the highest speed (except when using "reduce fast movements") seems a bit weird the behavior might still change; if you're posting presets that use this new behavior, please clearly state that you are using it so if we decide to change this behavior, people will know that those presets won't work anymore.


Top
   
PostPosted: Sat Mar 25, 2023 10:08 pm 
Site Admin
User avatar

Joined: Mon Mar 17, 2008 1:40 am
Posts: 11185
Quote:
weird sizing behavior when swapping between monitors
monitor 1 4k @ 200% dpi and monitor 2 1080p %100% dpi
wavelab cast x64 vst3x64 beta058 10.02

https://cdn.discordapp.com/attachments/ ... 14-758.mp4
I just did a quick test, and if I just change the DPI size on the same monitor, WaveLab increases or decreases the window size but doesn't appear to notify Stereo Tool at all. And Stereo Tool doesn't appear to notice the DPI change either. So I think that Stereo Tool thinks (for a while anyway, in your video I see that it changes at some point) that the DPI setting hasn't changed, and still performs the recalculations that I posted about yesterday when talking to WaveLab.


Top
   
PostPosted: Sun Mar 26, 2023 11:50 pm 

Joined: Tue Apr 23, 2019 6:02 pm
Posts: 66
Location: Banja Luka
I don't know if it's a problem with the stereo tool or with RadioBoss. This happens since I use the Stereo tool. The problem is as follows. After restarting, RadioBoss Stereo Tool forgets which preset was loaded. At least the web interface does not show which preset is loaded. Last night I tested various presets and after restarting RadioBoss there were only two cleanup presets in the recents preset. It wasn't one of the ones I used either. I am using the vst2 version of the tool.


Top
   
PostPosted: Mon Mar 27, 2023 1:03 am 
Site Admin
User avatar

Joined: Mon Mar 17, 2008 1:40 am
Posts: 11185
Quote:
I don't know if it's a problem with the stereo tool or with RadioBoss. This happens since I use the Stereo tool. The problem is as follows. After restarting, RadioBoss Stereo Tool forgets which preset was loaded. At least the web interface does not show which preset is loaded. Last night I tested various presets and after restarting RadioBoss there were only two cleanup presets in the recents preset. It wasn't one of the ones I used either. I am using the vst2 version of the tool.
That the name isn't shown is normal with the latest beta's, we're in the middle of a redesign of how presets work. Not sure about the missing cleanup presets; I did notice a few days ago that some imported presets didn't show up in all the categories where they should. So something is probably broken there.


Top
   
PostPosted: Mon Mar 27, 2023 2:44 am 

Joined: Fri Dec 09, 2022 3:19 pm
Posts: 43
Quote:
hvz post
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.
Indeed, that is what is supposed to do ;-) 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.

In a sense that is what platforming does, adjusting processing behavior to a characteristic of the source material. The wonderful thing today is the intelligence process can be very complex and interactive, and now we accept audio throughput time delay (within reason), so the processor has time to "think about it".

Here's a thought- Consider user GUI selection of a dynamic/auto parameter as a choice of "flavors", which would be descriptions of the concept or decision-making process of that particular flavor. There could be plenty of precise numerical adjustments for a given flavor, but the name of the flavor says the basic intent of that dynamic/auto profile.

For example, one dynamic/auto flavor (profile) could be called "Leave it alone" That flavor would detect source content that is already "done" in the processing sense and leave it alone (for the most part). I think you could get the essence of it across without telling proprietary trade secrets.

About the attack slider (knob), one approach is to label it in time rather than more-less, fast-slow. Of course, you still have the question of which side of the slider is 1 ms and which side is 100 ms. My preference is the left side (knob turned down) would be 1 ms.

It is correct that many sections of Stereo Tool have sliders labeled this way- in time and dB, and that is excellent. Great product, just a few ambiguities, at least to me.

On your post you illustrated dynamic attack in a graph with what appears to be control voltage (GR) on the Y axis and time on the X axis. Would you consider making a GUI with this method of adjusting gain reduction parameters? User could drag the line to their desired amplitude-time shape. You offer this now in the programmable equalizer. I think this system would have a warning color or pop up notifying the user if an "impossible" slope was drawn.

In your example we don't know for sure if enough control voltage was made to produce the gain reduction prescribed by ratio and threshold settings. A horizontal blue line near the top could show that. Perhaps the Y axis could be dB of gain reduction?

Just thinking of how a picture of the control action on a chart could make adjustment clearer, more intuitive and more international since language and terminology could be less likely to bring confusion.


Top
   
PostPosted: Mon Mar 27, 2023 10:52 am 
Site Admin
User avatar

Joined: Mon Mar 17, 2008 1:40 am
Posts: 11185
Quote:
Quote:
hvz post
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.
Indeed, that is what is supposed to do ;-) 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.

In a sense that is what platforming does, adjusting processing behavior to a characteristic of the source material. The wonderful thing today is the intelligence process can be very complex and interactive, and now we accept audio throughput time delay (within reason), so the processor has time to "think about it".

Here's a thought- Consider user GUI selection of a dynamic/auto parameter as a choice of "flavors", which would be descriptions of the concept or decision-making process of that particular flavor. There could be plenty of precise numerical adjustments for a given flavor, but the name of the flavor says the basic intent of that dynamic/auto profile.

For example, one dynamic/auto flavor (profile) could be called "Leave it alone" That flavor would detect source content that is already "done" in the processing sense and leave it alone (for the most part). I think you could get the essence of it across without telling proprietary trade secrets.

About the attack slider (knob), one approach is to label it in time rather than more-less, fast-slow. Of course, you still have the question of which side of the slider is 1 ms and which side is 100 ms. My preference is the left side (knob turned down) would be 1 ms.

It is correct that many sections of Stereo Tool have sliders labeled this way- in time and dB, and that is excellent. Great product, just a few ambiguities, at least to me.

On your post you illustrated dynamic attack in a graph with what appears to be control voltage (GR) on the Y axis and time on the X axis. Would you consider making a GUI with this method of adjusting gain reduction parameters? User could drag the line to their desired amplitude-time shape. You offer this now in the programmable equalizer. I think this system would have a warning color or pop up notifying the user if an "impossible" slope was drawn.

In your example we don't know for sure if enough control voltage was made to produce the gain reduction prescribed by ratio and threshold settings. A horizontal blue line near the top could show that. Perhaps the Y axis could be dB of gain reduction?

Just thinking of how a picture of the control action on a chart could make adjustment clearer, more intuitive and more international since language and terminology could be less likely to bring confusion.
We have some other ideas to change how you can configure the compressors. But we need to think about it a bit more. I also hope that we'll be able to reduce the number of parameters a lot.


Top
   
PostPosted: Mon Mar 27, 2023 5:25 pm 

Joined: Sat Oct 14, 2017 3:31 am
Posts: 133
Quote:
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.

OldNewSpeed.png

Since always using the highest speed (except when using "reduce fast movements") seems a bit weird the behavior might still change; if you're posting presets that use this new behavior, please clearly state that you are using it so if we decide to change this behavior, people will know that those presets won't work anymore.
Maybe that broke Simple Clipper for the distresser preset... I cannot change it's setting when using the distresser preset. Other presets allow me to change it's value.


Top
   
PostPosted: Tue Mar 28, 2023 10:35 am 
Site Admin
User avatar

Joined: Mon Mar 17, 2008 1:40 am
Posts: 11185
Posted BETA060, the VST DPS size changes should be ok now in WaveLab, and all the sliders that went up when going to the left have been inverted and renamed (from speed to time).


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 707 posts ]  Go to page Previous 135 36 37 38 3971 Next

All times are UTC+01:00


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Limited