easyeffects
easyeffects copied to clipboard
wwmm
Port to Qt and new LSP 1.2.15 features
I wonder if there's something new we can implement. https://github.com/lsp-plugins/lsp-plugins/releases/tag/1.2.15
- [ ] Implemented Hold option for Compressor, Dynamics Processor, Expander and Gate plugin series.
- [ ] Implemented Hold option for Multiband Compressor, Dynamics Processor, Expander and Gate plugin series.
- [ ] Added Dry/Wet balance control for Compressor, Dynamics Processor, Expander, Gate and Trigger plugin series.
- [ ] Added Dry/Wet balance control for Multiband Compressor, Dynamics Processor, Expander, Gate and GOTT Compressor plugin series.
Anything else?
Added support of LR2 (12 dB/oct) filters by the Crossover plugins series. Added S/M Apply switch to Crossover plugin series that applies effect of Solo/Mute buttons to corresponding frequency band's outputs.
Do we need this? We do not wrap the crossover plugins.
Do we need this? We do not wrap the crossover plugins.
No, you're right.
I understand the hold control thanks to this.
But the balance mix/dry is really needed? I can't test it now, but aren't mix and dry levels enough?
Anyway I was also thinking to begin to slowly switch plugins based on plain GTK UI with grids of spinbuttons to the Libadwaita preferences rows.
I feel having all plugins structured like the Filter with two columns of preferences rows is more clean and ordered rather than having a bunch of spinbuttons like the old way.
For compressors/gates I'd like to keep the stackview, but with controls ordered in preferences rows inside every pages.
But if the app will eventually switch to Qt/Qml, this would be useless... I don't know.
Update: The only old one I'd like to keep it's the Equalizer. Maybe moving only the tones and the balance controls in a bottom preferences rows because they prevent the page to be more shrunk horizontally. But overall it's the only structure I will keep as it is because having an Equalizer with horizontal bands/rows feels very weird.
But the balance mix/dry is really needed? I can't test it now, but aren't mix and dry levels enough?
I also think they are enough considering EE purpose is not as broad as the typical digital audio workstations.
Anyway I was also thinking to begin to slowly switch plugins based on plain GTK UI with grids of spinbuttons to the Libadwaita preferences rows. I feel having all plugins structured like the Filter with two columns of preferences rows is more clean and ordered rather than having a bunch of spinbuttons like the old way.
I have been thinking about doing this for a while. Feel free to do it.
For compressors/gates I'd like to keep the stackview, but with controls ordered in preferences rows inside every pages.
I agree. It is probably the most that can be done there.
The only old one I'd like to keep it's the Equalizer. Maybe moving only the tones and the balance controls in a bottom preferences rows because they prevent the page to be more shrunk horizontally. But overall it's the only structure I will keep as it is because having an Equalizer with horizontal bands/rows feels very weird.
Yes. It makes sense. Horizontal sliders there will feel out of place because no one else does this in a equalizer.
But if the app will eventually switch to Qt/Qml, this would be useless... I don't know.
Not at all. My intention is to replicate our current layout as much as possible. I still have a lot to do in the fastgame repository I've created for its qt port but so far it is becoming like this
If you compare to the images of its current libadwaita window https://github.com/wwmm/fastgame you will see that putting some style differences aside the layout is the same. Considering that I am working more under the hoods than on style they are already quite similar.
Just keep on doing what you have always done. Unless it is impossible to replicate outside of adwaita it will be in the Qt port if it actually happens.
I also think they are enough considering EE purpose is not as broad as the typical digital audio workstations.
But this control is weird. If I change it, should mix/dry levels change accordingly? In example, if I set 50%, I expect both levels to be at something below 0 dB and not -inf, but they don't change (I tested it in the native UI)...
If you compare to the images of its current libadwaita window https://github.com/wwmm/fastgame you will see that putting some style differences aside the layout is the same. Considering that I am working more under the hoods than on style they are already quite similar.
Ok. I was also wondering about the features that now we have for free. In example, the list sorter and the search entry. We don't sort the lists (we did before with vectors, but it was useless since it's done by GtkSorter) and do not implement the search function directly (except for the community presets, but only to extract the last part of the string). Are there these features in Qt?
Besides, talking about Qt apps, I notice that qBittorrent UI does not have good borders on Gnome. See:
Will Easy Effects have the same style?
But this control is weird. If I change it, should mix/dry levels change accordingly? In example, if I set 50%, I expect both levels to be at something below 0 dB and not -inf, but they don't change (I tested it in the native UI)...
I admit I am also a little confused. Maybe the balance is being applied after the dry/wet values are applied. Let's say that we have dry at 20% and wet at 70%. Maybe instead of changing the percentages the balance is mixing the signals resulting from these operations using a different mixing percentage. But if that is the case it feels somewhat useless. So I imagine something else is going on...
Ok. I was also wondering about the features that now we have for free. In example, the list sorter and the search entry. We don't sort the lists (we did before with vectors, but it was useless since it's done by GtkSorter) and do not implement the search function directly (except for the community presets, but only to extract the last part of the string). Are there these features in Qt?
I did not get to the part where I will have to think about the listview filtering/sorting yet but it seems to be done through https://doc.qt.io/qt-6/qsortfilterproxymodel.html. So I do not expect this to be much trouble. I am more concerned about what to do about the database. That is why I do not dare saying that the port is guaranteed.
Besides, talking about Qt apps, I notice that qBittorrent UI does not have good borders on Gnome. See: Will Easy Effects have the same style?
I finally had time to do some tests on my laptop where I still have gnome as desktop. That situation sucks indeed. After spending some time searching about what the hell is going on with the borders I figured it out and it is not good. It is the "war" between KDE and gnome about client side decorations all over again...
If you launch a Qt app in gnome in x11 mode through QT_QPA_PLATFORM=xcb then everything is fine with the border because for x11 apps gnome mutter adds a server side decoration. But it does not do it for wayland apps. So when a Qt app starts in wayland mode in gnome it gets no border. On KDE things are fine because it adds the decoration for both wayland and x11 apps. As expected considering it prefers server side decorations. But at least they did some level of integration for client side decorations. At least for gtk apps. So both sides look decent there.
There is a closed issue about this situation in the Mutter repo that was closed without any intention of fixing this on their side... They seem to expect this to be fixed by third party plugins... Or that each toolkit that is not gtk figure by themselves how to make things to be good in managers that support only CSD... So Qt has to find its own way, SDL too and so on...
For now the solution for the border is installing https://aur.archlinux.org/packages/qadwaitadecorations-qt6. I did it and Qt6 apps were fine after that. A similar package exists for Qt5... Qadwaitadecorations still is actively developed by Fedora's people and was not abandoned like the previous attempts. At least not yet...
Yes, this situation is definitely frustrating. And in some ways unfair. Being stuck to a toolkit just because gnome does not want to provide a minimal server side decorations for wayland apps when they do it for x11 apps is not reasonable...
Well... For the time being I will keep my investigations about this issue while I keep porting fastgame to Qt. EE code base is big enough for the same movement to take many months or more than a year anyway. So there is no need to take a decision now. There is time to watch how this csd mess evolve. Maybe some improvements will be made to Qt's csd support in the next releases. Maybe the plugins will become more mature. But at least on gnome's side it is clear nothing will be done...
I installed qtadwaitadecorations and the situation is better. But I honestly don't like installing those additional packages because I expect they are likely to break on new Qt versions.
Anyway, what I like about Libadwaita is that they are building an adaptive toolkit that will be suitable for both desktop and mobile devices. This mean Easy Effects could be more usable on mobile phones in the future.
What we miss now is a wrapper system for widgets. Basically at the moment Libadwaita is doing adaptive layouts in two ways:
- collapsing widgets one over another (i.e. overlay the sidebar on top of the content box)
- hiding widgets to show only the main ones (i.e. hide the content box to show only the sidebar)
Luckily they have this in the roadmap. Widgets should be always visible, but they wrap on shorter widths. This is the best solution. In example we can retain the same layout for desktops but showing both effects list and effect box on mobile devices just having one on top of another, so the user just have to scroll vertically without having to hide one of them.
The same could be done for effects boxes. In example the Filter effect can show the two adw preferences groups in horizontal orientation on desktops, but on mobile devices they will be displayed in vertical orientation.
I don't know if Qt has something similar on its roadmap.
But I honestly don't like installing those additional packages because I expect they are likely to break on new Qt versions.
The plugin author seems to have the intention to have the plugin upstreamed to Qt someday. I hope he succeeds...
I don't know if Qt has something similar on its roadmap
Qml has touch devices as its main target and the kirigami library developed by KDE's developers add some facilities to it in this regard. For example that side panel in my last images can become like this
I think I've saw somewhere a way to detect if Qt is on mobile or not. So it is probably possible to switch modes on the fly. It is just that for now I am forcing it to be like a standard side panel.
Maybe kirigami/qml has some edge on this because of the fact Qt is actually used on multiple platforms while gtk is multiplatform only on paper. And KDE is the one Valve is using on Steam Deck. Also along the way I think I've seen Android code to make packages for some kde kirigami apps. I doubt there are many using these kde apps on Android. But it is probably more than people using gtk/adwaita on mobile.
But honestly I think that on both libraries some level of redesigning is necessary in order to be good both on desktop and on mobile. Issue #2955 is there to prove that just using the library is not enough unless the app is very simple.
I think I've saw somewhere a way to detect if Qt is on mobile or not.
I actually have this line in the code for the custom spinbox https://github.com/wwmm/fastgame/blob/05972cea61fbe08a96bb7f5fce1259c9a0dd96e2/src/contents/ui/FgSpinBox.qml#L38
Irony of fate, after the new Qt update, I got issues with their apps. I had to uninstall the decorations patch...
Irony of fate, after the new Qt update, I got issues with their apps. I had to uninstall the decorations patch...
Same thing on my laptop. After recompiling the plugin the apps stopped crashing. But there is no border... Until this becomes a part of Qt or gnome goes back in that horrible decision, what is very unlikely, this will keep happening...
It turned out all apps using the latest version of Qt are broken on Gnome. -_-
It turned out all apps using the latest version of Qt are broken on Gnome. -_-
By broken do you mean there is no border but everything else is fine or broken as in the apps do not even open? Before removing or recompiling the plugin in my laptop they did not open. But after recompiling it they work. But without borders. In other words the plugin does nothing until it is updated to the latest Qt.
By broken do you mean there is no border but everything else is fine or broken as in the apps do not even open? Before removing or recompiling the plugin in my laptop they did not open. But after recompiling it they work. But without borders. In other words the plugin does nothing until it is updated to the latest Qt.
The app opens, but it's not visible. Do you confirm that recompiling against the latest Qt version resolves the issue on Gnome? Which app did you test? Fastgame? Can you open Qt apps from Arch repo?
By broken do you mean there is no border but everything else is fine or broken as in the apps do not even open? Before removing or recompiling the plugin in my laptop they did not open. But after recompiling it they work. But without borders. In other words the plugin does nothing until it is updated to the latest Qt.
The app opens, but it's not visible. Do you confirm that recompiling against the latest Qt version resolves the issue on Gnome? Which app did you test? Fastgame? Can you open Qt apps from Arch repo?
I tested fastgame and qbittorrent. With the plugin there before the recompilation or its removal qt apps crashed instantly. Removing the plugin was enough for qbittorrent to open for example. The only issue is the one from before about the borders. It is like the plugin isn't even there even if it compiles in the latest Qt.
Just to confirm things I've updated my laptop again and tried QT_QPA_PLATFORM=wayland qbittorrent and QT_QPA_PLATFORM=xcb qbittorrent to see if something different happened when forcing wayland or x11 but both cases worked. The difference is only the x11 mode having the borders. Do you see any error in the system's logs?
So you recompiled qBittorent? It's not showing yet to me. I had to install the Flatpak version to use it.
But I compiled a small Qt6 app from AUR and it's working, maybe all the apps should be recompiled?
So you recompiled qBittorent? It's not showing yet to me. I had to install the Flatpak version to use it.
No. I did not express myself well. First I removed the qadwaitadecorations-qt6-git package I had installed. This made Qt apps to open again. But without the borders. Then I recompiled qadwaitadecorations-qt6 to see if the borders would come back but they did not. Probably because qadwaitadecorations-qt6 needs patches for Qt 6.7.
There was no need to recompile qbittorrent here.
Well, I don't know how they work to you, but upstream qBitorrent was not working to me, even after removing qadwaita decorations. I also opened a thread on Arch forum and other people have the same issue.
Well, I don't know how they work to you, but upstream qBitorrent was not working to me, even after removing qadwaita decorations. I also opened a thread on Arch forum and other people have the same issue.
Strange. I do not even have KDE installed in my laptop. Just the minimum amount of dependencies that were necessary to install qbitorrent from the stable Arch repo and to compile and run fastgame there. My guess is that there is some kind of configuration somewhere breaking Qt.
Now upstream qBittorrent works properly, but Chromium v124 is broken (not visible with ozone=wayland flag). What about your laptop with Gnome?
Now upstream qBittorrent works properly, but Chromium v124 is broken (not visible with ozone=wayland flag). What about your laptop with Gnome?
It is fine if I just click on its launcher icon. I imagine that in this case it is using x11. If I use --ozone-platform-hint=auto as explained in Arch's wiki not only it does not work but the laptop freezes. Maybe some compatibility issue with the GPU. But if I use --ozone-platform=wayland it is fine.
In the desktop where I use KDE and the hardware is completely different --ozone-platform-hint=auto also does not work. The desktop doesn't freeze like the laptop but the window is not shown. The other option worked on both computers.
Same to me. --ozone-platform=wayland is working. --ozone-platform-hint=auto don't.
As this discussion's topic has already diverged :smile: I will put this information here for the future. It seems that Qt 6.8 will fix the lack of borders on GNOME https://doc-snapshots.qt.io/qt6-dev/whatsnew68.html:
Wayland Client on Linux
- Added a new window decoration style that is used on GNOME and uses similar styling as it.
As this discussion's topic has already diverged 😄 I will put this information here for the future. It seems that Qt 6.8 will fix the lack of borders on GNOME https://doc-snapshots.qt.io/qt6-dev/whatsnew68.html:
I'm waiting Arch repo to release Qt 6.8 and try out this new style.
But on EE I don't really mind about the GUI since the app should work in background most of the time. Anyway, since I see you are working on the porting to Qt, I wonder if there will be a way to completely close the GUI or Gnome users should have it open for the whole session.
This may seem a dumb question, but some apps like qBittorrent have the tray support disabled on Gnome, which means the app is shutdown if the GUI is closed. Will it be the same for EEqt or could we close the GUI but still having the service running as the current version?
But on EE I don't really mind about the GUI since the app should work in background most of the time. Anyway, since I see you are working on the porting to Qt, I wonder if there will be a way to completely close the GUI or Gnome users should have it open for the whole session.
This may seem a dumb question, but some apps like qBittorrent have the tray support disabled on Gnome, which means the app is shutdown if the GUI is closed. Will it be the same for EEqt or could we close the GUI but still having the service running as the current version?
I definitely want it to work fine in the background also in GNOME. Now that you talked about it I decided to do some tests on my laptop where I still have GNOME. If the appindicator extension is installed qbitorrent and my fastgame app close to tray as expected. But if this or similar extensions are not available fastgame crashes with a dbus error when it tries to minimize to tray. That is probably the reason why qbittorrent is detecting if tray support is there and disabling the whole thing.
Although any of the tray extensions solves the problem forcing people to have an extension is not nice. I will try to see what else can be done in this case... I thought GNOME was just not showing the tray icons. But they didn't even keep in place the bare minimum for apps that use tray to keep running in the background... I thought I could get away with some form of basic interprocess communication to make the window visible again when the user clicked on the launcher icon but this clearly is not going to work if the default behavior is crashing on GNOME =/
This is not promising... ^^
I can always send the app to an empty workspace if I should keep it opened, but this seems a regression since now I have it closed the whole time...
I'm not sure what apps actually do when attempting to close to tray, in any case a tray clearly cannot be assumed to exist in gnome. But it is possible for an app to not show any window, which will lead to the app being listed as a background app in the gnome top right system control menu. This feature may only work properly for flatpaks though, other install types may not show up in the background app list at all.
I'm not sure what apps actually do when attempting to close to tray, in any case a tray clearly cannot be assumed to exist in gnome.
Based on the error message Qt tried to access some kind of DBUS interface dedicated to tray menus/icon. And as GNOME does not implement it it crashed. So yes, we can't assume this to be available in GNOME. But this is easy to avoid. I just have to read XDG_SESSION_DESKTOP and XDG_CURRENT_DESKTOP to disable the tray if the session is a GNOME session. We already do something like this to handle the manual when inside KDE.
I will investigate if a combination of QLockFile and QLocalSocket will be enough to have a background service that works for everybody. I already use the lockfile to avoid multiple instances in the qt branch. But I think I will need some kind of server to handle the opening/closing of the window as well as some of the command line options that need to get results from the service instance. This approach will probably work. It is just annoying that a more complex solution is necessary just because of GNOME...