Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Port to Qt and new LSP 1.2.15 features #2960

Open
4 tasks
Digitalone1 opened this issue Mar 6, 2024 · 130 comments
Open
4 tasks

Port to Qt and new LSP 1.2.15 features #2960

Digitalone1 opened this issue Mar 6, 2024 · 130 comments

Comments

@Digitalone1
Copy link
Contributor

Digitalone1 commented Mar 6, 2024

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?

@wwmm
Copy link
Owner

wwmm commented Mar 7, 2024

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.

@Digitalone1
Copy link
Contributor Author

Do we need this? We do not wrap the crossover plugins.

No, you're right.

@Digitalone1
Copy link
Contributor Author

Digitalone1 commented Apr 8, 2024

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.

@wwmm
Copy link
Owner

wwmm commented Apr 8, 2024

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

image
image

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.

@Digitalone1
Copy link
Contributor Author

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:

image

Will Easy Effects have the same style?

@wwmm
Copy link
Owner

wwmm commented Apr 9, 2024

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...

@Digitalone1
Copy link
Contributor Author

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:

  1. collapsing widgets one over another (i.e. overlay the sidebar on top of the content box)
  2. 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.

@wwmm
Copy link
Owner

wwmm commented Apr 9, 2024

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

image
image

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.

@wwmm
Copy link
Owner

wwmm commented Apr 9, 2024

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

@Digitalone1
Copy link
Contributor Author

Digitalone1 commented Apr 11, 2024

Irony of fate, after the new Qt update, I got issues with their apps. I had to uninstall the decorations patch...

@wwmm
Copy link
Owner

wwmm commented Apr 11, 2024

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...

@Digitalone1
Copy link
Contributor Author

It turned out all apps using the latest version of Qt are broken on Gnome. -_-

@wwmm
Copy link
Owner

wwmm commented Apr 13, 2024

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.

@Digitalone1
Copy link
Contributor Author

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?

@wwmm
Copy link
Owner

wwmm commented Apr 13, 2024

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.

@wwmm
Copy link
Owner

wwmm commented Apr 13, 2024

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?

@Digitalone1
Copy link
Contributor Author

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?

@wwmm
Copy link
Owner

wwmm commented Apr 13, 2024

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.

@Digitalone1
Copy link
Contributor Author

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.

@wwmm
Copy link
Owner

wwmm commented Apr 13, 2024

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.

@Digitalone1
Copy link
Contributor Author

Now upstream qBittorrent works properly, but Chromium v124 is broken (not visible with ozone=wayland flag). What about your laptop with Gnome?

@wwmm
Copy link
Owner

wwmm commented Apr 13, 2024

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.

@wwmm
Copy link
Owner

wwmm commented Apr 13, 2024

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.

@Digitalone1
Copy link
Contributor Author

Same to me. --ozone-platform=wayland is working. --ozone-platform-hint=auto don't.

@wwmm
Copy link
Owner

wwmm commented Jun 14, 2024

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:

Wayland Client on Linux

  • Added a new window decoration style that is used on GNOME and uses similar styling as it.

@Digitalone1
Copy link
Contributor Author

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?

@wwmm
Copy link
Owner

wwmm commented Aug 21, 2024

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 =/

@Digitalone1
Copy link
Contributor Author

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...

@vchernin
Copy link
Contributor

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.

@wwmm
Copy link
Owner

wwmm commented Nov 16, 2024

Besides there's also this. This is a long sentence, I wonder if there's a way to format translations the same way as GTK mixing string parameters inside.

I see. The kde localization documentation seems to be this one https://techbase.kde.org/Development/Tutorials/Localization/i18n. There are some interesting things that gtk does not seem to provide but I did not notice yet if there is something that can be used to do what you want.

Now that I think about it that substitution is not because of gtk. It is the way that the fmt library is handling strings. So the strings in the c++ code will probably behave the same way as before. Just the ones on qml will needed a different handling. The last resort would be to define these strings on c++ and setting them as properties of a class that qml can read.

@wwmm
Copy link
Owner

wwmm commented Nov 16, 2024

Don't worry, I will let you know if I have time to implement another plugin. Maybe another simple one (Delay or Loudness)...

