Picard 3.0 Q&A

MusicBrainz Picard is a core piece of MetaBrainz. According to the 2017 user survey, ‘Using a tagger which relies on MB’ was the second most common way that editors found out about the existence of MusicBrainz, with 27.1%. Only narrowly beaten by the ever-popular ‘Don’t know/don’t remember’ option, at 28.8%. If MusicBrainz provides the metadata lifeblood, then MusicBrainz Picard is the conduit that splashes that bloody metadata across the globe, onto billions of music files. Gross! But also awesome!

Now MusicBrainz Picard is entering the next stage, with development moving onto version 3.0. What does this mean? outsidecontext, long-time voluntary MusicBrainz Picard contributor, maintainer and user support-er, has agreed to answer some of our questions.

aerozol: Kia ora outsidecontext, thank you for agreeing to answer some questions about Picard 3.0!

You have been an open-source contributor for MusicBrainz Picard for a long time, giving us your valuable time, and balancing it with your day job, family and other projects and hobbies. What is it that first attracted you to MusicBrainz? 

outsidecontext: Thank you aerozol for your interest. I found MusicBrainz in 2006. Like many of us in the community I wanted to clean up my personal music collection. A new version of Picard was in development at the time, internally called Picard Qt, because it was a port of the existing tagger to the Qt GUI toolkit. Development on the Qt version was primarily done by Lukáš Lalinský, who is now doing the amazing job of running AcoustID.

Because Picard Qt was in early alpha stage in 2007 I started contributing my first patches to fix issues I faced. From that point on I got more and more involved. There had been a couple of years in between where I had not been very active, but shortly after the release of Picard 2.0 in 2018 I took an active role in Picard’s development again.

aerozol: And what keeps you interested, after all this time?

outsidecontext: What motivates me is that I really love both the idea of MusicBrainz and also the community around it. I think it is one of the most welcoming and friendly online communities around.

I also intentionally chose to contribute to Picard and not the server code. In my professional work I have been mostly a web application developer, with a strong focus on backend work. In my current position I hardly do any programming myself anymore, except for code reviews. Working on a free software project scratches my itch to do some programming, but at the same time working on a desktop application is far enough from my day job that it stays interesting.

aerozol: How much of your time does MusicBrainz Picard take up?

outsidecontext: It’s hard to tell, as it varies, depending on how much time and energy I have. But I spend some time on Picard on most days before or after work. That’s not always development, but involves a lot of forum support, bug triaging, code reviews and general maintenance for example for the build system, packaging and automated tests.

aerozol: Briefly, what’s your favourite non MetaBrainz-related project or hobby that you are also spending time on or with, at the moment?

outsidecontext: In addition to swimming as a sport I take care of my terrariums, in which I currently keep praying mantises in particular. These animals are simply fascinating, and I love watching them.

aerozol: Wow, now I need another Q&A for all my questions about praying mantises! But, for now, let’s get down to business. Picard 3.0! I’ve heard it’s a big deal. Why?

outsidecontext: The big change of Picard 3.0 will be that we switch the Qt toolkit to the latest version Qt 6. This ensures Picard stays up-to-date, maintainable and compatible. For example it also allows us to provide a version for macOS that natively runs on the new “Apple Silicon” ARM based CPUs.

As upgrading the Qt toolkit also breaks many plugins we decided to take the big step of redesigning the plugin system. The current plugin system has a couple of limitations, and improving it has been in the talks for years.

And we will have this year’s Google Summer of Code project, which is done by twodoorcoupe and will provide some image processing functionality, such as resizing and format conversion, for Picard’s cover art support.
We will of course also have the usual general improvements and bugfixes. But we intentionally limited the scope to avoid too many large changes.

aerozol: What are the issues of the current plugin system, and how will Picard 3.0 improve this?

outsidecontext: There are two core issues: For one there is no properly defined plugin API, despite a couple of plugin hooks. That means existing plugins often use all kinds of internal Picard code, which makes it difficult to change Picard’s internals without breaking a plugin. Also existing plugins mix metadata about the plugin (for example its name, version or compatibility with Picard) with the actual code. In practice this means once you have installed a plugin Picard will run the plugin code on startup, regardless of whether the plugin is enabled or not. This can have unintended side effects and also is a potential security issue.

