MDE wrote:Part of the problem is if you have structured data (a field called "Instrument") as well as unstructured data, such as "Artistname (instrument)" in the Artist and/or performer field. I wonder if the simplest approach might be to just go for the unstructured data - i.e. not implement an Instrument field. Provided all lookups (internal and external) ignore everything in brackets, I can't see why that wouldn't work. It also means that the user can put whatever they like in brackets, not just "instrument". This could be used in a number of ways. For example, at the moment, I deal with "arrangements" by putting the arranger's name after a description, so a composer tag might read "Johann Sebastian Bach; Arr. Camille Saint-Saëns" - my Mp3tag action strips the "Arr." in creating the sort key, but Saint-Saëns is not available for look-ups in Muso. If instead we had say "Johann Sebastian Bach; (Arranged) Camille Saint-Saëns" and Muso ignored the brackets, then Saint-Saëns would be available for lookups (and the album with this track would be included under his name in any Composer hierarchy). In a Conductor tag, you could include something like "(Directed from the keyboard)" - again the words in brackets would be for display purposes only (on Album/Now playing in Muso [EDIT - see below] and, of course, on the player).
I am assuming that this would only be applied to the six "contributor" fields, by the way.
So I think the "brackets" approach has merit as a significant enhancement, not only in addressing the "instrument" problem. The main feature it lacks, compared with a structured "Instrument" field, is that you can't combine it in a hierarchy. So, for example, you can't browse Piano music by Composer (a fix for that would be to allow filters and hierarchies to work together, but I realise that is a different issue).
Thoughts?
[EDIT: I think maybe displaying the full tag in the hierarchy view is also useful - it helps when in "browse" mode to see the role of artists more clearly - I'll try and do some screenshots to demonstrate this]
I like the idea of ignoring any text in brackets after any of the 6 role fields for lookups, and for aggregating the artist groups, but otherwise to display it as entered. Though I'm wondering if there are any legitimate cases where brackets are part of an artist's name? I suppose I'll make this functionality optional anyway.
Then I could possibly extract the text in the brackets to add it to the hierarchical drill-down structure. Though I'm wondering whether these suffixes for all 6 role fields should be combined into one hierarchical entity (eg. "role suffix"), or they should be kept separate: composer (suffix), band (suffix), performer (suffix), etc.
NB. I think I like the term "role" as a generic term for the 6 artistic role fields, "artist" gets confused with the artist field, "contributor" is a term we've used for supporting roles [
http://musoware.com/wiki/index.php?title=Titled_Artists].
Displaying the full tag in the hierarchy view might sometimes be useful, but it would still separate "Lisa Beznosiuk" from "Lisa Beznosiuk (flute)", for example, in cases where your tags are not fully in synch. By having "Lisa Beznosiuk" and "flute" as separate entities, you could drill down from performer to instrument (though it would be labelled "Performer suffix" rather than "Instrument" for example - as you said the suffix could be used for many things).
EDIT: a nagging doubt has just popped into my head concerning the above idea of separating role from suffix as hierarchical entities: how to ensure that for a given role, we only show HIS suffixes, not any suffixes for other roles appearing on the same album.... Will think this through.... I think I had the same issue showing conductor/orchestra combinations where there are more than one combination on an album, but I got round that somehow (eg. C1/O1 and C2/O2 on an album - don't show C1/O2 and C2/O1 as conductor/orchestra combinations!).