Re: Turkish makam

[Werner LEMBERG]

>> Too bad that `makam.ly` is essentially undocumented...
> 
> From what I can see, makam.ly is the original faulty file, only
> there for backwards compatibility, which might be removed if there
> is no need for that.

We could make it become deprecated in the next release, to be
completely removed in the release after.


Werner

PATCHES - Countdown to January 16

[Colin Campbell]

Here is the current countdown report.

The next countdown will begin on January 16th.

A list of all merge requests can be found here:
https://gitlab.com/lilypond/lilypond/-/merge_requests?sort=label_priority


 Push:

!1809 Let Paper_book use \layout rather than \paper for global markups - 
David Kastrup

https://gitlab.com/lilypond/lilypond/-/merge_requests/1809

!1808 Outside-staff-priority for fermatas - Martín Rincón Botero
https://gitlab.com/lilypond/lilypond/-/merge_requests/1808


 Countdown:

!1811 Doc: \smallCaps does support accented characters - Jean Abou Samra
https://gitlab.com/lilypond/lilypond/-/merge_requests/1811

!1810 Let \rhythm markup derive from current layout - David Kastrup
https://gitlab.com/lilypond/lilypond/-/merge_requests/1810

!1787 Add PNG image support - Jean Abou Samra
https://gitlab.com/lilypond/lilypond/-/merge_requests/1787

!1783 less duplicated code for Arabic and improved docs - Amir Czwink
https://gitlab.com/lilypond/lilypond/-/merge_requests/1783


 Review:

No patches in Review at this time.


 New:

No patches in New at this time.


 Waiting:

No patches in Waiting at this time.


Cheers,

Colin

Re: Turkish makam

[Hans Åberg]

> On 13 Jan 2023, at 19:03, Werner LEMBERG  wrote:
> 
>> [...] a possible future change could be, say,
>> 
>>  \include "arabic.ly"
>>  \language "arabic-hel"
>> 
>> but I don't see much benefit for that.
> 
> Hmm, probably it *is* the way to go – this is exactly what is done in
> `makam.ly` and `turkish-makam.ly`.  Too bad that `makam.ly` is
> essentially undocumented...

From what I can see, makam.ly is the original faulty file, only there for 
backwards compatibility, which might be removed if there is no need for that. 
The file turkish-makam.ly  is the corrected one 
written by Adam Good.

I described the theoretical background in the post below:
https://lists.gnu.org/archive/html/lilypond-devel/2022-12/msg00187.html

Re: The hel-arabic.ly file story...

[Werner LEMBERG]

> [...] a possible future change could be, say,
> 
>   \include "arabic.ly"
>   \language "arabic-hel"
> 
> but I don't see much benefit for that.

Hmm, probably it *is* the way to go – this is exactly what is done in
`makam.ly` and `turkish-makam.ly`.  Too bad that `makam.ly` is
essentially undocumented...


Werner

Re: The hel-arabic.ly file story...

[Werner LEMBERG]

> Now, obviously renaming it will break scores, [...]

It won't.  Such a renaming could be done easily with `convert-ly`.  I
just don't see a reason for doing that – and especially, I don't see a
alternative name for `hel-arabic.ly` that is really superior.


Werner

Re: The hel-arabic.ly file story...

[Werner LEMBERG]

> The same holds for Arabic: As described in the documentation changes
> of MR !1783 you should say
> 
>   \include "arabic.ly"
> 
> if you want Italian-based note names for inputting Arabic music, and
> 
>   \include "hel-arabic.ly"
> 
> if you want English-based note names with customized, Italian-like
> alteration suffixes.

Of course, a possible future change could be, say,

  \include "arabic.ly"
  \language "arabic-hel"

but I don't see much benefit for that.


Werner

Re: The hel-arabic.ly file story...

[Werner LEMBERG]

> But what is the point of this high-level interface?  Surely,
> arabic.ly should be the obvious entry point.

It's similar to note name language support in LilyPond: We don't say

  \include "language.ly"

Instead, we rather have

  \include "deutsch.ly"

or

  \include "italiano.ly"

The same holds for Arabic: As described in the documentation changes
of MR !1783 you should say

  \include "arabic.ly"

if you want Italian-based note names for inputting Arabic music, and

  \include "hel-arabic.ly"

if you want English-based note names with customized, Italian-like
alteration suffixes.

MR !1783 tries to unify some common code of the two files, nothing
more.  There are probably more clean-ups coming to move the remaining
maqam extensions in `hel-arabic.ly` to `arabic.ly`, too – or not, I'm
not an expert.