The "filter" plugin is probably simpler to implement than the delay. In the case of the delay I am considering to put in the custom ui the other controls we never added. After its native window became available on EasyEffects not providing the other controls became a big inconsistency.

@Digitalone1
Copy link
Contributor Author

The last resort would be to define these strings on c++ and setting them as properties of a class that qml can read.

Yes, indeed we were setting them from C++ in libadwaita because they needed to go through ftm::format.

The "filter" plugin is probably simpler to implement than the delay. In the case of the delay I am considering to put in the custom ui the other controls we never added. After its native window became available on EasyEffects not providing the other controls became a big inconsistency.

Okay, I will consider the Filter.

@wwmm
Copy link
Owner

wwmm commented Nov 16, 2024

@Digitalone1 just in case you haven't already noticed I've written a simple script to convert the gsettigns schema to kconfig schemas https://github.com/wwmm/easyeffects/blob/eeqt/util/convert_schema_to_kcfg.sh. Those regex probably can be better 😄 but the main flaw is that the script is not able to convert enums. Gsettings and kconfig handle enums in so different ways that I did not figure out how to automate this conversion. But for the other types the script has been working well.

@Digitalone1
Copy link
Contributor Author

I used sed very few times. I will test it when have time and let you know if there's something to improve it.

@Digitalone1
Copy link
Contributor Author

Digitalone1 commented Nov 17, 2024

@wwmm So I optimized the existing sed regex using https://sed.js.org/

Regarding the enums, they are very difficult. I think there's no way to replace them completely because you don't have choice names and it's even more difficult to extract the default enum.

I can suggest you to extract the enum list strings in a local bash variable (I suppose an array of strings). I don't know if you can extract strings with sed and save them to a local variable, but you can try.

So, if it's possible, extract the enum lists with the following regex:

  • <enum[^>]+>(?:\s*<[^/]+\/>)+\s*<\/enum>

Then remove enum lists and (default) keys from gsettings using the one above, plus an additional regex:

  1. <enum[^>]+>(?:\s*<[^/]+\/>)+\s*<\/enum>
  2. <key\sname="[^"]+"\s+enum="[^"]+"\s*>\s*<default>"[^"]+"<\/default>\s*<\/key>

If you can obtain an array of gsettings enum lists, loop them through a for cycle and apply the following sed substitutions to each single string:

  1. 's/<enum[^>]+>/<entry name="" type="Enum">\n\t<label><\/label>\t<choices>/g'
  2. 's/<value\s+nick="/\t\t<choice name="">\n\t\t\t<label>/g'
  3. 's/"\s+value="[^"]+"\s*\/>/<\/label>\n\t\t<\/choice>/g'
  4. 's/<\/enum>/\t<\/choices>\n\t<default><\/default>\n<\/entry>/g'

You should have an array of kcfg entry strings like the followings:

        <entry name="" type="Enum">
            <label></label>
            <choices>
                <choice name="">
                    <label>RMS</label>
                </choice>
                <choice name="">
                    <label>Peak</label>
                </choice>
            <default></default>
        </entry>

And then you can loop them and append each one to the output file just before the </group> closing tag.

If everything works, you have the entries with the correct labels, but you still have to add the names and the default value, but it's faster since you only have to fill the empty (label) tags and the name properties.

@wwmm
Copy link
Owner

wwmm commented Nov 17, 2024

I can suggest you to extract the enum list strings in a local bash variable (I suppose an array of strings). I don't know if you can extract strings with sed and save them to a local variable, but you can try.

Hum... I am thinking about it but the effort this is requiring may not be worth it. The plugin with the most tiring enums to manually convert is probably the limiter and this one is already done.

@Digitalone1
Copy link
Contributor Author

Hum... I am thinking about it but the effort this is requiring may not be worth it. The plugin with the most tiring enums to manually convert is probably the limiter and this one is already done.

You can still apply the last four substitutions. Then you will have the entry choices, but not in the right place, so you should copy and paste them in another place of the file.

The part of extracting the enums to a local variable was aimed to build the strings externally and then place them below the other entries.

@Digitalone1
Copy link
Contributor Author

@wwmm In the next days I'm trying to implement the Filter. I think to make two centered cards with controls within them.

