Re: Oriental microtonal music

[Hans Åberg]

> On 29 Dec 2022, at 23:35, Karlin High  wrote:
> 
> My email address was in the To: header.
> 
> In Cc: were the other people I had mentioned here:
> 
> 
> 
> Therefore, I understood that post as a response to my question about which 
> available participants in the LilyPond community could advise on code reviews 
> for Oriental microtonal music.
> 
> A threading disconnect at worst.

Deliberately a new thread, as it is a wholly different topic:

I supplied the information the LilyPond developers might need for doing code 
reviews on their own, in view of that the people mentioned there, including me, 
and the two others, cc-ed here, likely do not want to be involved with that.

Re: Oriental microtonal music

[Karlin High]

On 12/29/2022 4:06 PM, David Kastrup wrote:

I doubt anybody has an idea what you want to to get done by whom for
what reason.


My email address was in the To: header.

In Cc: were the other people I had mentioned here:



Therefore, I understood that post as a response to my question about 
which available participants in the LilyPond community could advise on 
code reviews for Oriental microtonal music.


A threading disconnect at worst.
--
Karlin High
Missouri, USA

Re: Oriental microtonal music

[David Kastrup]

Hans Åberg  writes:

> Graham Breed wrote a file regular.ly  that allows
> for retuning into any ET (around C4, not A4), but Adam Good is expert
> on Turkish music specifically.
>
> There are some issues with Turkish, Persian and Arabic music that must
> be dealt with when adapting for LilyPond: Notation system limitations,
> transposability, and MIDI output.
>
> Because of those issues, I would prefer to use Helmholtz-Ellis
> notation. There, LilyPond does not have the double arrowhead
> accidentals.
>
> Though Persian music is transposed, in Turkish makam and Arabic maqam,
> one may rename. In LilyPond, transposability is hard wired, so some
> care must be taken here: Turkish music has different notation systems,
> but the common AEU (Arel–Ezgi–Uzdilek) is not transposable, as its
> sharp ♯ and and doublesharp 턪 represents microtonal accidentals, not
> the ordinary ones. AEU also writes the pitch a 4th above the sounding
> pitch.
>
> As for MIDI, the traditional tuning is Pythagorean tuning with
> Pythagorean commas for microtonal alterations in Turkish music, though
> with departures in actual performance. In Arabic and Persian music,
> these have drifted considerably, the double is a possibility.
>
> LilyPond does not support exact Pythagorean tuning, but it could be
> replaced by E₅₃ (53 ET) by the use of regular.ly 
> if included in the distribution. An alternative that does not require
> this file is E₇₂ (72 ET), which relative E₅₃ and Pythagorean tuning
> changes the diatonic scale into E₁₂ (12 ET), but alters the microtonal
> neutral seconds only with a few cents.
>
> I believe that Adam Good used E₇₂ for the rewritten Turkish makam file.
>
> The original LilyPond makam file had an error making it not transposable:
>
> E₅₃ has minor second m = 4, major second M = 9 commas (E₅₃ tonesteps),
> so that the sharp ♯ = 9 - 4 = 5 commas, and the Pythagorean comma is
> approximated by 1 E₅₃ tonestep, also called a comma. Therefore, in
> E₅₃, one arrives at the microtonal alteration of one comma by dividing
> the E₅₃ M by 9 or the E₅₃ ♯ by 5.
>
> A type of error one sees though, is that these last rules are not
> applied to E₅₃ but to E₁₂:
>
> In the original LilyPond file, they reasoned to divide the M of E₁₂
> further in form of the LilyPond accidental, which is internally
> represented as a rational number where ♯ is 1/2. So the doublesharp 턪,
> which has a value 1, is divided by 9, but unfortunately the ♯ of 1/2
> is not then an integral multiple of that. The new one by Adam Good
> corrects this issue.
>
> If the ♯ of E₁₂ is divided to 5 parts, one arrives at E₆₀, which is
> done in a suggested Persian file. The Arabic files written so far use
> E₂₄, possibly because LilyPond did not have the rational accidentals
> originally, but only this 24 ET.

I doubt anybody has an idea what you want to to get done by whom for
what reason.

