Introducing Option Profiles in Picard

[InvisibleMan78]

I would like to talk about one main thing:
Why do you name it “User profile”?
I would never think about the above possibilities under such a name.

Would it not be more obvious to name it “Options groups” or “Quick presets” like the original ticket says?

For the example itself I suggest to use a use case like:
Rename Pop Music vs Classical Music
or
Move to folders with Genre or without Genre

What I don’t yet get is the difference between this new “User Profiles” and the already existing “Scripting” and “File naming” part of Picard.

[hiccup]

@rdswift

One of the changes that is planned for implementation in the next version (v2.7) of Picard is the ability to set different user profiles

First of all let me admit I heaven’t followed or read what preceeded this.
Also I haven’t read and studied your excellent start post good enough (yet) to fully understand it.
So, my response may be off to what this is about, and what requested feature it involves.

But I am thinking: there is one file that contains all user settings for Picard: config.ini
Wouldn’t it be much simpler to have a new feature and setting where you can simply switch between config.ini’s?

You could name them differently, e.g. regular.ini, classical.ini, prepare.ini, etc.
Then in options, select an .ini and apply, and Picard could restart with all it’s specific settings and preferences?

[IvanDobsky]

@hiccup

You could name them differently, e.g. regular.ini, classical.ini, prepare.ini, etc.
Then in options, select an .ini and apply, and Picard could restart with all it’s specific settings and preferences?

This is the old hack we used to use. If you read the OP you will find the big advantage is the common settings stay in a common file. If you want to apply a change to ALL your current ini files you have to open each in turn and hit that option in each and everycase.

@InvisibleMan78

Why do you name it “User profile”?

Agree that this is a very confusing name. This does not let you have separate settings for John and Mary. Quick presets makes more sense to me too.

[hiccup]

@IvanDobsky

If you want to apply a change to ALL your current ini files you have to open each in turn and hit that option in each and everycase.

Ah yes, that is an important difference indeed.
Perhaps additionally having presets for scripts and activated plugins could be added to this presets feature?
That would probably eliminate the need for using the hack to use different ini’s for different configurations.
(or for having several portable installations, as is what I am doing)

[IvanDobsky]

@hiccup

(or for having several portable installations, as is what I am doing)

I remember the thread… and if I understand the OP correctly this will now be possible within the options of the running Picard.

[ulugabi]

Sounds promising, was really interested by this feature which I use often in EAC. Reading the doc it s indeed complex but I understand this offers more flexibility than a simple profile selector.

From the Notes it says we need to create the profile then select only this one then close the window and go to options to change the presets → Is that correct?

If yes would it be possible to make the process easier?
ex:

• Add a drop down menu in Options dialog box to choose the profile we want to edit (or at least showing which profile would be affected by the edits)
• Add a button Edit profile in the User profile editor

[rdswift]

@InvisibleMan78

Why do you name it “User profile”?

Good question. When I started working on this, there was already the very beginning of a patch to support this type of functionality and it was referred to as profiles in the code. During the discussions during development of the current system, it was always referred to as “User Profiles” and I guess that just sort of stuck.

@InvisibleMan78

Would it not be more obvious to name it “Options groups” or “Quick presets” like the original ticket says?

I’m not sure that would describe the system any better. I think I might have suggested calling it “Settings Overrides” at one point, but that just didn’t sound good (even to me).

@InvisibleMan78

For the example itself I suggest to use a use case like:
Rename Pop Music vs Classical Music
or
Move to folders with Genre or without Genre

Good suggestions for additional examples. I think there could (perhaps should) be a whole section in the documentation dedicated to user profiles, including a whole range of examples of how to use profiles for different workflows and use cases.

@InvisibleMan78

What I don’t yet get is the difference between this new “User Profiles” and the already existing “Scripting” and “File naming” part of Picard.

This new system is a simple (once you get used to the concept) way of turning on and off a collection of alternate settings, with each collection referred to as a profile. Each profile can contain the alternate settings for multiple options (selected by the user when creating the profile) spanning the various option pages such as Metadata, File Naming, Cover Art Providers, and Scripts. Rather than changing each option setting individually (and remember the old setting when you want to switch back), you can assign all alternate settings related to a different use case to one profile, and then switch them all at once by enabling or disabling the profile.

[rdswift]

@hiccup

Perhaps additionally having presets for scripts and activated plugins could be added to this presets feature?

Funny you should mention that… One of the other changes coming in Picard v2.7 is the ability to have multiple file naming scripts, and then select which script to use right from Picard’s main menu. This pairs nicely with the profile system in that a profile can enable different tagging scripts and parameters, and use a different file naming script, and you can change to use all these different alternate settings at once by simply enabling the profile.

