The GTK4 port has started :D

[wwmm]

GTK4 branch GTK4 https://github.com/wwmm/pulseeffects/tree/gtk4. There is still a long way to go. So far there is only a bare-bones main window and the presets menu. There are many small changes that will have to be done in all the interface files. And I will have to update each interface xml manually. So the whole process may take a while...

I have been thinking about the port and there are a few things I would like to implement in a different way:

• Something has to be done about issue [Question] [GUI] Why can I move applications vertically? #559. I have an idea about how to improve this situation
• C++ Boost is a big dependency that from time to time causes some issues to package maintainers when the version available in the repository is not new enough. At this moment there are two reasons why we use Boost. Reading and writing json files and calculating spline interpolations in the spectrum. I am not sure what to do about the spline but I will investigate if the JSON-GLib library is a suitable replacement https://gitlab.gnome.org/GNOME/json-glib for our presets needs. GLib is already a dependency that is not going away.
• I will try to simplify our GStreamer pipeline in preparation for a full PipeWire move in the future. When I began this project I had to deal with plugins that do not have a built-in bypass toggle. Mostly ladspa plugins. And as I did not know much about GStreamer's dynamic pipelines the way I found to add a bypass at the time was to wrap each plugin in a GStreamer bin. And what the bypass toggle does is adding or removing the plugin from its container... And the plugin order is changed by moving the containers around. It does not have to be this complicated... My plan is to simplify this in a way that will require as little change to the interface as possible once I try to replace GStreamer by PipeWire filters.

This list will be updated when more things come to my mind. In the last days I have been playing with the presets menu. The new listview concept in GTK4 is interesting. And adding search functionality to the presets menu was quite easy

I have decided to take the opportunity to do a redesign of a few things in this menu. And to show the last used preset in the menu bottom instead of the menu button. As we have input and output effects but both of them were updating the same button things were too confusing. I would not say that the new design is final. I will test it while I start the work in the settings menu.

[wwmm]

Something has to be done about issue #559. I have an idea about how to improve this situation

What I am thinking about is adding a "bottom panel" with a stack switcher at the center. This switcher will have to entries: Applications and Plugins. Similar to what happens in the settings menu. I think this will remove the current confusion. I also intend to move some of the audio information displayed in our headerbar to this bottom panel together with the global volume level meters that at this moment are besides the "Application" label in the plugins list.

[wwmm]

I testing new ideas for the settings menu. And for our SpinButtons

At least to me it seems good.

[Mlocik97]

I like it. But I would little rearange these color settings in spectrum so there is no that much blank white space. Maybe put it to 2nd column in grid between these spinButtons and numfields.

[wwmm]

But I would little rearange these color settings in spectrum so there is no that much blank white space

I've noticed this. Not sure what to do about it. When the menu has too much width things are not nice for tiling window manager users #885. But at the same time I do not know if it is possible to offer good support for them with the amount of widgets we have to control...

[wwmm]

New Players tab

This new approach fixes #559. New Plugins tab

It should fix #725. But the hardest part comes now. Implementing the plugin selection under the hoods. I will see how complicated it will be to do that in a 100 % PipeWire solution without GStreamer. If things get too hard it will be done with GStreamer.

I will have to rethink the spinbuttons in the first menus images. Gtk4 did not like the idea of inserting labels into them. Random crashes and warnings...

[Mlocik97]

This is starting to look really great. I love it.

[wwmm]

It took me some time but I was finally able to write a simple wrapper for LV2 plugins. With it I could finally take the decision of moving the effects pipeline from GStreamer to native PipeWire filters. This is a huge improvement. There is no need for us to manage real time priorities anymore. PipeWire will handle that for the filters threads. The code to handle the plugins is simpler now. There is no need anymore to launch recording streams for our effects pipelines. Now I can just link the sink to the first filter and the last one to the output device. No need for something in the middle. And hopefully the bugs that usually come when we have to take data away from the server to an external framework, GStreamer in our case, and back to the server will all be gone :-).

I have already ported a few plugins

I think I will be able to port almost all the plugins we used before to PipeWire filters. The RNNoise may be a little harder with its requirement of buffer of 480 samples =/... But it should be possible. But the WebRTC plugin may be problematic. The one we use right now is a GStreamer plugin. I do not know which alternative could be used... Let's see if some ideas come in the future.