> All I can surmise is that arabic.ly was not fit for purpose, so
> Hassan worked on hel-arabic.ly to address limitations and
> shortcomings.

I'm not aware of limitations or shortcomings.


Werner

Re: New list admin

[Jean Abou Samra]

Le 10/01/2023 à 22:17, Jean Abou Samra a écrit :

In order to increase the bus factor, I would like to
nominate one or two other regulars as admins. If you
feel like it, please let me know.




Thanks to Mark Knoop for accepting this task. He is now a co-admin.

Best,
Jean



OpenPGP_signature
Description: OpenPGP digital signature

Re: The hel-arabic.ly file story...

[Aaron Hill]

On 2023-01-13 1:44 am, Werner LEMBERG wrote:

it seems like we could easily find a better name for this file, more
descriptive of its purpose and less related to the original author.


While this might be true, I don't think there is a pressing reason to
change the name of a high-level interface just because three letters
of the name refer to an author.  `hel-arabic.ly` exists since more
than five years, and nobody has ever complained about the name, as far
as I can remember.


But what is the point of this high-level interface?  Surely, arabic.ly 
should be the obvious entry point.


Again, I do not know Arabic music.  All I can surmise is that arabic.ly 
was not fit for purpose, so Hassan worked on hel-arabic.ly to address 
limitations and shortcomings.  But for some unknown reason, these 
improvements were never integrated into arabic.ly itself.  So the 
unusual naming convention notwithstanding, I am more surprised no one 
complained about this fragmentation of includes.


This is a case of needing to think like a newcomer: how would I know 
whether I should be using arabic.ly or hel-arabic.ly?  If both really 
are valid but fit for different purposes, then the naming should be more 
direct.  Yet, if Hassan's improvements mean that his file really should 
be the preferred entry point, then why are we shipping the old version?  
Is it completely out of the question to unify includes and provide a 
singular arabic.ly?



-- Aaron Hill

Re: The hel-arabic.ly file story...

[Luca Fascione]

On Fri, Jan 13, 2023 at 10:44 AM Werner LEMBERG  wrote:

> `hel-arabic.ly` exists since more
> than five years, and nobody has ever complained about the name, as far
> as I can remember.
>

Well yes. but.
Out of the users of that file, how many
a) would have noticed,
b) would be aware of our naming standards,
c) would think it their task to report it?

It seems that we are looking at a very small group of users here,
who may well be more focused on music than on software engineering
practices.

For example, if 90% of our total users correspond to this characterization
(more interest in music than SW Eng), and
the users of arabic or hel-arabic are less than 20, both of which seem like
passable first guesses,
we're looking at a single person who may or may not have noticed (because
there'd be 2-ish total, and Hassan himself counts as one of them of course).

I guess I feel the SW Eng practice quality is our gate to keep, not our
users'.
We provide guidance and assistance so that everybody's contributions be of
a reasonable standard and all that, right?
It seems this thread is evidence that the case for this particular file is
that so far it has slipped past even our own eyes,
rather than having been accepted as meeting our criteria in the first place.

Now, obviously renaming it will break scores, we don't know how many, and
we don't know what amount of disruption
it would cause to fix it. And it's also a possibility to rename the file
and put back a new file with the old name which warns
of the deprecation and includes the new file, to maintain compatibility.
I'll now stop saying things everybody else already knows.

L


-- 
Luca Fascione

Re: The hel-arabic.ly file story...

[Werner LEMBERG]

> it seems like we could easily find a better name for this file, more
> descriptive of its purpose and less related to the original author.

While this might be true, I don't think there is a pressing reason to
change the name of a high-level interface just because three letters
of the name refer to an author.  `hel-arabic.ly` exists since more
than five years, and nobody has ever complained about the name, as far
as I can remember.


Werner

Re: The hel-arabic.ly file story...

[Luca Fascione]

On Fri, Jan 13, 2023 at 10:11 AM Aaron Hill 
wrote:

> I have no idea what "hel" is supposed to be referring to
>

If I remember right, in a previous post Hassan had indicated "hel" to be a
shorthand for his name _H_assan _El_ Fatihi.