You will also be able to export a file naming script to a file (for archiving or sharing), and import a script from a file (from your archived backup or provided by another user). This enables easy sharing of file naming scripts, and trying out a new script without losing or having to re-enter your current script.

[aerozol]

Wow, Picard ticket #9!

I don’t have very technical feedback, but one thing that would be great is to put whatever examples are used in the documentation as pre-set ‘user profiles’ (unactivated, of course) when Picard is installed.

As someone who only rarely uses Picard scripting functions I’ve sometimes thought some existing pre-sets would be a great accompaniment to the excellent ‘Scripting documentation’ button.

[rdswift]

@ulugabi

From the Notes it says we need to create the profile then select only this one then close the window and go to options to change the presets → Is that correct?

Not entirely. You can have more than one profile enabled, and the settings change will be applied to the first profile in the stack that manages that option. At this point, you still need to exit the profile manager and go into the Options pages to make your changes.

@ulugabi

If yes would it be possible to make the process easier?
ex:

• Add a drop down menu in Options dialog box to choose the profile we want to edit (or at least showing which profile would be affected by the edits)
• Add a button Edit profile in the User profile editor

Good suggestions, but I’m not sure what it would take to implement that into the system. I’ll have to give it some thought because it might be a more intuitive approach. Thanks.

[IvanDobsky]

@rdswift

it was always referred to as “User Profiles” and I guess that just sort of stuck.

“Users Profiles” means something else and has potential to confuse. What about “Settings Profiles”? It is for choosing between Settings, not between Users.

[rdswift]

@IvanDobsky

What about “Settings Profiles”?

Either that or “Option Profiles”, which is technically more correct. @outsidecontext / @Zas, any comments on changing the title?

[Zas]

After reading this thread, it seems obvious “User Profiles” doesn’t fit, I’m fine with “Settings Profiles” but since we use “Options” rather than “Settings” in menus, “Option Profiles” (Options?) fits well too.

[outsidecontext]

I’m as well fine with both “Option profiles” and “Settings profiles”, maybe the first one is indeed better following existing naming. But both are indeed better than “User profiles”.

[rdswift]

@ulugabi

If yes would it be possible to make the process easier?
ex:

• Add a drop down menu in Options dialog box to choose the profile we want to edit (or at least showing which profile would be affected by the edits)
• Add a button Edit profile in the User profile editor

I finally got around to entering a ticket for this.

PICARD-2239

[rdswift]

Thank-you everyone for your comments and suggestions regarding the initial design. Based on your feedback, we are making some changes to the way that option settings values are saved to try to make the system simpler and more intuitive. The updated documentation is shown below.

If you have any follow-up comments or suggestions, we’d love to hear them. Thanks.

---

Option Profiles

As of version 2.7, Picard supports multiple profiles that can allow the user to quickly switch between option settings.

How Option Profiles Work

A profile is defined by a set of options it manages. For example, one profile may include settings for file naming such as the target directory and which file naming script to use, while another profile may include different settings for the same options or different options entirely (or some of each). Profiles are stacked and processed in the order specified by the user, from top to bottom with the lowest level being the system’s “user settings” profile. Each user-defined profile can be enabled or disabled independently from the other user-defined profiles. The system’s “user settings” profile is always enabled and includes all options.

When an option value is retrieved as part of Picard’s processing, it comes from the first enabled profile in the stack that manages that option. Initially, the profile stack contains only the system’s “User base settings” profile, which holds the default settings for the user.

Example of Using Profiles

For this example, the user would like to define a set of options with alternate values, in this case a target directory where audio files are saved (option move_files_to).

The user creates a new profile (named “TargetMyDir”), adds the option move_files_to to it, and enables this profile. The stack is now:

[x] TargetMyDir    move_files_to
[x] user settings  move_files_to   [plus all other settings]

Since the profile “TargetMyDir” is enabled, the value for move_files_to is retrieved from this profile. The “user settings” still has the old move_files_to value.

Now the user wants to work on another set of music files, wanting to disable windows_compatibility for this set and save them to the “not_for_windows” directory.

They create a new profile (named “ByeByeWin”), add options move_files_to and windows_compatibility, and enable it. Now the stack looks like:

[x] ByeByeWin      move_files_to   windows_compatibility
[x] TargetMyDir    move_files_to
[x] user settings  move_files_to   windows_compatibility [plus all other settings]

They change the values of move_files_to (to “not_for_windows”) and windows_compatibility (to false) for this new profile. Now when they process their files, the files are saved to the “ByeByeWin” move_files_to directory, with windows_compatibility = false.

Now the user wants to save files to the “TargetMyDir” target directory again, with their usual options. To do this they simply disable the “ByeByeWin” profile (which can later be re-enabled if needed). The stack looks like:

