Re: Any ideas what is happening here?

[Dan Eble]

On Nov 3, 2021, at 22:10, Dan Eble  wrote:
> 
> Using \tuplet 1/1 instead of \volta 1 causes the same problem.

\tuplet:  https://gitlab.com/lilypond/lilypond/-/issues/6205
\volta:   https://gitlab.com/lilypond/lilypond/-/issues/6207
— 
Dan

Re: compiling MacOS application in LilyDev

[Karlin High]

On Sun, Nov 7, 2021, 6:46 PM Kieren MacMillan 
wrote:

> is it possible for me to compile a version of Lilypond that will run
> natively on my Mac OS machine?
>

One starting point:



>

Re: Manipulating instrument names and staff group names

[Kieren MacMillan]

Hi Harm,

> Start slowly, maybe with a markup-command you would like to have

Okay! I’ve got one: I’d like  to 
become an official #'style in TimeSignature. (This hasn’t been done yet, right?)

Thanks,
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: kie...@kierenmacmillan.info

compiling MacOS application in LilyDev

[Kieren MacMillan]

Hi all,

Now that I can compile master from source, is it possible for me to compile a 
version of Lilypond that will run natively on my Mac OS machine? (My 
development/compilation environment is LilyDev running in VirtualBox.)

Thanks,
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: kie...@kierenmacmillan.info

Re: Issue difficulty tags (was: Manipulating instrument names and staff group names)

[Kieren MacMillan]

Hi Carl,

> As far as I can see, this is desirable, but certainly not low-hanging fruit.

As I qualified, that’s from the metric of “motivation” (which was what Jean 
implied should be the main metric!).

> If you could come up with a an algorithm that would allow me to Do The Right 
> Thing given unlimited voice inputs, then I imagine it's implementable.  But I 
> think coming up with the algorithm is very challenging.

Well, I’ll take that on as an enjoyable (if potentially long-term) puzzle to 
solve.

Thanks,
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: kie...@kierenmacmillan.info

Re: Manipulating instrument names and staff group names

[Kieren MacMillan]

Hi Jean,

>>> "Defect" is for problems within the "core program",
>>> which means either C++ or Scheme. I would argue that those two are not
>>> really separable in most cases
>> Does that mean for someone like me — with a fighting chance of Scheme-ing, 
>> but very little chance of ever C++-ing — there are very few 
>> [non-documentation] issues I can likely fix?
> 
> A blatant counter-example is in the person of Harm.

So C++ and Scheme *are* [as I first suggested] separable?

Thanks,
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: kie...@kierenmacmillan.info

Re: Issue difficulty tags

[David Kastrup]

Carl Sorensen  writes:

> As far as I can see, this is desirable, but certainly not low-hanging
> fruit.  In fact, I think that defining the Right Thing is an extremely
> difficult task, let alone implementing it.
>
> If you have two voices to combine, there are three possible choices:
> Voice 1, Voice 2, or combined.
>
> If you go to three voices, you now have 7 choices: Voice 1, Voice 2,
> Voice 3, Voice 1+2, Voice 2+3, Voice 1+3, Voice 1+2+3.
>
> If you go three voices, you have 14 choices: Voices 1, 2, 3, 4, 1+2,
> 1+3, 1+4 2+3, 2+4, 3+4, 1+2+3, 1+3+4, 2+3+4, 1+2+3+4.  And then you
> have combinations of these: 1, 2, 3+4; 1, 2+3, 4; etc.
>
> I think this sounds like an easy problem, but once I looked into it, I
> decided there was nothing easy about it.
>
> If you could come up with a an algorithm that would allow me to Do The
> Right Thing given unlimited voice inputs, then I imagine it's
> implementable.  But I think coming up with the algorithm is very
> challenging.

I think the only reasonable approach here is to keep each voice in its
own continuing voice but juggle the listeners of the various engravers
around such that multiple noteheads can land on the same stem and
similar.  To me that seems the only feasible way for avoiding an
exponential explosion of contexts where you stand little chance of
finding a common Voice for drawing a slur from one moment to the next.

That's seriously non-beginner stuff.  It's actually architecture-level
stuff, diluting the Voice separation that turns ad-hoc polyphony (in
contrast to fixed polyphony determined by player separation or at least
instrument part separation) like that common in piano and other keyboard
music into a nuisance for typesetting with LilyPond.

-- 
David Kastrup

Re: Manipulating instrument names and staff group names

[Thomas Morley]

Am So., 7. Nov. 2021 um 22:30 Uhr schrieb Jean Abou Samra :
>
> Le 07/11/2021 à 21:59, Kieren MacMillan a écrit :
> > Hi Jonas,
> >
> >> "Defect" is for problems within the "core program",
> >> which means either C++ or Scheme. I would argue that those two are not
> >> really separable in most cases
> > Does that mean for someone like me — with a fighting chance of Scheme-ing, 
> > but very little chance of ever C++-ing — there are very few 
> > [non-documentation] issues I can likely fix?
>
>
> A blatant counter-example is in the person
> of Harm.

Indeed :)
I don't know C++, I don't know python. At the time I discovered
LilyPond I didn't know scheme.

While using LilyPond I felt the wish to get some things from LilyPond,
which were not there - and learned scheme.
Today there are several of my patches in the source:
http://git.savannah.gnu.org/cgit/lilypond.git/log/?qt=author=Thomas+Morley
Ofcourse the range of those patches is very wide: from correcting a
typo somewhere up to implementing new grobs.

May I give you some advice?
Start slowly, maybe with a markup-command you would like to have,
don't look at the partcombiner for now.
At least I'm always scared away looking there.
Make yourself famliar with using the repository, gitLab and the like.

