Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[InflatableMouse]

I have a collumn grouping artists 0-9, A-B, C-D, etc. As the library is expanding I've come to a point where even single letters still result in a large number sometimes.

Is it possible to create dynamic groups with an expression, based on the number of results it would give?

Thanks in advance!

[MrC]

I'm thinking in the Set rules for file display, you could use an expression w/global vars to evaluate and count the groupings you want, and then use those counts to produce a hierarchy of n levels.  For a panes view, this would mean a column could be expanded tree-fashion to N levels (see attached).  In a categories view, this would define the number of drill-downs.

I just posted this code to another user yesterday I think:

listbuild(1, \,
   If(Regex([Artist], /#^([A-Za-z])#/),    [R1], 0-9 etc.),
   If(Regex([Artist], /#^(.[A-Za-z])#/),   [R1], 0-9 etc.),
   If(Regex([Artist], /#^(..[A-Za-z])#/),  [R1], 0-9 etc.))&datatype=[list]

Instead of hard-coding the 3 levels, you'd test against the number of items counted in the Set rules for file display stage, and add levels at different thresholds (up to a certain hard-coded maximum number).

[InflatableMouse]

I'll play with that in the weekend, thanks!

[MrC]

Let us know how it turns out.  Before spending any time, try the expression above, as it will do essentially what you want now (without considering item count).

[InflatableMouse]

Hm I don't like the hierarchy with the levels.

I've been playing around.

Code: [Select]

listbuild(1, \,
   If(Regex([Artist], /#^([A-Za-z][A-Za-z])#/),  [R1], 0-9 etc.))&datatype=[list]

Makes a list like
Aa...
Ab...
Ac..
etc.

So that's a step in the right direction but it gets way too long with only a handful of Artists for each. What I would really like to see is
Aa-Ad
Ae-Ah
Ai-Al
Am-Ap
Aq-At
Au-Az <- 6, or its u-x and y-z
Ba-Bd
Be-Bh
etc...

But I don't think that can be done with that regex alone. I've been using this site as a reference. I've been trying to match the first letter to a group of 4 sequential letters with pipes or nested regexes ... that doesn't seem to work.

Any ideas?

[MrC]

I think we can do this.  I'm headed out for a bit - and will respond later if the problem isn't already solved.

[MrC]

How do you want diacritics handled?

How do you want digits handed?

I assume punctuation should be ignored.

One problem I see is that certain names will be common, and thus certain lists will be long.

[InflatableMouse]

How do you want diacritics handled?

Diacritics, is that just accented latin characters or also non-latin characters? Either way I didn't think about that. I have no idea. I have some accented characters but nothing exotic like greek, hebrew or arabic. Sorting should not change, I like it how its sorted by default.

How do you want digits handed?

0-9 and special characters before letters in one group.

I assume punctuation should be ignored.

Yes.

One problem I see is that certain names will be common, and thus certain lists will be long.

True, that's why I initially suggested it to be based on count. I still think that's a better idea. Do you think thats possible?

[MrC]

Diacritics are, to us Yanks, those funny characters.

I agree, creating groups that are equally sized would be the way to go.  But, I've run into a snag...

In order to group artists into a set of buckets, we have to sort and assign a numeric ID to each artist.  The assigning of an ID is easy.  But I can't have MC sort by artist first and then assign the ID (because the ~sort modifier in search rules occurs after the rules themselves).  So the assigned ID is in a random artist order, and that won't allow alphabetic grouping into buckets of size N.  Now if only you were happy with randomly placed artists with numeric headings. :-)

[InflatableMouse]

That's a shame but don't worry about it. I'll figure out some other way to make it easier to browse.

Maybe those hierarchy of levels is a good alternative after all 

Thanks for looking into it though!

[MrC]

Give this one a shot - it's not perfect, but to cover more edge cases, it starts to get ugly:

if(regex([Artist], /#([^[:punct:]\s])[[:punct:]\s]*?([^[:punct:]\s])#/),
   ifelse(
      isrange([R2], a-d),  [R1]a-[R1]d,
      isrange([R2], e-h),  [R1]e-[R1]h,
      isrange([R2], i-l),     [R1]i-[R1]l,
      isrange([R2], m-p), [R1]m-[R1]p,
      isrange([R2], q-t),   [R1]q-[R1]t,
      isrange([R2], u-z),   [R1]u-[R1]z,
      1, [R1]*
   ),
  *
)\replace([Artist], ;, /,)&datatype=[list]

It should be clear how the ranges are defined.

[InflatableMouse]

Ooh I'll play around with that!

I almost missed this post I came back to the thread to read up again and found your post  .

Thanks bud!

[InflatableMouse]

There is a little problem with this way of working.

When my focus in on the pane with the expression and I type the first letter I want to jump to, it takes ages to load. The mouse cursor changes to a running circle and clicking in MC gives the program unresponsive popup. After a while it releases with the cursor jumped to its new position.

I'm not sure if this is a bug or something in the expression?

[MrC]

I'm not sure what MC has to do when you type-select a pane that contains a hierarchical list.  It certainly has to calculate the expanded portion, but it might have to calculate much more than that.

I see the same thing - its not a bug with the expression, rather perhaps there are some optimizations that could improve this (perhaps both in the expression, and in MC).

@Matt - care to take a look?  use the expression three posts up and try to type-select to reach certain entries.

[vagskal]

For me type-select in a pane takes much longer if what I type begins with "a" than any other letter.

[Matt]

Tree building is lazy, and works a level at a time.

Normally this is good, because we quickly build the top-level list and you normally only expand a few items.

However, typed-navigation searches collapsed items by design.  This requires building all the levels in the tree as it searches, which is slow when the tree is built from a complex regex expression.

It's possible it would be better to not do lazy building for a case like this, although it's a bit of a complicated architecture shift.

A new expression function that's faster than Regex(...) is another possibility.

[MrC]

I don't think its worth trying to optimize for the crazy expression, since it doesn't solve the real goal anyway.  And I'm not sure the solution is at the expression level anyway.

The real goal would be for MC to be able to produce groupings of N lower-level items, and show the bracketing letters that result.  The current grouping creates letter or number spans, and doesn't take into account items within that span. 

For example, if I wanted 20 artists per group, MC might return as many unique initial characters as necessary (or some minimum length):

2 Unlim - Alanis
    > 2 Unlimited...18 more artists...Alanis Morissette
Alberto - Ashley
    > Alberto Iglesias.... 18 more artists...Ashley MacIsaac
...
Wes Mon - Ziggy
    > Wes Montgomery... <=18 more artists...Ziggy Marley

So the question is, can the view's Group Size be modified to also allow a different form of grouping such as a specified number of items?  This would be immensely helpful on devices where navigating long lists is dreadful (DLNA).