[wwmm]

And there is also the test signal pipeline. I still have to see how much work will be necessary to replace GStreamer there...

[Ikkevoid]

A lot of developers started to round the bottom corners in the apps, starting from gtk4 you can do it from css easily. What do you think about doing this in pulseeffects?
https://www.flathub.org/apps/details/com.usebottles.bottles
https://www.flathub.org/apps/details/org.gnome.gitlab.YaLTeR.Identity

[wwmm]

What do you think about doing this in pulseeffects?

I do not see any problems in doing that. The top corners are already round. So the bottom ones could be too. Do you know what they are putting in the css files?

[Ikkevoid]

Unfortunately I don't know, sorry. You can look at souk https://gitlab.gnome.org/haecker-felix/souk It's written in gtk4, and it has rounded corners, maybe it will help you somehow. Good luck, you are doing an amazing job!

[wwmm]

You can look at souk https://gitlab.gnome.org/haecker-felix/souk

Although I could not find the code that makes its window corners rounded it helped to find a way to do it

[Ikkevoid]

I was thinking about it, and I feel that pulse effects started to be cluttered a little, so I made a mock-up with settings in its own window. Also, the plugins reordering icons only show when you hover at the plugin. What do you think about it?

[wwmm]

I feel that pulse effects started to be cluttered a little

Being honest it has always been cluttered a lot since its early days XD. The problem is that for more advanced users(myself included) it is important to have easy access to some information and functionality.

I made a mock-up with settings in its own window

It is not a problem to have the global settings in its own window. But I did not understand how this window is being called in your mock-up. I did not notice any visible button to open it.

Also, the plugins reordering icons only show when you hover at the plugin

I agree. These buttons do not have to be shown all the time. But I did not understand how that icon besides the trash icon is supposed to be used. Only one icon to move up and down? I also did not understand if the icon in front of the plugin name has a purpose or if it is only for the looks.

What do you think about it?

I like the looks but there is one big problem in this approach. Having only one Players tab is not enough because the input effects pipeline has a different application list

I did not show this image before because I am not working in the microphone pipeline yet. But this is something that is already the case in all PulseEffects releases. One pipeline has players and the other applications that record the microphone. So at least one more tab like Recorders would be needed.

I am also not sure I like the idea of not having status information easily visible all the time. In this kind of application more advanced users need to be able to see the global level meters all the time. Having to open a new section to see this kind of information is annoying because we have to get out from the plugins controls we are using.

[wwmm]

In the presets menu proposal i s the new preset name entered where the Preset word is located? We also need place for a preset importing button.

As the input and the output pipeline use different presets this menu would have to be synced somehow when switching between sections. I think that it can be done. I am not sure about how the users will react to the fact that they will need to switch sections to access the presets of another pipeline. But it is not the end of the world.

[Ikkevoid]

About the reordering:
https://cdn.dribbble.com/users/951993/screenshots/6314238/drag_reorder_1.gif

It is not a problem to have the global settings in its own window. But I did not understand how this window is being called in your mock-up. I did not notice any visible button to open it.

Those global settings is called when you click the edit icon on the preset, but when I start to think about it, it's not such a good idea.

[wwmm]

But I did not understand how that icon besides the trash icon is supposed to be used

Same question in the presets menu. One button should be doing preset autoloading. Is the load button replaced by direct clicks in the line?

https://cdn.dribbble.com/users/951993/screenshots/6314238/drag_reorder_1.gif

I suspected that. The only problem is that it was ridiculously not obvious how to implement row dragging in gtk3 and I still have no idea about how this is supposed to be implemented in gtk4. I would need to find some code examples.

[wwmm]

Those global settings is called when you click the edit icon on the preset, but when I start to think about it, it's not such a good idea.

Definitely not. They are totally unrelated.

[Ikkevoid]

Same question in the presets menu. One button should be doing preset autoloading. Is the load button replaced by direct clicks in the line?

Yes, probably direct clicks, and the checkmark icon is next to the used preset