And don't run against walls for more than a day ;)
Ask!

Best,
  Harm

Re: Issue difficulty tags (was: Manipulating instrument names and staff group names)

[Carl Sorensen]

On 11/7/21, 12:46 PM, "lilypond-devel on behalf of Kieren MacMillan" 
 wrote:

Obvious “low-hanging fruit” [at least from the perspective of motivation]: 
I want — nay, need! — the part combiner to Do The Right Thing™: effectively 
unlimited voice inputs, no problem with quotes and lyrics, etc. etc. etc.

> and any sort of mentor can tell you
> if it sounds feasible for a beginner.

As far as I can see, this is desirable, but certainly not low-hanging fruit.  
In fact, I think that defining the Right Thing is an extremely difficult task, 
let alone implementing it.

If you have two voices to combine, there are three possible choices:  Voice 1, 
Voice 2, or combined.

If you go to three voices, you now have 7 choices: Voice 1, Voice 2, Voice 3, 
Voice 1+2, Voice 2+3, Voice 1+3, Voice 1+2+3.

If you go three voices, you have 14 choices: Voices 1, 2, 3, 4, 1+2, 1+3, 1+4 
2+3, 2+4, 3+4, 1+2+3, 1+3+4, 2+3+4, 1+2+3+4.  And then you have combinations of 
these: 1, 2, 3+4; 1, 2+3, 4; etc.

I think this sounds like an easy problem, but once I looked into it, I decided 
there was nothing easy about it.

If you could come up with a an algorithm that would allow me to Do The Right 
Thing given unlimited voice inputs, then I imagine it's implementable.  But I 
think coming up with the algorithm is very challenging.

Thanks,

Carl

Re: Manipulating instrument names and staff group names

[David Kastrup]

Jean Abou Samra  writes:

> Le 07/11/2021 à 21:59, Kieren MacMillan a écrit :
>> Hi Jonas,
>>
>>> "Defect" is for problems within the "core program",
>>> which means either C++ or Scheme. I would argue that those two are not
>>> really separable in most cases
>> Does that mean for someone like me — with a fighting chance of
>> Scheme-ing, but very little chance of ever C++-ing — there are very
>> few [non-documentation] issues I can likely fix?
>
>
> A blatant counter-example is in the person of Harm.

Well, he's certainly not able to fix quite a number of bugs.  Except
that any sufficiently advanced workaround is indistinguishable from a
bug fix.

But that aside, he certainly has tackled a number of issues that were
more in line of a feature request than a bug fix, and for bugs outside
of the core C++ parts, he also has done quite a bit of fixing.

There are also a number of other people (like David Nalesnik) who have
contributed large pieces of magic mostly in the Scheme domain, partly as
off-the-cuff contributions to discussions on the list.

-- 
David Kastrup

Re: Manipulating instrument names and staff group names

[Jean Abou Samra]

Le 07/11/2021 à 21:59, Kieren MacMillan a écrit :

Hi Jonas,


"Defect" is for problems within the "core program",
which means either C++ or Scheme. I would argue that those two are not
really separable in most cases

Does that mean for someone like me — with a fighting chance of Scheme-ing, but 
very little chance of ever C++-ing — there are very few [non-documentation] 
issues I can likely fix?



A blatant counter-example is in the person
of Harm.



Would you like to mentor me through this patch?


Sorry, only now I realize that this was sent
publicly. So yes (but let's handle the mentoring
in private messages).

Best,
Jean

Re: Manipulating instrument names and staff group names

[Kieren MacMillan]

Hi Jonas,

> "Defect" is for problems within the "core program",
> which means either C++ or Scheme. I would argue that those two are not
> really separable in most cases

Does that mean for someone like me — with a fighting chance of Scheme-ing, but 
very little chance of ever C++-ing — there are very few [non-documentation] 
issues I can likely fix?

Thanks, Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: kie...@kierenmacmillan.info

Re: Fwd: Manipulating instrument names and staff group names

[Jonas Hahnfeld via Discussions on LilyPond development]

Am Sonntag, dem 07.11.2021 um 11:07 -0500 schrieb Kieren MacMillan:
> > > 2. Is there a tag/label on GitLab which identifies all and only
> > > those issues which don’t (or at least shouldn’t likely) require
> > > any C++ work?
> > 
> > There isn't. We had Frog in the past (good for beginners,
> > not language-specific), but it was practically unused and
> > the issues tagged were not actually so easy. Feel free to
> > propose something on the devel list though.
> 
> My goal is to be able to search the issues by language(s) required
> [i.e., filter out anything that requires more than Scheme], sort the
> list by difficulty [ascending], and start hacking away from the top.
> In order to do this, I imagine we’d need tags/labels for both
> “language(s)” and “difficulty”. I don’t want to clutter up the
> label-space… but I offer that adding something would help beginners
> like me to feel comfortable jumping in.
> 
> 1. “Language(s)”. While I would love it to be one tag per language
> involved (C++, Scheme, Python) — which would allow really granular
> searching/filtering — that might be overkill for everyone else. Maybe
> just one tag (e.g., “Scripting”) for things that don’t require recompilation?

We have the "Scripts" label that should group everything related to the
Python scripts, plus some more specific labels for ABC2ly, MIDI2ly, and
MusicXML. Likewise "Defect" is for problems within the "core program",
which means either C++ or Scheme. I would argue that those two are not
really separable in most cases, so I don't think a new label is a good
fit here.

