<Composer> maps to display composerWhy not to 'Composer?
I would need to add a <Composers> tag (like <Artists>) to make the individuals availableI can't oversee what that would mean exactly, but in general my opinion is that it is good to always be clear and consistent about the differences between plural and singular for all tags.
I'm ok with this as long as the current functionality of <Composer> remains the same.But not the fact that for virtual tags MB currently parses 'display composer' instead of 'composer' I hope?
1. Can it be changed so that the actual 'Composer' tag is always used when a virtual tag uses <Composer>, and does not switch to using Display Composer if that happens to be populated too?#1
(perhaps <Display Composer> could additionally be made available for use in virtual tags so to have that option available too? But then again that may not be needed when 3.6 gets <Composers> )
2. Are there occasions where MusicBee will auto-populate the Display Composer tag by itself? (similar to Display Artist)
For now I am deleting all existing Display Composer tags from my library, which solves the current issues, but I am concerned MusicBee might populate them again at some point without me knowing.Not knowing anything about the classical side of music, are you sure that's a good idea...
Not knowing anything about the classical side of music, are you sure that's a good idea...That is where <Composers> gets in. (which is going to be added for MusicBee 3.6)
Looking at ur screenshot, I don't see C. Richard F. Maunder as a separate <composer> tag.
Do you have that value saved elsewhere? Won't you lose a record of that person in the file once you clear <display composer>?
For me, then <Composer> will be a singular value (it could be "Composer1, Composer2" though, note the use of a comma instead of a semicolon)Will <composers> be a writable tag? I got the impression that it would only be for display purposes in the virtual tag editor and other concerned areas.
<Composers> will contain all 'composers', which in my case (using Picard) will automatically get populated with all the people that had some significant role in how the composition came to be.
The suggestion is valid, the way I see it too, but if taken up, won't it necessitate a change in the result/output of <artist> as well?That may be a valid point, but I have no virtual tags that make use of artist or artists, so I have no opinion on that. Others may want to chip in on that?
Will <composers> be a writable tag? I got the impression that it would only be for display purposes in the virtual tag editor and other concerned areas.Absolutely, it will be a regular tag just like all the others.
I can't understand at the moment why you don't prefer <composer> having multi-values.I won't go into the details of my over-complicated schemes, but for
Ignore my statements if they are truly missing the point.I certainly won't ignore any of your comments ;-)
But not the fact that for virtual tags MB currently parses 'display composer' instead of 'composer' I hope?
#2
In my testing, <display composer> is only written to the file when the composer field in the Tag Editor is different from the actual value(s) in <composer>, if that make sense.
My stupidly complex Virtual Tags parse "Display Composer" as it is currently.Ok, but you are not actually 'telling' MusicBee to use 'Display Composer' to retrieve the data.
Ok, but you are not actually 'telling' MusicBee to use 'Display Composer' to retrieve the data.
It just 'happens' that you have populated 'Display Composer', and in that case MB switches from parsing 'Composer' to parsing 'Display Composer'.
There may be history for that behaviour, but I still find it odd and unexpected.
If I understand your setup correctly, as soon as <Composers> is available, couldn't you simply copy your <Composer> tags to <Composers>, and then do a search and replace in your virtual tags to replace <Composer> with <Composers>?
That shouldn't be a big operation?
Person 1; Person 2; Person 3edit:
And out of curiosity, in your case, where does mp3tag retrieve composer data from? MusicBrainz?
Not necessarily, because <Composers> will be formatted asI am doing: Composer1, Composer2, Composer3 for <Composer>Codewhile my use case for "Display Composers" is Person 1, Person 2 and Person 3.Person 1; Person 2; Person 3
While we're on this topic... @Steven, would it be a problem for <Lyricist> to be given the same treatment?
Correct me if I'm wrong, but <Lyricist> also maps to something like "Display Lyricist"?
On v3.6, there is indeed now a <composers> field available for use in virtual tags, display fields, etc.Absolutely, it will be a regular tag just like all the others.<Composers> will contain all 'composers', which in my case (using Picard) will automatically get populated...Will <composers> be a writable tag? I got the impression that it would only be for display purposes in the virtual tag editor and other concerned areas.
If <composers> is to work the same as <artists> (as I've understood it), it will merely be a readable tag that contains all the individual <composer> tags.
On v3.6, there is indeed now a <composers> field available for use in virtual tags, display fields, etc.
But one cannot actually write to this tag, it is read-only.
Forgetting all of that, is it working how you imagined it would for your use-case?
I really wish that for a future update we can have both 'Album Artists' and 'Composers' as fully functional, independent tags.Haven't given much thought to the above as I reply (will come back on it).
<album artists> sounds like it has its own separate 'debate' (hence why I didnt mention it above). Will think more on these and revert with more opinions.Here's my argumentation for having a dedicated Album Artists tag:
could you explain what the benefit of this read-only implementation of Composers is exactly?Yes, with it, one's able to access the actual <composer> values (like <artists> which accesses the actual <artist> values)
E.g. can it do anything that a simple virtual tag can not do?
Yes, with it, one's able to access the actual <composer> values (like <artists> which accesses the actual <artist> values)Thanks for this Mayibongwe.
Without <composers>, there'd be no way to access Wolfgang Amadeus Mozart on the below, since it would spit out the display composer instead:
I did add Composers as a tag in v3.6, so if its causing a problem i can remove itThe current implementation surely causes problems for me.
But I don't understand. How do you mean, "there'd be no way to access Wolfgang Amadeus Mozart on the below".Right. He is the composer, and he is in the Composer tag.
He is the composer, and he is in the Composer tag?
I did add Composers as a tag in v3.6, so if its causing a problem i can remove itWe're at crossroads here because if <composers> is removed, that means folks who want access to the actual composers will never have access to that tag.
i have removed it for nowThanks.
https://getmusicbee.com/patches/MusicBee36_Patched.zip
Correct me if I'm wrong, but <Lyricist> also maps to something like "Display Lyricist"?To answer the above...It doesn't, at least not from what I can see in MusicBee's Tag Editor and Inspector.
@hiccup, something else just caught my eye:It's interesting to see how focused and fascinated you are about that specific screenshot ;-)
On your earlier screenshot (https://getmusicbee.com/forum/index.php?topic=39262.msg220329#msg220329), you seem to have an <artists> tag (Christopher Hogwood) that you must have populated externally.
@hiccup, something else just caught my eye:Yes, I can...
On your earlier screenshot (https://getmusicbee.com/forum/index.php?topic=39262.msg220329#msg220329), you seem to have an <artists> tag (Christopher Hogwood) that you must have populated externally.
Like what had transpired with <composers> yesterday, you can't actually make use of that <artists> tag in MusicBee, can you?