I agree. These buttons do not have to be shown all the time. But I did not understand how that icon besides the trash icon is supposed to be used. Only one icon to move up and down? I also did not understand if the icon in front of the plugin name has a purpose or if it is only for the looks.

It looks good, I was thinking about making a unique icon for every plugin, So it would be easier to move around the plugins.

[Ikkevoid]

I suspected that. The only problem is that it was ridiculously not obvious how to implement row dragging in gtk3 and I still have no idea about how this is supposed to be implemented in gtk4. I would need to find some code examples.

If you use gnome, in the language and region settings there is a list reordering that uses one button, https://gitlab.gnome.org/GNOME/gnome-control-center/-/tree/master/panels/region

[wwmm]

It looks good, I was thinking about making a unique icon for every plugin, So it would be easier to move around the plugins.

It sounds interesting but it may be hard to keep this going as more and more plugins are added. Specially because I have no icon design abilities and I am the one usually adding plugins. So some kind of generic icon is necessary. Maybe one icon for each kind of plugin. But even then it may be hard to make different icons for each.

[Ikkevoid]

I could make all the icons for the plugins, and if you add a new plugin there would be a generic icon until I/someone else makes the icon, how about it?

[Ikkevoid]

I was thinking about moving the settings somehow, But the more I think about it the more I think it's a bad idea, I'll try to think about ordering the items in the tooltip better, but you've made an excellent job in making them. So the settings will have to stay the same

[wwmm]

I could make all the icons for the plugins, and if you add a new plugin there would be a generic icon until I/someone else makes the icon, how about it?

In this case no problems. Considering that we have more than one plugin of the same type(compressors and gates for example) it may be a good idea to think about icons for categories of plugins. But if you are in the middle of a very creative moment go ahead :-)

If you follow the category path you can have some idea of the possible categories reading this link https://lv2plug.in/ns/lv2core#Plugin

[wwmm]

The presets menu apply settings to the output pipeline or to the input pipeline. Wouldn't be better to have the names and icons of the sections matching the ones in the main window?

[wwmm]

And we also have to think how the test signals will be accessed. Right now this is done through the "sine wave" button in the header bar. Maybe it should become another section like input, output and info

[wwmm]

there is a way to convert to old json file to the new one?

There is but it is an annoying manual process. I did a few attempts along the way. The main step is removing the quotes from numbers. This site helps with this https://csvjson.com/json_beautifier. Paste the file content on the left side and check no quotes on numbers on the right panel. The problem is that it does not do that to booleans. So I had to use "search and replace" in a editor to replace "true" and "false" by true and false.

Maybe there is something else I do not remember. In order to ease this process I kept the keys with the same names. Hopefully someone will be able to write a script that converts the old presets to the new format.

[Gontier-Julien]

there is a way to convert to old json file to the new one?

There is but it is an annoying manual process. I did a few attempts along the way. The main step is removing the quotes from numbers. This site helps with this https://csvjson.com/json_beautifier. Paste the file content on the left side and check no quotes on numbers on the right panel. The problem is that it does not do that to booleans. So I had to use "search and replace" in a editor to replace "true" and "false" by true and false.

Maybe there is something else I do not remember. In order to ease this process I kept the keys with the same names. Hopefully someone will be able to write a script that converts the old presets to the new format.

I can maybe work on a script that can do this, but not probably until next week or so
But thank for the tip ^^

[Gontier-Julien]

Hey @wwmm just seen another thing.
It seem that EasyEffects doesn't make the corner square when it is maximized, i've tested Gnome To-do to see if it was not just a gtk4 issue or something, and Gnome todo doesn't keep the rounded corner when it is maximized.
And because of that EasyEffects leave a small gap on all 4 corners, witch is not great for the user experience.

So i think this is another thing to add to your to-do list ;)

[wwmm]

It seem that EasyEffects doesn't make the corner square when it is maximized

As I never maximize its window I did no notice that. As things are right now I would have to the "dynamic management" of the css properties manually depending on whether we are maximized or not. What is not great... Maybe this is one more of the things people are relying on libadwaita...

Honestly the squared corners are fine to me. It would be easier to just go back to them if the alternative is to have one more thing to handle manually.

[Gontier-Julien]

