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
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?
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’.
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”.
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.
Try to contact the author somewhere else as it seems @Sophist did not reply this topic.
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!’
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.
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.
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.
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.
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)
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.
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.
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:
Prefixed items first (or last)
Sort for prefix in semantic priority order i.e. “”, solo, guest, additional (which happens to be decreasing alphabetic)
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