how to change extents of a grob?

[Werner LEMBERG]

Dear LilyPonders,


I can get the extents of a grob with `ly:grob-extent`.  What is the
corresponding Scheme function to set the extents?

Or to ask in a different way: At the time when properties are
processed and you have to manipulate stencils, changing the stencil of
a grob doesn't change the extents of this grob, AFAICS.  How can I
adjust the extents at this stage to fit the dimensions of the stencil
(even if LilyPond no longer needs and/or uses the values for
positioning)?


Werner

Re: Ledger line sizes - a question from simple curiosity

[Jean Abou Samra]

Hello Paul,

One minor point: when asking a new question, please start a new thread
in your mail client. Replying to an existing thread looks like it will
do the trick if you change the subject, but the email actually contains
internal headers that make it appear in the same thread for recipients
(you can observe this in the archives at
https://lists.gnu.org/archive/html/lilypond-user/2022-04/threads.html).

Le 12/04/2022 à 01:15, Paul Hodges a écrit :
When specifying the thickness of ledger lines in LilyPond, one 
specifies not one but two multipliers, so that the result is 
proportionate to both staff line thickness and staff spacing.  E.g. 
(from the manual):

    \override StaffSymbol.ledger-line-thickness = #'(0.5 . 0.4)
For my own use I've simply used the first number to specify what I 
want and made the second 0.0 which seems to do fine.


I'm just wondering why a single proportion was considered insufficient...



This property is not just for user tweaks, but more importantly
allows LilyPond to provide a default. The default is '(1.0 . 0.1),
which makes the ledger thickness scale with both staff space
and line thickness. You can change the staff space and line thickness
independently, and the ledger line thickness will respond to both.

Best,
Jean

Re: bug in magnetic snapping lyrics engraver

[Werner LEMBERG]

>> This is ingenious :-) Thanks *a lot* for this solution.  In my
>> tests it seems to work fine
>
> You're welcome.

I spoke too soon :-) There is a problem with ligatures at the syllable
boundaries (and kerning).  While this can be considered an ugliness in
languages based on the latin script, it might be a real showstopper
for non-latin scripts like Devanagari.

In other words, it is not sufficient to shift the right syllable in a
syllable pair to the left.  Instead, the following should be done.

* Concatenate the text/markup of the left syllable with the right
  text/markup *on the input level* (for example, by using
  `make-concat-markup`) so that Pango/Cairo can handle all affected
  syllables together.

* Store the result in the right syllable and adjust the horizontal
  position.  This allows accumulation for multi-syllable words.

* Set the text/markup in the left syllable to empty.

I tried to implement this, but I failed.  In this replacement code

```
(when (< delta threshold)
  (let ((lt (ly:grob-property left-text 'text))
(rt (ly:grob-property grob 'text)))
(begin
  (ly:grob-set-property!
   left-text 'text empty-markup)
  (ly:grob-set-property!
   grob 'text (make-concat-markup (list lt rt)))
```

the `ly:grob-set-property!` calls have zero effect.  I guess that at
this point of time it is too late for modifying properties, and the
grobs have already been converted to stencils.

Maybe this is the reason for the more complicated approach in David's
original approach?  Do you know a quick fix for your code?


Werner

Re: Custom keypad for streamlining LilyPond input - thoughts?

[Karlin High]

On 4/7/2022 7:34 PM, Nikolai Hedler wrote:

Has something like this been done before for LilyPond?


I am reminded of Denemo.



"
Denemo allows you to use the numeric keypad as a kind of rhythm 
instrument – you play in a phrase or two of the music using the number 
keys to indicate the note durations. Audible feedback lets you hear what 
you have entered; playing the phrase a second time on a real instrument 
adds the pitches to the rhythm.

"
--
Karlin High
Missouri, USA

Re: Custom keypad for streamlining LilyPond input - thoughts?

[Jon Arnold]

You might check out Companion , which is an
open source alternative to the stream deck software. It can run on a Stream
Deck or any touch interface that can access the web UI over a network (like
a smartphone).
You can make graphic icons for the buttons.

