I've removed the single setting for chord localization, and now when you tap it a dialog is displayed with two options: "Default source localization" and "Default display localization". The settings work as you both described. I've updated the logic and the file now transposes as you would like. I also added support for {meta: notation [src] [display]} so that you can override one or both. Accepted values for those match what I support in the settings, which is:
Default
Čeština
Deutsch
Scandinavian
Hopefully that covers everything.
Thanks,
Mike
Great job!
May I kindly suggest to (also) accept the common namings:
- common and dutch (instead of default, which feels a wrong name -- my default is dutch, itsme's default is german);
- german (AFAIK this is more widely used than Deutsch)
It would also be nice to have "
latin" (Do, Re, Mi, ...) and "
solfège" (same, but non-transposable).
I do not know what "
Cestina" is.
As for the {meta: notation ...} I assume you consider this a song setting? I don't think it has much added value to change notation halfway a song.
Sure, I've added parsing for those values as well. Čeština is Czech. I can update the dropdown selections to show Czech and German when English is the current language.
Latin and solfège support would require a lot of changes. I don't currently have any code in place for representing chords as "Do, Re, Mi,..." and not many users have asked for that, so I'll have to add it to the feature request list for later. I get more requests for the Nashville numbering system. Perhaps I can tackle this all at once in a future update and also add support for Roman numerals for chords so that I've covered all bases.
{meta: notation ...} will be parsed out when the document is first opened and applied for the entire document as an override to the default setting. I would not consider it a song setting as it won't show up anywhere in the application. I do not allow the notation to be changed halfway. The last {meta: notation ...} listed will override any others.
Mike
(05-26-2019, 03:38 AM)Zubersoft Wrote: [ -> ]Čeština is Czech.
Yes, I know... I just do not know Czech as a music notation variant.
Quote:{meta: notation ...} will be parsed out when the document is first opened and applied for the entire document as an override to the default setting.
Thanks, that's precisely what I meant when I said 'song setting'.
If you look at my first post on the first page of this thread, I said this:
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".
So that's where I got it from.
Mike
Hi Mike,
I'd like to re-open this thread because for me it would be very nice to have chords displayed in "latin" format (Do, Re, Mi...).
I've read that it would be a hard work, but I know italian users are a lot, so perhaps this feature would make happy a great number of italian musicians, like me.
Do you have any plan to add this feature to future releases?
It's certainly on my list of things to do. I'm not exactly sure on the timeline for it though. I'm currently making a lot of changes for chord pro files, so I could consider tackling this as part of that, but it will push the update out even further if I do that.
Mike
I don't know what I'm doing wrong, but localization only works for the display but not for the input.
----------------------------------------
{meta notation: default Deutsch}
[A] [Bb] [B] [C]
-----------------------------------------
displays correct:
A B H C
====================
But:
-----------------------------------------
{meta notation: Deutsch Deutsch}
[A] [B] [H] [C]
------------------------------------------
displays wrong:
A H H C
Does anyone have any ideas?
Chord Localization has two input fields:
"Default source localization" (Akkordschreibweise in der Datei) specifies how chords are written within the ChordPro file.
"Default display localization" (Akkordschreibweise für die Anzeige) specifies how chords are shown.
Previous posts in this thread describe how it is supposed to work.
You are right, you have indeed discovered a bug:
[A] [B ] [H] [C] as file content with source localization German
should display as
A B H C with display localization German
as
A Bb B C with display localization Default
and as
A Bb H C with display localization Scandinavian
MuseScore3 behaves as expected, see attachments.
MuseScore's wording is a different:
MobileSheets "German" is called "Full German" by MuseScore
MobileSheets "Scandinavian" is called "German" by MuseScore
I had to rename the MuseScore source file to .txt because the forum doesn't accept .mscz files for upload.
I always use source localization default and display localization scandinavian. This is why I never ran into that issue before.
I corrected my previous post: Sciurius' ChordPro reference implementation handles it correctly.
Find attached a .cho file for testing.
Setting a "Chord Highlight" colour makes it obvious what MobileSheets detects as a valid chord.
Doing that shows that [H] is NOT detected as a valid chord. With source localization German [H] IS a valid chord, it is the chord that in source localization default is written as [B]
[
attachment=2726]
Transposing nevertheless works as intended:
Transposing from A to Bb, one semitone up, transposes A to B (Bb), B to H (B), H to C, C to Db
Now the transpose result 'H' of the second chord is displayed wrongly as B. Without transposing it was the third chord that was displayed wrongly
Note the 'B' as destination key in the transpose window: German spelling is used correctly
[
attachment=2727]
Thanks for the all the information. I'll work on investigating and fixing it.
Mike
Regardless of the remaining bug.
Just to make sure I've understood it correctly:
When importing a ChordPro file, if an entry {meta notation: [src]} is found, this will be used.
Otherwise - or if [src]="default" - the setting from
"Text File Settings / Chord Localization / Default source localization" is used, right?
After the import, changes to these settings no longer have any effect,
neither "Default source localization" nor changing or adding {meta notation: [src]}.
On the other hand, changes to {meta notation: [display]} or -
if not present or [display]="default" - to "Default display location" will always take effect for the display, right?
By the way: Does the file extension have any meaning when importing?
I.e. is a .cho file treated differently from a .txt file with the same content?
In the file you provided, the second chord was written as [B ] with a space after it. This causes it not to be recognized as a valid chord. Was that intentional? If I remove the space, then regardless of whatever source localization I select it, it's still highlighted correctly. I can't reproduce what you displayed above where only three out of the four chords is recognized.
Regardless, just so I understand exactly what the issue is as you've reported:
1) If source localization is set to German, and display localization is set to "Default", H is not changed to B and B is not changed to Bb because isn't transforming chords unless they are transposed
2) If source localization is set to German and display localization is set to "Default", then you also encounter issues with transposing where the second chord is transposing identically to H instead of being treated as Bb.
Is there anything else I'm missing?
Thanks,
Mike.
albatros - I believe the {meta notation} directives are always read and processed. Is there a reason you only believe they are being read during an import? If you are just asking, then the way the code is set up, they should always be read.
As far as the file extension, MobileSheets will process either extension, and if a .txt file contains chord pro directives, or if more than one valid chord in brackets is found on a line, then it will be treated as a chord pro file instead. Generally it's better to use the right file extension if possible though.
Mike