That makes your extensive writeup (that takes a lot of things for
granted that will not be in the experience or knowledge set of whoever
could actually be convinced to actually fix or write code) a complete
waste of time.

This waste of time, in turn, will serve for nothing except to convince
you that other developers/users of LilyPond are unable to cater to your
use cases.

I have no idea how to get you on the same page with anybody.  At the
same time, if you want something to be done, it is your job to figure
out a common base of communication.

-- 
David Kastrup

Re: Missing items to make Cairo ready

[Jean Abou Samra]

Le 29/12/2022 à 12:19, Jonas Hahnfeld a écrit :

(FWIW I don't think it is a good idea to add features that will only
work with Cairo. That sounds like a recipe for confusion to me, but I
haven't yet had the time to properly look into the merge request...)



I don't really see what the problem is.

If you try to use a PNG image in the default PS backend, you
get a user-friendly warning explaining that you need to run with
-dbackend=cairo (OK, makes me think I should add this to the default
SVG backend as well).

It's not much different from \epsfile being supported in the
default PS backend but not in the default SVG backend.

PNG embedding should be feasible for the default PS and SVG
backends too, but I'm not willing to spend time on it.



So, to support \epsfile
and \postscript, we can convert and embed as PNG.
Of course, this means we cannot drop Ghostscript,
but we're not going to do it anytime soon anyway.

PNG is a pixel-format, so depending on what users embed images for,
this may result in very inferior quality or huge files (if you render
at insane dimensions).



Well, if GS is still around, there is the other route too: create
PS output via Cairo, and convert to PDF with GS like we're already
doing. That way, you can have vector graphics into PDF from EPS.

That said, for this to be a problem, you need to have an EPS file
that actually contains vector graphics. My impression is that in
most cases, users pass files that contain embedded raster graphics,
probably converted from PNG, JPEG or TIFF in the first place.




Which raises another question: How do you embed
vector graphics into Cairo?



Cairo itself doesn't understand PS or PDF (it can just
embed the EPS content into EPS/PS without actually parsing
it). For that, I think you would have to use Poppler,
which has a Cairo backend.




I don't agree here. It is hard to sell any migration without some level
of parity. We had this with Python 3 and Guile 2, and I think it is
even more important for the output backend.



Sorry, I don't understand what you mean by this. Can
you elaborate?



OpenPGP_signature
Description: OpenPGP digital signature

Oriental microtonal music

[Hans Åberg]

Graham Breed wrote a file regular.ly  that allows for 
retuning into any ET (around C4, not A4), but Adam Good is expert on Turkish 
music specifically.

There are some issues with Turkish, Persian and Arabic music that must be dealt 
with when adapting for LilyPond: Notation system limitations, transposability, 
and MIDI output.

Because of those issues, I would prefer to use Helmholtz-Ellis notation. There, 
LilyPond does not have the double arrowhead accidentals.

Though Persian music is transposed, in Turkish makam and Arabic maqam, one may 
rename. In LilyPond, transposability is hard wired, so some care must be taken 
here: Turkish music has different notation systems, but the common AEU 
(Arel–Ezgi–Uzdilek) is not transposable, as its sharp ♯ and and doublesharp 턪 
represents microtonal accidentals, not the ordinary ones. AEU also writes the 
pitch a 4th above the sounding pitch.

As for MIDI, the traditional tuning is Pythagorean tuning with Pythagorean 
commas for microtonal alterations in Turkish music, though with departures in 
actual performance. In Arabic and Persian music, these have drifted 
considerably, the double is a possibility.

LilyPond does not support exact Pythagorean tuning, but it could be replaced by 
E₅₃ (53 ET) by the use of regular.ly  if included in the 
distribution. An alternative that does not require this file is E₇₂ (72 ET), 
which relative E₅₃ and Pythagorean tuning changes the diatonic scale into E₁₂ 
(12 ET), but alters the microtonal neutral seconds only with a few cents.

I believe that Adam Good used E₇₂ for the rewritten Turkish makam file.

The original LilyPond makam file had an error making it not transposable:

