wwmm
Multiband Compressor Messed Up, No Entering of Values, and Other Inconsistencies
I don't know what all has been reported already, as I couldn't really find these things, but unfortunately I've found some problems within just a few days of using the overhauled version:
First of all, there are some odd inconsistencies:
These might be in more places, but to name an instance, in the Stereo Tools you have options to set values for Input, Output, Side Level, Middle Level and more. But while you can now change the Side/Middle levels by increments of .01, you can only change the Input/Output values by increments of .1. The former or latter might have been the case for both before, but at least that was consistent. - So now, let's say you'd want to increase the Middle level by .25, but decrease the Output by .25 to compensate, you can only choose .2 or .3. - It's a tiny difference, but still, I don't understand why the value shows in the format of 0.00 while you can only chance it by .1.
No manual entering of values:
While you can manually enter something, you (or at least I) can only do it in the literal sense, but these do not apply, not even values that should work, and it will jump back to what it was before typing. - Hitting Enter doesn't work. Just selecting a different box in the hope that the value will stick doesn't work. You can only use the arrows of the GUI or the scroll-wheel. This also means that when values are large, such as milliseconds or frequencies, you're going to be scrolling a long time, even with a weighted free-rolling scroll-wheel like I have. This is a "global" issue, by the way, so for all boxes throughout EasyEffects.
And finally, the Multiband Compressor seems all messed up:
This will take some explanation of the details, so it will be longer, but I'll try to make it clear.
While it copied the values from a preset I already had and seems to sound or act the same, the values displayed seem incorrect and also not displayed like the previous version.
For example, each Band has a Start and End Frequency, with each of them connected to the previous or next Band if there is one. - So, for example: You set Band 1 its End-value to 50Hz, that would be the Start-value of Band 2. (Or, actually, you would set the Start-value of Band 2, which would be the non-editable End-value of Band 1, which would always have a Start-value of 0Hz.) - But this is not the case anymore.
Band 1 still has non-editable Start and End frequencies, although the value-box for Start looks like one you could change (except greyed out), but it now shows that it starts at 10Hz. I don't know if this is also actually effective, or just what it shows. Also, the End-value of Band 1 is not connected to the Start-value of Band 2. When I take my settings for example, I have Band 2 its Start-frequency set to 40Hz, but Band 1 is just at 32Hz for no reason, which you also can't change.
Then the next Band I configured skipped all the way to 2000Hz, but Band 2 its End-value sits at 68Hz, so it doesn't connect to the next active Band its Start-value. In fact, all Bands have a weirdly low and arbitrary End-value. To be specific, from Band 1 through 8, it's 32, 68, 68, 60, 60, 60, 76, 87.* - Again, I don't know if these values are actually in effect. I actually think they're not, considering it doesn't sound like that when Solo-ing each Band, but what is displayed is wrong and it looks broken. - It doesn't even make sense, because they don't even go up, sometimes even down in value, many are the same and way too close. - Besides, again, you cannot change them.
*I've also tried a completely "new" entry of the Multiband Compressor, but while Band 1 still starts with 10Hz, all of the Bands end at 0Hz, no matter if you change the Start-values of the other ones or turn them on or off. This entire module looks broken. Although, again, functionally it seems to work?... Maybe?... I just can't be sure if the values don't make any sense.
Please look into this plug-in and have it work properly, because it's a really important one for me, particularly to save my hearing.
Animations when Switching Effects:
Finally, something perhaps more preferential, though also functional. - I don't really like how, when you switch between the effect-modules, it does this quick sliding-animation. That in itself is fine, but it's in the way of making direct comparisons. - For example, sometimes I compare the levels with a Level Meter at the start and the end of the chain, which by clicking between them is easy to immediately see differences. But when it first does this sliding animation, however quickly, you lose track and it's in the way of seeing the values immediately. - I don't know if it's a KDE-thing or whatever, but it reduces the usefulness a bit for me. It's also just not necessary.
For context: I use the current LTS-version of Pop!_OS. So that is basically Ubuntu 22.04 and it uses GNOME 42.9 and I'm running it with Wayland. - I also jumped from a (perhaps the last) version before 8.0 to 8.0.3 through the Pop!_Shop (so the Flatpak from Flathub).
Please look into this plug-in and have it work properly, because it's a really important one for me, particularly to save my hearing.
Did you try to open its native Window? You can enable that in our preferences window (experimental features section). Some of the things you say are just how the native window is. For example the point about band 1 frequency range not being directly editable. We can go only as far as the plugin allows.
I don't know if it's a KDE-thing or whatever, but it reduces the usefulness a bit for me. It's also just not necessary.
It feels more like a Qt behavior that probably can be changed. But to be honest I can't notice the side effects you described. But that experience probably changes from one hardware to another.
No manual entering of values
I can't reproduce this. In fact while developing EasyEffects I quite often have to type values. I wonder if I am misunderstanding what you are reporting. Typing values in the spinbox is something that ha s always worked.
First of all, there are some odd inconsistencies:
While this can be fixed the solution can easily generate inconsistencies somewhere else. Like I mentioned above we can show the native window of some plugins. At some point in the past it felt better to choose in our custom window steps that were at least similar to the ones the native window uses. For people that need to use both kind of windows at the same time having different steps on both sides can be quite annoying.
I also noticed the wrong end-frequency value of active bands. Tomorrow I will try to take a look at them.
I can't reproduce this. In fact while developing EasyEffects I quite often have to type values. I wonder if I am misunderstanding what you are reporting. Typing values in the spinbox is something that ha s always worked.
Maybe this spinbox issue has been fixed yesterday in #4497.
Please look into this plug-in and have it work properly, because it's a really important one for me, particularly to save my hearing.
Did you try to open its native Window? You can enable that in our preferences window (experimental features section). Some of the things you say are just how the native window is. For example the point about band 1 frequency range not being directly editable. We can go only as far as the plugin allows.
I don't understand what you mean by "it is just how it is". I'm reporting things that are different from before, as they were, not new things I want to have added or changed. Or, well, rather "changed back" or fixed.
For example: I never claimed that the values in the Band 1 pane were or should be editable. I simply stated it as a matter of fact, in contrast to the other Bands. However, in this version it DOES show a greyed-out spinbox on the Start-value, unlike before, and it also shows 10Hz while it should probably be 0Hz.
That first image (which shows Band 1) should be showing 0Hz and 40Hz for Start and End respectively, like it did before, unless that was always wrong. - Also there is that greyed-out spinbox, but it doesn't really matter functionally.
Also, after a reboot, all of End-values are now 0Hz, unlike the arbitrary values I had mentioned before. - So none of them line up with the Start-values of the next Band.
I never had to do anything special like use experimental features. I just used it as it was, learned how to use it according to its own methods, but currently it's not the way it was before.
I've just tried activating "native windows" and clicking "show native window", but nothing shows up.
I don't know if it's a KDE-thing or whatever, but it reduces the usefulness a bit for me. It's also just not necessary.
It feels more like a Qt behavior that probably can be changed. But to be honest I can't notice the side effects you described. But that experience probably changes from one hardware to another.
You might not use it in the same way that I do, but for me that short animation is disruptive when comparing certain readings directly. Particularly when switching between two instances of the Level Meter, for example, which changes constantly as audio plays. So if I miss a split second, the information I needed is gone.
Maybe then it would be more useful to have a split-view of two effects alongside each other, but I don't know if that's possible at all. - Otherwise a "peak hold feature" or something that shows the highest peak or average optionally. But that might depend on each plug-in.
No manual entering of values
I can't reproduce this. In fact while developing EasyEffects I quite often have to type values. I wonder if I am misunderstanding what you are reporting. Typing values in the spinbox is something that ha s always worked.
I'm reporting that it will not apply the values that are entered manually. - I can enter them, but they will jump back to the previous value that was already there. I can only "spin" the values, not enter them manually. At least not so that it will "take" the value. This seems to be a bug. - I could do this in the pre-overhauled version, yes, but not since 8 (or at least 8.0.3, the first one I updated to).
(I wish I could show a simple GIF of it, but I don't seem to have a tool right now.)
First of all, there are some odd inconsistencies:
While this can be fixed the solution can easily generate inconsistencies somewhere else. Like I mentioned above we can show the native window of some plugins. At some point in the past it felt better to choose in our custom window steps that were at least similar to the ones the native window uses. For people that need to use both kind of windows at the same time having different steps on both sides can be quite annoying.
Well, it's just that it has been changed from how it was before, which made more sense or was more consistent. - This isn't the biggest issue, though, I can deal with this slight inconsistency between values. Just something I thought I'd mention. - I think it's more that one of the values allows for FINER tuning than before, so there's actually more capability there. Just not in all values.
The bigger issue is that values are completely wrong in some areas and I don't even know whether it's just a visual anomaly or also functional. - It seems to work, but I can't be sure of what values are applied when they don't show up correctly. Mainly referring to the Multiband Compressor in particular. - But I also can't be sure if any other effect or module shows correctly.
The bigger issue is that values are completely wrong in some areas and I don't even know whether it's just a visual anomaly or also functional. - It seems to work, but I can't be sure of what values are applied when they don't show up correctly. Mainly referring to the Multiband Compressor in particular. - But I also can't be sure if any other effect or module shows correctly.
After such a big change it is totally possible there is a bug somewhere. That is the reason I suggested to compare what is shown by our custom window with what is in the plugin native window. If the values and behavior of our custom window are different it is a bug on our side. if not we are just showing what the plugin is giving to us. That is what I meant by "it is what it is". If our custom window shows the same as the plugin we use is showing in its window we can't really fix it here.
I'm reporting that it will not apply the values that are entered manually. - I can enter them, but they will jump back to the previous value that was already there. I can only "spin" the values, not enter them manually.
This bug has been solved. Can you compile the master branch? If you use Arch Linux, install easyeffects-git. If you can't install it and have to wait the next release, try to write the number without the measurement unit.
The bigger issue is that values are completely wrong in some areas and I don't even know whether it's just a visual anomaly or also functional. - It seems to work, but I can't be sure of what values are applied when they don't show up correctly. Mainly referring to the Multiband Compressor in particular. - But I also can't be sure if any other effect or module shows correctly.
After such a big change it is totally possible there is a bug somewhere. That is the reason I suggested to compare what is shown by our custom window with what is in the plugin native window. If the values and behavior of our custom window are different it is a bug on our side. if not we are just showing what the plugin is giving to us. That is what I meant by "it is what it is". If our custom window shows the same as the plugin we use is showing in its window we can't really fix it here.
OK, I see. - Unfortunately I can't open the plug-in's native window, as described, so perhaps my installation is just broken. - So I could try to reinstall and see what happens first, as long as I could backup the presets/settings or I'll have to make some notes or screenshots.
I'm reporting that it will not apply the values that are entered manually. - I can enter them, but they will jump back to the previous value that was already there. I can only "spin" the values, not enter them manually.
This bug has been solved. Can you compile the master branch? If you use Arch Linux, install
easyeffects-git. If you can't install it and have to wait the next release, try to write the number without the measurement unit.
Yes, sorry, I did notice your comment on it before. - I am on Pop! (for now) so basically Ubuntu. You're right, leaving out the unit works. I always just neatly click behind the number to then hit backspace, if not select just the numbers I want to change and start typing. - Was this the issue all along and this will be made so it doesn't matter that it's included or not, or was it something else? Is putting the unit of measurement on the "face" of the front-end, as in next to the box, an idea? Pretty much like the descriptive name above each box. Though it could look messy or odd when the boxes are long with a lot of space after the value, and also with the "arrows" in between.
OK, I see. - Unfortunately I can't open the plug-in's native window, as described, so perhaps my installation is just broken.
Not necessarily. The native window only opens when audio is passing through EasyEffects pipeline(this is one of the main reasons why it is still marked as experimental). Maybe you just tried to open it when EasyEffects was idle.
OK, I see. - Unfortunately I can't open the plug-in's native window, as described, so perhaps my installation is just broken.
Not necessarily. The native window only opens when audio is passing through EasyEffects pipeline(this is one of the main reasons why it is still marked as experimental). Maybe you just tried to open it when EasyEffects was idle.
Native audio windows are all still stuck on x11 right? The Flatpak sandbox permissions we have set do not include x11. We can change it but software stores will complain about it as it is less secure, which seems questionable to be doing for an experimental feature. But we should probably explain this better regardless.
@MicHaeL-MonStaR It was a bug introduced because we had to change the validator for the input text in spinbox. It's already fixed and the new version won't have the bug anymore.
For example, each Band has a Start and End Frequency, with each of them connected to the previous or next Band if there is one. - So, for example: You set Band 1 its End-value to 50Hz, that would be the Start-value of Band 2. (Or, actually, you would set the Start-value of Band 2, which would be the non-editable End-value of Band 1, which would always have a Start-value of 0Hz.) - But this is not the case anymore.
I fixed this. We were converting the value to dB, but that was not necessary since it's a frequency. This was only done in the MB Compressor, the MB Gate is fine. The fix will be in the next release
Band 1 still has non-editable Start and End frequencies
The band 1 is always enabled and the split frequency cannot be set because the option in the native plugin is missing. I think it's our error to show the disabled frequency spinbox in the first band, it should be hidden.
OK, I see. - Unfortunately I can't open the plug-in's native window, as described, so perhaps my installation is just broken.
Not necessarily. The native window only opens when audio is passing through EasyEffects pipeline(this is one of the main reasons why it is still marked as experimental). Maybe you just tried to open it when EasyEffects was idle.
I had a suspicion it might be that I tried when nothing was playing, but I also thought it should probably just open anyway. I've just tried it again with audio going through it, but it still doesn't come up with any native window. This isn't a big deal to me, but it would be interesting since I always wondered.
For example, each Band has a Start and End Frequency, with each of them connected to the previous or next Band if there is one. - So, for example: You set Band 1 its End-value to 50Hz, that would be the Start-value of Band 2. (Or, actually, you would set the Start-value of Band 2, which would be the non-editable End-value of Band 1, which would always have a Start-value of 0Hz.) - But this is not the case anymore.
I fixed this. We were converting the value to dB, but that was not necessary since it's a frequency. This was only done in the MB Compressor, the MB Gate is fine. The fix will be in the next release
Band 1 still has non-editable Start and End frequencies
The band 1 is always enabled and the split frequency cannot be set because the option in the native plugin is missing. I think it's our error to show the disabled frequency spinbox in the first band, it should be hidden.
Alright. I will see it when it's out on Flathub, I suppose. - I'll just not mess with the settings too much for now. Thanks for looking into it.
I've just tried it again with audio going through it, but it still doesn't come up with any native window.
Hum... In this case the reason must be what @vchernin explained above.
I've just tried it again with audio going through it, but it still doesn't come up with any native window.
Hum... In this case the reason must be what @vchernin explained above.
It probably is then. I don't know enough, but it does seem like it's simply "blocked" from showing up.
OK, I see. - Unfortunately I can't open the plug-in's native window, as described, so perhaps my installation is just broken.
Not necessarily. The native window only opens when audio is passing through EasyEffects pipeline(this is one of the main reasons why it is still marked as experimental). Maybe you just tried to open it when EasyEffects was idle.
Native audio windows are all still stuck on x11 right? The Flatpak sandbox permissions we have set do not include x11. We can change it but software stores will complain about it as it is less secure, which seems questionable to be doing for an experimental feature. But we should probably explain this better regardless.
What about doing the thing some applications do, where it will prompt for a password to put the permission into the user's hands? Not sure if that is the same thing or even possible. - But that could be a compromise to make it functional without just opening it up and have people take issue with it.
What about doing the thing some applications do, where it will prompt for a password to put the permission into the user's hands? Not sure if that is the same thing or even possible. - But that could be a compromise to make it functional without just opening it up and have people take issue with it.
What you suggest makes sense, but simply put this is not something Flatpak supports. As simply as possible there are three categories of apps Flatpak tries to support:
- Apps that can exclusively rely on wayland, with x11 provided strictly as a fallback (what easy effects currently does). This is the most secure (aside from always disallowing x11, but that is a bit pointless as it just hurts x11 desktops).
- Apps that only allow access to x11 and don't support wayland at all, which is not many apps these days.
- A special case includes apps like steam which offer both wayland and x11 access simultaneously. It is not very secure, as ideally there is no x11 access when using wayland, but it does mean these features where wayland is used for one window, and x11 for others, can actually work.
@wwmm what do you think? Should we allow x11 access by default in the flatpak build for this experimental feature? Or should we just try put a better explanation?
One compromise could be checking availbilty of the x11 socket. If the x11 socket is not there that means either x11 doesn't exist at all on the system, or the socket has not been granted by Flatpak. So then the user can be warned when they try to open the experimental window.
what do you think? Should we allow x11 access by default in the flatpak build for this experimental feature? Or should we just try put a better explanation?
I think that the native window is useful enough to justify an exception. We should allow access to it.
I also have the problem that I can't manually enter values. For me it's the equalizer. If I click the gear icon on top of a band and try to enter frequency, gain or Q-Factor, it just resets to the old value when I press enter.
I use Ubuntu 25, so gnome with Wayland iirc
