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


#1

It’s a minor issue, but I thought to report it anyway.

When an artist is credited as ‘guest’, and plays more than one instrument on a recording, using @Sophist 's ‘Standardise performers’ plugin, only for one instrument ‘guest’ is preserved.

E.g. taking this recording:

Picard by default will retrieve:

  • Billy Preston: guest hammond organ and rhodes piano

But using @Sophist 's ‘Standardise performers’ plugin, it will say:

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

So that looks as if Billy Preston was playing Hammond as a guest, and Rhodes as the regular piano player of that band.
(which seems improbable)

The same happens when the ‘additional’ atribute has been set for a performer playing more than one instrument.

But that raises some doubts for me where the actual problem lies.

Suppose the regular singer of a band plays additional percussion on a recording.
(the band also has a regular percussionist)

I am guessing an editor will then set the checkbox for that singer. Thus marking both instruments (vocals and percussion) as being additional.

(Please correct me if I am wrong, and an editor can set ‘additional’ (and perhaps ‘guest’) separately per instrument?)

So if the checkbox ‘additional’ has been set for that musician, it would be wrong if the plugin would append ‘additional’ to both instruments.

So by now I am a bit confused if this is maybe a ‘Standardise performers’ issue, a Picard issue, a MusicBrainz issue, or perhaps a bit of all three?

.
I wasn’t sure where to post this, so I decided on the Picard board.
so moderators feel free to move if needed


Some enhancements for 'additional, 'guest' and 'solo' attributes?
The Standardise Performers plugin doesn't always append 'guest' and 'additional'
Picard Plugin: Format Performer Tags
#2

Does it make any difference if you add more than one artist relationship, with one instrument per relationship, rather than multi-instruments for one relationship?


#3

When the attributes like guest and additional does not apply to all instruments those other instruments should be added in a separate relationship


#4

After some more tries, and giving it some more thought:

I found a release that has a guest performer entered separately as a guest per instrument.


(Ben Cullum performing on two instruments as a guest)
That ends up displaying perfectly with the ‘Standardise performers’ plugin and my script.

But when a performer has one entry with more than one instrument gathered together with ‘guest’ checked, only the first instrument credit will have ‘guest’ prevailed.

e.g.


(Billy Preston)

The same happens with ‘additional’.


Dann Huff is credited as ‘additional acoustic guitar and electric guitar’ in one combined entry.

With the ‘Standardise performers’ plugin, the ‘additional’ attribute only shows for the first instrument:

additional acoustic guitar: Dann Huff
electric guitar: Dann Huff

So, some observations for now:

There are releases in the MusicBrainz database that have ‘messy’ and/or inconsistent entries for artists being a guest or not.
e.g.


where Omar Hakim is both a ‘guest’, and a non-guest (regular) performer.

Since the guest attribute relates to a person (while ‘additional’ relates to an instrument/role), it might be good if there was some mechanism on the MB data entry webpage that prevents a performer being entered as being both a guest and a non-guest for a release.
(or at least have it trigger some alert like ‘are you sure?’)

Picard doesn’t seem to do anything ‘wrong’.
It just copies a tag such as: ‘additional acoustic guitar and electric guitar: Dann Huff’ verbatim, so you will not even consider if ‘additional’ relates to only the first instrument, or to both instruments.

The ‘Standardise performers’ plugin will create separate lines for the instrument roles, and will show the checked attributes only for the first instrument.

  • for the ‘guest’ attribute that is most likely always incorrect. (a person is a guest, or he is not)
    so ‘guest’ should be appended to both lines.

  • for the ‘additional’ attribute it will depend on how an editor has entered it in MusicBrainz’ database:

If a performer played two additional instruments, and the editor entered both instruments under the same performer relationship using the ‘additional’ checkbox, the second instrument will not be labeled as additional using the plugin.
If an editor created two separate entries for these instruments, checking ‘additional’ for both entries, it will end up displaying correct.

If a performer plays an additional instrument besides his main instrument (e.g. the vocalist playing additional percussion), the editor should always be creating two separate entries, and not one for both instruments.

.
I have no editing experience (yet), so my knowledge and insights are quite limited concerning on that matter, but allow me a suggestion:

Would it be an idea to make a change to the way these attributes are entered in the database?

  • The attribute ‘guest’ would be a checkbox next to the performer’s name, and would label all contributions from that performer as being a guest.
  • The attribute ‘additional’ would be a checkbox next to each instrument (or role, in case of e.g. ‘recording engineer’).
    So you could e.g. leave ‘additional’ unchecked for ‘vocals’, and check it for ‘percussion’, or leave ‘additional’ unchecked for ‘producer’, and check it for ‘recording engineer’.

Does this make sense? And is it feasible?


#5

Oh yes, it certainly make sense.
And as you point out, it’s not that uncommon either.
More examples could be found among rap artists.
And then we have the metal world, where various guest appearances is common as well.

I know of one track which I have not even dared to try to enter yet, but I intend to.
And I certainly would prefer that the entry is treated correct, not needing to go to further edits, changes or votes later.
It would make things easier for all involved without having “messy and/or inconsistent entries for artists”. :smiley:


#6

Makes sense to me, but I suspect implementation might not be straightforward, depending on the exact database structure (i.e., not just a UI thing).


#7

I had hard times understanding the problem here but it seems like it is just a bug in a Picard plugin, right?
Why so much text when the problem is just, IIRC:

Issue when grouped relationship attribute (guest, additional, etc.), only the first one has the attribute.

:thinking:

Try to contact the author somewhere else as it seems @Sophist did not reply this topic.


#8

The creation of this specific thread can be considered as just some initial undirected brainfart on the notion that something seems off with how these attributes are handled, and turn up in my music manager in the end.

And as I mentioned, I wasn’t sure what board to choose for it. (Picard? MB style? plugins?)
Looking back, this Picard board was exactly the one that was not appropriate, so today I created two separate topics. One for MB style, and one directed at the plugin. (including an @ notification to the author)

So I have shot my arrows in a couple of directions by now, and I’ll now just wait who will scream ‘OUCH!’

(and thanks for educating me on ‘then’ vs ‘than’)


#9

I just don’t have time to spend on Picard stuff at the moment. It is number 4 in my priority list of open source projects to work on - and I don’t have enough time to work on no. 1.

The plugin is on Github - please feel free to submit a PR to improve it.


#10

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.


#11

#12

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?)


#13

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


#14

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.


#15

@ 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)


#16

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.


#17

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!


#18

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.


#19

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:


#20

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