More > JRiver Media Center 27 for Windows

Change a View to sort on Composer Surname

(1/4) > >>

AndrewFG:
All my tracks are tagged with full composer names (like Wolfgang Amadeus Mozart or Ludwig van Beethoven) and until now I have let my Composer View sort simply alphabetically on the full string. But I would like to change it to sort on Surname.

What is the easiest approach to do this? I think as a general rule the sort on Surname would be a sort on the last name in the string. But I am sure there will be many exceptions to that. Ideally I don’t want to retag a lot of files. So I am looking for advice about moving to a simple, reversible, sort algorithm, that can handle the general rule, and also the exceptions too.

Any thoughts?

DJLegba:
Looking through my collection, your "last word" sort would handle almost everything. I did edit all the composer tags to the format "Bach, Johann Sebastian (1685-1750)" because it works in every view, and Musici Music Tagger made it easy, but it does mean I have to edit the composer field every time I import a new album. I still haven't figured out a good way to enter composer collaborations.

dtc:
You can create a new field and store the sort name in that. You then sort on that field. There is a SWAP function that will switch the first and last name, but there are situations where that does not work, like The Beatles or Emerson, Lake and Palmer. So, you sometimes need to be able to override the swap function. That is usually done with 2 fields, one which does the swap and one that you can fill in by hand. So, something like Artist Sort and Artist Sort Manual. In the library field definition, use Calculated Data  with an expression that if the manual field is populated, [Artist Sort] is set to that, otherwise it uses swap.  Then just use [Artist Sort] in your sort. With that logic, most of the Artist Sort values are filled in automatically, and you just have to manually add values the anomalies.

Artist Sort calculated data  - If(isempty([Artist Sort Manual], swap([Artist],[Artist Sort Manua])

For composer, just change Artist to Composer.

See Expressions if the Wiki if you need help with the expressions.

wer:
Within the limits of the expression language, I'm not sure this can be done completely programmatically if you are strict about surnames and what you consider them to be.

dtc's example of Emerson, Lake and Palmer is good.  But do you consider Ludwig's surname to be Beethoven, or von Beethoven.  And when you have decided Beethoven, then you have to think about a name like "de Sermisy".

You may also have tracks where the composer is listed as "John Lennon and Paul McCartney" or various permutations of that.

I think what I would do is programmatically populate a new field with an expression just taking the last element of the name, and then overwrite that with the correct value for all the cases I didn't like.  Simple, but if you have thousands of artists, unappealing.

It would certainly be possible to construct a complicated IF statement that handled all the le, de, von etc prefixes, but even that would not work for Emerson Lake and Palmer, or Bachman Turner Overdrive.

I think you could make such a calculated field work IF you added a third field, which indicated if the name was a band or not. If band, use full field name, if not band, use computed surname.  Follow?

glynor:
This is definitely possible to do now, and I've discussed strategies for doing so a few times (though mine are often centered around Artist, Actors, and other similar auto-filled fields).

If you already have the field filled in Firstname Lastname format, you can build a sort-field you can use in various places with one simple "checkbox" Field and an expression. There are issues with it, if you want to be able to tag or view them in name-swapped order, but if you only want to sort-by the swapped order (and continue to view and edit everything in "normal order") then you're fine to use this.

Make an Override Field
First thing you need is a simple boolean field you can set to allow you to override your normal sort-behavior (for edge case names that don't get "swapped" properly). So, you can name it as you see fit, of course, but you want basically this:
Field Name: Composer Sort Override
Field Type: User data
Data Type: Integer
Relational: Store one value for each composer
Edit Type: Check
Acceptable Values: 0;1
Save in File Tags (when possible): Up to you, I'd do on so you don't have to re-do it for re-imports, but 🤷‍♂️.
Show a Link Checkbox: Off

Make a Field to Use for Sorting
Now, make a second new field. This one is going to be a Calculated Data type Field:
Field Name: Composer (Sort)
Field Type: Calculated Field
Edit Type: Cannot Be Edited
Show a link checkbox: Probably not.
Expression:

--- Code: ---If([Composer Sort Override],[Composer],Swap([Composer]))
--- End code ---

Then, you use [Composer (Sort)] to sort anywhere you'd have previously sorted the Composer field. You continue to display the Composer field everywhere in your views (you never look at the [Composer (Sort)] field columns or anything, except when testing), but you sort your stuff using it. You can sort the Categories too. Simply save a Sorting Preset with your [Composer (Sort)] field, and then any time you add [Composer] as a field, sort it by this preset instead of "Ascending" or "Descending".

The built-in Swap() and Unswap() function does know about some name suffixes (like Jr. and III) and it might even handle common prefixes like "von" as mentioned by wer above. Or, I suppose you could include them as articles in the articles list and attack it that way. If you have a lot of edge cases for which Swap() doesn't work of a particular type, you can just special case them with IfCase() or additional nested If() statements in the [Composer (Sort)] expression to "fix" those particular cases.

However, the [Composer Sort Override] checkbox is your release valve. If you check that box, it "overrides" the normal expression behavior and passes through the original text of the [Composer] field. The nice thing is, since you can make [Composer Sort Override] a relational field on [Composer] then you only need to check one instance of the particular composer's name to override. So, if you have any particular composer for whom the Swap() behavior doesn't work, tag the [Composer] field on just those files however needed to get them to sort correctly, and then check the box. You only have to check the box once, on one file, and then any file with that [Composer] value will be treated properly automatically (even future files).

Alternative Composer Sort Override Method
That's the simplest mode. If you don't like that you have to see those "specially tagged" files in the [Composer] field with possibly ugly-looking text (which won't "match" the rest of the data stored in [Composer]) for those Overriden composers, then you change the [Composer Sort Override] from a boolean field to a string field:
Field Name: Composer Sort Override
Field Type: User data
Data Type: String
Relational: Store one value for each composer
Edit Type: Standard
Acceptable Values: <empty>
Save in File Tags (when possible): Up to you, I'd do on so you don't have to re-do it for re-imports, but 🤷‍♂️.
Show a Link Checkbox: Up to you.

That's effectively what dtc suggested above. Then, you use it just like the checkbox version above, but instead, you type in what you'd like to override it with in this field (instead of just checking a checkbox). Then you just tweak the expression in [Composer (Sort)] to do If(IsEmpty([Composer Sort Override]) instead. That way, you don't have to look at the "ugly". The only downside is that you give up the simplicity of checking a box to pass-through names which are "already right" in [Composer] as they are now. I'd think that might be the more common failure case for Swap(), single-named people and whatnot, but you'd have to see how it worked out in your Library, and how willing you'd be to fix other special cases in the Expression. There's also the further downside that you have to remember to change the text in two places if you change a [Composer] value in the future (in the real field, and then in the corresponding [Composer Sort Override] field for at least one of those files afterwards). The Checkbox method doesn't have that downfall.

And, if you're perhaps a bit too clever, you could do it with three fields and combine both approaches. But that's likely more trouble than it is worth in ease-of-use and setup effort.

All of that should work just fine. The only issue is if you want to use that [Composer (Sort)] field as a Category and Column in your Views directly (so they look like they should sort in the order they do). That is difficult or impossible currently if you want to use those Columns or Categories to tag files, effectively replacing the "underlying" [Composer] tag. You can't do that, which is why I asked for the Writable Calculated Fields feature, but none of the versions of that idea we came up with in the other thread have been implemented.

So, for now, if you do it, you're stuck viewing [Composer] as it is, but if that is okay with you, you can sort it however you'd like.

Navigation

[0] Message Index

[#] Next page