'composer' incorrectly parsed in virtual tags

[The Incredible Boom Boom]

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"?

[hiccup]

Not necessarily, because <Composers> will be formatted as

Code

Person 1; Person 2; Person 3

while my use case for "Display Composers" is Person 1, Person 2 and Person 3.

I am doing:  Composer1, Composer2, Composer3   for <Composer>
and Composer1; Composer2; Composer3  for <Composers>

So the first one can be used for displaying purposes, and the second one for 'database' purposes.
Which is exactly the same as how I am using <Album Artist>  vs. <Album Artists>

To dive in a little bit deeper:

For me <Composer> can also look like:
Wolfgang Amadeus Mozart (Franz Xaver Süßmayr)
if there is a 'main' composer and another one that has done edits or completions.

I also have <Sort composer> that only contains the last names:
Mozart (Süßmayr)

In my case all the heavy lifting is done by Picard (scripts) that produces these variations of 'composer' tags exactly to my liking.
Pretty much all MusicBee has to do is read them.
(and using some fairly simple virtual tags on them)

[hiccup]

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"?

And while at it, could <Album Artists> also be added for 3.6?
It would make things more consistent overall, and free up a custom tag for me…

[Mayibongwe]

hiccup, I suddenly remembered this thread and I've come to collect my trophy, haha.

<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.

Absolutely, it will be a regular tag just like all the others.

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?

[Mayibongwe]

In fact, users are now prohibited from creating custom tags labelled <composers>, because it's now a native read-only tag.
In the update, I'm not sure how MusicBee addressed installations like yours that already had <composers> setup as a custom tag.

[hiccup]

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?

Regrettably, no.

For me it is a regression, since as you pointed out in your other post, I already had a custom tag named 'Composers'.
That one was fully writable and independent from 'Composer'.
I need that for reasons I explained a couple of posts earlier.

Now that v3.6 has a read-only 'Composers' tag, I can no longer use my custom 'Composers' tag.

I really wish that for a future update we can have both 'Album Artists' and 'Composers' as fully functional, independent tags.
 

[Mayibongwe]

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).
But for now, I'm positive we don't have a "fully functional and independent" <composers> tag because it would necessitate a change in <artist> and <artists>,
and those two have always worked that way since forever and their behaviour cannot be changed this many years later.

<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.

[hiccup]

<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:
https://getmusicbee.com/forum/index.php?topic=29851.msg166102#msg166102

I am not sure why Steven has added 'Composers' for v3.6 in the read-only way that he did.
If it was as a fulfillment for my requests for such a tag, it's not what I requested/suggested.

And, I don't agree that 'Composers' and 'Album Artists' should (or could) function identical to the long existing 'Artists' tag.
'Artists' is a very different beast, in that it can also display performers etc., and not only multivalue tags from strictly 'Artist' alone.

[Mayibongwe]

let's continue here for now: https://getmusicbee.com/forum/index.php?topic=40598
There seems to be a misunderstanding (on my part, or yours) on how these multivalue tags are supposed to work.

[hiccup]

@Mayibongwe:

For my classical MusicBee installation I am still using v3.5.
(and I will until v3.6 is officially released)

So I don't really have experienced this new Composers tag yet.
In case you are currently diving into the matter more deeply, could you explain what the benefit of this read-only implementation  of  Composers is exactly?
E.g. can it do anything that a simple virtual tag can not do?

[Mayibongwe]

could you explain what the benefit of this read-only implementation  of  Composers is exactly?
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)
Without <composers>, there'd be no way to access Wolfgang Amadeus Mozart on the below, since it would spit out the display composer instead:

Which circles back to your original question I suppose - "why is <composer> mapping to <display composer> and not composer itself?"
I haven't had an answer to that other than "that is how the neighbouring artist tags work. If the composer tags had to stray away from that behaviour, the artist tags might need to be changed as well for uniformity's sake - something which would be highly unlikely."

[hiccup]

Yes, with it, one's able to access the actual <composer> values (like <artists> which accesses the actual <artist> values)
Without <composers>, there'd be no way to access Wolfgang Amadeus Mozart on the below, since it would spit out the display composer instead:

Thanks for this Mayibongwe.

But I don't understand. (could be me and a drink on a Saturday night)
How do you mean, "there'd be no way to access Wolfgang Amadeus Mozart on the below".
He is the composer, and he is in the Composer tag?

Display composer is indeed a story by itself. (and currently discussed elsewhere if I am not mistaken)

I did a very brief test loading one of my classical tracks in a v3.6 test install to test this new Composers tag, and what I feared seem to be true:
While the track contains several Composers tags (three of them), the v3.6 beta Composers tag only displays what is in the Composer tag. Not what is in the actual Composers tag.

This is bad.

[Steven]

I did add Composers as a tag in v3.6, so if its causing a problem i can remove it

[hiccup]

I did add Composers as a tag in v3.6, so if its causing a problem i can remove it

The current implementation surely causes problems for me.
I would much rather have it changed to be a regular Composers tag.
Fully independent of the Composer tag.

But this is of course only my personal opinion.
Perhaps other users (that are actually using this feature and not just theorising about it) have something else to say about it.

[Mayibongwe]

But I don't understand. How do you mean, "there'd be no way to access Wolfgang Amadeus Mozart on the below".
He is the composer, and he is in the Composer tag?

Right. He is the composer, and he is in the Composer tag.
However, what led you to create this topic to begin with is the answer to the above quote.
The field <Composer> in MusicBee is actually <Display Composer> behind the scenes.

By default, a 'display tag' will be set to whatever value is contained in the actual tag.
The moment you change that display tag, you lose access to the actual tag's value.

On your screenshot: imagine that <Display Composer> was set to "hiccup's tag".
Without <composers>, you wouldn't be able to access Wolfgang, as <composer> would only return "hiccup's tag".

I did add Composers as a tag in v3.6, so if its causing a problem i can remove it

We'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 myself do not make use of the composer tags as much, I'm merely sharing my observations - no strong opinions.