Tested and compiled to the last commit, it seems to be more optimized? (love the non rounded corner when it is in fullscreen x) ), but it seems to take less resources.

One question tho, it seem when discord is started, there is more and frequent "cracking" and even worst when on vocal. It seem to only happen when the cpu is at max utilisation, so i think it is a latency change?

[wwmm]

For now I removed the rounded corners. At least until some way to do it dynamically is available.

It seem to only happen when the cpu is at max utilisation, so i think it is a latency change?

It is probably related to Pipewire's dynamic latency adjustment. Which plugins are enabled when this happens? Depending on how heavy the plugin is the combination of latency changes and heavy load on the cpu can be problematic. As the plugins are already using realtime priorites I am not sure about what else could be done on our side.

[Gontier-Julien]

For now I removed the rounded corners. At least until some way to do it dynamically is available.

It seem to only happen when the cpu is at max utilisation, so i think it is a latency change?

It is probably related to Pipewire's dynamic latency adjustment. Which plugins are enabled when this happens? Depending on how heavy the plugin is the combination of latency changes and heavy load on the cpu can be problematic. As the plugins are already using realtime priorites I am not sure about what else could be done on our side.

Make sense, i usually have, the eq, bass enchant, exciter, crystalizer and the compressor.

[Gontier-Julien]

Hey @wwmm latest commit fail to build with this error:

[15/101] Compiling C++ object src/easyeffects.p/compressor.cpp.o
FAILED: src/easyeffects.p/compressor.cpp.o
../src/compressor.cpp: In member function ‘virtual void Compressor::process(std::span<float>&, std::span<float>&, std::span<float>&, std::span<float>&)’:
../src/compressor.cpp:144:5: error: ‘spa_process_latency_info’ was not declared in this scope; did you mean ‘spa_latency_info’?
  144 |     spa_process_latency_info latency_info{};
      |     ^~~~~~~~~~~~~~~~~~~~~~~~
      |     spa_latency_info
../src/compressor.cpp:146:5: error: ‘latency_info’ was not declared in this scope; did you mean ‘spa_latency_info’?
  146 |     latency_info.ns = static_cast<uint64_t>(latency_value * 1000000000.0F);
      |     ^~~~~~~~~~~~
      |     spa_latency_info
../src/compressor.cpp:154:58: error: ‘SPA_PARAM_ProcessLatency’ was not declared in this scope; did you mean ‘SPA_PARAM_Latency’?
  154 |     const spa_pod* param = spa_process_latency_build(&b, SPA_PARAM_ProcessLatency, &latency_info);
      |                                                          ^~~~~~~~~~~~~~~~~~~~~~~~
      |                                                          SPA_PARAM_Latency
../src/compressor.cpp:154:28: error: ‘spa_process_latency_build’ was not declared in this scope; did you mean ‘spa_latency_build’?
  154 |     const spa_pod* param = spa_process_latency_build(&b, SPA_PARAM_ProcessLatency, &latency_info);
      |                            ^~~~~~~~~~~~~~~~~~~~~~~~~
      |                            spa_latency_build
[20/101] Compiling C++ object src/easyeffects.p/compressor_ui.cpp.o

[wwmm]

Hey @wwmm latest commit fail to build with this error:

Oops... I forgot I have to wait until the next PipeWire release is done before starting using this function. I did an update now removing these calls.

[Gontier-Julien]

Hey @wwmm latest commit fail to build with this error:

Oops... I forgot I have to wait until the next PipeWire release is done before starting using this function. I did an update now removing these calls.

I can update to the latest git version of PipeWire if needed, that no problem for me ^^
Is it better for the gtk4 version to use the git version of PipeWire? Or the normal one🤔

[wwmm]

I can update to the latest git version of PipeWire if needed, that no problem for me ^^

It is not necessary. I am just helping Pipewire's developer to test some new functionality related to latency reporting in the filters. I can wait for the new PipeWire version before permanently adding these calls to our code.

Is it better for the gtk4 version to use the git version of PipeWire? Or the normal one

For now it is not necessary to use the git version. Usually I wait for the new features to get to the stable release before starting using them.

[Gontier-Julien]

Hey @wwmm latest commit fail to build with this error:

Oops... I forgot I have to wait until the next PipeWire release is done before starting using this function. I did an update now removing these calls.

[77/101] Compiling C++ object src/easyeffects.p/plugin_base.cpp.o
FAILED: src/easyeffects.p/plugin_base.cpp.o 
../src/plugin_base.cpp: In function ‘void {anonymous}::on_param_changed(void*, void*, uint32_t, const spa_pod*)’:
../src/plugin_base.cpp:72:10: error: ‘SPA_PARAM_ProcessLatency’ was not declared in this scope; did you mean ‘SPA_PARAM_Latency’?
   72 |     case SPA_PARAM_ProcessLatency: {
      |          ^~~~~~~~~~~~~~~~~~~~~~~~
      |          SPA_PARAM_Latency
[82/101] Compiling C++ object src/easyeffects.p/presets_menu_ui.cpp.o

Still some error on this commit.

And i see that now there is an AUR pacakge, nice!

[wwmm]

Still some error on this commit.

Thanks! I forgot about that one.

And i see that now there is an AUR pacakge, nice!

:-)

[Gontier-Julien]

Still some error on this commit.

Thanks! I forgot about that one.

And i see that now there is an AUR pacakge, nice!

:-)

Honestly this gtk4 branch is amazing! And very stable for a daily use!

[wwmm]

Honestly this gtk4 branch is amazing! And very stable for a daily use!

Thanks! It is good to know that it has been stable on other computers too :-)

I have just finished the work on the autoload feature. It is not handled in the presets menu anymore. Now it has its own section under the PipeWire tab

And for input devices

The idea now is that the user creates a list of associations between presets and devices. Once one of that devices becomes the output/input device used by EasyEffects the corresponding preset will be automatically loaded. No need for that device to be the current default device anymore :-)

One bonus of this change is that our presets menu is a little less bloated now.

All that being said #918 is still a problem. Like I explained there some devices can be a little tricky. Just like Pulseaudio needed a special solution for these cases I will have to come up with one for Pipewire too. I have an idea but it requires listening to PipeWire's signals I still had no reason for listening to. So there is some work to be done before I can even try to see if my idea will work.

[wwmm]

With this the only "big feature" still needing to be ported is the one providing test signals.

[Gontier-Julien]

Honestly this gtk4 branch is amazing! And very stable for a daily use!

Thanks! It is good to know that it has been stable on other computers too :-)

I have just finished the work on the autoload feature. It is not handled in the presets menu anymore. Now it has its own section under the PipeWire tab

And for input devices

The idea now is that the user creates a list of associations between presets and devices. Once one of that devices becomes the output/input device used by EasyEffects the corresponding preset will be automatically loaded. No need for that device to be the current default device anymore :-)

One bonus of this change is that our presets menu is a little less bloated now.

All that being said #918 is still a problem. Like I explained there some devices can be a little tricky. Just like Pulseaudio needed a special solution for these cases I will have to come up with one for Pipewire too. I have an idea but it requires listening to PipeWire's signals I still had no reason for listening to. So there is some work to be done before I can even try to see if my idea will work.

That amazing! And yes it make the preset less bloated as you said, and i think it more logical of having it in the PipeWire tab.

Maybe should i ask what is the current state/roadmap of EasyEffect, like what are you planning to add/change?🤔

[wwmm]

Maybe should i ask what is the current state/roadmap of EasyEffect, like what are you planning to add/change?

Something I have been considering is moving the presets menu to somewhere else. Probably the same position that the blocklist menu is now but in the plugins tab. The reason is that I have to put the test signals section somewhere. At this moment the best idea is to have one more section in the title bar for them. Just like there is one for PipeWire. But if I do that and the presets menu stays in its current position there will be too many things in the title bar.

Besides that and the reimplementation of the test signals the only thing I want to do before moving the gtk4 branch to master is fixing #918.

[wwmm]

PipeWire 0.3.31 is the new minimum required version.

[Gontier-Julien]

PipeWire 0.3.31 is the new minimum required version.

It seem with this update (witch change a lot it seems) it is going to benefit EasyEffect a lots 😃

[wwmm]

I did some changes to the preset autoloading feature. It now takes into account the hardware profile. As it can be seen in the image below the same device can trigger different presets depending on which hardware profile it is set