E₅₃ has minor second m = 4, major second M = 9 commas (E₅₃ tonesteps), so that 
the sharp ♯ = 9 - 4 = 5 commas, and the Pythagorean comma is approximated by 1 
E₅₃ tonestep, also called a comma. Therefore, in E₅₃, one arrives at the 
microtonal alteration of one comma by dividing the E₅₃ M by 9 or the E₅₃ ♯ by 5.

A type of error one sees though, is that these last rules are not applied to 
E₅₃ but to E₁₂:

In the original LilyPond file, they reasoned to divide the M of E₁₂ further in 
form of the LilyPond accidental, which is internally represented as a rational 
number where ♯ is 1/2. So the doublesharp 턪, which has a value 1, is divided by 
9, but unfortunately the ♯  of 1/2 is not then an integral multiple of that. 
The new one by Adam Good corrects this issue.

If the ♯ of E₁₂ is divided to 5 parts, one arrives at E₆₀, which is done in a 
suggested Persian file. The Arabic files written so far use E₂₄, possibly 
because LilyPond did not have the rational accidentals originally, but only 
this 24 ET.

Re: Missing items to make Cairo ready

[Jonas Hahnfeld via Discussions on LilyPond development]

On Thu, 2022-12-29 at 12:02 +0100, Jean Abou Samra wrote:
> 
> Le 29/12/2022 à 11:53, Jonas Hahnfeld a écrit :
> > On Thu, 2022-12-29 at 01:53 +0100, Jean Abou Samra wrote:
> > > Hi,
> > > 
> > > I have just opened issues for the missing features of
> > > the Cairo backend that I am aware of.
> > > 
> > > https://gitlab.com/lilypond/lilypond/-/issues/6500
> > > https://gitlab.com/lilypond/lilypond/-/issues/6501
> > > https://gitlab.com/lilypond/lilypond/-/issues/6502
> > > https://gitlab.com/lilypond/lilypond/-/issues/6503
> > > https://gitlab.com/lilypond/lilypond/-/issues/6504
> > > 
> > > Are there any others?
> > In my understanding (please correct me if I get this wrong), the
> > elephant in the room is that we _cannot_ support a number of features /
> > markup commands in Cairo, or at least a significant subset of how some
> > of them are used today: \epsfile and \postscript will only work with
> > Cairo if you produce a Postscript file, but not in the "default" modes
> > of outputting PDFs and PNGs.
> 
> 
> Yes. To my knowledge, they are the only ones, though.
> 
> Here is an idea. We already have a working EPS → PNG
> conversion through GS. With
> https://gitlab.com/lilypond/lilypond/-/merge_requests/1787
> Cairo supports PNG images.

