05-25-2019, 10:12 AM (This post was last modified: 05-26-2019, 03:33 AM by Zubersoft.)
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:
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.
05-26-2019, 04:49 AM (This post was last modified: 05-26-2019, 04:50 AM by sciurius.)
(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".
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?
Marco
Samsung Galaxy S8 Ultra 14.6" - Nord Stage 2 HA88
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.
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]
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
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?
05-11-2024, 03:44 AM (This post was last modified: 05-11-2024, 03:54 AM by Zubersoft.)
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.
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.