I think this will fix #918. But only once the people affected start to test this I will know for sure.

[Tooniis]

I tested the gtk4 branch and I have some comments:

1. Where did the spectrum sampling frequency setting go?
   
2. Sometimes the top right settings menu doesn't close when I press the menu button again, and the only way to close it is to change window focus.
3. Would be nice to still have the preset autoloading assignment button in the preset menu
   
4. I think it would be better to move the buttons in the equalizer to the right to keep the sliders at the center of focus, and let the sliders be scrolled sideways independently of the other controls.
   

[Gontier-Julien]

I tested the gtk4 branch and I have some comments:

1. Where did the spectrum sampling frequency setting go?
   ![Screenshot from 2021-07-02 09-14-25](https://user-images.githubusercontent.com/36982494/124224022-f3710a80-db15-11eb-80ee-b66be11162dd.png)

2. Sometimes the top right settings menu doesn't close when I press the menu button again, and the only way to close it is to change window focus.

3. Would be nice to still have the preset autoloading assignment button in the preset menu
   ![Screenshot from 2021-07-02 09-01-43](https://user-images.githubusercontent.com/36982494/124224247-55ca0b00-db16-11eb-9315-66b5ad78fb0f.png)

4. I think it would be better to move the buttons in the equalizer to the right to keep the sliders at the center of focus, and let the sliders be scrolled sideways independently of the other controls.
   ![Screenshot from 2021-07-02 09-23-48](https://user-images.githubusercontent.com/36982494/124224711-3ed7e880-db17-11eb-8406-17adcd68f7ff.png)

1. ask @wwmm for this, but i don't think it while be here anymore.
2. It a know GTK4 bug and not EasyEffect
3. The preset menu was moved to the PipeWire tabs to have less bloat in the preset menu.
4. And for this i let @wwmm respond to it, but it is perfectly fine in my opinion.

[wwmm]

Where did the spectrum sampling frequency setting go?

When moving from GStreamer to native PipeWire filters I had to write my own replacement for a few plugins. The spectrum plugin was one of them. The one I used before is a built-in GStreamer plugin and can not be wrapped in a PipeWire filter. As the priority at this moment is porting as many features as possible I moved to another tasks as soon as I had a spectrum plugin that worked. Maybe in the future it can have more controls. It just isn't the priority right now.

Sometimes the top right settings menu doesn't close when I press the menu button again, and the only way to close it is to change window focus.

I still think gtk4 has some issues with popovers menus. A few months ago I even reported a very serious one to them that fortunately has already been fixed. But I did not have time to go back to the gtk page yet to talk about the other issues I have been seeing.

It is not that there isn't any chance I am doing a mistake. But it does feel like a toolkit problem.

Would be nice to still have the preset autoloading assignment button in the preset menu

That is not possible anymore. The way autoloading profiles are created is too different from before. The old approach necessarily associated the profile to the current default device. This is not the case anymore. It will be hard to work with the increase in flexibility having only one button in the presets menu.

The other point to have in mind is that that button was not obvious to new users. It was clear to me that most people did not realize what it did.

I think it would be better to move the buttons in the equalizer to the right to keep the sliders at the center of focus, and let the sliders be scrolled sideways independently of the other controls.

I do not mind having the buttons on the right side. But for that to happen this additional scroll only for the sliders is necessary. And I will have to see if no technical difficulty appears along the way. The interface is being handled in a very different way compared to how it was done in the past.

[wwmm]

The microphone section now has at its bottom right corner a toggle button that allows the user to listen to the processed microphone signal

This should be useful in situations like the one described in #970

[wwmm]

There is also a working sine wave generator

I decided to put it in the PipeWire tab and keep the presets menu in the headerbar. I still want to add a pink noise generator but I have to find a code example for it. Or at least a simple explanation of an algorithm that generates it.

Besides this the only thing left to be done before a new release is making the About EasyEffects button in our settings menu to actually show something XD. The manual needs a huge update. But writing manuals is really boring... I will not delay the next release because of it. And most of the plugins have the same interface as before anyway. The other parts of the window that are really different...

[wwmm]

After many months of work EasyEffects has been finally released. This issue can be closed :-)