Print

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

[locust]

For my audio, currently in my view pane,  generally I switch between and use all list styles bar Tiles..

I have a search list that contains many different custom sorting options such as

Date Imported [A/Z] & Date imported [Z/A]

It works fine, only on the Album Thumbnail list style though..

My request is to either change the Modify Results option of Sort By, to have the ability to sort by the grouping as well.. Or if you do not wish to alter that part of MC, add another option that will.

There are only one of issue this could throw up that I can see atm (If you can think of more please feel free to post them)

Taking into account my, custom grouping field when not considering the expressions within essentially generates the following format

[Album Artist] | [Year] | [Album] [Album Rating]     [Publisher] | [Sub Publisher] | [Catalog #]

An issue would be because I use custom grouping (Maybe the same would happen for stock grouping, I'm unsure), if I were to make a search list that was listed Style [A/Z].. It could have the potential to explode the size of the list generated exponentially..Because of the grouping for every style there would be an entry for every artist and then album if they has songs  corresponding to that style. (Probably would crash mc).. So I think that some thought would have to go into which fields "stock" fields would be allowed to have their grouping sorted in this manner.

Anyway I would like the ability for the sorting features of a search list to span all list styles but understand there could be a few hic-ups getting there..

Anyone else think this is an ok idea?

Thank you

[rick.ca]

Grouping is independent of, and takes precedence over, sorting modifications—whether set in Rules for file display or in a Search list. It's difficult to imagine it being otherwise. If grouping is specified, all files with the same group value will be grouped, and the groups will be sorted as specified (i.e., ascending or descending)—not according to any other rules. Those other rules will apply only to the sorting of files within the groups.

It works fine, only on the Album Thumbnail list style though.

It "works" in this case because there is no grouping. And it probably only works to the extent one value can be determined for an album for the sort criteria specified in the search list. Unless the value is the same for all tracks (like [Style] might be), or can be averaged (like [Year]), the value will be "[Varies]" which is of no use to sorting.

It could have the potential to explode the size of the list generated exponentially.

Because grouping is independent of sorting, there's no chance of this sort of outcome. If what you're looking for has anything to do with how files are grouped, you're necessarily restricted to defining the group in the manner that will produce the desired results. If, for example, you have albums with tracks of varying [Style] and want different styles in different groups, then include [Style] in your grouping string. The result will vary depending on whether it's placed at the beginning, middle or end.

This, of course, will not give you the dynamic group/sort change you seem to be looking for. That is, the automatic changing of view grouping and sorting settings triggered by a Search list selection. I doubt we'll ever see such a thing. If it's important, consider making duplicate views with alternate grouping and sorting settings, rather that attempt to do the same thing with search lists.

[locust]

If it's important, consider making duplicate views with alternate grouping and sorting settings, rather that attempt to do the same thing with search lists.

Thanks for the reply

I think I will do that.

If push came to shove I think there may be another simpler idea that could get the same results. I don't know if it stands any chance, but I might as well get the idea out there.

As you said I should make different view that uses a different grouping.

Say I have two custom fields,

my normal one
[Album Artist] | [Year] | [Album] [Album Rating]     [Publisher] | [Sub Publisher] | [Catalog #]

and one that is defined by date
[Date Imported] | [Album Artist] | [Year] | [Album] [Album Rating]     [Publisher] | [Sub Publisher] | [Catalog #]

I think I mentioned this in another thread but for different reasons I recall..

If when making a new search list item, if there could be an option to call upon More (Sort Groups [A/Z]) & More (Sort Groups [Z\A]) (like in what is circled in red in the image below)

We could then have a couple of search list entries that uses More (Sort Groups [A/Z] & Sort Groups [Z/A]) with the grouping that has the [Date Modified] field first.

The only thing is that mc would have to remember to switch back to the default (or original user specified) grouping when "All" is selected in the pane.

As you said grouping doesn't modify results so this option would require a place in the edit search box by itself as it couldn't go under the modify results section to avoid ambiguity. (But I think would be worth the extra space)

I am unsure as to whether this would change anything that is fundamental to the design of mc.

What do you think Rick? would this be a more realistic solution than my previous post?

I think it could prove quite useful for anyone who uses search lists. (Ah I think I just got it the clue is in the name. Search list? I can be quite stupid at times.. To search a list it must all already be made and to change the grouping would re-generate the list, not search it.. So this would change how the original and fundamental way search lists were designed For one I don't think they could be called search lists any more.. Maybe Search List & Grouping or something

Anyway I'm going to still post this it may stand a chance.

If it were to go though there would be one last inkling to deal with..

To set the option to change the grouping you could either make custom fields that contain the custom grouping and call upon them in the search list box.. Or you could allow people just to type in the custom grouping there & then.. Or both maybe..

Thanks for your time

[rick.ca]

What do you think Rick? would this be a more realistic solution than my previous post?

I don't see any difference between this and what I assumed you were talking about before...

That is, the automatic changing of view grouping and sorting settings triggered by a Search list selection. I doubt we'll ever see such a thing.

[locust]

  Duh lol, my head isn't screwed on right tonight.. I thought it in a different way and included some extra points I hadn't thought of before and forgot my original post...

I mean I think those extra, more detailed points I made, make a better argument for this to happen than the original post...

I know it changes a fundamental of search list but is that change really that big?

Wouldn't you like to be able to sift through your collection in that way without needing the extra view?

I will live with having the extra view but I think it would be nice not to need it to view the collection in different ways..

[rick.ca]

Wouldn't you like to be able to sift through your collection in that way without needing the extra view?

Perhaps. But you and/or I appreciating such a feature or behaviour is not sufficient reason to add it to the program. Regardless of much effort is required to make the change, it's not worth doing unless it's clear it will be useful to a significant number of users. I doubt a significant number of users would even understand the purpose of this. But even if there were, the benefits to them would have to be weighed against the negatives to others. Many new users are already overwhelmed by the complexity of the program, struggle with the very concept of a library with views, and are frustrated having to learn how to do what they believe should be straightforward things like setting how a view is grouped and sorted. Anything that makes that even more complicated (even if just by the existence of an option that isn't needed or relevant in most situations) needs to be well justified.

[locust]

Very true...

I suppose the challenge for me, is to think of as many reasons why this would be good whilst trying to refine the possible implementation of how it would be done to ensure minimal impact on the user base...

I suppose one addition that could help the majority or users appreciate this (If they use search lists) is just switching between the existing stock groupings.

Many new users are already overwhelmed by the complexity

I was definitely one of those people at the beginning and still am regarding regex.. When I first started using it I thought it would be better if mc had at least three different modes.. Beginner, Intermediate & expert. (Just like some of the system maintainable software you get)

The only difference would be the range of options available to each class.. (Whilst that would be beneficial for people starting out and unlocking new more options when they feel they can handle them, it would probably make it more difficult for people to answer question on the forum

Anyway thanks for your replies Rick