[jagny42]

It would be nice to be able include/exclude particular Collections and -keep-  that criteria so that after I close MS Pro and bring it back up again for another session, the criteria still remains. For instance,  I have a "Collection" of over 100 Christmas songs which I only want to see at Christmas time. I have a "Collection" of many Irish songs which I only want to see around St. Patrick's Day.   I really don't want to see these songs the rest of the year.  It would be nice to be able to "hide" these Collections.

[sciurius]

Maybe what you actually might want is a feature I've been asking for for a while now: separate (distinct) databases.
You can have a database for Irish songs, one for Christmas songs, etc. Songs will never get in the way unless you explicitly open the database they are in.

This will make it marginally harder to import a song from one 'collection' (database) into another, but since all my songs are organized in folders on the SD card it is trivially easy anyway.

[BRX]

We have several suggestions floating around with similar goals.

I suggested an option for permanent filters (carrying over sessions) and also (maybe alternatively) savable filters for recurring uses, maybe even a favourite filter list with a handful to pick from.

[itsme]

The existing filters already support a lot. 
An example in my case: "all relevant songs" could mean
- exclude songs that are not in any collection
- exclude christmas songs
- show only songs with a certain rating
I can achieve that following these steps:
- show filters
- Collection - Include - Select All
- deselect collection "XMas"
- include only rating 3-5
Goal reached, but needs a number of clicks.
Cumbersome: switch to "all songs" (or a different filter combination) and back 
This is where Brix' proposal would help: storing some filter combinations for later reuse would be very comfortable. I support this idea.

[sciurius]

The reason why I think separate databases have added value is that it also keeps the settings apart. For example, I have a collection of 'small' sheets (think simple folk tunes), that I want to view 2 pages side by side. Another collection has 'large' sheets (think Bach) that I want to view by half pages.

[AndyL]

The problem with separate databases is if you want songs that are in more than one. Around Christmas time I might want to add a few Christmas tunes to my set list, but still have stuff from my "normal" list. So I would favour some sort of "persistent" filter.

What about dynamic collections. A collection that is defined by a filter. Or maybe that is too confusing, so just another tab of "Named Filters".

Andy

[itsme]

As often there are good arguments for different solutions. I use collections for every band or session I play with. There are many songs that I need in several collections, so for me keeping all songs in one place is a good way to go. I use filters to show only a relevant part of my growing library to simplify selecting and reduce scrolling.

[itsme]

A collection that is defined by a filter or a tab of "Named Filters" is not the best way to implement persistent filters.
It should be possible to apply persistent filters in every scenario where today's filter settings can be applied.
One situation where I frequently miss persistent filters is during editing of a setlist: the right column with songs preselected by filters and a song is missing there because it is not yet added to e.g. the collection that it should be in.

I could imagine extensions like these of the existing filter bar:
- a selection element (window, list box, dropdown...) to choose one out of a list of named persistent filters
- the selected persistent filter settings should be restored into the filter settings on the filter bar to allow further refinement and should be applied to the current selection
- "save" and "save as" for the current filter settings as a persistent filter
Thus persistent filters could be used everywhere where the filter bar is available.
It's an open issue that the filter bar is already rather crowded. That could be solved by allowing to configure available filters or by the possibility to scroll horizontally, both similar to the handling of the tabs on the main library screen.

[Zubersoft]

In order to make the persistent filters fit on the bar, I think the cleanest way to implement them is as follows: Add two new icons to the left of the additional filters icon. The first icon brings up a dropdown of all of the existing filters with a check next to the currently selected filter. This allows you to quickly switch the active filter. The second icon is a save icon and provides a dropdown with two options - save and save as. This approach doesn't use much additional space on the filter bar (which already scrolls horizontally on smaller devices).

How does that sound?

[itsme]

Sounds great. As always: it's fantastic how you listen to your customers. Many many thanks.

[jagny42]

In order to make the persistent filters fit on the bar, I think the cleanest way to implement them is as follows:  Add two new icons to the left of the additional filters icon. The first icon brings up a dropdown of all of the existing filters with a check next to the currently selected filter. This allows you to quickly switch the active filter.  The second icon is a save icon and provides a dropdown with two options - save and save as.  This approach doesn't use much additional space on the filter bar (which already scrolls horizontally on smaller devices).

How does that sound?

Sounds good to me!  

[sciurius]

The reason why I think separate databases have added value is that it also keeps the settings apart.

Also, I have many setlists, some for Group (collection) A, some for B, and so on. I would want to keep them separate, too.

[BRX]

@Mike
Sounds exactly like what i wanted. Great. Can't wait. :-)

@sciurius
I imagine you can simply get the separation with the name of the group in the setlist and a persistent or favourite filter as well.

[sciurius]

I imagine you can simply get the separation with the name of the group in the setlist and a persistent or favourite filter as well.

Yes, although I would like to avoid the burden of adding the group name to each and every setlist.

Also, before a gig I want to transfer all songs for this group to my phone, just in case. The phone is not capable of holding the complete database with all songs. Note that just the setlist (.msf file) is not sufficient, since there may be last minute changes so I need all songs (for this group) on the phone.

I won't say that separate databases is a necessity, but it certain has a number of interesting benefits.

[BRX]

Johan, regarding separate/multiple databases I was thinking.

Are you "administrating" your MSP sheet folders on the SD card yourself or do you let MSP do it? Myself I'm doing the former. As I mentioned before I'm prefering my own directory structures and the easier "mini" backup by copying only the database files without the sheets.

I'm not sure if and how this would work with MSP organizing the folder structure. But isn't it quite easy to have separate databases with the other alternative simply by duplicating and renaming the (exposed) database files, edit them as needed and just rename the needed database files back if you need to switch to another database?

Probably with your programming skills you (or Mike in any case) could even write a simple APK to automate and do just that conveniently from Android so you don't have to use a file manager.