(FWIW I don't think it is a good idea to add features that will only
work with Cairo. That sounds like a recipe for confusion to me, but I
haven't yet had the time to properly look into the merge request...)

> So, to support \epsfile
> and \postscript, we can convert and embed as PNG.
> Of course, this means we cannot drop Ghostscript,
> but we're not going to do it anytime soon anyway.

PNG is a pixel-format, so depending on what users embed images for,
this may result in very inferior quality or huge files (if you render
at insane dimensions). Which raises another question: How do you embed
vector graphics into Cairo?

> The Cairo backend needs to be the default for some time
> before the old PS backend is dropped.

Agreed, but that's several steps down the road. Let's agree on the
first part before going there.

> It means we can separate the moment we switch to Cairo
> by default while keeping GS and the old backend, and
> the moment where we drop those. The *second* one is the
> moment where users will really need to have converted
> their EPS images to PNG.

I don't agree here. It is hard to sell any migration without some level
of parity. We had this with Python 3 and Guile 2, and I think it is
even more important for the output backend.


signature.asc
Description: This is a digitally signed message part

Re: Missing items to make Cairo ready

[Jean Abou Samra]

Le 29/12/2022 à 11:53, Jonas Hahnfeld a écrit :

On Thu, 2022-12-29 at 01:53 +0100, Jean Abou Samra wrote:

Hi,

I have just opened issues for the missing features of
the Cairo backend that I am aware of.

https://gitlab.com/lilypond/lilypond/-/issues/6500
https://gitlab.com/lilypond/lilypond/-/issues/6501
https://gitlab.com/lilypond/lilypond/-/issues/6502
https://gitlab.com/lilypond/lilypond/-/issues/6503
https://gitlab.com/lilypond/lilypond/-/issues/6504

Are there any others?

In my understanding (please correct me if I get this wrong), the
elephant in the room is that we _cannot_ support a number of features /
markup commands in Cairo, or at least a significant subset of how some
of them are used today: \epsfile and \postscript will only work with
Cairo if you produce a Postscript file, but not in the "default" modes
of outputting PDFs and PNGs.



Yes. To my knowledge, they are the only ones, though.

Here is an idea. We already have a working EPS → PNG
conversion through GS. With
https://gitlab.com/lilypond/lilypond/-/merge_requests/1787
Cairo supports PNG images. So, to support \epsfile
and \postscript, we can convert and embed as PNG.
Of course, this means we cannot drop Ghostscript,
but we're not going to do it anytime soon anyway.
The Cairo backend needs to be the default for some time
before the old PS backend is dropped.

It means we can separate the moment we switch to Cairo
by default while keeping GS and the old backend, and
the moment where we drop those. The *second* one is the
moment where users will really need to have converted
their EPS images to PNG.



OpenPGP_signature
Description: OpenPGP digital signature

Re: Missing items to make Cairo ready

[Jonas Hahnfeld via Discussions on LilyPond development]

On Thu, 2022-12-29 at 01:53 +0100, Jean Abou Samra wrote:
> Hi,
> 
> I have just opened issues for the missing features of
> the Cairo backend that I am aware of.
> 
> https://gitlab.com/lilypond/lilypond/-/issues/6500
> https://gitlab.com/lilypond/lilypond/-/issues/6501
> https://gitlab.com/lilypond/lilypond/-/issues/6502
> https://gitlab.com/lilypond/lilypond/-/issues/6503
> https://gitlab.com/lilypond/lilypond/-/issues/6504
> 
> Are there any others?

In my understanding (please correct me if I get this wrong), the
elephant in the room is that we _cannot_ support a number of features /
markup commands in Cairo, or at least a significant subset of how some
of them are used today: \epsfile and \postscript will only work with
Cairo if you produce a Postscript file, but not in the "default" modes
of outputting PDFs and PNGs.

> I ask this because we are at an early point in the
> 2.26 release cycle, which could potentially be ideal
> to get testing for "Cairo by default" if it were
> ready, but it isn't yet.

Because of the above, I think that there is nothing we can do in order
to make "Cairo by default" happen for the next stable release - we
first need to (in 2.26) properly deprecate everything we cannot / do
not want to support with Cairo. Then they can be removed and Cairo be
made the default backend in LilyPond 3.0, which, in my understanding,
is a major major change in how LilyPond has created output since its
very beginning.
For that reason, I'm not fond of opt-out testing Cairo any time soon.

Jonas


signature.asc
Description: This is a digitally signed message part

Re: Duplicate SVG attribute

[Paolo Prete]

On Thu, Dec 29, 2022 at 12:18 AM Jean Abou Samra  wrote:

> Le 25/12/2022 à 21:01, Paolo Prete a écrit :
> > Thanks as always for your help, and also for the snippet you provided.
> >
> > You're right it's not usual to do that override twice for the same
> > grob, and I'll update you with a concrete test-case in which the
> > mentioned issue happens, so to see if we have some stable ways for
> > working around it in a stable way.
>
>
>
> https://gitlab.com/lilypond/lilypond/-/merge_requests/1780 should fix
> this.
>
> Unless the context is more specific, I don't really see a nice workaround.
> You can use after-line-breaking to mutate as wanted, but that will mess up
> if the user of your Spontini editor does their own after-line-breaking
> override.
>
> You could just use the "dirty" workaround iff the LilyPond version is <
> 2.25.1.
> After all, there is no stability problem if you know that it won't be used
> past a certain version.
>
>
>
Thanks for the fix!
I ask you a little modification of the previous workaround: what could be a
convenient way to add, in your scheme code, a check that the version must
be < 2.25.1 ?
 Thanks again