> 2. “Difficulty”. Any multi-level (and thus multi-tag) system would be
> fine, as long as it’s at least three levels (e.g., Easy, Medium, Hard);
> optimal would be, say, a scale from 1 to 10 (e.g., Difficulty-1, 
> Difficulty-2, etc.).

As Jean already pointed out, assigning a difficulty is difficult
without having a very close look at the issue at hand. For example, a
small issue requiring only one changed line can at first seem very
similar to a problem that turns out to be related to the entire design
of LilyPond and is actually much harder to solve.

Jonas



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

Re: Manipulating instrument names and staff group names

[Kieren MacMillan]

Hi Jean,

> On Nov 6, 2021, at 4:20 PM, Jean Abou Samra  wrote:
> 
>> #1034 seems safe, there's no actual "programming" involved, as far as I can 
>> see.
> 
> The NR appendix is autogenerated, so you'd need to add
> a new optional keyword argument to define-music-function
> like #:category for markup commands, and let the script
> understand that (scm/document-identifiers.scm).

Would you like to mentor me through this patch?

Thanks,
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: kie...@kierenmacmillan.info

Re: Issue difficulty tags (was: Manipulating instrument names and staff group names)

[Jean Abou Samra]

Le 07/11/2021 à 20:45, Kieren MacMillan a écrit :

Hi Jean,


The problem for both of these is that often,
investigating what the bug is and how it
might be fixed is the main part of the work.
So if you have a good idea of what language
is required and how hard it is, you're
close enough to a fix that it's worth it
to actually prepare the fix.

On the other hand, for someone like me, with [relatively] limited knowledge of 
either the languages involved *or* the current codebase, perhaps just 
investigating the bug to the point of tag-ability might help me climb those 
learning curves…?



Well, it can take hours to investigate a
bug even to that point. For an experienced
developer. In that case, don't give yourself
the goal of doing this on many issues: take
a few and dig into them.



I don't think we can do much better than tagging easy issues.

Well, that basically solves my main problem, so can we start there?



I believe this is most reasonable.



The obvious alternative to all of this is for me to have an assigned “mentor”

Would that motivate you?

Not really… I was just offering another mechanism that might help ensure that 
my contributions ultimately match my intention and enthusiasm.  ;)


I started with what I was interested in/competent enough with.

Well, I’m happy to do that, too… but fair warning: that’s likely to lead to a 
lot more “syntactic sugar” patches rather than bug fixes.


ask about what you have in mind,

Obvious “low-hanging fruit” [at least from the perspective of motivation]: I 
want — nay, need! — the part combiner to Do The Right Thing™: effectively 
unlimited voice inputs, no problem with quotes and lyrics, etc. etc. etc.


and any sort of mentor can tell you
if it sounds feasible for a beginner.

Well?  ;)



Huh, the part combiner is not exactly a simple beast.
Sorry not to give the hoped answer.

I mean, ok, that's my prejudice. It's easy to know
for sure: take scm/part-combiner.scm, read it, and
see where that gets you.

Best,
Jean

Re: Issue difficulty tags (was: Manipulating instrument names and staff group names)

[Kieren MacMillan]

Hi Jean,

> The problem for both of these is that often,
> investigating what the bug is and how it
> might be fixed is the main part of the work.
> So if you have a good idea of what language
> is required and how hard it is, you're
> close enough to a fix that it's worth it
> to actually prepare the fix.

On the other hand, for someone like me, with [relatively] limited knowledge of 
either the languages involved *or* the current codebase, perhaps just 
investigating the bug to the point of tag-ability might help me climb those 
learning curves…?

> I don't think we can do much better than tagging easy issues.

Well, that basically solves my main problem, so can we start there?

>> The obvious alternative to all of this is for me to have an assigned “mentor”
> Would that motivate you?

Not really… I was just offering another mechanism that might help ensure that 
my contributions ultimately match my intention and enthusiasm.  ;)

> I started with what I was interested in/competent enough with.

Well, I’m happy to do that, too… but fair warning: that’s likely to lead to a 
lot more “syntactic sugar” patches rather than bug fixes.

> ask about what you have in mind,

Obvious “low-hanging fruit” [at least from the perspective of motivation]: I 
want — nay, need! — the part combiner to Do The Right Thing™: effectively 
unlimited voice inputs, no problem with quotes and lyrics, etc. etc. etc.

> and any sort of mentor can tell you
> if it sounds feasible for a beginner.

Well?  ;)

Thanks!
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: kie...@kierenmacmillan.info

Issue difficulty tags (was: Manipulating instrument names and staff group names)

[Jean Abou Samra]

Le 07/11/2021 à 17:07, Kieren MacMillan a écrit :

Hello developers!

Thanks to Lukas and Jean, I’ve got a working LilyDev environment *and* have 
successfully done the GitLab branch/push/delete/etc. thing. In other words: For 
the first time in almost 20 years of Pond-ing, I’m ready to actively contribute 
code directly to the codebase!!

So… first bit of business, carried over from a -user thread:


From: Jean Abou Samra mailto:j...@abou-samra.fr>>
Subject: Re: Manipulating instrument names and staff group names
Date: November 6, 2021 at 4:08:15 PM EDT
To: Kieren MacMillan mailto:kieren_macmil...@sympatico.ca>>
Cc: Lilypond-User Mailing List mailto:lilypond-u...@gnu.org>>


2. Is there a tag/label on GitLab which identifies all and only those issues 
which don’t (or at least shouldn’t likely) require any C++ work?

There isn't. We had Frog in the past (good for beginners,
not language-specific), but it was practically unused and
the issues tagged were not actually so easy. Feel free to
propose something on the devel list though.