FWIW, I would have found it more natural to shorten the name as "hf" or
"hef", as "el" is just a definite article in Arabic
and is as such part of a fair few family names (like it's the case in
French and Italian with prefixes like "De" or "D'" or
German's "von" and so on, I guess "hel" is as if Beethoven's file would be
called "lvon-sonata.ly", it's... strange),
but obviously that's Hassan's choice.

In saying this, I do find awkward and in poor form to have files called
with a pattern like "johns-ballad.ly" in the general repo,
it seems like we could easily find a better name for this file, more
descriptive of its purpose and less related to the original author.

L

-- 
Luca Fascione

Re: The hel-arabic.ly file story...

[hassan . elfatihi]

Hello
I just answered the questions
I have no problem with including arabic.ly in hel-arabic.ly.
For me the subject can be closed
Best regard
Hassan EL FATIHI

Re: The hel-arabic.ly file story...

[Werner LEMBERG]

Hassan,


> Question: Should all key signatures for the various maqams simply go
>   only into arabic.ly ?
> Answer: All key signatures for the various maqams simply go only
> into hel-arabic.ly (if not modified, as recently proposed)

You are missing the point.  Whether the signatures are in `arabic.ly`
or in `hel-arabic.ly` is a purely technical decision.  It doesn't
affect the user interface in any way.  I can only repeat: The user can
select between `\include "arabic.ly"` and `\include "hel-arabic"` – it
is completely irrelevant where the maqam definitions are actually
stored internally.

For example, a different layout could be

  arabic.ly:
... some setup for arabic ...
\include "maqam.ly"

  hel-arabic.ly:
.. some setup for hel-arabic ...
\include "maqam.ly"


 Werner

Re: The hel-arabic.ly file story...

[Aaron Hill]

On 2023-01-13 12:23 am, Luca Fascione wrote:

Hassan,
it would help us enormously if you could share with us the reasoning 
behind

these choices.
For example, you stated "All key signatures for maqams go in 
hel-arabic.ly":

could you explain to us
why this is the better place for them, compared to arabic.ly?
This will provide some intuition to all involved as to how to make 
similar

choices in the future, for example.


While I readily admit I lack experience with music of Arabic traditions, 
I for one am confused why there are two different includes.  arabic.ly 
seems like it should be the default starting point, as it has the 
simpler, more direct naming.  On the other hand, hel-arabic.ly would at 
a glance appear to be for a more specific flavor or subset of music.  As 
such, it would logically follow that hel-arabic.ly inherits from 
arabic.ly, as all of the common elements supporting Arabic music should 
live in the base include.


That of course presumes there are common elements between the two files. 
 If they are truly independent, I can easily understand why they should 
stand alone.  And if hel-arabic.ly is really what users *should* be 
including (meaning that arabic.ly offers little value), then we would 
want to discard the old arabic.ly and rename hel-arabic.ly to be 
arabic.ly with the better, straightforward naming.  (I must confess I 
have no idea what "hel" is supposed to be referring to, but perhaps I am 
just too ignorant of Arabic music where it has an obvious meaning.)



-- Aaron Hill

Re: The hel-arabic.ly file story...

[Luca Fascione]

Hassan,
it would help us enormously if you could share with us the reasoning behind
these choices.
For example, you stated "All key signatures for maqams go in hel-arabic.ly":
could you explain to us
why this is the better place for them, compared to arabic.ly?
This will provide some intuition to all involved as to how to make similar
choices in the future, for example.

Many thanks
Luca

On Fri, Jan 13, 2023 at 9:07 AM  wrote:

> Hello
> Answers to questions
> Question : while hel-arabic.ly has this line that
> includes arabic.ly , what are they getting out of this? Some more
> key signatures and keyAlterationOrder?
>
> answer: normally hel-arabic.ly doesn't need arabic.ly (if not modified,
> as recently proposed)
>
> Question: Should all key signatures for the various maqams simply go only
> into
> arabic.ly ?
> Answer : All key signatures for the various maqams simply go only into
> hel-arabic.ly
> (if not modified, as recently proposed)
> If you want examples I can provide them.
> This is why I did not want to link hel-arabic.ly to arabic.ly
> Best regard
>
>

-- 
Luca Fascione

Re: The hel-arabic.ly file story...

[hassan . elfatihi]

Hello 
Answers to questions 
Question : while hel-arabic.ly has this line that 
includes arabic.ly , what are they getting out of this? Some more 
key signatures and keyAlterationOrder? 

answer: normally hel-arabic.ly doesn't need arabic.ly (if not modified, as 
recently proposed) 

Question: Should all key signatures for the various maqams simply go only into 
arabic.ly ? 
Answer : All key signatures for the various maqams simply go only into 
hel-arabic.ly 
(if not modified, as recently proposed) 
If you want examples I can provide them. 
This is why I did not want to link hel-arabic.ly to arabic.ly 
Best regard