Picard 3 Plugin Updates

With today’s announcement of Picard 3 rc1 availability, I’ve finally addressed some issues with the Picard 3 version of a couple of my plugins.


Additional Artists Details

There has been a long-standing problem where the plugin failed to populate the new variables initially, and required an album to be refreshed for that to happen. The reason was that the album was being “finalized” before all of the api calls for the additional information (usually area information requests) were completed. The plugin now blocks the finalization until all of the requests have completed, so no more need to refresh (although the album may now appear to take slightly longer to load initially).

The second issue was that the cache used to reduce the number of additional api calls was being deleted each time Picard was closed, causing all the api calls to be repeated as required in the next session. I’ve now added a new option (enabled by default) for the plugin to retain a copy of the cached information in a JSON file on your hard drive, and reload it when Picard is started. This allows the cache to persist between Picard sessions, and means that area (and optionally artist) information only needs to be retrieved once. In my testing here, a various artists compilation album that initially took over 20 seconds to load (because of the area lookups for all of the different track artists) took under 2 seconds for subsequent loads, even after closing Picard and starting a new session. Not only will this speed things up for the user, it should help reduce the load on the MusicBrainz api by eliminating duplicate calls for the same information.

There are actions in the plugin’s options page to allow importing and exporting copies of the cache from/to external files to allow for backup and transferring to another system.

For more details, please see the plugin’s user guide.


Additional Artists Variables

The main change with this plugin is to add more variables! Specifically, there are now variables exposing artist names and sort names based on your preferred locale and name translation settings in Picard’s MetaData Options. These variables will only be created if you have enabled translation of artist names, and there is at least one artist alias for a locale matching one of your preferred locales.

List of new variables

Album Variables

  • _artists_album_additional_alias - All album artists listed (locale-specific alias names) except for the primary / first artist, separated by strings provided from the release entry
  • _artists_album_additional_alias_multi - All album artists listed (locale-specific alias names) except for the primary / first artist, as a multi-value
  • _artists_album_additional_alias_sort - All album artists listed (locale-specific alias sort names) except for the primary / first artist, separated by strings provided from the release entry
  • _artists_album_additional_alias_sort_multi - All album artists listed (locale-specific alias sort names) except for the primary / first artist, as a multi-value
  • _artists_album_all_alias - All album artists listed (locale-specific alias names), separated by strings provided from the release entry
  • _artists_album_all_alias_multi - All album artists listed (locale-specific alias names), as a multi-value
  • _artists_album_all_alias_sort - All album artists listed (locale-specific alias sort names), separated by strings provided from the release entry
  • _artists_album_all_alias_sort_multi - All album artists listed (locale-specific alias sort names), as a multi-value
  • _artists_album_primary_alias - The primary / first album artist listed (locale-specific alias name)
  • _artists_album_primary_alias_sort - The primary / first album artist listed (locale-specific alias sort name)

Track Variables

  • _artists_track_additional_alias - All track artists listed (locale-specific alias names) except for the primary / first artist, separated by strings provided from the release entry
  • _artists_track_additional_alias_multi - All track artists listed (locale-specific alias names) except for the primary / first artist, as a multi-value
  • _artists_track_additional_alias_sort - All track artists listed (locale-specific alias sort names) except for the primary / first artist, separated by strings provided from the release entry
  • _artists_track_additional_alias_sort_multi - All track artists listed (locale-specific alias sort names) except for the primary / first artist, as a multi-value
  • _artists_track_all_alias - All track artists listed (locale-specific alias names), separated by strings provided from the release entry
  • _artists_track_all_alias_multi - All track artists listed (locale-specific alias names), as a multi-value
  • _artists_track_all_alias_sort - All track artists listed (locale-specific alias sort names), separated by strings provided from the release entry
  • _artists_track_all_alias_sort_multi - All track artists listed (locale-specific alias sort names), as a multi-value
  • _artists_track_primary_alias - The primary / first track artist listed (locale-specific alias name)
  • _artists_track_primary_alias_sort - The primary / first track artist listed (locale-specific alias sort name)

The other change is that all variables created by this plugin are registered so that they appear in the scripting autocomplete, mouse-over descriptions, and scripting documentation. This is new functionality that was added as part of Picard 3.

For more details, please see the plugin’s user guide.


As always, if you run into any issues with these or any of my plugins, please let me know by entering a ticket in the appropriate repository on GitHub. The easiest way to do this is by right-clicking on the plugin in the list in the “Plugins” page under “Options”, and select the “Report a Bug” action.

6 Likes

