If I was to support this feature, it wouldn't change the existing design of songs and setlists. It would just add the concept of a grouping of setlists, so you would first have to select the setlist group, then you could tap one of those setlists and it would show the list of songs inside it. I optionally could support combining all of the setlists into a temporary setlist for playback (this is the way "Load All" works for other group types like Artist/Album/etc). It would basically just be adding one more layer of heirarchy. This is very different than the concept of setlists containing other setlists, as that changes a setlist from just being a simple list of songs to something more complex with an undefined heirarchy depth (as setlists can contain other setlists which could contain setlists, etc). Having said that, this change still isn't an easy one because none of my existing code is set up for a group of groups. I would need a lot of new code for the library screen and a different editing screen (where setlists are shown on the right instead of songs). Based upon how much time I currently have for development, this change could easily take 3-4 weeks. So I'll have to put it as an enhancement for the future.
The idea of song groups that you've presented is very interesting BRX, but it would be a drastic design change. The level of effort for that would be many times greater. If I represented one of these song groups as being a song itself, but then changed every function so that it could look up files/pages from its child songs, then it would fit inside the current design for setlists and such. It also wouldn't be as problematic as setlists containing setlists as I would not allow song groups to contain other song groups - so I'm guaranteed only one more level of depth heirarchy wise. There would still have to be a huge number of UI changes though, and a lot of changes necessary to handle correct loading/processing of a song group.
Mike
The idea of song groups that you've presented is very interesting BRX, but it would be a drastic design change. The level of effort for that would be many times greater. If I represented one of these song groups as being a song itself, but then changed every function so that it could look up files/pages from its child songs, then it would fit inside the current design for setlists and such. It also wouldn't be as problematic as setlists containing setlists as I would not allow song groups to contain other song groups - so I'm guaranteed only one more level of depth heirarchy wise. There would still have to be a huge number of UI changes though, and a lot of changes necessary to handle correct loading/processing of a song group.
Mike