Improve discoverability of presets?

[vchernin]

One of the most helpful features is being able to use a preset someone else has put together. This is useful even if you just need an example to understand how the pipeline works.

The problem is to find them you need to go to github, find the presets wiki page, click a link to a preset repo, make sure you download the actual preset json (not html!) and then import it. All of this assumes the user somehow found the github page (and wasn't immediately confused since they don't know what github is).

It would be nice to somehow make this easier. Some ideas:

• Provide some hardcoded "built-in" presets in the presets dropdown, installed by default in builds.
• have a remote list of presets, e.g. from the preset search bar you could search from a list of presets online. This might end up being a hardcoded list of in-tree presets (or maybe a seperate repo), not to mention it would require network access for the flatpak build.
• for flatpak we can build a seperate extension package with a bunch of hardcoded presets. This would look like this in gnome software (see the add ons). But this doesn't help other packages.

[wwmm]

Provide some hardcoded "built-in" presets in the presets dropdown, installed by default in builds.

I think that would be annoying to people not interested in the built-in presets if they are visible all the time. What in turn would force us to implement some logic to allow them to be hidden.

I am not sure about where and when but built-in presets were discussed in the past. I still have mixed feelings about them. I think that some users will expect them to somehow magically make their computer's sound "good" and that is not going to happen in most cases. And then we will start to have open issues about "built-in presets not being good".

Something that we could do is pointing the presets import dialog to the system folder where the "built-in" presets are installed. But I still think we should really consider the flux of issues about the built-in presets "quality". They are probably going to happen and it is the kind of thing where the end result depends a lot on the users hardware and environment.

[Digitalone1]

I agree with @wwmm regarding the built-in presets.

I think the only doable thing could be adding a link that points to the preset page here on Github. Adding a sort of mechanism to download the preset from a repository would introduce a complexity I think it's not worth it.

[polarathene]

If other packages installed on a system can dump presets into a presets.d/ location, then EasyEffects could read that on start and import those presets?

