[reggoboy]

Hi folks!

I make Setlists for rehearsals, and now they're cluttering up my list. I'd like to keep them, but get them out of the main setlist view, and reserve the main view for actual gigs. Who knows, maybe after I do enough gigs, I will even want to thin out the display of gigs.

How do you handle this? Is there a way to create Setlist Folders and hide things in there? Or is there some type of tag or metadata I can assign to Setlists which I can then use to filter? My impression is that all the filters apply to the SONGS that the setlist may contain, not to the setlist themselves.

Thoughts?

Thanks!

[Zubersoft]

Some users have certainly asked for the ability to archive setlists, so it's something I'm considering, but there will have to be an easy to view all the archived setlists to unarchive them if needed, so I haven't thought through all the details for how I want to implement all this. You are correct that most filters will act on the songs within the setlist, as the setlist itself doesn't have any metadata to filter on. You can search based on setlist title, but that's it.

Mike

[reggoboy]

Gotcha!

Yes there are several ways to skin this cat. Not sure which is best. You could have an archive flag. Or something more generic like setlist “labels”, and users could make one called archive or whatever they want. 

Worth mentioning that I already use emoji to try to keep setlists for different bands I’m in separate. So I would probably make a label for each band. Maybe I would have a rehearsal vs gig label. Maybe I would have a paid vs free gig label too. 

Either way, I’d probably want to sort flexibly, but usually chronologically. 

Just some thoughts.

[itsme]

I handle that by using a dedicated naming scheme: all my setlists are named <bandname abbreviation>_yyyy-mm-dd_location-or-event e.g. FB_2024-09-13_Altstadtfest and have my setlists sorted A-Z descending.
Current gigs are on top, older ones get out of sight. No need for archiving anything or implement any changes in MobileSheets.
Modify for your specific needs.
   

[Geoff Bacon]

I've posted similar to this several times but can't find the posts so that I could link them..
So apologies to those who have seen something like this before.

This is what I do:
The set list tab is sorted A-Z (ascending)
Each setlist name is formatted like this "Venue(or Group or Gig)" "yyyy-mm-dd" "anything else you want" e.g. "Pub 2025-01-26 Birthday"

This means that all historic set lists will have the same venue (group or whatever) co-located and that for each venue, the lists will be in ascending date order (most recent at the bottom). The letter keys can be used to jump to (near?) a required venue

For current gigs, use the same name format but add one (or more) space characters to the start of the name; these lists will show under the # section at the top of the screen and are easily visible and available for selection.

After playing the gig, long press the setlist and press the 3 vertical dots at the top of the screen.
Choose rename and remove the leading space(s). The list will then assume it's place at the bottom of that venue.
These list can then be used to check not repeating songs at a regular venue (sadly only by eye balling)

Job done.

The amount of effort involved in adopting this method depends on your current naming convention
If your names don't start with numbers then you could just adopt it for your future lists and gradually change the others to conform over time.

Hope this helps

Geoff

[reggoboy]

Thanks for the replies, folks.

Yes, I'm quite adept at encoding multiple pieces of metadata into setlist names, etc:

   

But it's all a workaround for not having a better way to do it. And I don't have to explain to you the limitations of this. Most of us already know about problems like this, which is why we chose MobileSheets in the first place :-) It has flexible library management features. 

For example; we don't "need" Collections, either. We could encode the genre and composer and book title into the "Song Name" of every song. But that makes for very limited filtering and sorting capabilities (and very clumsy looking song names). Much richer database experience to classify data entities into their own metadata categories. 

Anyway, I've mentioned some use cases above for consideration :-)

Thanks!