Also, for plugin developers around curious about the new plugin system, @rdswift Picard 3 plugins can be used as references, because they exercise many of the features:

  • plugin translations locale/*.toml
  • plugin UI
  • homepage/documentation link (homepage)
  • bug report link (report_bugs_to)
  • multilingual MANIFEST
  • use of Weblate and Readthedocs
  • git tags / semver versioning
  • registry
  • new plugin API (def enable(api: PluginApi))
  • and more.

If you have any question about porting a plugin from v2 to v3, I guess he can help too.

4 Likes

Just released a new version of “Additional Artists Details” for the latest Picard 3.0rc2 version. This new version of AAD uses a local sqlite database for its persistent cache (to save memory and disk space), along with a number of other features. If you use this plugin, please review the option settings once you have updated it. For more information, please see the documentation.

4 Likes

Potentially a big problem.

The changes use the Python sqlite3 module, which it seems is not distributed with Picard. As a result, the plugin will fail to load if it doesn’t find that module. (Of course, everything worked fine here when I was testing because I was running Picard from source code, with the full Python base modules available.)

I’m looking into possible alternatives, but in the meantime you can still use the v2.0.2 version of the plugin, and will be able to migrate your saved cache data into the new version when I get the issue resolved.

We could include sqlite support in all packages. It’s not shipped in PyInstaller packages as neither Picard nor any of its dependencies use it, but if it seems generally useful for plugins we could include it. I don’t think libsqlite3 will add too much to the package.

I’m of two minds on that.

On the one hand, that would enable this plugin to function with the database approach, and open the door to other plugins that might be able to link Picard to other local databases. For example, I maintain a local sqlite database of all the releases, tracks, artists and such for everything in my music collection (including a location for which archive box contains the original CD), for easy lookup and the ability to produce a catalog of my music library. I’m sure there are others that may be doing something similar.

On the other hand, I know how hard you’ve worked at trying to reduce the dependencies and libraries distributed with Picard. Does it make sense to include something that isn’t used by Picard itself? Especially when the trigger for including something is a fairly niche plugin, which may not be very widely used. (Note that I have no way of knowing the popularity and extent of the use for any of my plugins.) Does it make sense to have every user pay a (slight) disk space penalty just to accommodate a niche market?

A bit of a conundrum to be sure. My selfish side would love to see the sqlite library included, but my pragmatic side isn’t convinced it is worth it.

I know this thread isn’t actually about all plugins, but what am I missing to get https://picard.musicbrainz.org/api/v2/download?id=instruments ported to v3? It seems so simple, but I can’t get an %_instruments% script variable to generate.

(I can’t use Picard’s default behavior because it does things like include “bass guitar” within “guitar” when I want them separated, and includes “background vocals” inside “vocals” when I want them separated, etc.)

@yindesu not sure to understand, but you tried to convert the plugin to V3 and it doesn’t work, right?
I assume you used the migration script?
I suspect some function signatures changed and you need to manually update them.

If you want I can have a look and convert the plugin (Picard team will convert old V2 plugins on demand, we didn’t convert all because some are unused and that’s a way to wipe old stuff no one use).

As I understand it, that plugin was developed by @dseomn so he may want to take a look at converting it. If he’s not interested, I am familiar with metadata plugins for Picard 3 (based on converting my Additional Artists Variables plugin and a few others) and could do the conversion. Alternatively, I could do the conversion and later transfer the repository to @dseomn so that he retains ownership (and gets to deal with any bug reports or maintenance requests :wink:). I’ll try sending him an email to see what he prefers.

I tried migrated the Instruments plugin several ways - with picard/scripts/migrate_plugin.py at master · metabrainz/picard · GitHub and more manually. Either way, it no longer behaves the same in Picard 3 as it did in Picard 2 when used to power my userscript Taggerscript + Plugin: Separating performers by instrument - #10 by yindesu

Think I figured it out… this V2 code didn’t migrate automatically/correctly from

def add_instruments(tagger, metadata, *args):

to the V3 signature

def add_instruments(api, track, metadata, track_node, release_node=None):

3 Likes

Is there any option to keep it in an official metabrainz repo like it was in v2? I do still use that plugin and I’m happy to maintain it, but I don’t really want to install picard 3 until it’s in Debian. So if people want it migrated to v3 before that, it’s probably better if it’s somewhere that the metabrainz team can let others contribute to.

I understand your position regrading not switching until it’s released in Debian.

The Picard 3 plugins each need to be in their own repo, so there isn’t really an option for keeping it under the old “picard-plugins” repo. When I have a few minutes, I’ll set up a repo for it and do the conversion. Then whenever you’re ready I can just transfer the repo to you.

Right, I wasn’t asking about keeping it in picard-plugins, but about keeping it in its own metabrainz repo.

@dseomn yes, that’s possible to host it as metabrainz/picard-plugin-*

2 Likes

Sorry, I misunderstood. As @Zas mentioned, we can set it up so that it’s hosted as a metabrainz repository. We did this for some others, including @Sophist’s “View Script Variables” plugin.

Further to this, I’ve converted the “Instruments” plugin and it is now available at GitHub - metabrainz/picard-plugin-instruments: Adds a multi-valued tag (~instruments) containing all the instruments (including vocals), for use in scripts. · GitHub. I’ve also submitted a request to have it added to the official plugin registry for Picard 3.

EDIT: The plugin has now been added to the registry, so should appear on the list when installing a plugin.

1 Like

I’m wondering:
The decision to overhaul the mechanics behind how plugins work for Picard v3 is breaking functionality of existing plugins that many users have been using and have appreciated for many years now. For example, the Classical Extras plugin is an impressive piece of work that the developer must have spend countless time and effort on.
What is being done to try to make sure that such plugins are not thrown into the trash bin as some useless old coat?

As people request a plugin be converted for use with Picard 3, we’ve been trying to contact the plugin author to find out their plans with respect to conversion. If they have no plans to do the conversion, a small group of volunteers (2 or 3 of us) take on the task as we have time. I don’t think any of us have addressed “Classical Extras” yet, even though it is one of the more popular plugins. I know that I haven’t had the time available to take on something that large and complex, and I expect that’s the same for the other volunteers doing the conversion work.

1 Like

Thank you for your (rd)swift reply.
I will be clinging on to Picard v2 then.
Will Picard v2 be maintained and updated?