Then the community can be encouraged to package those github resources for users that are not comfortable with github but are fine with using a package manager on the system (assuming that's how they got EasyEffects in the first place)

I don't use Flatpak but assume it could accomplish the same. Deferring to community makes sense, EasyEffects can perhaps provide a placeholder message when no presets exist on a fresh install to the wiki page about where to find those community presets, and then it's up to those links to document support for alternative installation via flatpak or package managers.

[wwmm]

If other packages installed on a system can dump presets into a presets.d/ location, then EasyEffects could read that on start and import those presets?

Automatically import everything in the directory? I am not sure it is a good idea unless we somehow track the "first app start". If I remember well we can set a default path for the import dialog. So it could always open in the system folder with the community presets. This is fine. I just don't know how the flatpak package will react to this.

[vchernin]

So it could always open in the system folder with the community presets.

Assuming this is possible it might be worth testing the portal file chooser with GTK_USE_PORTAL=1 which is normally only used for the Flatpak build.

I just don't know how the flatpak package will react to this.

With Flatpak extension packages can be made containing the presets. If said extension packages are installed we can mount the contents somewhere like /app/extensions/Presets. So from EasyEffects' perspective it is just some directory it can read whenever. There isn't any problem with Flatpak that I can see (aside from ensuring the directory is set correctly).

[vchernin]

Then the community can be encouraged to package those github resources for users that are not comfortable with github but are fine with using a package manager on the system (assuming that's how they got EasyEffects in the first place)

This will work well with Flatpak since the extension packages can show up in gnome software. So you don't even need to open the command line.

[polarathene]

Automatically import everything in the directory?

Yes? I mean that's a common pattern I've seen for software that supports supplying multiple configs from other packages or users (usually via an additional user config location in their home directory .config/ for example).

I believe there is some XDG ENV that can be used if the user wants to customize the location for where configs live (if you'd like to support such but prefer to avoid additional UI settings).

All that's happening here is the presets are listed in the UI, nothing else is done until a user enables a preset right? Perhaps the UI doesn't suit have long lists of presets to navigate/filter?

Or if this idea doesn't mix well with the user likely not being interested in most of the presets from a package (at least after initial exploration). That could be resolved by having a UI method to hide/ignore an entry, updating a config (to simplify restoring it, it may be better to just dim the item and group sort ignored presets below the "non-hidden" ones).

[wwmm]

Or if this idea doesn't mix well with the user likely not being interested in most of the presets from a package

As an user I think it is super annoying being forced to see in the presets list entries I am not interested at. So I definitely do not want to see my presets lists suddenly "polluted" by tons of entries I have no reason to see.

That could be resolved by having a UI method to hide/ignore an entry

With just a few entries it would work. But if this community presets folder starts to have tons of things it would not be practical to do this manually.

I still think that it is better to just point the import dialog to the system folder with these presets.

[polarathene]

So I definitely do not want to see my presets lists suddenly "polluted" by tons of entries I have no reason to see.

Right... but you wouldn't be the user who'd install a package, but import the preset you want directly?

~~Alternatively, you have a location that presets can be found at, and could add a button to import from the list there.~~ (EDIT: Like the import button that's already there... ahaha :man_facepalming: )

I still think that it is better to just point the import dialog to the system folder with these presets.

Yeah totally, I just woke up recently and that didn't occur to me :sweat_smile:

[wwmm]

EDIT: Like the import button that's already there... ahaha man_facepalming )

Haha. I admit the gtk icon isn't making the button function obvious. But yes. We already have an import button. By default it opens the user "recent files". We can just make it show the system folder with the presets. And maybe make it more obvious that this button is for importing things.

[vchernin]

Provided the file chooser can be set to open at a directory, I think the remaining questions is what should the preset packages look like.

Should we have:

• A package containing every preset from the wiki: Arch: easyeffects-all-presets Flatpak: com.github.wwmm.easyeffects.Presets.all

• One package per presets repo listed in the wiki: Arch: easyeffects-presets-digitalone1 Flatpak: com.github.wwmm.easyeffects.Presets.digitalone1.

• One package per preset file listed in the wiki: Arch: easyeffects-presets-digitalone1-loudnessequalizer Flatpak: com.github.wwmm.easyeffects.Presets.digitalone1-loudnessequalizer.

Besides that there are some other details I thought of.

• To edit a package provided preset you’d need to save your own copy of the preset right?

• If these packages are created I think the wiki and every presets repo should point to the packages before giving users manual instructions.

• Should these presets packages be marked as dependencies of easyeffects to install them by default? (this is also possible to do in Flatpak).

[wwmm]

Provided the file chooser can be set to open at a directory

I did not test but the function gtk_file_chooser_set_current_folder probably works with the GtkFileChooserNative we have been using.

A package containing every preset from the wiki

It is what I would do if I were the package maintainer. But we have to do things in a way that multiple packages can work because I doubt there will be only one.

To edit a package provided preset you’d need to save your own copy of the preset right?

Yes. The import preset dialog does a copy when importing a preset. The whole thing will work in the same way it does when importing from another folder. The user just need read access to the folder where the preset file is.

Should these presets packages be marked as dependencies of easyeffects to install them by default?

From a technical point of view they are optional dependencies. But at least in Flatpak it makes sense to install everything. Preset files are just text files. Even with hundreds of them almost no disk space will be used.

[servimo]

I think some simple presets examples for input and output is good, don't need to be a bunch of presets.

[vchernin]

A package containing every preset from the wiki

It is what I would do if I were the package maintainer. But we have to do things in a way that multiple packages can work because I doubt there will be only one.

The packaging part should be fairly easy, it is just downloading a bunch of files from a git repo. I am just not sure if it makes sense to put everything in one package though. It may become too busy, luckily the way Flatpak extensions work can be used for one extension package or many.

So for now we could have one presets package with everything and change it later on if it becomes too much.

I think some simple presets examples for input and output is good, don't need to be a bunch of presets.

It would be good to make a definitive list using the wiki. If we decide to have multiple preset packages should they be organized by category/type or by maintainer?

It may be a problem/confusing if say we include digitalone1’s loudnessequalizer in a simple presets package, but the file is also included in the digitalone1 preset package.

[polarathene]

@vchernin

• One package per presets repo listed in the wiki: Arch: easyeffects-presets-digitalone1 Flatpak: com.github.wwmm.easyeffects.Presets.digitalone1.

It makes sense to me that you'd have a package per preset if they're maintained separately as individual repos. But I guess that's up to the packager.

Otherwise if you're going to bundle multiple sources, you might as well have a -community package.. or migrate them into this project in a subdir?

---

Moving community presets into the project might be helpful, since there was talk about presets needing to be updated with upcoming breaking changes. In that sense, popular presets that were shipped by default could be updated here to go with that release out of the box.

Then again, that may not be helpful. If it did update a preset a user had loaded, they might not have expected an implicit change in settings, nor would it work for any custom preset that was modified from a community preset...

I assume these presets rarely need much maintenance or get much updates (I haven't looked at their repo history), perhaps that changes with releases as effects are introduced or receive improvements, but that might also be another good reason for keeping a set of community presets in sync with the projects releases?

Alternatively, switch easyeffects to an organization and have presets co-located under that umbrella? You can give the original maintainers only push rights to their own repos AFAIK, while having rights for any EasyEffects maintainer to also update them if needed.

Either way, that doesn't change the main goal of making it easy for third-parties to package their own presets for EasyEffects to find/import at a common location :+1:

[polarathene]

@wwmm

I did not test but the function gtk_file_chooser_set_current_folder probably works with the GtkFileChooserNative we have been using.

I am on KDE, would it work with alternative file choosers? (IIRC, that support is referred to as through portals)

Yes. The import preset dialog does a copy when importing a preset.

The in-app menu section on presets does not mention that it makes a copy btw. I'm not sure if it's necessary, but it might not be obvious that the import isn't an open/link to the original in that case.

That said I'm not familiar with the original query about editing a preset. I assumed it was imported as a static preset, and that editing it would require a "load" -> make changes -> "add" new preset?

[polarathene]

As a user btw, I also found the current UI a bit odd.

It took me a while to realize that even though I was in the "Input" view, when I clicked "Presets" button, it was opening with "Output", perhaps as a convenience for a user to easily switch between "Output" and "Input" to switch presets, but when adding a preset, I was accidentally adding for "Output" instead of "Input".

I haven't verified, but I suppose it was saving the "Output" to "Output" in this case, and if I didn't notice it later, I probably would have lost my tweaks for "Input"?

Might make sense to open "Presets" to the current (or last active) "Output"/"Input" view? And :information_source: button to preview a list of raw settings might be neat too, maybe with the filepath on disk too.

[vchernin]

That said I'm not familiar with the original query about editing a preset. I assumed it was imported as a static preset, and that editing it would require a "load" -> make changes -> "add" new preset?

The original reason I asked was because the packaged presets directory at least in Flatpak will not be persisted. Meaning EasyEffects can write to the directory but the contents will be reset when the app is relaunched. So the correct behaviour is to do a copy like it does currently so users can actually edit the preset.

[wwmm]

I am on KDE, would it work with alternative file choosers?

This kind of thing happens at a lower level. We just ask GTK to use a native file dialog. What is actually going to happen in the end is out of our control.

The in-app menu section on presets does not mention that it makes a copy btw. I'm not sure if it's necessary, but it might not be obvious that the import isn't an open/link to the original in that case.

It is the easiest thing to do. EasyEffects assumes preset files are inside ~/.config/easyeffects/input or ~/.config/easyeffects/output. If we make a link to the original file the preset will be broken once the user deletes the original file or moves it somewhere else.

That said I'm not familiar with the original query about editing a preset. I assumed it was imported as a static preset, and that editing it would require a "load" -> make changes -> "add" new preset?

What is happening under the hoods is a little elaborated. When you load a preset file each value in a json key is loaded to the corresponding variable in our gsettings database. The widgets in our interface are connected to these variables in our gsettings database. So they are updated whenever the database variables are changed. And the same thing happens with the plugins that we use. They are also connected to our gsettings database. What loading a preset file does is updating our database. After that GSettings "broadcasts" the change to anything that has connected to our configuration keys.

Let's consider that you load a preset and do not touch any control. Even if you close EasyEffects these settings are saved in our database. There is no need to reload a preset when EasyEffects is restarted because GSettings will broadcast all these values again.

At any moment you can either save a new preset file or overwriting one that already exists. In both cases what is going to happen is that the code managing presets will read the GSettings database and put everything that is there in the file.

[wwmm]

perhaps as a convenience for a user to easily switch between "Output" and "Input" to switch presets

Yes. Having to switch views just to apply a preset file is quite annoying when you are using both pipelines at the same time. It would make some things more obvious for new users. But once you already know what is happening begin forced to switch views is not fun. I almost did that a long time ago but after considering how often I apply presets without switching views I gave up on the idea :smile:

[wwmm]

Yes. Having to switch views just to apply a preset file is quite annoying when you are using both pipelines at the same time. It would make some things more obvious for new users. But once you already know what is happening begin forced to switch views is not fun. I almost did that a long time ago but after considering how often I apply presets without switching views I gave up on the idea smile

That being said it is something that could be considered in the future. It has already been done to the blocklist menus. Nowadays I have most of my real use cases automated through presets autoloading. With the exception of some corner cases here and there manual preset loading is something I do for development purposes.

[polarathene]

It would make some things more obvious for new users.

Perhaps then, at least for the saving preset UX, would it make any sense to have a separate button embedded into the "Output"/"Input" -> "Effects" subview? On the left side-bar next to "Add Effect" perhaps? (overwriting an existing preset could be done from the current button as that's more explicit)

Likewise the global bypass is for both, but I'm not sure if there's an easy way to toggle only "Output" or "Input" effect chain off (not that important to me).

I realize that the adding new preset issue really only applies to "Input", since the default is "Output". And it can probably just be chalked up to user error. The two types of preset were right there, but as a new user I somehow overlooked it still :sweat_smile: perhaps assuming because I was saving a preset from the "Input" view, I expected it was saving that preset, as it didn't make sense to me UX wise to add a preset for the opposite view I'm in :thinking:

---

Nowadays I have most of my real use cases automated through presets autoloading. With the exception of some corner cases here and there manual preset loading is something I do for development purposes.

It's likely a niche issue, I'm not likely to tweak presets much once I'm happy with them. And once I realized I should be aware of what preset type I'm saving, I know to make sure it's for the correct type :+1:

~~I'm not familiar with what "automated through presets autoloading" means.~~ (EDIT: Just looked it up in the in-app manual on presets section and understand now :+1: )

[wwmm]

Likewise the global bypass is for both, but I'm not sure if there's an easy way to toggle only "Output" or "Input" effect chain off (not that important to me).

No. The global bypass disables effects for both pipelines at the same time. There is no control to disable only one of them. The user will have to manually disable each plugin in the desired pipeline.

[vchernin]

One detail I thought of is how should updates work? If a user installs a preset from a preset package, but the package is later updated, should we prompt the user to "update" their preset by replacing their copy with the new version of the preset?

If the user has changed parts of the provided preset trying to merge their changes into the upstsream update is probably too complex to do. So instead I think a simple yes or no prompt is more reasonable. But then I guess we would need a new property in the preset so it remembers the package it was sourced from, and we can know if the upstream preset is updated just by checking the sha256, versioning feels excessive.

[wwmm]

If the user has changed parts of the provided preset trying to merge their changes into the upstsream update is probably too complex to do. So instead I think a simple yes or no prompt is more reasonable. But then I guess we would need a new property in the preset so it remembers the package it was sourced from, and we can know if the upstream preset is updated just by checking the sha256, versioning feels excessive.

I think the problem is over complicating things indeed. Specially because these presets are probably not going to be updated frequently. At least initially I think we should just add basic support for this and wait to see how things go so we do not do "a lot of work in vain".

[ghost]

I think some simple presets examples for input and output is good, don't need to be a bunch of presets.

Maybe I could incorporate a couple of presets for everyday use, like listening to music with your headphones or speakers. And update them if they are no longer compatible with new versions of EasyEffects.

[ghost]

It would be good to incorporate a couple of presets because I think most users know EasyEffects due to the Equalizer. And well dealing with issues like Quality (Q) Release or Attack is not common among users. So why not incorporate a set of presets. And even better with a tag like EQ, Reverb, Pitch or something similar.

[ghost]

The goal is for EasyEffects to be friendly to users who are only looking for good sound quality but who don't have to deal with these issues to achieve it.

[ghost]

One of the most helpful features is being able to use a preset someone else has put together. This is useful even if you just need an example to understand how the pipeline works.

Maybe my presets can help with this: easyeffects-presets-by-soonan5. Since the configuration of each tool is much more pleasant than the one that comes by default. Just look at the equalizer, if you add it, you will find that it comes by default with 32 bands which makes it confusing for the average user. Since it gives the impression that it is advanced (and it is) but in most cases you only need 8-10 bands to achieve good results (of course after setting the filter type, frequency, slope and quality) And here something curious: Quality (Q) does not mean that it will sound better (but as I said most users do not know about it), so they set it to maximum value and BOOM! nothing comes out as expected.

[ghost]

And then we will start to have open issues about "built-in presets not being good".

Well sometimes it depends on the perspective of the user who creates the preset. For example, there are users who seek to give more presence to the bass and the kick, others who need to give more brightness to the vocals and others who want to eliminate an annoying frequency that their computer speakers have (and well, I think that the latter depends on each user) From my point of view I prefer to attenuate frequencies instead of boosting them since it is what has helped me to have a quality similar to that of my old Walkaman.