[Serafin]

Mike,

I'd like to make a suggestion for MobileSheets to track additional attributes/properties for setlists (for sets / gigs).

These can be represented as additional (configurable) fields to expose on the setlists tab view and can be used to filter what setlists are visible. Capabilities to export to a spreadsheet for additional slicing and reporting would be desirable as well.

Currently, some of us already use set names to implicitly track these properties (e.g., all my setlists include the date and occasion), but a more structured and expanded capability would be very powerful for gig tracking and management.

I imagine that you would have to track these attributes on a metadata record of some sort that is keyed to the setlist. There would need to be an additional setlist editor view (like the song editor fields tab) to edit these fields. It would be useful if these attributes (the metadata record) are copied when a setlist is copied.

Fields that come to mind:

• Date
  
• Time (bonus to have separate fields for call time, performance time/duration, billable time, etc.)
  
• Venue/Client
  
• Contact (venue contact, band director, etc. - phone and e-mail)
  
• Event link(s) (link to additional information, publicity, etc.)
  
• Occasion (church service, concert, bar gig, wedding, rehearsal, etc.)
  
• Group (different bands, choirs, ensembles that I am part of)
  
• Collaborators (list of other specific musicians)
  
• Pay, Tips, and Expenses
  
• Rating (how well did the set / gig go)
  
• Comments (free-form text field for other notes - attire to wear, instruments to bring, where to park, etc.)
  

Tags/keywords can be used for certain other attributes that might not naturally warrant a field. E.g., I might want a tag to "bookmark" a set for further review or to mark a cancelled event for future reference.

Serafin

[itsme]

That sounds very specific, triggered by your (very specific) personal requirements.
How about just adding a text file to your setlist to keep this info?

[Serafin]

That sounds very specific, triggered by your (very specific) personal requirements.
How about just adding a text file to your setlist to keep this info?

I appreciate your perspective. Perhaps it isn't a common use case in your environment, and we can argue about the common usefulness of some specific fields I suggested, but for working musicians who perform in multiple venues or with multiple groups, I believe that there is a good case to be made for being able to leverage the existing setlist database (the list of setlists) for more than just the list of songs performed or to be performed. It also seems natural to add other database functions to the database that MobileSheets is.

I (and others) will find it useful to run queries and create reports to...

• display set lists that apply to Band A only
  
• display set lists for say previous wedding banquets or wedding ceremonies (songs may come from multiple genres)
  
• report usage occurrences for songs were performed at XYZ church (for royalty reporting purposes)
  
• sort set lists for concerts according to rating (what set lists worked well in the past?)
  
• account for other gig (most setlists represent gigs or events) attributes - personnel, income, etc.
  

There's an existing category of software for managing gig data, but some (most) are overkill for individual musicians or small groups, and I believe that there's a case to be made for leveraging what already exists in MobileSheets.

I do like your idea of using a text file that is attached to the setlist to achieve some of these use cases, but this partial solution wouldn't facilitate queries and reports.

[Zubersoft]

I always appreciate feedback and suggestions for things that will add value to the software. Priorities are usually driven by what is requested the most often and will provide value to the greatest number of users. So it would certainly help to get a sense for the percentage of users that would utilize these features. I know I have certainly gotten various requests to track what songs are loaded, how long they were viewed, etc, so I'm going to be adding tables in the database to start tracking that information at some point. 

Mike

[Serafin]

I acted on the idea of keeping gig notes in a text file as suggested by itsme above but modified the concept slightly.

I recently stumbled upon the notes feature that already exists in MS. These notes however are attached to specific songs even in the case of setlist notes.

So, I created a cho file I named Set Notes that I can reuse like a song in multiple setlists. This song file itself doesn't contain any meaningful information. It allows me however to attach setlist notes that are specific to each setlist without having to drill down into the song editor to edit set/gig information.

It would be nice if setlists could have their own setlist notes that didn't require attachment to a song, but this workaround is ok for now, albeit not as powerful as database fields that can be queried/filtered/reported as described in my suggestion above.

[Zubersoft]

At some point I'm going to rework the notes dialog, and when I do that, I can look into adding a new database field to allow setlist notes to be added for the setlist itself. Those notes would be accessible only through the dialog though, as it would otherwise conflict with the other song notes.

Mike