Multiple Artists, ';' separator, etc. - discussion

[chrisjj]

I am just wondering where you draw a line between a group and a multi-artist.

In none of the proposed solutions does MM draw that line, so each user can draw it where he likes.

Fine, you shouldn't specify this artist as multi-artist and you will not get a 4 different nodes for this group. But what if someone wants such possibility? I think this should be configurable

FTR, I do not. I think this - alternative names - is way outside the scope of the current need to have acceptable multi-artist for a production release.

So, why I need to copy/paste this multi-artist name at all?

For all the situtations in which your recommended multi-track Properties doesn't work. These range from track groups with identifying propertes that are mixed hence unredable in Properties, to app-to-app.

I think that most natural and obvious way for all users is to enter and to see artists exactly as it is displayed on the cover of the album

For that, please stick to Album Art. Most of us need Artist text fields to work well because that's where we put the useful, regularised transcriptions of cover info.

[Teknojnky]

I am just wondering where you draw a line between a group and a multi-artist. Is your criteria for that a number of involved artists? How about "Ike & Tina Turner"? Is this a group or multi-artist? Should I enter "Ike Turner/Tina Turner" or "Ike Turner;Tina Turner" if I want to see their albums under "Tina Turner" node? How about one-man projects like "Adiemus" by Karl Jenkins, "Red Noise" by Bill Nelson or "Thinkman" by Ruper Hine? How about variations with personal names like "The Wailers" (first two albums) and "Bob Marley & The Wailers" (rest of them), or even some albums under a name "Bob Marley"? Should I see all those albums under 3 nodes or 1 node?

Ike & Tina Turner is a group.

Ike Turner
Tina Turner

are Artists, they should be separate. Anything else is a so-called 'bastardization' of the naming convention to suit a logistical/orginization preference.

I absolutely do not want my artist tree to show each of the 4 artists individually, except in specific cases where they performed as an individual (for example Neil Young).

Fine, you shouldn't specify this artist as multi-artist and you will not get a 4 different nodes for this group. But what if someone wants such possibility? I think this should be configurable - give to users a choice to choose how albums should be included to involved artists.

I can understand perfectly that someone may want to list them on 4 different nodes, however this goes again to the changing of the naming standards to suit a user preference.

My needs are simple.

A user-defined UI separator, user-defined exceptions, and supporting of the various standard fields defined to indicate accompanied or secondary artists.

Are you sure that your needs are so simple? User-defined separator, user-defined exceptions... You think this is simpler than one single-line field and one multi-row table? From which point of view is this simple - MM developers or us, users?

Simple from a logical view, not necessary a user or developer view.

I don't see any good reason to have one single-line field where I need to enter multi-artists with sepparators beside of the possibility for copy/paste. But speaking of that, I don't know why is this such a big problem. MM already has a possibility to mass-enter some values within "Edit Properties for Multiple Tracks". It is enough to select all songs from some multi-artist and to enter its involved artists into some new multi-row table for just one song - when you click on the OK button, the MM should enter the same multi-artist into all selected songs. So, why I need to copy/paste this multi-artist name at all?

I think that most natural and obvious way for all users is to enter and to see artists exactly as it is displayed on the cover of the album, without any artificial separator like "/" or ";". This is a reason why we need to have two editing possibilities: one single-line for display purpose and second multi-row table for specifying which artists are involved.

What it sounds like you and possibly others want is for MM to display a combined Artist + Contributing Artist, whilst having separate fields in the database.

I do not necessarily disagree.

I think the confusion is the individual preference of what constitutes a contributing artist vs the primary artist.

And the cases where individual artist names making up the GROUP name.

Example:
<artist> Ike & Tina Turner </artist> (a single entity)
<contributers> Ike Turner; Tina Turner </contributors> (multiple entity)

Now obviously that is 2 separate fields, how to display it tho?
Which separator should be used?
Should there be multiple lines instead of a seperator?

[spacefish]

For what it's worth, I think a(n artist) relationship table would be nice to have but has nothing to do with multiple artist handling. Jiri mentioned it as an aside earlier in the thread but I don't think it was meant to be a part of the final multiple artist handling design. I don't think it needs to be considered in the process but should be considered for a future enhancement. Let's get one thing done at a time. If jiri feels like he can work it in along side the multi-artist enhancement, more cookies for jiri!

[ZvezdanD]

Example:
<artist> Ike & Tina Turner </artist> (a single entity)
<contributers> Ike Turner; Tina Turner </contributors> (multiple entity)

Yeah, this is what I wish to see.

Now obviously that is 2 separate fields, how to display it tho?
Which separator should be used?
Should there be multiple lines instead of a seperator?

I already said about this - the single-line field for displayed artist name ("Ike & Tina Turner") and multi-row table instead of separators for contributors (one row "Ike Turner", second row "Tina Turner"). Same table could be used for multi-item artists. Call it as you want: contributing artists or multi-item artists, but we need a way to separate artists from each other.

We also should consider MoDementia suggestion:

