Merge vocals into instruments (STYLE-609)

The fact that vocals have their own attributes instead of being part of the instrument tree causes all sort of problems. For example, they can’t be related to for a hypothetical instrumentation relationship, and it’s not possible to just select “vocals” on the “member of” relationship. We should consider turning them into instruments (which the human voice basically is anyway!), and merging all three “performer” relationship types into one, with the generic “instruments” and “vocals” as selectable options as well as any of our current instrument and vocal attributes.

While actually doing this takes quite a bit of effort and won’t be as simple as just deciding it should happen, does anyone see a particularly big reason why it should not happen? I want to get the process initiated, but only if there’s a reasonably high acceptance of the idea :slight_smile:

9 Likes

Without UI changes to keep the vocal “instruments” separate, this would make it harder to enter vocal relationships.

1 Like

Why would it? You just write “soprano” and it gives you soprano, like now, no? (I guess I can see how it’d make it slightly harder to enter just “vocals” with no specific qualifier, but on the other hand, it’d allow actually using that in places like “member of” relationships)

No, it gives you soprano flute, soprano saxophone, soprano violin, soprano clarinet, soprano recorder…

For recordings with multiple vocalists, vocal credits are usually listed together, separate from the instrumentalists, so it makes sense to group them together in the UI.

And with pop recordings you have the problem of vocals often not being clearly credited as “vocals” / “lead vocals” or similar. How would I know what to enter in the search field?

I’m only talking about the effects on UI/usability here, not the database stuff.

1 Like

And one of these would/will be “soprano vocals”. I don’t see the issue here. :confused:

You would type “vocals” or “lead vocals”.

1 Like

[quote=“Freso, post:6, topic:105524”]
And one of these would/will be “soprano vocals”. I don’t see the issue here.[/quote]

The issue is that I’m looking for vocals in a list of instruments.

Why? How did I know to type that?

2 Likes

I would image that it would get renamed to something like “instruments and vocals” or “instruments/vocals”.

How do you know to type “guitar” if someone is credited with “guitar”?

1 Like

I wonder how it’d interact with any (hypothetical, future) attempt to add roles to opera works, and linking those with a performer on a release? I guess it’d probably not matter, as it’d just go unused for instruments…

The issue: we would make a very common case harder. I.e. a usability regression.

… iff the future UI will work as we imagine. It all depends on the details. I guess one could come up with a dialog that is more streamlined. One off-the-cuff suggestion is to have both „add instrument“ and „add vocal“ buttons in the same dialog.

What I like about the suggested change is that it makes the case of mixed vocal/instrument performers easier – like the archetypical guitar-plus-vocal. No need to add the artist twice!

1 Like

That would also be served by any relationship that has an instrument/vocal attribute including both UI parts. I’m not sure that moving vocals into the instrument ui would improve usability.

1 Like

I think all this UI discussion is beside the point. It is essential to decide how to best represent things at the database level; what the editing UI or a tagger make from this is secondary.

4 Likes

Right now, that only works for relationships that use them as attributes. We can’t, for example, have a relationship that says “this artist predominantly performs soprano vocals”, while we could do that with electric guitar. Similarly, we could relate a violin and piano work to “instrumentation: violin and piano”, but not a voice and piano one. Just UI changes don’t solve that issue, which is basically that vocals and instruments are currently completely different levels of data, despite being basically equivalent in use.

3 Likes

I strongly disagree here. The discussion here clearly stated that it will affect the UI and is not merely a data structure change not visible to the user. If it is only a change in data and the UI stays the same there is no need to discuss this.

But as I understood it so far it is planned to merge the instrument and vocal trees and this will change the UI. I see having just a single “instruments” select list which also contains the vocals as confusing and a loss in usability. I am sure we can find ways to make up for this somehow with some UI changes, but these need to be part of this discussion.

4 Likes

I’ll grant you that better representation at the database level is primary, and the editor UI or use of data is secondary. But usability regressions also matter. Therefore, it might be that a desirable database change must not proceed until an complementary UI change is also designed and ready to proceed.

5 Likes

I think for this to work the taxonomy represented by the Instruments table would need to be a hierarchical one. So at the top there would be a “Vocal” or “Voice” category; with subcategories for the typical “Soprano”, “Alto”, “Tenor”, and “Bass”; with further subdivisions below that. Then UI’s could employ the hierarchy to use filters to present to the users a subset of the available instruments if that aids in usability. I would also argue that a hierarchical taxonomy is more than a mere accommodation of UI needs; but represents better data modeling of instruments since there is an explicit “type of” relationship between Instrument types that can be used to find “similar” instruments.

1 Like

I think merging vocals and instruments could be useful, since we already have “instruments” that are the body of the player, and there are edge cases that could be classified as a either an instrument or a vocal (such as beatboxing). Then again, if we go with @dukeja’s suggestion, we’ll still have that problem (though it’s still a good suggestion).

Not really a useful comment of mine, I know, just some random thoughts. :wink:

This may be taking the conversation a bit too far afield, but I thought some involved in this conversation would appreciate this. The ICOM International Committee for Museums and Collections of Musical Instruments has adapted an old and widely supported classification system called the Hornbostel-Sachs classification system to classify the various instruments they keep in their collections. The thing is, that classification system doesn’t necessarily lend itself to improved UI experiences. The UI experience, as well as the way in which instruments are referenced in music compositions, recordings, or releases; isn’t from the perspective of a museum curator.

But it’s interesting to look at. Perhaps the coding system could be used to remove ambiguity.

MIMO Revision of the Hornbostel-Sachs classification system

I think Musicbrainz, taking a leaf from Wikipedia’s book, already traces its „Instrument Tree“ in part to Hornbostel-Sachs.

In our context, I think H-S is too academic to be very helpful. At least I always forget what an ideophone is…

It’s also quite old, is it updated to developments of the last 40 years? C.f. the recent discussion of sequencing/programming/…

@dukeja’s link is an update of that classification. But I have only read a little bit, because it’s a long document. :wink:

Personally I think that a “tree” is a bit too limiting for classification. For example, instruments can be both chordophones and electrophones. That’s hard to visualise in a tree.

1 Like