@Digitalone1
Copy link
Contributor Author

@wwmm Related to #3513:

  • At the moment we are missing the warning signal/icon (present in libadwaita) when output level > 0 dB.
  • Can we do something to fix the dB unit of the output level like we did in libadwaita? At the moment it keeps moving since the size of the values is always changing.

@wwmm
Copy link
Owner

wwmm commented Nov 20, 2024

@wwmm Related to #3513:

* At the moment we are missing the warning signal/icon (present in libadwaita) when output level > 0 dB.

* Can we do something to fix the `dB` unit of the output level like we did in libadwaita? At the moment it keeps moving since the size of the values is always changing.

I am looking into this and I think I may have to reconsider the idea of using a Kirigami.ActionToolBar to show these values in the bottom bar. Initially I thought I would be able to easily fix this problem using the function padStart from javascript. And if I force it to use a character like * it works. But somehow it doesn't with spaces. Not because padStart is failing. It is doing its job. It seems that Kirigami.ActionToolBar's code is somehow trimming empty spaces. What removes the fix padStart did.

The reason why I prefer to use Kirigami.ActionToolBar when possible is that it automatically moves its widgets to a menu when there is not enough horizontal space. But in this case it may be better to use the traditional Qt ToolBar instead.

@wwmm
Copy link
Owner

wwmm commented Nov 21, 2024

I am looking at our gtk code and the solution there was to put the dB unit in its own label. I will see if this has the same effects here.

@wwmm
Copy link
Owner

wwmm commented Nov 21, 2024

I am looking at our gtk code and the solution there was to put the dB unit in its own label. I will see if this has the same effects here.

No. The auto resize is still a problem. Some kind of solution where a fixed size can be used will be necessary. Now I see that we did the same in the gtk code. The number of characters of the label is fixed.

@Digitalone1
Copy link
Contributor Author

Digitalone1 commented Nov 21, 2024

The trick we used in Libadwaita was to set a fixed width for each value: 4 characters for both left and right should be enough.

@wwmm
Copy link
Owner

wwmm commented Nov 21, 2024

The trick we used in Libadwaita was to set a fixed width for each value: 4 characters for both left and right should be enough.

I think that replicating this with any of the layout managers will be impossible because they handle height and width themselves. And they really want to resize the label based on the text size. Usually this is a good thing but not this time. I will investigate how the containers based on anchors behave.

@Digitalone1
Copy link
Contributor Author

Digitalone1 commented Nov 21, 2024

@wwmm I see a new Shift gain control for the LSP Filter. Should we add it?

Update: I see we return 0.0F for the latency in the filter, but it has the out_latency port as other LSP plugins. Why?

@wwmm
Copy link
Owner

wwmm commented Nov 21, 2024

I see a new Shift gain control for the LSP Filter. Should we add it?

Its documentation suggests it is used in the native window graphical analysis https://lsp-plug.in/?page=manuals&section=filter_stereo. We do not need to wrap these kind of controls.

Update: I see we return 0.0F for the latency in the filter, but it has the out_latency port as other LSP plugins. Why?

Hum... Maybe nothing it does actually adds latency. I do not remember. Try to print its value in the terminal while experimenting with different filter options. If it is always zero we can keep ignoring it.

@Digitalone1
Copy link
Contributor Author

Hum... Maybe nothing it does actually adds latency. I do not remember. Try to print its value in the terminal while experimenting with different filter options. If it is always zero we can keeping ignoring it.

I don't know how to do it, but isn't it better to read them anyway even if they are 0? Maybe in the future something changes and we won't have to implement it...

@wwmm
Copy link
Owner

wwmm commented Nov 21, 2024

I don't know how to do it, but isn't it better to read them anyway even if they are 0? Maybe in the future something changes and we won't have to implement it...

It is fine to do that. Maybe I did not do it in the past because the approach was to emit signals to update the latency. What would produce useless signals in this case. But it is different now.

@wwmm
Copy link
Owner

wwmm commented Nov 21, 2024

  • Can we do something to fix the dB unit of the output level like we did in libadwaita? At the moment it keeps moving since the size of the values is always changing.

