MobileSheets Forums

Full Version: chordpro - setlist specific transposing
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
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
(11-27-2016, 08:23 AM)rs68 Wrote: [ -> ]Is this helpful also for others ?

+1
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.
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?
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.
(11-28-2016, 04:19 AM)GraemeJ Wrote: [ -> ]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. Big Grin

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. :-)
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.
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.
+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?
(11-29-2016, 08:31 AM)BRX Wrote: [ -> ]+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).
Pages: 1 2