My goal is to be able to search the issues by language(s) required [i.e., 
filter out anything that requires more than Scheme], sort the list by 
difficulty [ascending], and start hacking away from the top. In order to do 
this, I imagine we’d need tags/labels for both “language(s)” and “difficulty”. 
I don’t want to clutter up the label-space… but I offer that adding something 
would help beginners like me to feel comfortable jumping in.

1. “Language(s)”. While I would love it to be one tag per language involved 
(C++, Scheme, Python) — which would allow really granular searching/filtering — 
that might be overkill for everyone else. Maybe just one tag (e.g., 
“Scripting”) for things that don’t require recompilation?

2. “Difficulty”. Any multi-level (and thus multi-tag) system would be fine, as 
long as it’s at least three levels (e.g., Easy, Medium, Hard); optimal would 
be, say, a scale from 1 to 10 (e.g., Difficulty-1, Difficulty-2, etc.).



The problem for both of these is that often,
investigating what the bug is and how it
might be fixed is the main part of the work.
So if you have a good idea of what language
is required and how hard it is, you're
close enough to a fix that it's worth it
to actually prepare the fix.

In other words: it's easy to see if an issue
is easy, and it's hard to see if an non-easy
issue is medium or hard. Consequently, I don't
think we can do much better than tagging easy
issues. We're solving open problems, not
assignments :-)

Add that a contribution need not be linked to
an issue. It can be a code cleanup, adding your
secret pet feature, restructuring internals (that
one is not for beginners), adding a predefined
command for something common, ...



As a first “Frog Task”, I’d be happy to do a pass through all ~1,000 currently 
open issues and do my best to apply at least the right Language tag(s); I could 
also take a guess at the Difficulty level (but might, in many cases, be way off 
to start!) which more experienced developers could re-tag as necessary.

The obvious alternative to all of this is for me to have an assigned “mentor”, 
who would farm out “the right next task”, taking into account my skill set, the 
language(s) and difficulty of the issue, etc. But I don’t want to add ongoing 
work to anyone else’s plate, so I figured the suggestion above might be 
superior.


Would that motivate you? We have different
personalities... I wouldn't have liked a
(virtual, past) mentor telling me what to
work on next: rather, I started with what
I was interested in/competent enough with.
And I continue like that -- just like
everyone here.

If you would like specific proposals of
issues to work with, I have no problem
bringing them (others should feel free
to propose themselves too). But I would
spontaneously expect it to come in the
other way: ask about what you have in
mind, and any sort of mentor can tell you
if it sounds feasible for a beginner.

Designing mentorship programs is hard :-)

Best,
Jean

Re: strange bbox of 'flat' glyph

[Han-Wen Nienhuys]

On Sun, Nov 7, 2021 at 10:20 AM Werner LEMBERG  wrote:
>
>
> Does anybody know why the top and the bottom of the bounding box of
> the 'Flat' glyph, contrary to 'Sharp' and 'Natural', don't coincide
> (more or less) with the extrema of the glyph's outline?  A small

I can't remember any reason.

-- 
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen

PATCHES - Countdown for November 7th

[James]

Hello,

Here is the current patch countdown list. The next countdown will be on 
November 9th.


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


 Push:

!987 Use Grob_info_t<> to reduce dynamic casting - Dan Eble
https://gitlab.com/lilypond/lilypond/-/merge_requests/987

!986 release: don't modify our own environment - Han-Wen Nienhuys
https://gitlab.com/lilypond/lilypond/-/merge_requests/986


 Countdown:

!989 Fix \tuplet ... \set ... creating unexpected Staff - Dan Eble
https://gitlab.com/lilypond/lilypond/-/merge_requests/989

!988 python/musexpr.py tests fixed - Timofey
https://gitlab.com/lilypond/lilypond/-/merge_requests/988


 Review:

!992 Doc: insignificant follow-ups to “Various doc issues” (!872) - Jean 
Abou Samra

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

!990 Forbid C-style casts - Dan Eble
https://gitlab.com/lilypond/lilypond/-/merge_requests/990


 New:

!897 support cairo backend in lilypond-book - Han-Wen Nienhuys
https://gitlab.com/lilypond/lilypond/-/merge_requests/897


 Waiting:

!913 release: binaries with cairo - Han-Wen Nienhuys
https://gitlab.com/lilypond/lilypond/-/merge_requests/913


***


--
Regards

James






OpenPGP_0xAAC8D177A7F5A364.asc
Description: OpenPGP public key

Fwd: Manipulating instrument names and staff group names

[Kieren MacMillan]

Hello developers!

Thanks to Lukas and Jean, I’ve got a working LilyDev environment *and* have 
successfully done the GitLab branch/push/delete/etc. thing. In other words: For 
the first time in almost 20 years of Pond-ing, I’m ready to actively contribute 
code directly to the codebase!!

So… first bit of business, carried over from a -user thread:

> From: Jean Abou Samra mailto:j...@abou-samra.fr>>
> Subject: Re: Manipulating instrument names and staff group names
> Date: November 6, 2021 at 4:08:15 PM EDT
> To: Kieren MacMillan  >
> Cc: Lilypond-User Mailing List  >
> 
>> 2. Is there a tag/label on GitLab which identifies all and only those issues 
>> which don’t (or at least shouldn’t likely) require any C++ work?
> 
> There isn't. We had Frog in the past (good for beginners,
> not language-specific), but it was practically unused and
> the issues tagged were not actually so easy. Feel free to
> propose something on the devel list though.