After trying several things and failing to do it, even when using a custom Label through Kirigami.ActionToolBar property displayComponent or an independent label outside of the actionbar, I decided to ask chatgpt about it. And to my surprise it actually suggested a solution that worked! 😄

The trick was using richtext to disable the automatic removal of white spaces that Qt does by default. Now I will try to bring the saturation icon back.

@Digitalone1
Copy link
Contributor Author

Digitalone1 commented Nov 21, 2024

Good work for the saturation icon and the output level.

But, am I doing something wrong or the plugin bypass is not working for all effects?

Update: Besides, if I change a control in EE when the native UI is open, the app crash with a core dump.

@wwmm
Copy link
Owner

wwmm commented Nov 21, 2024

But, am I doing something wrong or the plugin bypass is not working for all effects?

Not yet. It will probably be just a matter of using the plugin database instance as argument of

pluginsListModel.append({
. But if we try to do this now we will probably get segmentation faults if a plugin that was not implemented is added to the list. So I am waiting for all the plugins to be ready before working on the bypass button.

Update: Besides, if I change a control in EE when the native UI is open, the app crash with a core dump.

Strange. I can change the custom window parameters while the native windows are opened without problems. The only one that made the app freeze once was the Stereo Tools native window. But no segmentation faults so far.

@wwmm
Copy link
Owner

wwmm commented Nov 21, 2024

Are you able to see what gdb shows about the segmentation fault?

@Digitalone1
Copy link
Contributor Author

Are you able to see what gdb shows about the segmentation fault?

Unfortunately not, I restarted the laptop. Can you tell me what I should do to take note of a segmentation fault? I may not have the proper tools since I'm using a new laptop.

I was also thinking to open a new issue to track other things to do for the Qt port in a list. This issue is for discussions only (it wasn't even started for the Qt port either...).

@wwmm
Copy link
Owner

wwmm commented Nov 21, 2024

Unfortunately not, I restarted the laptop. Can you tell me what I should do to take note of a segmentation fault? I may not have the proper tools since I'm using a new laptop.

If you run sudo coredumpctl list and then sudo coredumpctl gdb pid you may still be able to see what happened. Assuming that the crash is easy to reproduce just run sudo coredumpctl gdb as soon as a crash happens.

@Digitalone1
Copy link
Contributor Author

Okay, I'll try to do it if a core dump happens.

I noticed also that we don't read the latency from calf plugins. Is there a reason? Maybe calf don't report it? It's weird since also an old plugin like zamaudio maximizer is signaling the latency.

@wwmm
Copy link
Owner

wwmm commented Nov 21, 2024

Maybe calf don't report it?

It was the case in the past. I do not know if things have changed. But I doubt some plugins like the bass enhancer or the exciter add latency. So maybe the ones we use really do not add anything to it.

@wwmm
Copy link
Owner

wwmm commented Nov 22, 2024

I am looking at the presets manager member that scans community presets directories recursively and a question came to my mind. Was there a reason to not use https://en.cppreference.com/w/cpp/filesystem/recursive_directory_iterator ?

@Digitalone1
Copy link
Contributor Author

Digitalone1 commented Nov 22, 2024

I am looking at the presets manager member that scans community presets directories recursively and a question came to my mind. Was there a reason to not use https://en.cppreference.com/w/cpp/filesystem/recursive_directory_iterator ?

Maybe I missed that function, but we needed also to track the depth of the subfolder since we specified the community presets should be contained in the first or the second level of the package name directory: https://github.com/wwmm/easyeffects/blob/master/COMMUNITY_PRESETS_GUIDELINES.md?plain=1#L212-L214

This could be checked with the depth method: https://en.cppreference.com/w/cpp/filesystem/recursive_directory_iterator/depth

Besides, in some parts of the code, we need only to scan the top level to retrieve the package names, so we need the classic iterator at least for this purpose.

So I suppose the classic iterator to retrieve the package names and the recursive iterator to retrieve the presets inside each package directory, but only on two levels (depth 0 and 1).

@wwmm
Copy link
Owner

wwmm commented Nov 22, 2024

I see. For now I will just copy the function as it is. But it may be a good idea to add to the todo list the port to the standard library function and it's depth call to simplify this code a little.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants