# Add an instrument type for standard groupings \[STYLE-936\]
**URL:** https://community.metabrainz.org/t/add-an-instrument-type-for-standard-groupings-style-936/364879
**Category:** Style
**Tags:** officialstyle
**Created:** [March 8, 2018, 7:30am UTC](https://community.metabrainz.org/t/add-an-instrument-type-for-standard-groupings-style-936/364879 "2018-03-08T07:30:22Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@reosarevok](https://community.metabrainz.org/u/reosarevok)
#### Post date: [March 8, 2018, 7:30am UTC](https://community.metabrainz.org/t/add-an-instrument-type-for-standard-groupings-style-936/364879/1 "2018-03-08T07:30:22Z")
In a recent conversation with @ApeKattQuest_MonkeyPython, he mentioned [the Brazilian “bateria”](https://en.wikipedia.org/wiki/Bateria) as something he would want to add to MusicBrainz to be able to indicate a lot of instruments are part of it, but which doesn’t really match the current options as it’s not really an instrument in itself. This reminded me that we’re still using “strings [string quartet]” and stuff like that for other standard group combinations (well, I’m just using “strings”, but I know @loujin for example uses “strings [string quartet]”). And we thought we’d like to create a new type of “instrument” (name may be “grouping”?) for these kind of groupings, that would allow us to state, for example, “string quartet includes violin, viola, cello”. It seems like a reasonable thing that for us to store, but I didn’t want to just add this without some discussion - so I’d like to know if people think this would be a bad idea 🙂
I think this would also be useful for [STYLE-470](https://tickets.metabrainz.org/browse/STYLE-470) (instrumentation for works). It would also allow merging “orchestra performed” into the instrument list, same as with vocals ([STYLE-609](https://tickets.metabrainz.org/browse/STYLE-609)), to eventually have just one “performed” relationship instead of many.
If after [STYLE-609](https://tickets.metabrainz.org/browse/STYLE-609) we have a UI that separates instruments and vocals somehow even if they’re stored the same way in the background, I’d probably also want a third section for groupings (and I’d probably want to move “choir vocals” to be a grouping, eventually, too, but that’s getting ahead of ourselves).
---
### Author:  [@reosarevok](https://community.metabrainz.org/u/reosarevok)
#### Post date: [March 8, 2018, 7:30am UTC](https://community.metabrainz.org/t/add-an-instrument-type-for-standard-groupings-style-936/364879/2 "2018-03-08T07:30:35Z")
---
### Author:  [@obtext](https://community.metabrainz.org/u/obtext)
#### Post date: [March 8, 2018, 8:41am UTC](https://community.metabrainz.org/t/add-an-instrument-type-for-standard-groupings-style-936/364879/3 "2018-03-08T08:41:51Z")
I think it’s a good idea. Another example would be the [gamelan](https://musicbrainz.org/instrument/a26a663e-3add-42e1-ac07-ce289d5f330a).
How about calling it an ensemble? Or does that sound too much like a group of perfomers?
---
### Author:  [@ApeKattQuest\_MonkeyPython](https://community.metabrainz.org/u/ApeKattQuest_MonkeyPython)
#### Post date: [March 8, 2018, 9:25am UTC](https://community.metabrainz.org/t/add-an-instrument-type-for-standard-groupings-style-936/364879/4 "2018-03-08T09:25:22Z")
oh yes, gamelan is also a good example.
I’ve also seen “ensemble” used - actually I think maybe that’s the most common used term?
but as it is also a specific thing, would “grouping” be a more neutral word?
---
### Author:  [@Griomo](https://community.metabrainz.org/u/Griomo)
#### Post date: [March 8, 2018, 10:10am UTC](https://community.metabrainz.org/t/add-an-instrument-type-for-standard-groupings-style-936/364879/5 "2018-03-08T10:10:33Z")
> [@reosarevok](#):
>
> “string quartet includes violin, viola, cello”.
That definition would include [4vln](http://imslp.org/wiki/Category:For_4_violins), [4vla](http://imslp.org/wiki/Category:For_4_violas), and [4vlc](http://imslp.org/wiki/Category:For_4_cellos) works, and Arensky’s both Str4:s, of which the 1st is standard (2vln,vla,vlc) and the 2nd is not (Vln,vla,2vlc); which inturn is fine, and fine to have explicit. One can always sort out those 2vlc str5:s by detailed instrumentation or tags.
Ensemble is the common term.
---
### Author:  [@loujin](https://community.metabrainz.org/u/loujin)
#### Post date: [March 8, 2018, 7:45pm UTC](https://community.metabrainz.org/t/add-an-instrument-type-for-standard-groupings-style-936/364879/6 "2018-03-08T19:45:31Z")
> [@reosarevok](#):
>
> I’d like to know if people think this would be a bad idea 🙂
Not me 😄
I’m using “strings” for a group of string instruments, so a dedicated “ensemble” (with precise instruments) would be better (+ all other standard combinations in classical)
Question for the future: does that mean we would use preferably this ensemble instead of individual performers for recording relations?
---
### Author:  [@ApeKattQuest\_MonkeyPython](https://community.metabrainz.org/u/ApeKattQuest_MonkeyPython)
#### Post date: [March 8, 2018, 7:47pm UTC](https://community.metabrainz.org/t/add-an-instrument-type-for-standard-groupings-style-936/364879/7 "2018-03-08T19:47:57Z")
> [@loujin](#):
>
> Question for the future: does that mean we would use preferably this ensemble instead of individual performers for recording relations?
I’d say that if you know the individual performers and their instruments, it’s still good to add those.
But that if all there is is a “strings quartet” credit, you can use the new ensemble
---
### Author:  [@mfmeulenbelt](https://community.metabrainz.org/u/mfmeulenbelt)
#### Post date: [March 8, 2018, 7:53pm UTC](https://community.metabrainz.org/t/add-an-instrument-type-for-standard-groupings-style-936/364879/8 "2018-03-08T19:53:24Z")
I think this is a good idea, but how should we handle ensembles whose members are less set in stone? No doubt there are cases when an instrument is often considered to be a part, used to be considered a part or is starting to be considered a part of an ensemble.
---
### Author:  [@MetaTunes](https://community.metabrainz.org/u/MetaTunes)
#### Post date: [March 8, 2018, 10:55pm UTC](https://community.metabrainz.org/t/add-an-instrument-type-for-standard-groupings-style-936/364879/9 "2018-03-08T22:55:34Z")
In principle, this sounds very logical. Presumably, “orchestra” would now be an ensemble-type instrument of which there might be variants such as “string orchestra” or “chamber orchestra”? I guess the devil is in the detail. For example, would there be knock-on effects for Picard or existing database queries?
---
### Author:  [@spitzwegerich](https://community.metabrainz.org/u/spitzwegerich)
#### Post date: [March 9, 2018, 8:26am UTC](https://community.metabrainz.org/t/add-an-instrument-type-for-standard-groupings-style-936/364879/10 "2018-03-09T08:26:01Z")
I like the idea, but we should make sure to get this right from the beginning. That is, please set up the thing such that we can represent the logic of the members of an ensemble **on recording level** :
Let us add the ensemble-instrument “string quartet” to some recording, let us add the instruments “artist A, violin”, “artist B, violin”, “artist C viola”, “artist D cello” to the recording and **additionally let us set some relationship indicating that they are part of the string quartet**. (I hope that this is planned, but from the written suggestion I’m not sure.) Ideally, we can also indicate the voice like “violin I”, “violin II” at that relationship (like we already can enter that the role of that baritone singer is “Papageno”)
Without that, it’s going to be a mess. This [discussion](https://community.metabrainz.org/t/duplicating-recording-artist-in-recording-ar/181473?u=spitzwegerich) is somewhat related.
---
### Author:  [@obtext](https://community.metabrainz.org/u/obtext)
#### Post date: [March 9, 2018, 9:01am UTC](https://community.metabrainz.org/t/add-an-instrument-type-for-standard-groupings-style-936/364879/11 "2018-03-09T09:01:23Z")
> [@spitzwegerich](#):
>
> Let us add the ensemble-instrument “string quartet” to some recording, let us add the instruments “artist A, violin”, “artist B, violin”, “artist C viola”, “artist D cello” to the recording and additionally let us set some relationship indicating that they are part of the string quartet.
I agree that would be ideal, but I fear it would be a complicated change to make, requiring a three-way relationship between recording, quartet and performer. (I’d be happy to be corrected if there’s an easier way or if this is easier than I think.) However, even if we can’t do this (yet) I don’t see why it should block the introduction of the new instrument type. The functionality you mention could still be added later (and probably scripts could then be used to fix things up in most cases.)
---
### Author:  [@spitzwegerich](https://community.metabrainz.org/u/spitzwegerich)
#### Post date: [March 9, 2018, 7:36pm UTC](https://community.metabrainz.org/t/add-an-instrument-type-for-standard-groupings-style-936/364879/12 "2018-03-09T19:36:43Z")
> [@obtext](#):
>
> I agree that would be ideal, but I fear it would be a complicated change to make, requiring a three-way relationship between recording, quartet and performer.
The [request](https://tickets.metabrainz.org/browse/MBS-1159) for 3-point (or n-point) relationships is sitting there since 2010. 27 votes, and nothing happens. Why wait forever? This should be done really with high priority, and if the instrument groups add another reason to it, so much the better.
Sure, it needs some thought how to optimally represent those relationships in the database. But in the end, it’s a fairly standard database task and no rocket science.
> [@obtext](#):
>
> The functionality you mention could still be added later (and probably scripts could then be used to fix things up in most cases.)
Honestly, I disagree. Starting with some half-baked solution and counting on later script magic or clean-up volunteers is a waste of resources at least, not to say wishful thinking. First provide the needed framework, then add the new feature to allow the editors to get everything right in the first run.
---
### Author:  [@obtext](https://community.metabrainz.org/u/obtext)
#### Post date: [March 10, 2018, 10:03am UTC](https://community.metabrainz.org/t/add-an-instrument-type-for-standard-groupings-style-936/364879/13 "2018-03-10T10:03:31Z")
> [@spitzwegerich](#):
>
> The request for 3-point (or n-point) relationships is sitting there since 2010. 27 votes, and nothing happens.
Yes, that’s exactly why I said I feared it would be complicated. I assume that if it were easy then [MBS-1159](https://tickets.metabrainz.org/browse/MBS-1159) would have been done by now. 😉
But maybe the only reason it hasn’t is that it’s lacked a ‘killer application’, and [STYLE-936](https://tickets.metabrainz.org/browse/STYLE-936) will provide it. If so, great!
> [@spitzwegerich](#):
>
> Starting with some half-baked solution and counting on later script magic or clean-up volunteers is a waste of resources at least, not to say wishful thinking.
We already have many [examples](https://musicbrainz.org/recording/37c6ddfe-228a-4e45-be13-c0788ad945dc) of recordings that have separate performer relationships to a string quartet (‘[strings](https://musicbrainz.org/instrument/32eca297-dde6-45d0-9305-ae479947c2a8)’) and to the individuals involved. How would the suggested change make matters worse?
---
### Author:  [@ApeKattQuest\_MonkeyPython](https://community.metabrainz.org/u/ApeKattQuest_MonkeyPython)
#### Post date: [March 12, 2018, 7:35pm UTC](https://community.metabrainz.org/t/add-an-instrument-type-for-standard-groupings-style-936/364879/14 "2018-03-12T19:35:33Z")
> [@spitzwegerich](#):
>
> Starting with some half-baked solution and counting on later script magic or clean-up volunteers is a waste of resources at least, not to say wishful thinking.
I would like to say something, the "use on releases to indicate that Ensembles are playing “ensemble” is only one, application of this suggestion.
Generally the reason I wanted this in the first place was being able to link instruments that are played together succinctly. That is my (as instrument inserter no less) first priority for this.
That it _can_ be used for “strings [string quartet]” type relations to recordings and releases is only one of several utilities.
> [@obtext](#):
>
> But maybe the only reason it hasn’t is that it’s lacked a ‘killer application’, and STYLE-936 will provide it. If so, great!
I also like this point, and it’s fairly valid.
It is also not half-baked, I’ve been marinating on idea like this for quite a while now, (and also a similar one, a “instrument family” one which would have less uses outside of instrument grouping.)
Thank you ~C
---
### Author:  [@reosarevok](https://community.metabrainz.org/u/reosarevok)
#### Post date: [March 12, 2018, 7:49pm UTC](https://community.metabrainz.org/t/add-an-instrument-type-for-standard-groupings-style-936/364879/15 "2018-03-12T19:49:12Z")
> [@spitzwegerich](#):
>
> Honestly, I disagree. Starting with some half-baked solution and counting on later script magic or clean-up volunteers is a waste of resources at least, not to say wishful thinking. First provide the needed framework, then add the new feature to allow the editors to get everything right in the first run.
I would agree with this if this was a completely new feature that substituted nothing, but the worst thing that can happen is that previous unrelated “violin”, “viola”, “cello” and “strings” credits will now be “violin”, “viola”, “cello” and “string quartet” (or “violin”, “cello”, “piano” and “instruments” → “violin”, “cello”, “piano” and “piano trio”) so I don’t think this would make anything actually worse.
> [@spitzwegerich](#):
>
> The request for 3-point (or n-point) relationships is sitting there since 2010. 27 votes, and nothing happens. Why wait forever? This should be done really with high priority, and if the instrument groups add another reason to it, so much the better.
>
> Sure, it needs some thought how to optimally represent those relationships in the database. But in the end, it’s a fairly standard database task and no rocket science.
I guess nobody wanted to start working on what is, in effect, a complete change of all our underlying systems soon after the NGS migration, and after that there’s been too much going on (including this year’s planned UX improvements). I brought this ticket up on the dev meeting, the answer was we _might_ see it in late 2019 but not earlier.
---
### Author:  [@spitzwegerich](https://community.metabrainz.org/u/spitzwegerich)
#### Post date: [March 12, 2018, 8:52pm UTC](https://community.metabrainz.org/t/add-an-instrument-type-for-standard-groupings-style-936/364879/16 "2018-03-12T20:52:54Z")
> [@reosarevok](#):
>
> I would agree with this if this was a completely new feature that substituted nothing, but the worst thing that can happen is that previous unrelated “violin”, “viola”, “cello” and “strings” credits will now be “violin”, “viola”, “cello” and “string quartet” (or “violin”, “cello”, “piano” and “instruments” -\> “violin”, “cello”, “piano” and “piano trio”) so I don’t think this would make anything actually worse.
I agree that it somewhat improves the current situation. Nevertheless it leaves a stale after-taste, as we don’t get the functionality that we really want.
And, hey, this is musicbrainz. We are doing things the right way, dont we?
> [@reosarevok](#):
>
> I guess nobody wanted to start working on what is, in effect, a complete change of all our underlying systems soon after the NGS migration, and after that there’s been too much going on (including this year’s planned UX improvements). I brought this ticket up on the dev meeting, the answer was we might see it in late 2019 but not earlier.
Late 2019 is … well … late. Of course it’s clearly better than “never”.
---
### Author:  [@spitzwegerich](https://community.metabrainz.org/u/spitzwegerich)
#### Post date: [March 12, 2018, 9:10pm UTC](https://community.metabrainz.org/t/add-an-instrument-type-for-standard-groupings-style-936/364879/17 "2018-03-12T21:10:02Z")
I just realized: Isn’t the existing relationship
[artist] performed [instrument] on [recording]
already a 3-point relationship? I guess it’s constructed by a 2-point [artist]-[recording] relationship, having an [instrument] in its “backpack”.
When we can place an [instrument] into the backpack, shouldn’t it be possible to put another [relationship] into the backpack, too?
Then we can modify the “orchestra” [artist]-[recording]-relationship by adding a list of “instrument”-relationships to its backpack, representing the members of the orchestra. (A list should be possible as in the “vocals” relationship; besides “instrument” we also need other performers like “vocal”, “conductor”).
That’s probably not the cleanest way to represent the logic in the database, but, hey, it might be another half-baked solution which actually carries the full information!
---
### Author:  [@spitzwegerich](https://community.metabrainz.org/u/spitzwegerich)
#### Post date: [March 13, 2018, 4:44pm UTC](https://community.metabrainz.org/t/add-an-instrument-type-for-standard-groupings-style-936/364879/18 "2018-03-13T16:44:10Z")
@reosarevok I just read [[Notes from #MetaBrainz meeting 2018-03-12](https://community.metabrainz.org/t/notes-from-metabrainz-meeting-2018-03-12/366124/1#mbs-1159)] “MBS-1159: Add support for 3-point relationships” and [Making sure you're not a bot!](https://chatlogs.metabrainz.org/brainzbot/metabrainz/msg/4137591/)
First, I would like to thank you for listening to my objections and for bringing [MBS-1159] up!
Knowing the obstacles by now, let me clarify that I’m not strictly against implementing [STYLE-936]. As pointed out, it still improves the things, given the fact that people are already doing things like strings[string quartet]. Or saxophone[saxophone quartet] (I just remembered our discussion in 2016 when I edited [this release](https://musicbrainz.org/release/706e124a-99eb-4c70-808b-9bd9d6e17c77).)
But two things would be great:
- Someone knowing the internals of the mb database should check if the desired functionality could be implemented as drafted in my last post. (On the chat protocol I saw that also CatCat realized that the existing “instrument”-relationship is already a 3-point one!)
- Keep the tension on MBS-1159! My impression that everybody wants it.
---
### Author:  [@Griomo](https://community.metabrainz.org/u/Griomo)
#### Post date: [March 17, 2018, 1:05pm UTC](https://community.metabrainz.org/t/add-an-instrument-type-for-standard-groupings-style-936/364879/19 "2018-03-17T13:05:29Z")
> [@spitzwegerich](#):
>
> Ideally, we can also indicate the voice like “violin I”, “violin II” at that relationship (like we already can enter that the role of that baritone singer is “Papageno”)
If you mean the ‘credited as’ field used as on [this release](https://musicbrainz.org/release/0dab8489-a013-3e75-a0eb-cc50f8e6a008), it makeshifts well by not overwriting its ‘tenor vocals’ parent.
> [@spitzwegerich](#):
>
> I just realized: Isn’t the existing relationship
>
> [artist] performed [instrument] on [recording]
>
> already a 3-point relationship? I guess it’s constructed by a 2-point [artist]-[recording] relationship, having an [instrument] in its “backpack”.
And I, from reading this thread thinking there are no 3-points, recently did some wrong edits. Apparently, [recorded] at [place] is already displayed on release level as [recorded] at [place] in [area] = 3 (or even […] in [area], [country] = 4).
(I thus added [recorded] in [area] and had it corrected, one edit [here](https://musicbrainz.org/edit/51525258).)
Something similar is [commented](https://tickets.metabrainz.org/browse/MBS-1159?focusedCommentId=32898&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-32898) under MBS-1159, but then there should be no ticket in the 1st place. What would be the difference, under the hood and userwise?
---
### Author:  [@reosarevok](https://community.metabrainz.org/u/reosarevok)
#### Post date: [March 17, 2018, 2:44pm UTC](https://community.metabrainz.org/t/add-an-instrument-type-for-standard-groupings-style-936/364879/20 "2018-03-17T14:44:42Z")
> [@Griomo](#):
>
> And I, from reading this thread thinking there are no 3-points, recently did some wrong edits. Apparently, [recorded] at [place] is already displayed on release level as [recorded] at [place] in [area] = 3 (or even […] in [area], [country] = 4).
>
> (I thus added [recorded] in [area] and had it corrected, one edit here.)
>
> Something similar is commented under MBS-1159, but then there should be no ticket in the 1st place. What would be the difference, under the hood and userwise?
Artist performed Instrument is done by storing the instrument as an attribute - I imagine something like X performed instrument on Y with an attribute “as a member of X” _could_ work, even if it sounds like a huge hack. That said, instruments are orders of magnitude less common than artists, so depending on how it’s currently implemented, it might not scale.
The place/area thing is just for display - the place is always in that area, so we can display it. We can’t do the same for artists, since we can’t always assume they performed as part of a group (and sometimes they might be members of many groups at once to begin with)
[Next page](https://community.metabrainz.org/t/add-an-instrument-type-for-standard-groupings-style-936/364879.md?page=2)