[DTownSMR]

All good stuff to chew on but in the end they are really just workarounds to a specific problem...at least in my use of MSP. Some of you sound like you have more of a static setlist setup. In my use case I'm changing setlists every week, sometimes doing multiple setlists in a week, and add to that sometimes setting up setlists for in the future. Keeping things straight is both error prone (i.e. when at rehearsal the song key is changed you potentially have to remember all the other setlists that song is in) and it's also a bunch more work since every time you practice/rehearse/play you have to keep changing the key. Yes, changing the key is "easy" but something that software should really handle IMHO.

I guess the bottom line for me, perhaps not for Mike's todo list   , is if I step back and not think in terms of "how can I get it done in MSP as it currently is coded" but rather in OOP terms of where does "X" really belong...Then I really can't seem to get away from the fact that IF the key of a song can be different in multiple setlists then the key for a song in a given setlist belongs in the "setlist" object not in the "song" object. It's a setlist attribute not a song attribute at that point.

My idea/suggestion would be that if you modify the key of a song in a set it adds that information to the setlist. That is assuming that it's readily apparent that it's in a set (since it can tell me what the next song is I'll assume that it is at least knowable if not downright simple). Perhaps if you change the key from the song tab it changes the song entry in the DB but honestly I don't know if that makes sense. Probably better to just throw that "change" away since it's not associated with anything. The chordPro file itself has a specified key I think the cleanest solution would be to with have to delete and re-add if you want to change the key of the db version.