The new plugin system will cleanly separate metadata from code and will provide an actual plugin API.

We also want to improve the situation for third-party plugins, so they do not need to rely on the central plugin repository. The current system makes it difficult for complex plugins, like the popular Classical Extras. For updating a plugin the plugin developers need to rely on someone from the core team to review and merge any changes. At the same time a plugin like Classical Extras is complex enough that it cannot be maintained by the small Picard core team.

aerozol: That sounds great! But also scary. What if I rely on or just prefer how things are now, in Picard 2? Will I still be able to use it?

outsidecontext: Yes, Picard 2 will continue to work and we also have plans to do some maintenance releases with bug fixes and minor improvements to keep it around for a while. We will do this primarily to support older systems and keep Picard running there.

One downside of the Qt 6 update will be that we have to drop support for some older operating systems. We will for example not be able to support Windows 7 anymore. For macOS it is not final yet, but it looks like the minimum supported version might become macOS 11 “Big Sur”. We try to keep this as low as possible, but in the end it also depends on what Qt 6 and the Github build servers are supporting.

But if you are running a system that is compatible with Picard 3.0, I think there will be little reason not to switch. The overall application stays the same.

aerozol: What features are you most looking forward to implementing in Picard 3.0, that you haven’t been able to do in Picard 2? And why wasn’t it possible before?

outsidecontext: It really is the new plugin system. The plugin system has been an issue for years, but it is just not possible to tackle without breaking changes. Also this allows us to do more extensive refactoring of the current code base and get rid of otherwise unused code. zas has been working on many large code refactorings in recent weeks.

aerozol: You mentioned that you intentionally limited the scope for Picard 3.0. Why is this?

outsidecontext: The Picard core team is small, currently it’s mainly zas, myself and rdswift. I don’t want this to become a project where we are developing a new version in the background without releasing anything usable for years. In recent years we have managed to release multiple versions per year, and we should strive to do so in the future.

I understand that it is tempting to say that if we increase the major version number we should change everything. There are many ideas: Totally rework the UI, replace the configuration system, rebuild Picard from the ground up to allow better multi-threading.

But we have to be realistic and focus on changes we can actually manage in a reasonable timeframe. This is not the last version of Picard, it is just the next version. We can do all of the above in future updates. There can, and hopefully will, be a Picard 4.0.

Having said this I also want to stress that we don’t exclude features, it just needs someone to actually work on it. If you have some development skills and want to see some specific change become part of Picard 3.0, get in touch and start working on it.

aerozol: It’s not all fun and games in the Github code-mines, I assume. Is there something you’re dreading having to code, or re-code, for Picard 3.0?

outsidecontext: For me personally it is mostly the platform support, ensuring the build system works and that Picard runs on all supported operating systems. Issues with that are often time consuming and annoying to fix.

aerozol: Is there anything else that you would like to share?

outsidecontext: Yes, I want to thank everyone in the community who has contributed to Picard with code, translations, feedback, ideas, issue reporting or just with some friendly words. I really enjoy the discussion on the forums and on IRC.

aerozol: If users want to follow Picard 3.0 production, is there somewhere we can follow progress? And is there anything we can do to help?

outsidecontext: Yes, all the tickets we want to tackle for Picard 3 can be seen in the MetaBrainz tickets system. If you are interested you can also take a look at current pull requests on Github.

As soon as we have a first draft of the new plugin system ready we will also have a blog post about that and you are then welcomed to discuss it. At that time we should also be near a first alpha release for broader testing.

aerozol: Ngā mihi nui for your time outsidecontext!

If you have other questions please feel free to drop them in the comments on this post, in the community forums, or in their relevant tickets in the ticket tracker. But, please don’t bother asking when it will be ready – I can assure you that, at this stage, there is no firm timeline for Picard 3.0.