Posts: 13,221
Threads: 299
Joined: Apr 2012
Reputation:
233
It's been mentioned in previous threads, but I cannot support setlists within setlists. It just breaks the architecture and requires a UI with infinite depth like a file system which is exactly the kind of thing I'm trying to avoid (because setlists can contain setlists that contain setlists and so on). I will support lists of setlists because that doesn't require massive design changes (although it still requires a new editor and a new tab with different behavior from the others). This should accomplish the same goal as long as you only need to group together setlists into one combined list.
Mike
Posts: 129
Threads: 44
Joined: Oct 2013
Reputation:
0
OK, i'm not deep enough into the app. Didn't see any difference between "setlist" and "list".
But good, that you will support it.
Posts: 1,043
Threads: 112
Joined: Dec 2015
Reputation:
11
Does it make difference (in terms of not having to change the architecture) if you only make nested list entries possible in the setlist tab? Only like a subcategory if you know what I mean? So it's just a way to display several subsetlists (or "blocks") under a "master entry" setlist for a gig without changing the rest?
Posts: 13,221
Threads: 299
Joined: Apr 2012
Reputation:
233
What you have both described is exactly the idea I'm proposing - I will have a tab that lets you group togther setlists under one "master entry" or "block" as BRX referred to it. This is what I mean when I say the tab will contain lists of setlists - each entry on the tab is a container for grouping setlists. So this doesn't break the architecture at all - it just requires a new tab, new editor, etc, and if you load one of these entries, it will basically create a temporarily setlist that is just the combination of all songs under all setlists under the entry.
Mike