Retrieving (entering?) 'guest' and 'additional' attributes for performers playing more than one instrument?

Thanks for responding Sophist.
My coding talents are next to zero, so the chances of me creating anything eligible for something like a pull request are as thin as the hairs on the eyelids of a tardigrade.
Good luck with all your projects, take care.

1 Like

I think that links to an older version?
It says 0.2, and I have 0.3 installed.
(probably updated to work with picard 2.x?)

1 Like

The latest version is at https://github.com/metabrainz/picard-plugins/blob/2.0/plugins/standardise_performers/standardise_performers.py

2 Likes

The coding of a fix is easy, but I don’t have time to test it.

In essence, before the for loop at line 52, you need to process the first element of the instruments array and if they exist move the words guest and solo into a variable called guest_solo. Then inside the loop at line 53 you insert this guest_solo variable before the instrument i.e. “newkey = ‘%s:%s%s’ % (mainkey, guest_solo, instrument)”. The only tricky bit is to ensure that guest_solo includes the space after each word.

This will split “guest Hammond organ and Rhodes piano: Billy Preston” into “guest Hammond organ: Billy Preston” and “guest Rhodes piano: Billy Preston” which is what I think you want.

1 Like

@ moderators
Maybe it would be better to move the previous 6 replies here:
The Standardise Performers plugin doesn't always append 'guest' and 'additional'

That’s a thread I created for narrowing down the ‘attributes issue’ to the Standardise Performers’ plugin, after learning to dissect the actual issue I ran into a bit better.

The other side of the matter concerns how these attributes are entered in MB’s database in the first place, for which I then also created a new topic:
Some enhancements for 'additional, ‘guest’ and ‘solo’ attributes?

So maybe it would be best to just close this more generic ‘attributes’ thread, and continue with the two more specific ‘Standardise Performers plugin attributes’ and the ‘MB style attributes’ threads?

Three threads about the same matter is a bit much isn’t it?
(I’m sorry about that)

1 Like

Based on the suggested changes by @Sophist, I’ve modified the plugin and submitted a pull request. The updated code can be found here. I’ve done some preliminary testing and I think it does what you’re looking for. If you run into any problems, please let me know.

3 Likes

Wow, that’s nice, and quick!

I am a bit unfocused, and much in need of shut-eye right now, so my very brief testing your code is probably not reliable at all, but at first look it looks like it results in:

  • guest hammond organ and rhodes piano: Billy Preston

while I am hoping for something like:

  • guest hammond organ: Billy Preston
  • guest rhodes piano: Billy preston

(since the reason I like and use this plugin, is that it primarily groups and sorts on instruments)

And to complicate things, I also have my own script running, that would then turn it into:

  • hammond organ · guest: Billy Preston
  • rhodes piano · guest: Billy Preston

But the support and effort is already promising and much appreciated, so thanks a lot, and nightynight to you all!

It should be splitting them into the two separate lines as you were hoping for – at least that’s what it was doing here during my testing. When you have a chance to do some further testing, please let me know if it’s okay or if there is still a problem.

2 Likes

It’s absolutely o.k.
(As I suspected myself, I must have been doing something wrong in my quick and brief single test yesterday)

Thanks @rdswift and @Sophist !

some proof: :wink:

2 Likes

This looks like a useful function that should perhaps be handled by a plugin. I wonder whether the standardise performers plugin should do this as it would standardise the instruments completely and instead of:

  • hammond organ: Fred Bloggs
  • guest hammond organ: John Smith

you would get:

  • hammond organ: John Smith, guest: Fred Bloggs

If we decide to include this functionality (which would be very easy to code) we should also decide what sequence to have performers in:

  • hammond organ: John Smith, guest: Fred Bloggs, solo: Sophist, additional: hiccup
  • hammond organ: guest: Fred Bloggs, solo: Sophist, additional: hiccup, John Smith
  • hammond organ: solo: Sophist, guest: Fred Bloggs, John Smith, additional: hiccup

or some other sequence?

And what if it is a combination of 2 or 3 from [“guest”, “solo”, “additional”]?

For code simplicity we could sort the performers as follows:

  1. Prefixed items first (or last)
  2. Sort for prefix in semantic priority order i.e. “”, solo, guest, additional (which happens to be decreasing alphabetic)
  3. Alphabetic sort for name (which for simplicity sake would put Fred Smith before John Bloggs) (because there is no performers_sorted tag from which to get the correct sort order).
  • hammond organ: Fred Smith, John Bloggs, solo: Sophist, guest: R.D. Swift, additional: hiccup
1 Like

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?

That would be fantastic.

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.

I definitely like an approach that puts all “guitar” or “vocal” credits together, etc. Like guitar, solo vs solo guitar.

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.

Format Performer Tags [Download]

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:

{Group_1} Instrument {Group_2}: Performer {Group_3}

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.

5 Likes

Amazing response from @rdswift - a new plugin with a UI in a day!!

2 Likes

Truly amazing indeed.
Me trying it out will take longer than him creating this.
And it’s already looking good at first glance…

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.

2 Likes