For what it's worth I used to use a program that would convert some keys on
my MIDI keyboard to things like bar checks, rests, rhythmic values, etc.
Some examples:
https://github.com/taerin-markman/midi2key
https://midikey2key.de/ (Windows only)

On Wed, Apr 13, 2022 at 12:16 PM Nikolai Hedler  wrote:

> After some research, I found some discussion of a software tool
> Nicolas built that had a similar intention; from what I can tell, his
> strategy was to use this software to interpret input from a standard
> keyboard as LilyPond functions, rather than using separate hardware.
> The obvious advantage of his approach is that no additional hardware
> is required; on the other hand, it is only compatible with the editing
> software it was written for and requires the user to learn (and, I
> believe, memorize) the key "map" or use a "cheat sheet" of some sort.
> Unfortunately, it also appears that it's no longer available...
>
> - Nikolai
>
> On Fri, Apr 8, 2022 at 5:07 AM Jean Abou Samra  wrote:
> >
> >
> >
> > Le 08/04/2022 à 02:34, Nikolai Hedler a écrit :
> > > 3. Has something like this been done before for LilyPond?
> >
> > You might be interested in discussing this with Nicolas Sceaux, who did
> > something similar if I recall correctly.
> >
> > https://editions-nicolas-sceaux.fr/
> >
> > Best,
> > Jean
> >
>
>

Re: Custom keypad for streamlining LilyPond input - thoughts?

[Nikolai Hedler]

After some research, I found some discussion of a software tool
Nicolas built that had a similar intention; from what I can tell, his
strategy was to use this software to interpret input from a standard
keyboard as LilyPond functions, rather than using separate hardware.
The obvious advantage of his approach is that no additional hardware
is required; on the other hand, it is only compatible with the editing
software it was written for and requires the user to learn (and, I
believe, memorize) the key "map" or use a "cheat sheet" of some sort.
Unfortunately, it also appears that it's no longer available...

- Nikolai

On Fri, Apr 8, 2022 at 5:07 AM Jean Abou Samra  wrote:
>
>
>
> Le 08/04/2022 à 02:34, Nikolai Hedler a écrit :
> > 3. Has something like this been done before for LilyPond?
>
> You might be interested in discussing this with Nicolas Sceaux, who did
> something similar if I recall correctly.
>
> https://editions-nicolas-sceaux.fr/
>
> Best,
> Jean
>

Re: DurationLine avoiding RehearsalMarks

[Jean Abou Samra]

Le 13/04/2022 à 17:57, Jean Abou Samra a écrit :

Le 13/04/2022 à 17:03, Thomas Morley a écrit :
Am Di., 12. Apr. 2022 um 11:54 Uhr schrieb Jean Abou Samra 
:

Le 12/04/2022 à 11:16, Thomas Morley a écrit :

[...]

In many details DurationLine was tailored after Glissando and
Glissando _is_ effected by the breathing sign.

[...]


Well, if the goal is to have DurationLine similar to Glissando,
how about reusing line-spanner-interface code? I haven't reviewed
the code very thoroughly, but I assumed there was a difference
warranting a different code path. If you put
ly:line-spanner::calc-{left,right}-bound-info in
DurationLine.{left,righ}-bound-info, that gives you X values for free
in the bound info properties. Would that solve the problem?

If I go for ly:line-spanner::calc-{left,right}-bound-info then

\layout {
    \context {
  \Voice
  \consists Duration_line_engraver
    }
}

{ b1\- }

errors with
 "programming error: extremal broken spanner's bound has no parent
vertical axis group"
More complex examples may add:
 "programming error: bound item has no parent vertical axis group"
Both coming from `ly:line-spanner::calc-right-bound-info' based upon
`Line_spanner::calc_bound_info' in /lily/line-spanner.cc

As a mere user I'd say: "Nice error-message, but why should I care...?"

As a programmer, I doubt the example above can be made working with
ly:line-spanner::calc-right-bound-info.
At least, I don't know how.




Oh, I'm sorry, I missed that detail of my own code. A DurationLine will
always be horizontal, thus you can and should use
ly:horizontal-line-spanner::calc-{left,right}-bound-info (with 
'horizontal'

in the name).  The difference is that the functions without 'horizontal'
try to compute vertical positions. This falls apart here, for 
understandable