My goal is to be able to search the issues by language(s) required [i.e., 
filter out anything that requires more than Scheme], sort the list by 
difficulty [ascending], and start hacking away from the top. In order to do 
this, I imagine we’d need tags/labels for both “language(s)” and “difficulty”. 
I don’t want to clutter up the label-space… but I offer that adding something 
would help beginners like me to feel comfortable jumping in.

1. “Language(s)”. While I would love it to be one tag per language involved 
(C++, Scheme, Python) — which would allow really granular searching/filtering — 
that might be overkill for everyone else. Maybe just one tag (e.g., 
“Scripting”) for things that don’t require recompilation?

2. “Difficulty”. Any multi-level (and thus multi-tag) system would be fine, as 
long as it’s at least three levels (e.g., Easy, Medium, Hard); optimal would 
be, say, a scale from 1 to 10 (e.g., Difficulty-1, Difficulty-2, etc.).

As a first “Frog Task”, I’d be happy to do a pass through all ~1,000 currently 
open issues and do my best to apply at least the right Language tag(s); I could 
also take a guess at the Difficulty level (but might, in many cases, be way off 
to start!) which more experienced developers could re-tag as necessary.

The obvious alternative to all of this is for me to have an assigned “mentor”, 
who would farm out “the right next task”, taking into account my skill set, the 
language(s) and difficulty of the issue, etc. But I don’t want to add ongoing 
work to anyone else’s plate, so I figured the suggestion above might be 
superior.

Thoughts?
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info 
‣ email: kie...@kierenmacmillan.info 

Re: cross-staff, broken Glissando

[Jean Abou Samra]

Le 07/11/2021 à 14:15, Thomas Morley a écrit :

Am So., 7. Nov. 2021 um 14:00 Uhr schrieb Jean Abou Samra :


That said,...
If I always compensate the right ending-point with (pseudo-code)
(ly:grob-relative-coordinate   Y)
Then the crosses are at those positions Mike's patch promises.

Really System? Isn't this going to create a
cyclic dependency between the stencil and
vertical alignment for non-cross-staff glissandi
via VerticalAxisGroup skylines? Off the top I would
think it should be a matter of correcting
reference points (see above).

I compile with recent master, so your added warnings for  cyclic
dependencies may pop up.
They don't.


Ah, because vertical alignment works via
ly:grob-translate-axis! and doesn't mark the
dependencies. Sigh.

Look at:

<<
\new Staff {
  c'1
}
\new Staff {
  \override Glissando.stencil =
#(lambda (grob)
   (ly:message "~s"
   (ly:grob-relative-coordinate
 grob
 (ly:grob-system grob)
 Y))
   (ly:line-spanner::print grob))
  c'1\glissando c''1
}
  >>

It prints "0.0". So there's no cyclic dependency
warned about, but it's not doing what you intend.
How could it? The glissando is part of the vertical
skylines of the VerticalAxisGroup. These are the
basis for vertical alignment. So you need the glissando's
stencil before you can take the Y coordinate of the
glissando relative to the system. Unless you have
a cross-staff glissando, because these aren't part
of the skylines -- but even then there is usually no
reason to take the root system and not just a refpoint
computed generically for both non-cross-staff
and cross-staff grobs.

For non-cross-staff Glissando it returns always zero, yes, for
cross-staff a certain value is found:

<<
\new Staff = "top" {
  c'1
}
\new Staff {
  \override Glissando.stencil =
#(lambda (grob)
   (ly:message "~s"
   (ly:grob-relative-coordinate
 grob
 (ly:grob-system grob)
 Y))
   (ly:line-spanner::print grob))
  c'1\glissando \change Staff = "top" c''1
}
  >>

-> -12.779

I tend to think: nice, let us always add this value, in any case it
only matters for cross-staff at all.

Why not?


Because if you set the vertical-skylines to ##f,
the value will suddenly get nonzero and the stencil
will change unexpectedly. It's not a good thing to
rely on callback order.

Best,
Jean

Re: cross-staff, broken Glissando

[Thomas Morley]

Am So., 7. Nov. 2021 um 14:00 Uhr schrieb Jean Abou Samra :

> >>> That said,...
> >>> If I always compensate the right ending-point with (pseudo-code)
> >>> (ly:grob-relative-coordinate   Y)
> >>> Then the crosses are at those positions Mike's patch promises.
> >> Really System? Isn't this going to create a
> >> cyclic dependency between the stencil and
> >> vertical alignment for non-cross-staff glissandi
> >> via VerticalAxisGroup skylines? Off the top I would
> >> think it should be a matter of correcting
> >> reference points (see above).
> > I compile with recent master, so your added warnings for  cyclic
> > dependencies may pop up.
> > They don't.
>
>
> Ah, because vertical alignment works via
> ly:grob-translate-axis! and doesn't mark the
> dependencies. Sigh.
>
> Look at:
>
> <<
>\new Staff {
>  c'1
>}
>\new Staff {
>  \override Glissando.stencil =
>#(lambda (grob)
>   (ly:message "~s"
>   (ly:grob-relative-coordinate
> grob
> (ly:grob-system grob)
> Y))
>   (ly:line-spanner::print grob))
>  c'1\glissando c''1
>}
>  >>
>
> It prints "0.0". So there's no cyclic dependency
> warned about, but it's not doing what you intend.
> How could it? The glissando is part of the vertical
> skylines of the VerticalAxisGroup. These are the
> basis for vertical alignment. So you need the glissando's
> stencil before you can take the Y coordinate of the
> glissando relative to the system. Unless you have
> a cross-staff glissando, because these aren't part
> of the skylines -- but even then there is usually no
> reason to take the root system and not just a refpoint
> computed generically for both non-cross-staff
> and cross-staff grobs.

