An Option for the rules to get the first letter of the Artist to seperate the Artist in ABC.. folder
An Option for the rules to get the first letter of the Artist to seperate the Artists in a ABC.. folder structure.
Wesley
shared this idea
This is now released. The variable syntax is:
Which would mean group start characters of album_artist where the groups are three characters long (e.g. ABC). You can vary that length and you can have any variable in place of album_artist.
I’m not working on the ‘dummy’ or wildcards yet.
-
Yeah - nice ideas. I need to think more about how the 'discovery' of a pattern fits into the current scan/fix cycle.
I want to avoid conditional expressions. Where possible, I want to aim for declarative configuration/syntax.
-
kraymer commented
My 1st level of folders is : ABC, DEF ... YZ, Compilations
I see 3 options to handle complicated hierarchies :
- manual : rely on a heavy syntax handling conditional branchment (eg. /(if albumArtist=='various')'Compilations' else artist@1) and let the user enter the good pattern
- semi-automatic (better) : keep the syntax minimal (more or less as it is now in bliss) and add wildcards symbol to indicate to bliss that it must match a token to ID3 tag content
- fully automatic : once you've coded the logic to resolve wildcards, why keep the user in the loop? Just ask user to provide bliss the root folder where his classification is applied, and by browsing the files, bliss figures a pattern. If number of files is not sufficient and bliss can't find a pattern, fallback on semi-automatic input. -
Sorry. What I mean is that say the <dummy> was implemented and you specify:
<dummy>/<artist>/...
And your structure is:
A/Abba/...
B/Bryan Ferry/...And so on, 'A' and 'B' will match <dummy> and be re-used when deciding the correct file path. Let's say in the above example you wanted to enforce underscores instead of spaces. The first file path will be compliant. The second, however, is uncompliant and will suggest:
B/Bryan_Ferry
... instead.
The important bit is that the <dummy> matches anything and then gets re-used. You could look on it as a 'wildcard'. This way, the <dummy> can be used whenever there is a path segment that cannot be 'handled' by bliss.
Really this is a separate feature, but will help with future requirements.
I hope I understand.
-
I understand now, you mean a variable that will allow anything for that segment, thus allowing someone with an existing structure like ABC/... ?
I was thinking about it the other way, i.e. how the dummy variable would be rendered as part of the file path. It should just retain whatever data exists.
-
Ok sounds like you are onto something - how would the dummy variable work exactly? How would it know whether to separate into singular folders (A, B, C) or multiple (ABC). How would it appear exactly?
-
Yeah, nice idea. Would it be one parent folder per letter e.g. A, B, C, or I wonder if people have folders that hold ABC, DEF... etc.