reasons: the right bound of your DurationLine is a NonMusicalPaperColumn,
so how would one tell where the line should end vertically?




If there is a reason to keep DurationLine calculations separate, you
could go for using ly:generic-bound-extent. The line-spanner-interface
uses its C++ equivalent internally.

Didn't try this so far.
But the description:
"Function: ly:generic-bound-extent grob common
Determine the extent of grob relative to common along the x axis,
finding its extent as a bound when it a has bound-alignment-interfaces
property list set and otherwise the full extent."
is kryptic to say the least.



It's in a sense similar to the (so far nonexistent/C++-only) function
ly:axis-group-interface::staff-extent we discussed, except that it
doesn't filter grobs for having a certain grob in their ancestry,
but for having one of certain interfaces, captured in the
bound-alignment-interfaces property. E.g., for NonMusicalPaperColumn,
this property defaults to '(break-alignment-interface), which means
that

  (ly:generic-bound-extent [NonMusicalPaperColumn] [System])

gives you the extent of the elements of the NonMusicalPaperColumn
that are part of a BreakAlignment, i.e. grobs with the 
break-aligned-interface,

like BarLine, KeySignature, etc., but not those that are outside
of a BreakAlignment, i.e. those having the break-*aligned*-interface


And of course that one should have been 'alignable' ...



(tricky difference, I know, I always need to look up which is 'alignable'
and which is 'aligned' ...), namely MetronomeMark, RehearsalMark, ...
There are some slightly fussy details, but that's the idea. Is that
clear?

HTH,
Jean

Re: DurationLine avoiding RehearsalMarks

[Jean Abou Samra]

Le 13/04/2022 à 17:03, Thomas Morley a écrit :

Am Di., 12. Apr. 2022 um 11:54 Uhr schrieb Jean Abou Samra :

Le 12/04/2022 à 11:16, Thomas Morley a écrit :

[...]

In many details DurationLine was tailored after Glissando and
Glissando _is_ effected by the breathing sign.

[...]


Well, if the goal is to have DurationLine similar to Glissando,
how about reusing line-spanner-interface code? I haven't reviewed
the code very thoroughly, but I assumed there was a difference
warranting a different code path. If you put
ly:line-spanner::calc-{left,right}-bound-info in
DurationLine.{left,righ}-bound-info, that gives you X values for free
in the bound info properties. Would that solve the problem?

If I go for ly:line-spanner::calc-{left,right}-bound-info then

\layout {
\context {
  \Voice
  \consists Duration_line_engraver
}
}

{ b1\- }

errors with
 "programming error: extremal broken spanner's bound has no parent
vertical axis group"
More complex examples may add:
 "programming error: bound item has no parent vertical axis group"
Both coming from `ly:line-spanner::calc-right-bound-info' based upon
`Line_spanner::calc_bound_info' in /lily/line-spanner.cc

As a mere user I'd say: "Nice error-message, but why should I care...?"

As a programmer, I doubt the example above can be made working with
ly:line-spanner::calc-right-bound-info.
At least, I don't know how.




Oh, I'm sorry, I missed that detail of my own code. A DurationLine will
always be horizontal, thus you can and should use
ly:horizontal-line-spanner::calc-{left,right}-bound-info (with 'horizontal'
in the name).  The difference is that the functions without 'horizontal'
try to compute vertical positions. This falls apart here, for understandable
reasons: the right bound of your DurationLine is a NonMusicalPaperColumn,
so how would one tell where the line should end vertically?




If there is a reason to keep DurationLine calculations separate, you
could go for using ly:generic-bound-extent. The line-spanner-interface
uses its C++ equivalent internally.

Didn't try this so far.
But the description:
"Function: ly:generic-bound-extent grob common
Determine the extent of grob relative to common along the x axis,
finding its extent as a bound when it a has bound-alignment-interfaces
property list set and otherwise the full extent."
is kryptic to say the least.



It's in a sense similar to the (so far nonexistent/C++-only) function
ly:axis-group-interface::staff-extent we discussed, except that it
doesn't filter grobs for having a certain grob in their ancestry,
but for having one of certain interfaces, captured in the
bound-alignment-interfaces property. E.g., for NonMusicalPaperColumn,
this property defaults to '(break-alignment-interface), which means
that

  (ly:generic-bound-extent [NonMusicalPaperColumn] [System])

