In a recent conversation with @ApeKattQuest_MonkeyPython, he mentioned the Brazilian “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 (instrumentation for works). It would also allow merging “orchestra performed” into the instrument list, same as with vocals (STYLE-609), to eventually have just one “performed” relationship instead of many.
If after 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).
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?
That definition would include 4vln, 4vla, and 4vlc 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.
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?
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
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.
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?
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 is somewhat related.
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.)
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.
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.
Yes, that’s exactly why I said I feared it would be complicated. I assume that if it were easy then 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 will provide it. If so, great!
We already have many examples of recordings that have separate performer relationships to a string quartet (‘strings’) and to the individuals involved. How would the suggested change make matters worse?
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.
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
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 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.
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?
Late 2019 is … well … late. Of course it’s clearly better than “never”.
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!
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.)
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.
If you mean the ‘credited as’ field used as on this release, it makeshifts well by not overwriting its ‘tenor vocals’ parent.
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)