For non-cross-staff Glissando it returns always zero, yes, for
cross-staff a certain value is found:

<<
   \new Staff = "top" {
 c'1
   }
   \new Staff {
 \override Glissando.stencil =
   #(lambda (grob)
  (ly:message "~s"
  (ly:grob-relative-coordinate
grob
(ly:grob-system grob)
Y))
  (ly:line-spanner::print grob))
 c'1\glissando \change Staff = "top" c''1
   }
 >>

-> -12.779

I tend to think: nice, let us always add this value, in any case it
only matters for cross-staff at all.

Why not?


Cheers,
  Harm

Re: cross-staff, broken Glissando

[Thomas Morley]

Am So., 7. Nov. 2021 um 13:47 Uhr schrieb Aaron Hill :
>
> On 2021-11-07 4:26 am, Jean Abou Samra wrote:
> > (Adding Aaron in CC.)
>
> Thanks, Jean.  I am subscribed to lily-devel, so I did see the thread.
>
>
> >> Alas, because my lack of C++-knowledge, I can't do it myself.
> >
> > You should learn C++ someday :-)
>
> As my work schedule allows, I would be willing to assist you both in
> breaking down C++ code into Scheme and providing some educational
> guidance to get you fishing on your own.
>
>
> -- Aaron Hill

Thanks, Aaron!
Once I find the time and energy I may come back to you.

Best.
  Harm

Re: cross-staff, broken Glissando

[Jean Abou Samra]

Le 07/11/2021 à 13:47, Thomas Morley a écrit :

Am So., 7. Nov. 2021 um 13:26 Uhr schrieb Jean Abou Samra :

(Adding Aaron in CC.)

Le 07/11/2021 à 12:39, Thomas Morley a écrit :

Hi,

commit 94860164493ab3a209986b0e3662ff7bd8958cb5
Author: Mike Solomon 
Date:   Mon Mar 28 10:58:29 2011 -0400

  Assures smooth transitions at glissando line breaks.

  When a glissando breaks over lines, the left point of the 
beginning-of-line
  glissando picks up on the y-axis where the right point of the end-of-line
  glissando ends.

is not true for cross-staff, broken Glissando.
For a down-pointing Glissando, ending in a lower Staff this "pick-up"
point is not matched.
For an up-pointing Glissando starting in a lower Staff the first part
is completely off. This is
https://gitlab.com/lilypond/lilypond/-/issues/4806
See attachment.


I get seemingly correct output in the issue's
example when adding

\override Glissando.simple-Y = ##f

So I'd start by investigating why simple-Y was
added in the first place.

Doing so fails for:
{
   \override Glissando.simple-Y = ##f
   e'''1.\glissando s2
   \break
   s2 \once \override NoteColumn.glissando-skip = ##t
   c''
   \break
   s2 bes
}
->
programming error: no note heads for the line spanner on neighbor
line? Confused.
continuing, cross fingers


Well yes, hence “investigate”.



While attempting to code stemmed Glissandi in scheme, there was a very
helpful discussion starting here:
https://lists.gnu.org/archive/html/lilypond-user/2021-10/msg00326.html
lastly arriving at
https://lists.gnu.org/archive/html/lilypond-user/2021-11/msg3.html
Basically I try to get start- and end-points of all kinds of
Glissandi, printing crosses there.
Many thanks to Aaron!

That said,...
If I always compensate the right ending-point with (pseudo-code)
(ly:grob-relative-coordinate   Y)
Then the crosses are at those positions Mike's patch promises.

Really System? Isn't this going to create a
cyclic dependency between the stencil and
vertical alignment for non-cross-staff glissandi
via VerticalAxisGroup skylines? Off the top I would
think it should be a matter of correcting
reference points (see above).

I compile with recent master, so your added warnings for  cyclic
dependencies may pop up.
They don't.



Ah, because vertical alignment works via
ly:grob-translate-axis! and doesn't mark the
dependencies. Sigh.

Look at:

<<
  \new Staff {
    c'1
  }
  \new Staff {
    \override Glissando.stencil =
  #(lambda (grob)
 (ly:message "~s"
 (ly:grob-relative-coordinate
   grob
   (ly:grob-system grob)
   Y))
 (ly:line-spanner::print grob))
    c'1\glissando c''1
  }
>>

It prints "0.0". So there's no cyclic dependency
warned about, but it's not doing what you intend.
How could it? The glissando is part of the vertical
skylines of the VerticalAxisGroup. These are the
basis for vertical alignment. So you need the glissando's
stencil before you can take the Y coordinate of the
glissando relative to the system. Unless you have
a cross-staff glissando, because these aren't part
of the skylines -- but even then there is usually no
reason to take the root system and not just a refpoint
computed generically for both non-cross-staff
and cross-staff grobs.


[Aaron]
As my work schedule allows, I would be willing to assist you both in 
breaking down C++ code into Scheme and providing some educational 
guidance to get you fishing on your own.


Thanks. I did learn some C++ (mostly by
try-and-fail while reading LilyPond source
code), but I will keep the proposal in
mind.

Best,
Jean

Re: cross-staff, broken Glissando

[Thomas Morley]

Am So., 7. Nov. 2021 um 13:26 Uhr schrieb Jean Abou Samra :
>
> (Adding Aaron in CC.)
>
> Le 07/11/2021 à 12:39, Thomas Morley a écrit :
> > Hi,
> >
> > commit 94860164493ab3a209986b0e3662ff7bd8958cb5
> > Author: Mike Solomon 
> > Date:   Mon Mar 28 10:58:29 2011 -0400
> >
> >  Assures smooth transitions at glissando line breaks.
> >
> >  When a glissando breaks over lines, the left point of the 
> > beginning-of-line
> >  glissando picks up on the y-axis where the right point of the 
> > end-of-line
> >  glissando ends.
> >
> > is not true for cross-staff, broken Glissando.
> > For a down-pointing Glissando, ending in a lower Staff this "pick-up"
> > point is not matched.
> > For an up-pointing Glissando starting in a lower Staff the first part
> > is completely off. This is
> > https://gitlab.com/lilypond/lilypond/-/issues/4806
> > See attachment.
>
>
> I get seemingly correct output in the issue's
> example when adding
>
>\override Glissando.simple-Y = ##f
>
> So I'd start by investigating why simple-Y was
> added in the first place.

Doing so fails for:
{
  \override Glissando.simple-Y = ##f
  e'''1.\glissando s2
  \break
  s2 \once \override NoteColumn.glissando-skip = ##t
  c''
  \break
  s2 bes
}
->
programming error: no note heads for the line spanner on neighbor
line? Confused.
continuing, cross fingers

