Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Album List enhancements in 0.9 beta 11 (Read 23401 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Album List enhancements in 0.9 beta 11

In foobar2000 0.8.3, the album list had the ability to have multiple entries for a single track. In the first 0.9 betas this feature was removed. With beta 11 it returns, although in a more powerful form and with a different syntax.

The major reason why the old version of the multiple-entries-per-track feature was removed was that it required that the formatting string be split at the pipe character "|" before evaluating it. In 0.9, the formatting string is evaluated first and split later, so the old solution no longer worked. Beta 11 offers a new solution that integrates better with the titleformatting syntax, and lifts some restrictions from the old solution.

Through a special field syntax or dedicated functions you can insert a list of all values of a field into the final string. This list will be decoded at the splitting stage. The list uses an encoding scheme similar to color codes. Like color codes (which don't work in album list, mind you) this limits the number of functions you can use on the output of these fields/functions without breaking the encoding, which would mess up the generated album list tree.

The exact encoding of the value list is an implementation detail and may change in future versions.

Now for the new fields and functions, collectively called branching expressions:

%<name>%
This generates a new tree branch for every non-empty value of the tag called name. If the tag does not exist, %<name>% evaluates to "?" (without the quotes). If at least one non-empty value exists, the boolean value of %<name>% is true, otherwise it is false.

This uses the normal remapping of metadata field names. It is not possible to access technical info or special fields with this syntax. (They don't have multiple values anyway.)

If only empty values exist, the track will be excluded from the generated album list tree.

Example:
Code: [Select]
// genre is not remapped
$if2(%<genre>%,Unknown genre)|
// tracknumber is remapped, but no extra processing is applied (padding with zeroes)
%<tracknumber>%|
// artist is remapped and uses the values of the first actual tag, not all values of all tags artist can be remapped to
%<artist>%

In TagScript syntax you can use field("<name>"), or see below for an alternative.

$meta_branch_remap(name)
This is identical to %<name>% except it does not produce a "?", if the tag does not exist.

$meta_branch(name)
Like $meta_branch_remap(name), but without the tag remapping.


If you use multiple branching expressions in a single album list view, the number of entries produced by each will be multiplied. If, for example, you use "%<genre>%|%<artist>%" and a track has two genres and three artists, this track will get six entries, one for each genre-artist combination. (By the way, you would not have to put a "|" between %<genre>% and %<artist>%, you can use multiple branching expression on the same level of the album list hierarchy.)

Beware that gratuitous use of branching expressions can noticably prolong the time needed to generate the album list tree. There should be no significant performance loss, if you have mostly single-value tags.

Album List enhancements in 0.9 beta 11

Reply #1 –
Which functions will be able to deal with this new feature?
I mean, I can see "$if" will but, what about the other string checking functions ($strstr etc)?

Album List enhancements in 0.9 beta 11

Reply #2 –
Sorry, I forgot to mention this. I'll refer to the grouping of functions as it is used in the Titleformat Reference on the wiki.

All control flow functions are safe.

All arithmetic functions are useless, since the value of a branching expression is generally not an integer.

Boolean functions can be used as normal, though traditional functions - especially $meta_test()  may offer better performance than branching expressions. That is unless you specifically want to test for the "at least one non-empty value" condition.

The color functions are useless in album list, as it does not support color codes.

The value of a branching expression can be stored in variables and retrieved without loss.

String functions are more complicated, so the rest of this post is dedicated to them.

As a rule of thumb, every function that replaces characters or sequences of characters should be safe, i.e. $lower(), $upper(), $caps(), $caps2(), and $ansi(). Even replace is safe, as long as you keep away from the range of non-printable ASCII characters; linefeed, carriage return, and tab are safe though.

Path manipulation functions like $directory(), $filename(), and $ext() are not safe.

Any string manipulation function that removes a part of a string or inserts a substring  by position is generally unsafe. This includes $left(), $right(), $cut(), $pad(), etc.

$abbr() is not safe.

String comparison and measuring functions - with the exception of $strstr() - are generally useless. $strstr() can be used to test for the occurrence of a substring in the the returned value list, but you won't know in which value the occurrence is located.

If you are unsure about a particular function, just try it out or ask here. I'll compile this information into a wiki article soon.

Album List enhancements in 0.9 beta 11

Reply #3 –
Thanks for your answer.

---------------------------


Now that we have this feature back, somebody should really do something to fix that famous inconsistence between the behaviour of properties dialog whether you have a single or multiple selection.

I'm asking that because, when you have a single selection, if you add a value to a multi values field, the newly added one will invariably be put at the end of the existent list of values. If you want to show that in a particular position among all the values you have to remove all those that will have to follow the new one and then re-add them. With a multiple selection, thanks to the "\" separator working, you can just insert the new value wherever you like in the "values string".
All this is needed to get a custom sort when showing the whole %tag%.
For me it's of everyday use because I have a lot of jazz tracks where I want to show all the performers and all the instruments of the track and, everytime I discover a not perfectly tagged track I have to do as mentioned.
I know I can write the string with "\" also in single selection and then separate the values with masstagger but, all the same, I have to write the whole string as the dialog presents me the values as separated fields and not as a single string.

Sorry for this almost out of subject but I feel it's related to %<tag>%.

Thanks again.

Album List enhancements in 0.9 beta 11

Reply #4 –
Quote
Sorry for this almost out of subject but I feel it's related to %<tag>%.[a href="index.php?act=findpost&pid=342772"][{POST_SNAPBACK}][/a]

I disagree on the "almost" and on the "related". As I already said somewhere else, I do agree that a unified properties dialog would be nice to have, but there already is a place for discussing this feature request for the properties dialog, and this place is not here.

Album List enhancements in 0.9 beta 11

Reply #5 –
Amen

Album List enhancements in 0.9 beta 11

Reply #6 –
The information about branching expression is now available in the Wiki.

Discussion about this feature should still happen in this thread (instead of on the wiki).

Album List enhancements in 0.9 beta 11

Reply #7 –
Why was the custom sort option removed from the album list? I found that to be an essential feature, and was even hoping that it would be expanded in 0.9 to allow a different custom sort for each view.

Is there some other way to produce a view that looks like this without a sort option?

- Artist
---- My First Album (2000)
---- Another Album (2002)

Where the albums are sorted by date, but date appears at the end of the string?

Album List enhancements in 0.9 beta 11

Reply #8 –
The new %<artist>% tag is great for multiples entries,
The best view i have found is %<artist>%|$if2(%album%,-No Album-)[ - %artist%]
that give:
- A_artist
--- Album1 - A_artist
--- Album2 - B_artist, A_artist
- B_Artist
--- Album2 - B_artist, A_artist
--- Album3 - B_artist

But my dream order is something like:
- A
--- A_Artist
----- Album1
----- Album2 with B_Artist
- B
--- B_Artist
----- Album3
----- Album2 with A_Artist

Is it possible to do?
(It's a call to all talented coders here  )

Album List enhancements in 0.9 beta 11

Reply #9 –
I didn't know exactly where to post it, but clicking on Help in the Album list  settings points to this page:
http://wiki.hydrogenaudio.org/index.php?ti...C4-0F0B89566E6E
instead of thispage:
http://wiki.hydrogenaudio.org/index.php?ti...25.3Cname.3E.25

Is it normal? Because the second page is more interesting than the first one


And by the way for functions, when you say that it is not safe, it means that the result may be weird or that we really should not use the corresponding functions?

Album List enhancements in 0.9 beta 11

Reply #10 –
Quote from: Bachi-Bouzouk on
Is it normal? Because the second page is more interesting than the first one
That depends on what you are looking for. The first page is still a stub. It is by design that the help button does not take you directly to the second one, though I added a link to it on the other page.

Quote from: Bachi-Bouzouk on
And by the way for functions, when you say that it is not safe, it means that the result may be weird or that we really should not use the corresponding functions?
You should not use those functions, because the result will most definitely be weird. It shouldn't be possible to cause crash or anything though; if you would manage to do that, you would have found a bug.