I’ve been following these conversations on script and plugin. And I have one little request to shuffle in as well.
If I am updating the tags on a file I don’t start from a clean slate. Other tags will already be in the file. This can cause a mess when more instruments are added. Especially if I run the Standardise Tags after already tagging in the non-standard way.
So my question: Is there a way to wipe out all instruments from the file tags before adding in the cleanly listed instruments of this addon?
It’s probably a matter of subjective and personal preference, but I have my script producing output like this:
instrument: Per Former
instrument · guest: Per Former
instrument ‹additional› : Per Former
instrument ‹additional› guest: Per Former
instrument ‹solo› : Per Former
etc.
I prefer having ‘guest’ at the end, right before the performer, since it is saying something about the person instead of the instrument.
Note that I am using ‘‹’ and ‘›’ instead of ‘(’ and ‘)’ because the latter would cause problems later on in certain tagging formulas I am using in my music manager.
And note the small ‘middle dot’ as some subtle devider between instrument and guest (only showing when the performer has no ‘additional’ or ‘solo’ attributes)
Additionally I have a separate part of my script that groups all vocal roles together alphabetically. So:
background vocals
choir vocals
spoken vocals
become
vocals ‹background›
vocals ‹choir›
vocals ‹spoken word›
.
This is an example of the end result in my player:
.
I am also interested in the opinion and possible input from @psychoadept about this…
Well - I can see that this is an equally valid way of looking at it - and on reflection I now see that my suggestion is polluting the list of names with attributes like “guest” or “solo” - so maybe better to leave them in the performer tag key rather than put them in the values.
In which case, I agree that some people might prefer to have “trumpet:solo” next to “trumpet” - but others might prefer to see “solo trumpet” next to “solo trombone”.
So please ignore my previous suggestion to include it as standard in this plugin.
Ditto. Personal choice.
So if anyone fancies writing a separate plugin which puts the adjectives after the noun instead of before it for both these use cases, then that might be useful to some people.
Seeing as how everyone has their own personal preferences, I challenged myself to try and come up with something that would provide a bit of flexibility in how the tags were formatted. I’m providing the result to the community. It’s pretty rough and the code could be a lot cleaner, but if anyone wants to give it a try I would appreciate any testing and comments. Note that this currently only works with instrument performer credits. A possible future enhancement would be to extend it to also accommodate vocal performer credits.
This plugin allows the user to configure the way that (instrument) performer tags are written. Once installed a settings page will be added to Picard’s options, which is where the plugin is configured.
These settings will determine the format for any Performer tags prepared. The format is divided into five parts: the performer; the instrument; and three user selectable groups for the extra information. This is set out as:
You can select the group in which each of the extra information words appears. These extra information words are “additional”, “guest”, “minor” and “solo”.
For each of the groups you can select the starting and ending characters, and whether the group is sorted in ascending or descending order.
For example, a performer relationship for Billy Preston playing a guest solo on the Hammond organ could be saved in any of the following formats:
Performer [guest solo hammond organ]: Billy Preston
Performer [solo hammond organ]: Billy Preston (guest)
Performer [hammond organ, solo]: Billy Preston (guest)
Performer [hammond organ]: Billy Preston (guest solo)
This shows only a few examples of the many possible displays that can be configured.
I never noticed (or encountered) ‘minor’ before. What is the intention for it?
It’s not a checkbox in MB’s entering panel similar to ‘guest’ and ‘solo’ is it?
It’s probably my fault this is included here, I prompted rdswift to include this when he fixed the standardise_performers plugin. My reasoning was that Picard internally supports this prefix, but on a closer look the minor prefix only applies to “collaboration” relationships between artists. Why it is in Picard I can’t say for sure. But the code is more generic inside Picard, and maybe this is some legacy thing.
At this moment I am not able to do some thorough testing, but before I do: is this plugin to be used complementary to the ‘Standardise performers’ plugin?
I.e. should the both be activated, or would it be better to disable SP and only use yours?
It includes all the functionality of the existing ‘Standardise performers’ plugin – in fact using @Sophist’s excellent work as a starting point – so it can be run stand-alone. I don’t think it would hurt anything by running the two plugins together, but I haven’t tried it.
Yup. After your comment, I included it just to be on the safe side. If there is enough interest to warrant making an “official” version and submitting it for inclusion on the Picard website, I can back out the part dealing with “minor”.
Thanks, I was motivated. It was either that or review 120 pages of legal submissions for a hearing where I’m on the presiding panel.
I still struggle with UI development. Qt and I are not the best of friends. This one was a quick hack that still took 3 times as long as it should. I’m sure the layout could be much better and more intuitive, but my main focus was to have something to capture and edit the variables. If there’s enough interest to warrant developing an “official” release, I’d welcome user input on improvements to the UI (e.g.: layout, input types, terminology, etc.)
Performer Matt Sharp has not been processed, and Jason McGerr is displayed twice, once unprocessed and once processed.
edit:
Missing form my screenshots is that I later noticed that the release also has release credits at the bottom of it’s MB page.
That is probably also a factor in this?
Thanks for the info. I’ll take a look at this in more detail, and use these releases for testing.
That is definitely a factor for some of them, but I don’t think all of them can be attributed to this. I’m reviewing the JSON dump of the raw information returned for the album “The Con” to try to see where things are falling down. Problem is that it’s over 160,000 lines long, so it’s a bit like looking for a needle in a haystack.
I’ll try dumping a different set of data from what’s being passed to the plugin to see if I can spot something to use as a work around.
Holy …
That’s not 160 lines (my country uses different delimiters ) , but 160 thousand?
Incredible.
No thanks needed. Testing and reporting is the least I can do to contribute to this marvelous creation of yours that I have been wishing that somebody could create.
(my script for it is working kind of o.k., but it has grown to more than 11.000 lines by now, and would need to be updated every time a new instrument is added to the database.)
After your comment, I included it just to be on the safe side. If there is enough interest to warrant making an “official” version and submitting it for inclusion on the Picard website, I can back out the part dealing with “minor”.