>
>
> > While attempting to code stemmed Glissandi in scheme, there was a very
> > helpful discussion starting here:
> > https://lists.gnu.org/archive/html/lilypond-user/2021-10/msg00326.html
> > lastly arriving at
> > https://lists.gnu.org/archive/html/lilypond-user/2021-11/msg3.html
> > Basically I try to get start- and end-points of all kinds of
> > Glissandi, printing crosses there.
> > Many thanks to Aaron!
> >
> > That said,...
> > If I always compensate the right ending-point with (pseudo-code)
> > (ly:grob-relative-coordinate   Y)
> > Then the crosses are at those positions Mike's patch promises.
>
> Really System? Isn't this going to create a
> cyclic dependency between the stencil and
> vertical alignment for non-cross-staff glissandi
> via VerticalAxisGroup skylines? Off the top I would
> think it should be a matter of correcting
> reference points (see above).

I compile with recent master, so your added warnings for  cyclic
dependencies may pop up.
They don't.

>
>
> > I attach the new scheme-code and an image (with correct placed
> > crosses, but untouched default-stencil)
> >
> > Ofcourse it's trivial to extend this scheme-code to create
> > Glissando-stencil instead of those crosses.
> > Better ofcourse is fixing the problem in our source.
> >
> > Alas, because my lack of C++-knowledge, I can't do it myself.
>
> You should learn C++ someday :-)

Well, I often read people complaining about ununderstandable scheme...
For me it's more that cyptic C++.
Tbh, my lack of time and energy are the most importing reasons why I
did not really start that challenge.

>
> Best,
> Jean

Thanks,
  Harm

Re: cross-staff, broken Glissando

[Aaron Hill]

On 2021-11-07 4:26 am, Jean Abou Samra wrote:

(Adding Aaron in CC.)


Thanks, Jean.  I am subscribed to lily-devel, so I did see the thread.



Alas, because my lack of C++-knowledge, I can't do it myself.


You should learn C++ someday :-)


As my work schedule allows, I would be willing to assist you both in 
breaking down C++ code into Scheme and providing some educational 
guidance to get you fishing on your own.



-- Aaron Hill

Re: cross-staff, broken Glissando

[Jean Abou Samra]

(Adding Aaron in CC.)

Le 07/11/2021 à 12:39, Thomas Morley a écrit :

Hi,

commit 94860164493ab3a209986b0e3662ff7bd8958cb5
Author: Mike Solomon 
Date:   Mon Mar 28 10:58:29 2011 -0400

 Assures smooth transitions at glissando line breaks.

 When a glissando breaks over lines, the left point of the beginning-of-line
 glissando picks up on the y-axis where the right point of the end-of-line
 glissando ends.

is not true for cross-staff, broken Glissando.
For a down-pointing Glissando, ending in a lower Staff this "pick-up"
point is not matched.
For an up-pointing Glissando starting in a lower Staff the first part
is completely off. This is
https://gitlab.com/lilypond/lilypond/-/issues/4806
See attachment.



I get seemingly correct output in the issue's
example when adding

  \override Glissando.simple-Y = ##f

So I'd start by investigating why simple-Y was
added in the first place.



While attempting to code stemmed Glissandi in scheme, there was a very
helpful discussion starting here:
https://lists.gnu.org/archive/html/lilypond-user/2021-10/msg00326.html
lastly arriving at
https://lists.gnu.org/archive/html/lilypond-user/2021-11/msg3.html
Basically I try to get start- and end-points of all kinds of
Glissandi, printing crosses there.
Many thanks to Aaron!

That said,...
If I always compensate the right ending-point with (pseudo-code)
(ly:grob-relative-coordinate   Y)
Then the crosses are at those positions Mike's patch promises.


Really System? Isn't this going to create a
cyclic dependency between the stencil and
vertical alignment for non-cross-staff glissandi
via VerticalAxisGroup skylines? Off the top I would
think it should be a matter of correcting
reference points (see above).



I attach the new scheme-code and an image (with correct placed
crosses, but untouched default-stencil)

Ofcourse it's trivial to extend this scheme-code to create
Glissando-stencil instead of those crosses.
Better ofcourse is fixing the problem in our source.

Alas, because my lack of C++-knowledge, I can't do it myself.


You should learn C++ someday :-)

Best,
Jean

cross-staff, broken Glissando

[Thomas Morley]

Hi,

commit 94860164493ab3a209986b0e3662ff7bd8958cb5
Author: Mike Solomon 
Date:   Mon Mar 28 10:58:29 2011 -0400

Assures smooth transitions at glissando line breaks.

