[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
The hel-arabic.ly file story...
The hel-arabic.ly file story...
Wed, 28 Dec 2022 16:17:57 +0000
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
The current state of the documentation for Arabic music
) 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
) shortly after my last contribution to "arabic.ly" with this commit:
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
% 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
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
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:
Here is the commit and code review for the documentation changes:
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
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
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:
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,
- The hel-arabic.ly file story...,
Amir Czwink <=