Some enhancements for 'additional, 'guest' and 'solo' attributes?

MusicBrainz Style
1

I have been wondering about how MB, Picard and certain plugins handle attributes such as ‘additional’, ‘guest’ and ‘solo’.

I wrote down some broader observations here earlier:
Retrieving (entering?) 'guest' and 'additional' attributes for performers playing more then one instrument?

Now trying to narrow down the different stages where these attributes come to play, I thought to zoom in at the source, it being the entering stages in the database.

I noticed that an editor can create an entry for a performer (instrument role), and add several instruments for that performer.
He can set some checkboxes such as ‘guest’ additional’ and ‘solo’ there.

What I am wondering about is this:

If he checks ‘guest’, that relates to that musician as a person, and it will (almost certainly?) be correct that it applies to all the instruments that are listed in that entry.

But when ‘solo’ or ‘additional’ is checked, that will also be applied to all instruments. And that will in many cases not be correct.
E.g. a keyboard player playing hammond organ, and a solo on a rhodes piano)
(I think understand now that in that case an editor should create separate entries for both instruments for that musician, but will all editors know that and be aware of that?)

Also, when ‘guest’ is checked in one ‘multi-instrument’ entry for a musician, but -perhaps another- editor creates an additional entry for that musician without labeling him as a guest (or the other way around), the release will have the same person credited as a guest for some instruments, and as a non-guest (a regular) for others.

This is a real-world example where something like this happens:


(also take a look at the release credits at the bottom)

Would it be an idea to have:

A single checkbox for ‘guest’, that will apply to the person (thus all instruments) for that entry.
Separate checkboxes per instrument for ‘additional’ and ‘solo’.

Some control mechanism in the entry system that either prevents or warns when a new entry is inconsistent in relation to labeling one and the same person as being both a guest and a regular for one and the same release?

2

I don’t understand the problem or the specificity of MONEY FOR NOTHING track.
I guess you mean STING on guest vocals, but what is wrong or what is outstanding, there?

3

When this ‘attributes’ issue triggered my attention earlier this week, it was partially because that specific release had no less than five entries for who was playing drums.
Among which Omar Hakim was both a guest and a regular.
(which obviously can’t be the case)

(you can read it back here:
_https://community.metabrainz.org/t/a-script-to-change-and-reorder-tag-names/399594_)

Checking that specific release again just now, it looks like somebody has made some correctional edits very recently, so Omar is now not a guest anymore.

edit,
I shouldn’t post when unfocused and my attention is divided.
I think Omar is still a guest also when you look at the release notes at the bottom.

4

Regardless of the specific example, I think the issue is as described. I.e. if a performer is listed with several instruments, and ‘solo’ is checked, then all instruments have the solo attribute. If this is not required, then separate relationships must be entered. The suggestion is that ‘solo’ should be an attribute of the instrument, not the performer (like ‘credited as’) thus eliminating the need for multiple relationships. My guess is that this is a database structure issue and therefore not an easy fix.

5

Here you see? It is why I did not understand, it is a non issue to me. :joy:

6

But it is for some editors and some edits.

1 Like
7

Yes sorry, I meant that it’s by design. We have choice between two ways of listing instruments played by an artist so we can just choose the one that works on case by case.
It’s maybe not intuitive?
It seems intuitive as, feeling the limit of all instruments in same relationhsip, you found the solution of creating separate relationship in this case.
I don’t see great improvement in removing one of the two ways we have, except maintainability‐wise, maybe.

1 Like