When a glissando breaks over lines, the left point of the beginning-of-line
glissando picks up on the y-axis where the right point of the end-of-line
glissando ends.

is not true for cross-staff, broken Glissando.
For a down-pointing Glissando, ending in a lower Staff this "pick-up"
point is not matched.
For an up-pointing Glissando starting in a lower Staff the first part
is completely off. This is
https://gitlab.com/lilypond/lilypond/-/issues/4806
See attachment.

While attempting to code stemmed Glissandi in scheme, there was a very
helpful discussion starting here:
https://lists.gnu.org/archive/html/lilypond-user/2021-10/msg00326.html
lastly arriving at
https://lists.gnu.org/archive/html/lilypond-user/2021-11/msg3.html
Basically I try to get start- and end-points of all kinds of
Glissandi, printing crosses there.
Many thanks to Aaron!

That said,...
If I always compensate the right ending-point with (pseudo-code)
(ly:grob-relative-coordinate   Y)
Then the crosses are at those positions Mike's patch promises.

I attach the new scheme-code and an image (with correct placed
crosses, but untouched default-stencil)

Ofcourse it's trivial to extend this scheme-code to create
Glissando-stencil instead of those crosses.
Better ofcourse is fixing the problem in our source.

Alas, because my lack of C++-knowledge, I can't do it myself.

Anyone up for it?

Thanks,
  Harm


start-end-gradient-06.pdf
Description: Adobe PDF document
\version "2.22.0" % "2.23.3"

%% rewritten by Aaron Hill, many thanks!
%% https://lists.gnu.org/archive/html/lilypond-user/2021-10/msg00354.html

%% Comments/TODOs/amendments by Harm

\paper {
  indent = 0
  ragged-right = ##f
  line-width = 120
}

\layout {
  \context {
\Voice
\override Glissando.layer = 1000
\override Glissando.bound-details.left.padding =  0
\override Glissando.bound-details.right.padding = 0
\override Glissando.breakable = ##t
  }
}

%% cross stencil
#(define*
   (make-cross-stencil coords #:optional (thick 0.1) (sz 0.2))
   (ly:stencil-add
 (make-line-stencil
   thick
   (- (car coords) sz)
   (- (cdr coords) sz)
   (+ (car coords) sz)
   (+ (cdr coords) sz))
 (make-line-stencil
   thick
   (- (car coords) sz)
   (+ (cdr coords) sz)
   (+ (car coords) sz)
   (- (cdr coords) sz

%% glissando stencil
#(define glissando-stencil-proc (lambda (grob) (ly:line-spanner::print grob)))

%% get start/end points
#(define gliss-data
  (lambda (grob)
(let* ((simple-y? (and (ly:grob-property grob 'simple-Y)
   (not (ly:grob-property grob 'cross-staff
   (lbi (ly:grob-property grob 'left-bound-info))
   (rbi (ly:grob-property grob 'right-bound-info))
;;;
;; TODO (1)
;;;
;;  Common refpoint of the spanner-bounds is already grob System
;;  Why searching again, doesn't it will return grob System again?
;;  Is there any ly-counter-example?
;;  See the test-code below inside `pretty-print'
   (common-x (ly:grob-common-refpoint grob
  (ly:grob-common-refpoint
   (ly:spanner-bound grob LEFT)
   (ly:spanner-bound grob RIGHT) X) X))
   (scaling (magstep (ly:grob-property grob 'font-size 0)))
   (left-padding (ly:assoc-get 'padding lbi 0))
   (left-stencil (ly:assoc-get 'stencil lbi #f))
   (left-common-y (ly:assoc-get 'common-y lbi grob))
   (right-padding (ly:assoc-get 'padding rbi 0))
   (right-stencil (ly:assoc-get 'stencil rbi #f))
   (right-common-y (ly:assoc-get 'common-y rbi grob))
   (common-y (ly:grob-common-refpoint left-common-y right-common-y Y))
   (normalized-endpoints
 (ly:grob-property grob 'normalized-endpoints '(0 . 1)))
   (span-left-x (ly:assoc-get 'X lbi 0))
   (span-left-y (ly:assoc-get 'Y lbi 0))
   (span-right-x (ly:assoc-get 'X rbi 0))
   (span-right-y (ly:assoc-get 'Y rbi 0))
   (original-grob (ly:grob-original grob))
   (siblings (ly:spanner-broken-into original-grob)))

  ;; Take relative coords in X/Y direction into account.
  ;; This needs to come before other modifications of x/y values!
  ;; Especially `dy-right' is important for cross-staff spanners
  (let* ((dx (ly:grob-relative-coordinate grob common-x X))
;;;
;; TODO (2)
;;;
;;  Do we need to calculate `dy' at all?
;;  Will (ly:grob-relative-coordinate grob common-y Y) ever be not zero, if
;;  grob and common-Y are equal?
;;  Is it possible at all they are ever unequal? ly-counter-example?!
 (dy (if simple-y?
 0
 (ly:grob-relative-coordinate grob common-y Y)))
;;;
;; TODO (1)
;;;
;; Why call 

strange bbox of 'flat' glyph

[Werner LEMBERG]

Does anybody know why the top and the bottom of the bounding box of
the 'Flat' glyph, contrary to 'Sharp' and 'Natural', don't coincide
(more or less) with the extrema of the glyph's outline?  A small
overshoot outside of the box make sense (although Feta doesn't handle
this consistently), but the opposite, that is, additional whitespace
within the box, looks rather pointless...

I think the whole bbox should be shifted down.

Note that accidentals with arrows have a similar problem: the bounding
box side near the tip of the arrow should be closer.


Werner