[DTownSMR]

Note: I had originally asked about this under message "song filter when building a set".

Short story is - I could really use song filters to persist across invocations of MSP.

Last update in the previous thread was that it was partially implemented (from library screen to group editor screen) but the persistent part was still on the todo list so I'm just wondered again where it stands.

I added this thread because it turned out to be a feature request not a question and having it here made more sense (and hopefully I can find it easier now to check on it's progress.    )

[itsme]

I see these issues with setlists, the setlist editor and filters:
1.) Filters should persist within the setlist editor.
When I open the setlist editor and set a filter, the filter is applied only to the right column (the list of songs from where I select songs to add to the list, not to the left column, the setlist itself. This is great and really helpful to limit the number of songs to choose from.
But: when I close the setlist editor to see the created setlist and reopen the setlist editor, the filter settings are lost and have to be set again from scratch.
2.) Filters should not be applied to opened setlists
A setlist is a setlist, nothing should disappear from it when a filter is set. It should show all songs that were added to the setlist, exactly what is shown in  the left column in the setlist editor. I'm aware that I request an exception here: I expect setlists to be different to other groups.

[Zubersoft]

I'm not sure I like the idea of not applying filters when viewing a setlist's songs on the library screen. That is inconsistent with all the other tabs and would probably be very confusing to people. I can certainly see times where users might want to find just one song inside a large setlist and either load that one song or jump to that song.

As far as persisting the filters when editing setlists, that brings up a couple of issues that I would need feedback on:

1) The screen that is used for editing setlists is basically the same screen that is used for editing any group of songs. Would the filters be persisted for all group types or just setlists?
2) Should the filters be maintained and persisted separately for every group type? Furthermore, if you set filters for one setlist and then edit a different setlist, should those same filters be applied? Or do I have to persist filters per setlist as well, as that would significantly drive up the amount of data I have to store. Or do I just reset the filters if a different setlist is edited?

In this case, I'm just talking about persisting them across screens in the app. Are you also wanting these persisted between loads of the application? With all of the different supported filters, I'm probably going to need to add a new database table to store everything.

[DTownSMR]

Perhaps I'm not aware of all that filters can do but I didn't know filters would (or even could) remove songs from setlists?!? Or maybe I'm missing something.

Here's my use case:

I use collections to separate songs for different bands I play in. I use a value in a custom field to flag chordPro files. 95% I just want to look at songs from 1 collection & a custom field value of chordPro. I don't want to have to {re-}fill out the filter every time I create a new setlist with those two values. It's tedious.  

I'm not sure of any other use case so perhaps other folks can chime in on how they're using filters.

[DTownSMR]

As far as persisting the filters when editing setlists, that brings up a couple of issues that I would need feedback on:

1) The screen that is used for editing setlists is basically the same screen that is used for editing any group of songs. Would the filters be persisted for all group types or just setlists?
2) Should the filters be maintained and persisted separately for every group type? Furthermore, if you set filters for one setlist and then edit a different setlist, should those same filters be applied? Or do I have to persist filters per setlist as well, as that would significantly drive up the amount of data I have to store.  Or do I just reset the filters if a different setlist is edited?

In this case, I'm just talking about persisting them across screens in the app. Are you also wanting these persisted between loads of the application? With all of the different supported filters, I'm probably going to need to add a new database table to store everything.

As I stated, I only have one use case and that would lead me to answer that the filter is:

• a single object
  
• persisted everywhere the same
  
• no different per group type
  
• not tied to a setlist
  
• persisted across loads of the application
  

It would be nice for folks that use filters to chime in with their use cases. I think that would help a lot.

Some of what you're asking could be supported with the notion of named filters. The name could be a setlist or a group type and could auto-magically be applied upon name match. If no match found, use one named "default" or some such. If no one chimes in other use cases it might still be beneficial to add the name support to make future feature requests trivial.

[DTownSMR]

2.) Filters should not be applied to opened setlists
A setlist is a setlist, nothing should disappear from it when a filter is set. It should show all songs that were added to the setlist, exactly what is shown in  the left column in the setlist editor. I'm aware that I request an exception here: I expect setlists to be different to other groups.

I did play around a bit with the open setlist issue. And at least as far as the way I use setlists, I would agree that an open setlist shouldn't have filters applied. Filters should come into play only when editing the setlist to simplify the songs to choose from.

In my case where my setlists are based on different bands, opening a setlist from any other band than the one currently in the filter would show a partial or empty setlist. That would be odd. Moreover, I think it would lead to confusion since the filter would hide song(s) in the list of songs but when you actually load the setlist they would still be there.

Good catch itsme!

[Zubersoft]

Well, that's fine, but how should I go about making it obvious that you can't filter the songs in a setlist then? Because I could see it being just as confusing for someone to change the filters while viewing a setlist and have nothing happen. Should I disable or hide the entire filters bar in this scenario?

[itsme]

Not showing the filters bar in a setlist is one really good solution.
Another possibility that would be consistent for all tabs would be to have separate filter settings for each of the library tabs, different for Songs, Collections, Setlists and so on. The same filter bar UI of course, just persisting the filter bar settings independently.
The group editor should have its own. One set of filter settings (not caring about the group it is editing) seems enough for me, but it is essential to allow the group editor having different filters than the corresponding group.
For me it would be a helpful use case to apply a well-thought set of filters on "Songs", a different one on "Collections" and none on all other library tabs. Just as an example.
Keeping them when MSP is restarted would be convenient, but not essential.
Storing filter settings per setlist seems too much (for me)  and not required at all.

[Ben]

I also don't ever filter setlists, therefore vote for exempting them from active filters that were applied e.g. in the Songs tab.
An open Setlist or even the Setlist Tab doesn't need to show the filters in my opinion.

[DTownSMR]

Should I disable or hide the entire filters bar in this scenario?

I'd vote for having the filters bar hidden.

[BRX]

Hide as default.