Dear lilypond developers, Dear Mr. Hassan El Fatihi, I am the developer that made the last major contributions to ly/arabic.ly and I am using lilypond very frequently and can say that I am a big fan of it. Sadly, I've recently found out that arabic.ly apparently is not the favourable way for writing Arabic sheet music using lilypond anymore. I'm writing this mail because I want to critizie the way new contributions with (I'm sorry but thats the truth) bad quality over proven ones, that have been existing since 2008 at least, have been included into lilypond without questioning its purpose, and the bad inconvenience for the end user resulting from that.
The current state of the documentation for Arabic music (https://lilypond.org/doc/v2.24/Documentation/notation/arabic-music.html ) promotes the usage of "hel-arabic.ly" over "arabic.ly" which made me curious and let me check the file and its commits. The "hel-arabic.ly" file was created with this commit (https://gitlab.com/lilypond/lilypond/-/commit/2be5896dc7025f2d5e2b11567dd5d00d32ffb75c ) shortly after my last contribution to "arabic.ly" with this commit: https://gitlab.com/lilypond/lilypond/-/commit/6f2916047111d80326f15e67ede30cddbbeedbb4 The commit says "Support for English note names in Arabic Music" which made me wonder, why you would need a seperate file for that. You could simply write: \include "arabic.ly" \language "english" % continue as normally However, when checking the file, I see its just a huge copy-paste of arabic.ly, with some customizations, that has been filled with many more modes/maqams which totally contradicts what the abovely posted documentation for the end user has been suggesting for more than a decade and even suggests until now! I don't understand at all why the file has been copy-pasted instead of using a '\include "arabic.ly"' inside of hel-arabic.ly and extending from there or simply extending arabic.ly itself. In fact, hel-arabic.ly does also contain a lot of code duplication in itself. Why? Did really nobody see this in the code review? And for the end user it is now just total confusion. The documentation now says basically something like: "Hey, you have two possibilities hel-arabic.ly or arabic.ly, each of them has its own sets of maqams defined. Check the files. Have fun." And in addition, some of the existing ones in arabic.ly have been copied but renamed (WHY?!) which is again contradicting the documentation. The documentation points out pretty well why it doesn't make sense to define a key signature for every single maqam/mode, one of the reasons being that literature does not even agree on the same maqam/mode definitions. Still, one developer decided to contribute his ideas and nobody questioned that in the code review. If the code review is just there for checking white spaces, why do we do it anyways?! Here is the commit and code review: https://gitlab.com/lilypond/lilypond/-/issues/5172 https://codereview.appspot.com/322510043 Here is the commit and code review for the documentation changes: https://gitlab.com/lilypond/lilypond/-/issues/5531 https://codereview.appspot.com/560790043 This one actually makes me wonder more. I mean 90% of the documentation does not go hand in hand with hel-arabic.ly but with arabic.ly. Even if hel-arabic.ly was an improvement, how come the documentation is only partly fixed?! By the way, what does "hel" even stand for? Please tell me it is not derived from the authors initials. I fixed the code duplication issues and added a merge request (https://gitlab.com/lilypond/lilypond/-/merge_requests/1783). This allows using the documented maqam/mode names even when using hel- arabic.ly. I also extended the documentation on how to define custom maqams/modes that renders the left over ones defined in hel-arabic.ly useless but I left them there, in case anyone wants to use them. The only other "improvement" of hel-arabic.ly is the custom note language that has been defined. It is called "arabic", though uses English note names but somewhat Italian/Catalan accidental suffixes. I don't really understand why we would need that. I've never heard someone say "C dieses" but either "C sharp" or "Do dieses". And even the code documentation in "scm/define-note-names.scm" contradicts its definition. (For example: "bb = double-flat" but you can not define double flats using this language). However, somehow this language is what the author requires since it has custom accidentals for 5/2 and 7/2 tones. Personally I've never heard of any music, especially not Arabic, that uses accidentals that lower or raise by a fourth or a fifth. Maybe the author can elaborate what this is required for? Obviously, the note language is not documented anywhere and does not even appear in the languages list: https://lilypond.org/doc/v2.24/Documentation/notation/writing-pitches#note-names-in-other-languages Personally, I still find it very inconvenient for the end user to have two arabic init files but I see that the same problems exists for Turkish music unforunately (i.e. makam.ly and turkish-makam.ly). I personally would vote for removing hel-arabic.ly and the custom note language "arabic" altogether but I can live with its current state. It appears to me that this is some highly customized solution that the author requires for himself but it is not really standardized and reusable. I think lilypond should have a standard and, since it is open and extensible, everyone can make his custom extensions to his own installation often also without recompiling it. I don't want to discredit the autors contributions but actually I felt that this quality level disparages the work of other developers that have put a lot of effort into lilypond and arabic.ly and its documentation in this case. In my opinion lilypond is in any way superior to any other sheet music software when it comes down to writing Arabic sheet music and it is in my best interested that it stays like this. Sorry for the trouble! Best regards and happy music typing, Amir Czwink