I think there may need to be, or the possability to add later, further qualifcation of the separator list.
1. Displayed/Not real Artists "&", "feat.", "and" etc
2. Not displayed/Real Artist "Band Member"

[ZvezdanD]

For what it's worth, I think a(n artist) relationship table would be nice to have but has nothing to do with multiple artist handling.

Subject of this thread has "etc" in the title and I don't think this is off topic. In my opinion contributions/alternate names/relationships are equaly important as multi-item artists and closely related to them. Both of this require our decision if we want single-line edit field with separators or multi-row table without them.

[chrisjj]

In my opinion contributions/alternate names/relationships are equaly important as multi-item artists

MM already has multi-artist that needs fixing before production release, whereas alternative names etc. is simply a wishlist item.

[spacefish]

For what it's worth, I think a(n artist) relationship table would be nice to have but has nothing to do with multiple artist handling.

Subject of this thread has "etc" in the title and I don't think this is off topic. In my opinion contributions/alternate names/relationships are equaly important as multi-item artists and closely related to them. Both of this require our decision if we want single-line edit field with separators or multi-row table without them.

I agree it's important but it's not crucial to handling multiple artists. We don't NEED a relationship table to have an acceptable process. It would simply be nice to have. I wanted to avoid losing focus on the main issue in favor of arguing an etcetera. By all means discuss it but don't let it be the driving factor for the method you're suggesting. The two are mutually exclusive.

[ZvezdanD]

The two are mutually exclusive.

Maybe jiri said "could" instead of "must", but I think it is obvious that we need two tags per track for multi-artists - one tag for displaying purpose and second for parsing purpose. If you take a look again at his suggestion, you will see that contributions/alternate names are related to multi-item artist and could be treated in the same way (http://www.mediamonkey.com/forum/viewto ... 870#142870):

Artist (TPE1): Artist1 & Artist2 feat. Artist3
Inv.People(TIPL or other): Person1/Guitar/Person2/Bass/Artist1/Artist/Artist2/Artist/Artist3/Artist

Here is my variations on his example. First two are examples for multi-item artists:
Artist (TPE1): David Bowie & Queen
Inv.People(TIPL or other): David Bowie/Main Artist/Queen/Main Artist

Artist (TPE1): Freemasons feat. Siedah Garrett
Inv.People(TIPL or other): Freemasons/Main Artist/Siedah Garrett/Featuring Artist

Next example is for contributing artist:
Artist (TPE1): Ike & Tina Turner
Inv.People(TIPL or other): Ike Turner/Contributing Artist/Tina Turner/Contributing Artist

Last example is for alternate name:
Artist (TPE1): Bob Marley & The Wailers
Inv.People(TIPL or other): Bob Marley/Alternate Name/The Wailers/Alternate Name/Bob Marley & The Wailers/Alternate Name

As you can see, all of this examples require same approach. Why they couldn't solve all of this in one go?

[chrisjj]

I think it is obvious that we need two tags per track for multi-artists

We don't. Both my and MoDementia's proposal's meet the concensus requirements for multi-artist without requiring two tags.

- one tag for displaying purpose and second for parsing purpose

For regular display, search etc., the Artist tag is used directly. For multi-artist interpretations (Artist nodes, multi-field editing) the same tag is parsed w.r.t. the Options' separators and exceptions.

[ZvezdanD]

I think that jiri should start a poll if we want to enter/see multi-artists as David Bowie & Queen, Freemasons feat. Siedah Garrett, ... or like David Bowie;Queen, Freemasons;Siedah Garrett, ... (regardless of used separator). BTW, I know many users which don't like the second approach at all, but none of them which don't like the first.

[chrisjj]

I think that jiri should start a poll [asking] if we want

Eh, why? 'Cos we already know:

many users which don't like the second approach at all, but none of them which don't like the first.

The disliked second is the current (beta) behaviour, and the prefered first is covered by the two proposals under discussion.

[spacefish]

The two are mutually exclusive.

As you can see, all of this examples require same approach. Why they couldn't solve all of this in one go?

I'm not saying they can't. I'm just saying they don't need to. One does not require the other to work. At the risk of sounding like a broken record, if jiri wants to give us a relationship table, too, great.

[jiri]

Let me clarify my opinion on several things posted in this thread:

The disliked second is the current (beta) behaviour

By no means we consider the current functionality to not be ready for a release. It isn't perfect yet, that's why I started this thread and wanted to get suggestions for implementation in MM 3.1, but it's still working pretty well.

Artist (TPE1): Freemasons feat. Siedah Garrett
Inv.People(TIPL or other): Freemasons/Main Artist/Siedah Garrett/Featuring Artist

Zvezdan, yes, this is an interesting enhancement of what I previously wrote in this thread. I believe that this is the way to go and yes, I can confirm that I believe that two different fields are absolutely needed per tag. Since not everyone would possibly like it, the second should be configurable (i.e. writing of TIPL or such a field).

Jiri

[Teknojnky]

Involved people is already support, it is simply on the 'details' tab and not the main 'basic' tab.

Perhaps an option to visually combine fields is all that is needed (aside from having user defined separator/exclusions).

[MoDementia]

";"