[ ] ByeByeWin      move_files_to   windows_compatibility
[x] TargetMyDir    move_files_to
[x] user settings  move_files_to   windows_compatibility [plus all other settings]

Finally, to return to their usual output directory the user only has to disable the “TargetMyDir” profile so the stack is:

[ ] ByeByeWin      move_files_to   windows_compatibility
[ ] TargetMyDir    move_files_to
[x] user settings  move_files_to   windows_compatibility [plus all other settings]

Managing Option Profiles

All option profile management is done within the Option Profile Editor screen available from the “Options ‣ Option Profiles…” item on the menu bar. From this screen you will be able to add, copy, edit, remove, enable and disable profiles, as well as setting the order of the profile stack.

Initially, the list of profiles will be empty. To create a new profile click on the New button. This will create a profile with no options selected for the profile to manage. To rename the profile, right-click on the profile name and select the “Rename profile” command. The list of options that the profile is to manage are selected from the list in the right-hand pane. Options can be selected either by group or individually. The groups can be expanded to see the individual options belonging to that group.

You can see the value currently assigned to a profile’s option setting by hovering your cursor over the setting in the list. The value will be displayed as a tooltip for the setting.

The profiles stack order can be rearranged either by selecting a profile and using the up and down arrow buttons below the list, or by dragging the profile to a new position in the stack. Profiles are enabled when the box beside the profile’s name is checked.

When you are satisfied with your changes, click the Make It So! button to store them and exit the profile editor screen. Use the Cancel button to exit without saving your changes.

Note: Creating a new profile, or adding new options to an existing profile, does not save the settings for the options. Settings must be updated in the “Options…” window, as described in the following section.

Saving Profile Option Settings

To save a value to a profile option setting, simply select the target profile in the “Options…” window, make the desired changes, and then click the Make It So! button.

The changes will only be applied to the selected profile, and only for option settings managed by the profile — all other changes will be ignored. The default target is “User base settings” which is the user’s normal settings, and includes all options. If no option profiles have been defined, this “Save settings to:” section will not be displayed in the “Options…” window.

Whenever a profile is selected in the “Save settings to:” section, the setting values displayed are updated to show the values that are associated with the profile. Any option settings not managed by the profile will display the values for the user’s base settings.

From the “Options…” window you will also be able to see which profiles, if any, manage any of the options on the current page. This is done by clicking the Attached Profiles button beside the output target profile selector.

[aerozol]

Looks awesome!

@rdswift

Initially, the list of profiles will be empty.

Is there a reason why we wouldn’t pre-populate the profile with the examples?

[rdswift]

I suppose it’s something that we would consider if there was a great demand for it, but (in my opinion) the examples in the documentation really serve no purpose other than to illustrate the process, unless the user had exactly the same use case. My thinking was that it didn’t make a lot of sense to include code in the program that doesn’t really add any value.

[rdswift]

@InvisibleMan78

What I don’t yet get is the difference between this new “User Profiles” and the already existing “Scripting” and “File naming” part of Picard.

Sorry, I should have addressed this sooner. The primary difference is that an Option Profile can contain multiple option setting changes, thus making it much easier to switch between collections of settings. For example, when tagging classical music perhaps you want to use a different file naming script, enable different tagging scripts, and save to a different output directory than you use for pop music. You could set all of these settings changes in a “classical” profile, and switch them all on or off at once simply by enabling/disabling the profile. It also allows changes to options besides just the scripting and file naming sections.

Another nice part is that we’ve designed it to be entirely optional. To continue to use Picard as you do now, just don’t create any option profiles. This is the way that users would operate if they always process their files the same way and never change any settings.

Using option profiles can be beneficial when the user has multiple use cases and workflows, such as:

• Initial tagging [modern]
• Initial tagging [classical]
• Updating metadata on already tagged files
• Tagging files for use with a specific MP3 player
• Tagging files for archival purposes

I’m sure there are many other use cases. Our intent was to provide a system that was flexible enough to allow the user to set it up such that it helps meet their specific needs, while still remaining relatively easy to use. That’s where user feedback will be so very important. I’ve been poking at this for so long now that its use has become second nature to me, and I no longer see things through an unfamiliar user’s perspective. That leads to me taking things for granted when perhaps that’s not appropriate.

[rdswift]

@ulugabi

If yes would it be possible to make the process easier?
ex:

• Add a drop down menu in Options dialog box to choose the profile we want to edit (or at least showing which profile would be affected by the edits)
• Add a button Edit profile in the User profile editor

The updated version incorporates your first suggestion (thank-you for the idea). Your second suggestion (as I understand it) is a lot more difficult to implement because it would require either rewriting or duplicating all of the current Options settings code. I’m not saying that it can’t or won’t ever be done, but not for the initial release (at least not by me ).