spacefish wrote:How you fathom that no one will need to adapt to your method is beyond me.
Sorry SF, clearly I was unclear
. What I mean is: going from the current MM production release to my proposal, no user who wants the existing (combined artists) interpretation needs adapt, because the new is compatible with previous data and usage (though not identical in the case of MP3 '/', so perhaps an Options checkbox is needed). No user who wants standard (i.e. /-separated) multi-artist interpretation has to adapt either. The user who wants custom multi-artist interpretation necessarily adapts - declares any custom separators (e.g. ", "," feat. ") and any artist exceptions (but just once per artist) e.g. "AC/DC".
Okay. So basically you're saying that this method will work for everyone but only folks who want multiple artists parsed in a logical and friendly manner (i.e. Queen & David Bowie, not Queen/David Bowie), will need to adapt. Please correct me if I'm wrong.
Still, I think that a majority of users will want to see their artists, as well as report them via plugins, etc., in a friendly way and not with a straight slash (the reason I've been pushing for parsing methods at the same time during this discussion). Is it worth the extra work (because there will be a lot more with your method than there is currently) to update exception tables and separator options manually? I don't think it is. I believe the program should do as much of the work as possible. Yes, some values for separators will need to be entered initially by the user but designed into the work flow of adding/editing properties, rather than a separate options table, makes it virtually invisible to the user.
I don't have that multi-artist separator defined? Add +
here next to the artist (tandem to the artist field in the properties window; available in a pull-down menu next time I need to use it as a multi-artist separator). Since this method only assigns one artist per artist field, I don't have to worry about the + in the next band's name. MM knows it's only one artist because it's in an artist field.
I don't have that multi-artist separator defined? Cancel out of properties, go to options, remember where I need to add this +
symbol, add it there, (do I need a separator between my separators?), click OK. Click properties again, edit track as usual. Next time I have an artist with + in their name though, I have to decide whether or not to add them to the exception table too otherwise the program will think it's a multi-artist separator.
Lot more steps in your method and I have to worry about the next artist that has in their name a symbol I might have added to the separator list. Too much thinking for me!
Tell me then, if I enter into the artist field
Jam & Spoon, Crosby, Stills, Nash & Young, Rod Stewart, Bryan Adams & Sting, Dan Turèll + Halfdan E
how will I get everyone except Rod Stewart, Bryan Adams & Sting into the exceptions list separately by pressing a hotkey?
Ah, multiple /new/ exceptions in a /single/ new artist property value. I get you - thanks. Well I suggest if the Devs thought it was worth it, make that hotkey (or menu/button command - let's call it Mark As Single Artist) let you enter:
Code: Select all
Jam & Spoon[MASA], Crosby, Stills, Nash & Young[MASA], Rod Stewart, Bryan Adams & Sting, [select>]Dan Turèll + Halfdan E[<select][MASA]
i.e. MASA enters onto the exception list the selected text if any, else the leftward text less any existing exceptions and terminal separators.
I think this would be really easy to use.
So type in first artist name, press hotkey, type in second artist, press hotkey, or... ? Or if there's a requirement to go back and select things afterwards and press hotkeys at each selection and go OOPS I selected too many letters now how do I fix it? there's going to be a lot of confusion. I'm not saying it couldn't work. I just think it's a cumbersome method and perhaps needs a more streamlined mechanic. Lots of steps needing to be retraced which could just as easily be avoided with a multi-field interface.