[rs68]

Hello,

I like the feature to make either song-specific or setlist specific comments.
Something similar would be in my opinion also helpful for setting the transposing of chorpro files. 
e.g. in one setlist the song is tranposed from key "A" to "C", and in another from "A" to "F".

It could be also achieved by storing different versions of the file, but to have always same base would be a more conveninet solution.

Is this helpful also for others ?

thanks.

rs68

[DTownSMR]

Is this helpful also for others ?

+1

[itsme]

In case I need a ChordPro song in 2 keys I just make a copy in MSP. This creates a second song (= database entry) in MSP that refers to THE SAME ChordPro file with independent meta data. I transpose the songs as required and set the "Keys" field in the song editor accordingly. Then I can add the songs to collections and setlists as usual.
Edits in the ChordPro file (fixing typos, adding/removing chords, changing line breaks etc.) show up in all versions, edits of meta data in MSP song editor have to be done independently per song.

[GraemeJ]

It's so easy to transpose in Chordpro, I fail to see the point? I'm not a regular user of this format, so maybe I'm missing something?

[itsme]

It's easy to transpose, yes. MSP helps to remember the key(s). I have a collection for every band / line-up I play with. So it's helpful to have a song in one key in my "Frankenbaend" collection and in a different key in my "Moonlight Crisis" collection. When creating a setlist for a gig I choose the songs from these collections and the songs appear just how I need them.

[DTownSMR]

It's so easy to transpose in Chordpro, I fail to see the point?  I'm not a regular user of this format, so maybe I'm missing something?

The point, or should I phrase it as need, is that I routinely have sets based on different personnel for different dates that have the same song in different sets with keys associated with them. So I build the sets but that chordpro song that is in both gets the key of the last built set. I manually have to remember to switch the key between the various practices/sessions with each group...an error prone task and one that has bitten me on more than one occasion. Easy to change yes, not so easy to remember what needs to be changed when.

I suppose I could go with itsme's idea of different db entries but that's one of the benefits I saw in using the chordpro format. I wanted to get away from the 2-4 different db entries per song. I'll have to chew on that a bit more I guess. :-)

[sciurius]

As itsme wrote, making copies has several advantages. You can change the key per setlist, but also other annotations like how the song should be performed etc. Changes to the ChordPro file contents still end up in all copies.
But I guess your 'problem' is a bit more subtile, given the phrase "I wanted to get away from the 2-4 different db entries per song."
Yes, making copies will imply that you'll get more than one db entry. And you must not forget to make a copy first before starting to adapt the metadata.
So, what I think would be the most elegant and user-friendly (but probably hard to implement!) approach is a sort of copy-on-write: When you try to change metadata or annotations, MSPro will ask "This song is used in different setlists, do you want to keep your changes local to this setlist?".
As a consequence, when removing a song from a setlist, all local changes will be lost.
And this not only applies to setlists, but also to collections, albums, and so on.

[itsme]

This brings up another issue: cleaning up the library. If I delete a song from the library it disappears from all collections, setlists and so on. So old setlists that I want to keep for documentation reasons become incomplete.
If there was a warning like "this song is part of ... " before it is deleted I could cancel deleting to export the setlist befor or save it anyhow.

[BRX]

+1 for the warning when removing songs from the library.

I think going with multiple copies of the song is the way. There's no space wasted since the same source file is used. Also - when we get the filters additions when Mike gets to them - one will be able to filter out unnecessary duplicates from view in the library, which I'll use heavily, I think.

As for key changes in the different setlists, wouldn't a setlist specific note like “change key to A“ a sufficient workaround if you still don't like multiple song copies?

[GraemeJ]

+1 for the warning when removing songs from the library.

........wouldn't a setlist specific note like “change key to A“ a sufficient workaround if you still don't like multiple song copies?

I've always thought the whole point of having the library was to maintain a record of every chart you have used, or likely to use.  Setlists are where you would normally display the chart for actual performance.  Charts themselves take up little space, so why delete anything from the library?

As for the transpose thing, I think the use of a note to denote a key change (or whatever) is a far better solution to this problem than asking Mike to write even more code (that might cause a problem elsewhere).

[sciurius]

As for key changes in the different setlists, wouldn't a setlist specific note like “change key to A“ a sufficient workaround if you still don't like multiple song copies?

It's a partial solution.

So I have my song, in the key of G. It is part of setlist X. I add it to another setlist with note "Change key to A".
On the set, I read the note and change the key to A.
Later, on another gig, I play setlist X and the song is still in the key of A...
Yes, I should have changed the key back (to what? G doesn't neccessarily have to be the default key) after playing it but I assure you that will be forgotten.

Making copies is currently the best option, I think.

[BRX]

Yeah, obviously you have to make a change key note in every setlist you use a song with no constant key. As OP mentioned his problem was remembering the needed change.

But I agree with you that it is more practicable to use copies.

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

[itsme]

In my understanding a song in a new key is a new arrangement and belongs to a copy of the song (the song, not necessarily the file).
The new key belongs to a band / line-up, for which I use collections. I use setlists specifically for a gig. For the repertoire of a band I use a collection. With the same band we usually play a song in the same key, at many gigs matching many setlists. So why should I store the key many times with the setlists?
It fits perfectly for my needs how MSP implements that, no workaround at all.

[DTownSMR]

It fits perfectly for my needs how MSP implements that, no workaround at all.

Different strokes...I'm glad that for you, how it works...umm...works. In my use case it really doesn't and the proposed "solutions" in this thread are work arounds to a fundamental problem that I realize isn't a problem for everyone but it still is for me. Hence why I was pretty specific in my last post...
     "but in the end they are really just workarounds to a specific problem...at least in my use of MSP"

AFAIK, making a copy of the song just for the key change would have me back at the same problem I was running into with PDF's that led me down the chordPro path. Song bloat in my song list and different overlays per key requiring duplication of effort (not to mention being error prone) keeping things up-to-date. Yes, I get it that different overlays is PERFECT for some and is exactly what they need...but again, not in my use case. I need the same annotation overlay in every key and they must be kept in sync. Perhaps there are features I'm unaware of.

As for my suggestion of adding song keys to setlist meta data, I don't see where your use case would be impacted by adding support of key changes to songs in a setlist. You wouldn't have to put the key in for each setlist it would simply use the song metadata key (re: default) for the song as you already set as desired. So you could still do things as you do today (i.e. key changes to a song on the songs tab would be kept as song metadata). But if the a user sets the key in the setlist (re: from within a setlist) the setlist metadata could simply override the song metadata. Seems pretty straightforward to me and gives folks options for different work flows.