gives you the extent of the elements of the NonMusicalPaperColumn
that are part of a BreakAlignment, i.e. grobs with the 
break-aligned-interface,

like BarLine, KeySignature, etc., but not those that are outside
of a BreakAlignment, i.e. those having the break-*aligned*-interface
(tricky difference, I know, I always need to look up which is 'alignable'
and which is 'aligned' ...), namely MetronomeMark, RehearsalMark, ...
There are some slightly fussy details, but that's the idea. Is that
clear?

HTH,
Jean

Re: DurationLine avoiding RehearsalMarks

[Thomas Morley]

Am Di., 12. Apr. 2022 um 11:54 Uhr schrieb Jean Abou Samra :
> Le 12/04/2022 à 11:16, Thomas Morley a écrit :
[...]
> > In many details DurationLine was tailored after Glissando and
> > Glissando _is_ effected by the breathing sign.
[...]

> Well, if the goal is to have DurationLine similar to Glissando,
> how about reusing line-spanner-interface code? I haven't reviewed
> the code very thoroughly, but I assumed there was a difference
> warranting a different code path. If you put
> ly:line-spanner::calc-{left,right}-bound-info in
> DurationLine.{left,righ}-bound-info, that gives you X values for free
> in the bound info properties. Would that solve the problem?

If I go for ly:line-spanner::calc-{left,right}-bound-info then

\layout {
   \context {
 \Voice
 \consists Duration_line_engraver
   }
}

{ b1\- }

errors with
"programming error: extremal broken spanner's bound has no parent
vertical axis group"
More complex examples may add:
"programming error: bound item has no parent vertical axis group"
Both coming from `ly:line-spanner::calc-right-bound-info' based upon
`Line_spanner::calc_bound_info' in /lily/line-spanner.cc

As a mere user I'd say: "Nice error-message, but why should I care...?"

As a programmer, I doubt the example above can be made working with
ly:line-spanner::calc-right-bound-info.
At least, I don't know how.

> If there is a reason to keep DurationLine calculations separate, you
> could go for using ly:generic-bound-extent. The line-spanner-interface
> uses its C++ equivalent internally.

Didn't try this so far.
But the description:
"Function: ly:generic-bound-extent grob common
Determine the extent of grob relative to common along the x axis,
finding its extent as a bound when it a has bound-alignment-interfaces
property list set and otherwise the full extent."
is kryptic to say the least.

Thanks,
  Harm

Re: Musical questions

[Jacques Menu]

Thanks Hans!

JM

> Le 13 avr. 2022 à 10:10, Hans Åberg  a écrit :
> 
> 
>> On 11 Apr 2022, at 16:16, Jacques Menu  wrote:
>> 
>> Hello folks,
>> 
>> In Mendelssohn Bartholdy’s Ave maris stella, the soprano has this:
>> 
>> 
>> 
>> With LilyPond, I can obtain the ad lib cue notes with smaller note heads in 
>> a cadenza. Is that my best bet?
>> 
>> Also, what is the musicial signification of the ligatures above the staff?
> 
> Another score does not have them, so it might be (incorrect) phrase marks 
> added by the editor.
> 

Re: Musical questions

[Hans Åberg]

> On 11 Apr 2022, at 16:16, Jacques Menu  wrote:
> 
> Hello folks,
> 
> In Mendelssohn Bartholdy’s Ave maris stella, the soprano has this:
> 
> 
> 
> With LilyPond, I can obtain the ad lib cue notes with smaller note heads in a 
> cadenza. Is that my best bet?
> 
> Also, what is the musicial signification of the ligatures above the staff?

Another score does not have them, so it might be (incorrect) phrase marks added 
by the editor.

Re: Location of guile socket Linux

[Kenneth Flak]

Jean Abou Samra, Apr 12, 2022 at 20:41:
> Hi Kenneth,
Thanks a lot Jean! I suppose I'll compile lilypond myself as soon as I get
around to it. Nice solution :-)

K