So I have SongKong configured to prepend the album name with the composer(s) when it is missing making it clearer what the album is. But I dont prepend the GROUP field with the composer field so when you play a GROUP the display does not show the composer.
I wasnt clear if you could use tagCustom or tagValue so that the composer is always appended to the GROUP name or not, if not I may modify SongKong accordingly.
Secondly I have similar problem browsing by work, its not so much a problem because if you know the composer you want you can browse by composer first and then will be presented with works for that composer. But if you go straight to work it would be clearer if could see composer as part of the title. Is it possible to create a browse index by append indexing value i.e browse by composer:work (if we have both values)
(24-05-2017 11:57)paultaylor Wrote: [ -> ]So I have SongKong configured to prepend the album name with the composer(s) when it is missing making it clearer what the album is. But I dont prepend the GROUP field with the composer field so when you play a GROUP the display does not show the composer.
I wasnt clear if you could use tagCustom or tagValue so that the composer is always appended to the GROUP name or not, if not I may modify SongKong accordingly.
To do this, add the following setting to the tagFormat property:
Group.displayFormat={$composer^^: $group}
Quote:Secondly I have similar problem browsing by work, its not so much a problem because if you know the composer you want you can browse by composer first and then will be presented with works for that composer. But if you go straight to work it would be clearer if could see composer as part of the title. Is it possible to create a browse index by append indexing value i.e browse by composer:work (if we have both values)
You could add this to tagFormat:
ComposerWork.indexFormat={$composer^^: $work}
This does what you want if both the Composer and Work tags are populated but it is likely to produce unwanted index entries if one or other of these tags is not populated.
(25-05-2017 07:57)simoncn Wrote: [ -> ]To do this, add the following setting to the tagFormat property:
Group.displayFormat={$composer^^: $group}
Great that works perfectly.
With that in mind now that I understand what the Artist.displayFormat={$artist$orchestra$conductor} default value does I should simply remove this for songs fixed by SongKong, since SongKong already adds orchestra and conductor to the artist field and can therefore end up with duplicate values displayed
(
Alternatively I could change to
Artist.displayFormat={$performer_name$orchestra$conductor}
but this would only be correct for Classical music)
(25-05-2017 07:57)simoncn Wrote: [ -> ]You could add this to tagFormat:
ComposerWork.indexFormat={$composer^^: $work}
This does what you want if both the Composer and Work tags are populated but it is likely to produce unwanted index entries if one or other of these tags is not populated.
I changed this to Work.indexFormat={$composer^^: $work} since it didnt recognise ComposerWork but it doesn't seem to work as expected, in that it always displays either 'Composer:' or 'Work' but it
never displays both, even though we usually have both ?
(25-05-2017 09:30)paultaylor Wrote: [ -> ]I changed this to Work.indexFormat={$composer^^: $work} since it didnt recognise ComposerWork but it doesn't seem to work as expected, in that it always displays either 'Composer:' or 'Work' but it never displays both, even though we usually have both ?
This is because you have used the tag name Work instead of ComposerWork. If you change Work to ComposerWork and add ComposerWork to indexTags, it should do what you expect.
The difference is that the ComposerWork tag doesn't have any values in your files but the Work tag does.
(25-05-2017 19:03)simoncn Wrote: [ -> ]The difference is that the ComposerWork tag doesn't have any values in your files but the Work tag does.
Ah, so ComposerWork is a pseudo tag built from other tags ,I have it working as follows:
indexTags:Composer, ComposerWork:Work
itemTags:Work
tagFormat:ComposerWork.indexFormat={$composer^^: $work}
But like you say it doesn't work as required when only have one of the values, and for Pop/Rock I often have a composer but not a work so in these cases I wouldn't want a value in ComposerWork.
Is this concept documented anywhere or it just a hack I could not find anything about it in the userguide. I don't know if there other issues for this 'pseudo tag' but it seems to be it would be much more useful if it only added values when each part had a value, any chance of it working this way ?
There are no hacks in MinimServer.
The indexFormat option is described in
this section and
this section. It uses the same "format string" specification and implementation as displayFormat and this is why it creates a menu entry if some but not all tags in the format string are populated.
I would like to provide extra flexibility in the future to handle the case of some tags not being populated. I think it would be necessary to enable the user to say which tags must be present in order to create an index entry and which tags are optional. In the case of composer:work, you would want both tags to be present. This would require changes to how the indexFormat setting is specified by the user as well as internal changes to the design and implementation. It will be a little while before I am able to start work on this because of upcoming travel plans.
(26-05-2017 12:24)simoncn Wrote: [ -> ]There are no hacks in MinimServer.
Thought probably not after posting, but I was looking under indexTags section and I could not find this concept of pseudotag explained. I see there is a section under index Tag Formatting for WorkByTitle.indexFormat but I'm still struggling a bit with the concept though. Since displayFormat works with real field (i.e artist) I assumed indexFormat also worked with a real field, I cant work out if it makes sense to use it with both real and pseudo fields or only pseudo fields ?
(26-05-2017 12:24)simoncn Wrote: [ -> ]I would like to provide extra flexibility in the future to handle the case of some tags not being populated. I think it would be necessary to enable the user to say which tags must be present in order to create an index entry and which tags are optional. In the case of composer:work, you would want both tags to be present. This would require changes to how the indexFormat setting is specified by the user as well as internal changes to the design and implementation. It will be a little while before I am able to start work on this because of upcoming travel plans.
Sounds good.
(26-05-2017 14:16)paultaylor Wrote: [ -> ]Thought probably not after posting, but I was looking under indexTags section and I could not find this concept of pseudotag explained. I see there is a section under index Tag Formatting for WorkByTitle.indexFormat but I'm still struggling a bit with the concept though. Since displayFormat works with real field (i.e artist) I assumed indexFormat also worked with a real field, I cant work out if it makes sense to use it with both real and pseudo fields or only pseudo fields ?
What do you mean by 'pseudo tag' and 'pseudo field'?
I mean that composerwork is not based on an actual composerwork field stored in the files themselves instead it is constructed from two actual metadata fields work and composer
(26-05-2017 21:27)paultaylor Wrote: [ -> ]I mean that composerwork is not based on an actual composerwork field stored in the files themselves instead it is constructed from two actual metadata fields work and composer
For indexFormat processing, there is no distinction between a real tag (which could be either present or absent in each file) and a pseudo-tag (never present in any file). If the indexFormat tag value exists in a file, it is not changed. If the indexFormat tag value doesn't exist and the indexFormat format string returns a non-empty value, the tag value is created. Each file is processed individually using these rules.