• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
ChordPro: Chord Localization
#1
I really appreciate the new "Chord Localization" feature. I always missed that. Is it already implemented? I only noticed the settings entry to configure it but it seems to have no effect at all.
first language: German
Acer A1-830, Android 4.4.2 - HP x2 210 G2 Detachable, Win 10 1803
www.moonlightcrisis.de - www.basdjo.de - www.frankenbaend.de


Reply
#2
It is implemented. I followed the OnSong settings for localization as described here: 
  • Default displays chords as capital letters from A through G with flat or sharp symbols as needed. Minor chords are denoted by a lowercase "m" to the right of the chord.
  • Čeština displays chords in a convention familiar with the Czech language. This displays "B" as "H" and "Bb" as "B". In addition, minor chords are denoted by lowercase "mi".
  • Deutsch displays chords in a convention familiar with German-speaking people. This displays "B" as "H" and "Bb" as "B".
  • Scandinavian displays chords in a convention familiar with Scandinavian-speaking people. This displays "B" as "H" and "Bb" as "Bb".
Is some of that not working for you, or were you expecting different behavior?

Mike
Reply
#3
What you describe is what I expect, but none of them work.
Is something wrong with my ChordPro file?


Attached Files Thumbnail(s)
   

.pro   Chords+Localization1.pro (Size: 271 bytes / Downloads: 2)
first language: German
Acer A1-830, Android 4.4.2 - HP x2 210 G2 Detachable, Win 10 1803
www.moonlightcrisis.de - www.basdjo.de - www.frankenbaend.de


Reply
#4
Looks like a mistake on my part. If you transpose, the localization is correctly handled, but if the song is in the original key, it does not modify the chords that are displayed. I'll get this fixed.

Thanks,
Mike
Reply
#5
I'm going to have to think about this one a bit, because if Bb is B, but you put Bb and B in the same file, what should be the correct handling? Should it treat Bb as B, but then the B that is already there is actually a Bb? So they become identical? The transformations can lead to odd results if you mix things like that.
Reply
#6
What would happen if the process was to transpose to another key then transpose back using the localization?
Dell Latitude 13.5" 2-in-1 Win 10, ver 19.--
Samsung Note Pro SM-P900 12.2 Android 5.0.2
Asus TF700T, os = CROMi-kk_R1 KitKat-4.4.4r2-CM11-US DEODEX, Based on Android 4.4.4
Nook HD+ OEM
Reply
#7
I'm following those rules listed above closely now. If I encounter something that doesn't match the rules, I transform it to that (i.e. if Bb is B and I encounter Bb, it's transformed to B, and if I encounter B, it's handled as a H). I think this is the expected behavior.

Mike
Reply
#8
I have a similar thread in the forum of the ChordPro reference implementation. Maybe you want to take a look:
https://groups.google.com/forum/#!topic/...rd7kq6CC7k

The reference implementation provides complete flexibility even for localization of the input file. I think this is not required.
I would be fully satisfied if I had to write the chords into the file in todays standard format (A Bb B C) and they are displayed in their localized form (A Bb H C).
first language: German
Acer A1-830, Android 4.4.2 - HP x2 210 G2 Detachable, Win 10 1803
www.moonlightcrisis.de - www.basdjo.de - www.frankenbaend.de


Reply
#9
(05-13-2019, 10:51 AM)Skip Wrote: What would happen if the process was to transpose to another key then transpose back using the localization?

Neither localization nor transposing should ever change the content of a ChordPro file. The question is always how a certain content of a file shall be displayed, so "transpose back" is not necessary to be discussed.
To display a transposed song the localization setting shall be respected.
If sharps or flats are used for transposing is a user decision. A setting for this already exists in the transpose dialog.
first language: German
Acer A1-830, Android 4.4.2 - HP x2 210 G2 Detachable, Win 10 1803
www.moonlightcrisis.de - www.basdjo.de - www.frankenbaend.de


Reply
#10
Here's my test file for (traditional) German and Scandinavian. Chords are in 'Common' notation, the lyrics line contains the expected localized result.


Attached Files
.pro   Chords+Localization2.pro (Size: 609 bytes / Downloads: 2)
first language: German
Acer A1-830, Android 4.4.2 - HP x2 210 G2 Detachable, Win 10 1803
www.moonlightcrisis.de - www.basdjo.de - www.frankenbaend.de


Reply
#11
Currently transposing and chord localization don't cooperate correctly.

In the attached example the chordpro file contains chords in D major, D G Bm A D. It is in default chord spelling, Bm means B natural.
Transposing to G major works fine in default and Scandinavian, Bm is transposed correctly to Em.
In Deutsch and in Cestina Bm is transposed to D#m which is wrong.
The reason is that Bm is interpreted as Bbm and thus transposed to D#m (in addition: the 'b' vs. '#' selection buttons are not respected).

This should not be the case! How chords are written within the file and how they are displayed have to be handled independently. Otherwise changing the localization would require changing ALL existing chordpro files!

