[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!

[reggoboy]

Reflecting on the broader subject of adding metadata to Setlists, I had a gig last night and I thought of another setlist metadata entity that would be helpful: Venue. 

Here's why: we want to reuse our catalog as much as possible, but we also want to bring variety when we come to venues we've already played at, especially if we played the same tunes there recently. And some of us play in multiple different bands, maybe at the same venues, so that needs to be sorted out.

Setlists already have Date metadata. If they could also have Band and Venue metadata, and all three supported filter/sort, then we could quickly get a list, sorted by date, of all the songs that band played at that venue. (Would be super cool if it could eliminate duplicate songs, but that's asking a lot :-) ) Then we could quickly see which songs haven't been played there in a while, and prioritize those.

And while we're at it ;-) since there might be several venues in the same town, and so you really want to avoid playing the same songs even at various venues in the same town, it would be handy if the filter was a multi-select: if I'm playing in town X, I will select ALL the venues in or near that town when I'm looking for a playlist history.

Sounds useful, eh??

Thanks!

[reggoboy]

I'm going to upvote my previous suggestion for Band and Venue attributes on Setlists. I've played with this a bunch more, and with multiple bands playing multiple overlapping venues, this really seems like a powerful library management feature for this essential use-case!

[Zubersoft]

That would require significant changes, as I've never supported metadata for setlists or other group types. So there'd have to be a new way to manage that metadata (either an entirely new editing screen or dialog, or options in the overflow menu once a setlist is selected), I'd have to modify the shared code for the filtering to support filtering on those fields (which will really only work once I move filters to a collapsible side panel so that there's room), and then I have to make all the database changes to support the new fields. So it's certainly something I can do, but it's going to take a lot of work, so it would help if more users indicated they would get value out of this.

Mike

[itsme]

Reggoboy's request is IMHO too specific to justify such huge changes.
BUT: it would absolutely make sense to implement meta data for groups. They should be flexibly usable for users' individual needs, similar to custom and custom2, additionally with configurable names.
I can organise my workflow for many gigs with various line-ups without problems. Reggoboy could use the meta data of setlists to store whatever he thinks to need.
My personal use cases for meta data for groups would be:
I use albums for fakebooks. If albums had meta data I would configure them to store e.g. author, publisher, year, ISBN ...
European copyright depends on the year of death of all authors. If composers had meta data I would use them to store the date of death and a different display name and sort name.

[RobNY]

Just the other day I was thinking about how there is no metadata for setlists.  For me, being able to assign a "collection" would be helpful as I use collection as a way to split my library among my different projects.  I could then assign scores and setlists to a collection called "Band A".   

Venue, as an attribute for setlists, is also an interesting idea.

Along these lines, I wasn't sure what the filter box even did when looking at the setlist tab. (I think it filters all setlists that contain scores that belong to the selected collection).   However, i think it would be more intuitive to have different filters for Setlists -- as Setlists are less an attribute and more of an aggregation (unlike Artist, Type, Key, etc).

[Geoff Bacon]

@RobNY
I've never used the collection field for filtering setlists, I just use the "All Fields" and the desired text. It does seem to do something but I don't know exactly what.

If you name your setlists along the lines of "group venue yyyy-mm-dd" e.g. "U3A St Peter's 2025-02-27", you can use the alphabetic letter to easily find all old lists for this group and/or venue (assuming sorted by Ascending Date)

When creating a new setlist, put one or more spaces at the start of the name e.g.  " U3A St Peter's 2025-02-27". This will put pu the entry at the top of the page (the "#" category) so easily visible.
After the gig, three vertical dots (top right), Rename without the leading space(s) to make it sort to the correct place.

Geoff

[RobNY]

@RobNY
I've never used the collection field for filtering setlists, I just use the "All Fields" and the desired text. It does seem to do something but I don't know exactly what.

If you name your setlists along the lines of "group venue yyyy-mm-dd" e.g. "U3A St Peter's 2025-02-27", you can use the alphabetic letter to easily find all old lists for this group and/or venue (assuming sorted by Ascending Date)

When creating a new setlist, put one or more spaces at the start of the name e.g.  " U3A St Peter's 2025-02-27". This will put pu the entry at the top of the page (the "#" category) so easily visible.
After the gig, three vertical dots (top right), Rename without the leading space(s) to make it sort to the correct place.

Geoff

Yes, that's sort of how I'm doing it now.  But to address the original "archive" question I think that giving setlists their own version of a "collection" (or some tagging feature independent of the songs) could solve all these issues.  It would allow you to group/filter setlists by Band, Venue, and also have the ability to create 'archived setlist collections'.