Please take a look at my posts from 2019-05-14 in the ChordPro reference implementation thread linked above.
The reference implementation has two independent settings: "Notation" specifies how chords are written within the file, "Transcode to" specifies how the chords are displayed.
IMHO it is not essential to have that "Notation" setting also in MSP. Presuming that chords have to be typed in "Default" chord spelling would be fine for me.
But the setting of "Transcode to" (reference implementation) / "Chord Localization" (MSP) has to be only relevant for how chords are displayed (with or without transposing), it should not have any influence on how the chords from the file are interpreted.


Attached Files Thumbnail(s)
       

.pro   FieldsOfAthenry.pro (Size: 1.56 KB / Downloads: 1)
first language: German
Acer A1-830, Android 4.4.2 - HP x2 210 G2 Detachable, Win 10 1803
www.moonlightcrisis.de - www.basdjo.de - www.frankenbaend.de


Reply
#12
I'm not sure what the correct behavior is here. If I encounter a "B" in a file with localization set to Deutsch, for example, how do I know if that is an actual "B" or a "Bb"?  Do I trust the file to be right or adhere to the localization rules? What if the user does have a file where B is Bb - should they have to update all of their files and change "B" to "Bb" even though that doesn't match the localization setting? It seems like either way, someone will not have the behavior they want in certain scenarios.

I'd love to hear more feedback from people on this as I'm not entirely sure what people are expecting the behavior to be. Please also note that I have upcoming changes to the chord localization processing so the behavior of the current version probably shouldn't be the basis of the conversation. Instead, we need to discuss how it should behave in general.

Thanks,
Mike
Reply
#13
I had to deal with this extensively when I added chord localizations to ChordPro.

In ChordPro, there is a source notation (where the score is written in) and a target notation (how it must be shown). So if the source notation is German, B means H♭. By default, this is also the way it will be shown. If you would select to show common notation, you'll get B♭ instead of B.

ChordPro defaults to common notation, but MSPro could show by default using the notation system corresponding to the localization.

I think it would be a bad choice to default the source notation to the localization since many people download ChordPro files from the internet and these are almost always in common notation. So I propose to add this as a (new) metadata item, e.g.

   {meta: notation German}

Summarizing for MSPro:
  • Add a setting for the default source notation
  • Add a setting for the desired show notation
  • Allow {meta: notation xxx} to override the source notation

Does this sound an acceptable approach?
Johan
www.johanvromans.nlwww.hetgeluidvanseptember.nlwww.howsagoin.nl
Samsung Galaxy Note S4 (T830) 10.5", Android 9.0, AirTurn Duo & Digit.
Samsung Galaxy Note 2 (N8010) 10.1", Android 7.1.2 (LineageOS) (backup).
Samsung A3 (A320FL), Android 8.0 (emergency).
Reply
#14
@Mike:
> Please also note that I have upcoming changes to the chord localization processing so the behavior of the current version probably shouldn't be the basis of the conversation. 
> Instead, we need to discuss how it should behave in general.
That's why I bring this up as long as chord localization is still work in progress

> If I encounter a "B" in a file with localization set to Deutsch, for example, how do I know if that is an actual "B" or a "Bb"?  
You cannot "know" that, it is ambiguous. It needs a setting so that the user can specify it or you have to define a rule what is expected by MSP.
Re-using the "show" setting is the worst solution. That would require on ANY change of the localization setting that I need to search through ALL my chordpro files if they contain an affected chord. Otherwise transposing produces confusingly wrong results as in my "Fields Of Athenry" example.

It's really worth taking a look at Sciurius' reference implementation, he has implemented it already with (hopefully) all bells and whistles.
first language: German
Acer A1-830, Android 4.4.2 - HP x2 210 G2 Detachable, Win 10 1803
www.moonlightcrisis.de - www.basdjo.de - www.frankenbaend.de


Reply
#15
(05-23-2019, 07:58 PM)sciurius Wrote: I had to deal with this extensively when I added chord localizations to ChordPro.

In ChordPro, there is a source notation (where the score is written in) and a target notation (how it must be shown). So if the source notation is German, B means H♭. By default, this is also the way it will be shown. If you would select to show common notation, you'll get B♭ instead of B.

ChordPro defaults to common notation, but MSPro could show by default using the notation system corresponding to the localization.

I think it would be a bad choice to default the source notation to the localization since many people download ChordPro files from the internet and these are almost always in common notation. So I propose to add this as a (new) metadata item, e.g.

   {meta: notation German}

Summarizing for MSPro:
  • Add a setting for the default source notation
  • Add a setting for the desired show notation
  • Allow {meta: notation xxx} to override the source notation

Does this sound an acceptable approach?

That would be perfect
first language: German
Acer A1-830, Android 4.4.2 - HP x2 210 G2 Detachable, Win 10 1803
www.moonlightcrisis.de - www.basdjo.de - www.frankenbaend.de


Reply


Digg   Delicious   Reddit   Facebook   Twitter   StumbleUpon  


Users browsing this thread:
1 Guest(s)


  Theme © 2014 iAndrew  
Powered By MyBB, © 2002-2020 MyBB Group.