Re: Beam not breaking

[Kieren MacMillan]

Hi all,

Never mind… I figured it out.

Now on to the bug (?) I actually wanted to ask about.  =)

\version "2.23.4"
{
  \time 1/4
  \override Beam.breakable = ##t
  \override Beam.positions = #'(4 . 3)
  c'8 8[ \break 8] 8
}

Is that expected output?

Thanks,
Kieren.

Beam not breaking

[Kieren MacMillan]

Hi all,

Why is the Beam not breaking here?

\version "2.23.4"
{ \time 1/4 \override Beam.breakable = ##t c'8[ \break 8] }

Thanks,
Kieren.

Re: Updating alists

[David Kastrup]

Jean Abou Samra  writes:

> Le 30/12/2021 à 23:04, Lukas-Fabian Moser a écrit :
>> Hi Jean,
>>
>>>
>>> Both of these cases seem to work the same as in
>>> current versions if I do
>>>
>>> [...]
>>>
>>>  SCM
>>>  assq_tail (SCM key, SCM alist, SCM based_on = SCM_EOL)
>>>  {
>>> -  for (SCM p = alist; !scm_is_eq (p, based_on); p = scm_cdr (p))
>>> +  for (SCM p = alist; scm_is_pair (p) && scm_is_pair (scm_car (p))
>>> && !scm_is_eq (p, based_on); p = scm_cdr (p))
>>>  {
>>>    if (scm_is_eq (scm_caar (p), key))
>>>  return p;
>>
>> Thanks! This seems to be a sensible precaution anyway, as it only
>> changes a certain crash into returning #f. So it might be sensible
>> to make this change anyway?
>
>
> Turns out that you can already trigger the
> crash in current versions with
>
> \version "2.23.5"
>
> x = 0
> x.y.z = 1

That's not what I call a crash.  That triggers a Scheme error.

lilypond /tmp/bab.ly
GNU LilyPond 2.23.5 (running Guile 1.8)
Processing `/tmp/bab.ly'
Parsing.../usr/local/share/lilypond/2.23.5/scm/lily/lily.scm:978:21: In 
procedure ly:parse-file in expression (ly:parse-file file-name):
/usr/local/share/lilypond/2.23.5/scm/lily/lily.scm:978:21: Wrong type 
(expecting pair): 0

And frankly, I don't see something wrong with that.  Could use a better
error locator, sure.  But it's not the same as a core dump.

-- 
David Kastrup

Re: Updating alists

[David Kastrup]

Lukas-Fabian Moser  writes:

> Hi Jean,
>
>>
>> Both of these cases seem to work the same as in
>> current versions if I do
>>
>> [...]
>>
>>  SCM
>>  assq_tail (SCM key, SCM alist, SCM based_on = SCM_EOL)
>>  {
>> -  for (SCM p = alist; !scm_is_eq (p, based_on); p = scm_cdr (p))
>> +  for (SCM p = alist; scm_is_pair (p) && scm_is_pair (scm_car (p))
>> && !scm_is_eq (p, based_on); p = scm_cdr (p))
>>  {
>>    if (scm_is_eq (scm_caar (p), key))
>>  return p;
>
> Thanks! This seems to be a sensible precaution anyway, as it only
> changes a certain crash into returning #f. So it might be sensible to
> make this change anyway?

Uh what?  assq_tail is exclusively used on internal data structures.
There is no "certain crash" without internal data structures being
corrupted and it seems counterproductive to expend additional
performance in order to hide that internal data structures have been
corrupted.

> I'm a bit surprised about the remark in the code stating that the
> choice not to coalesce multiple override's was made to save the cost
> of detecting them, as it does not seem to be a code path used heavily
> at all.

Overrides of subproperties are used pretty extensively in some newer
code.

Maybe it would make sense to check where code is being used before
trying to change it?

-- 
David Kastrup

Re: Updating alists (was: Tenuto marking too close to note)

[Jean Abou Samra]

Le 30/12/2021 à 23:04, Lukas-Fabian Moser a écrit :

Hi Jean,



Both of these cases seem to work the same as in
current versions if I do

[...]

 SCM
 assq_tail (SCM key, SCM alist, SCM based_on = SCM_EOL)
 {
-  for (SCM p = alist; !scm_is_eq (p, based_on); p = scm_cdr (p))
+  for (SCM p = alist; scm_is_pair (p) && scm_is_pair (scm_car (p)) 
&& !scm_is_eq (p, based_on); p = scm_cdr (p))

 {
   if (scm_is_eq (scm_caar (p), key))
 return p;


Thanks! This seems to be a sensible precaution anyway, as it only 
changes a certain crash into returning #f. So it might be sensible to 
make this change anyway?



Turns out that you can already trigger the
crash in current versions with

\version "2.23.5"

x = 0
x.y.z = 1


So, yes, it might be sensible.



But I really don't have deep enough an insight on this code
to judge, sorry.


I'm a bit surprised about the remark in the code stating that the 
choice not to coalesce multiple override's was made to save the cost 
of detecting them, as it does not seem to be a code path used heavily 
at all.



As someone with usually bad intuition about
performance, I would just benchmark the
change.

Best,
Jean

Re: Updating alists (was: Tenuto marking too close to note)

[Lukas-Fabian Moser]

Hi Jean,



Both of these cases seem to work the same as in
current versions if I do

[...]

 SCM
 assq_tail (SCM key, SCM alist, SCM based_on = SCM_EOL)
 {
-  for (SCM p = alist; !scm_is_eq (p, based_on); p = scm_cdr (p))
+  for (SCM p = alist; scm_is_pair (p) && scm_is_pair (scm_car (p)) && 
!scm_is_eq (p, based_on); p = scm_cdr (p))

 {
   if (scm_is_eq (scm_caar (p), key))
 return p;


Thanks! This seems to be a sensible precaution anyway, as it only 
changes a certain crash into returning #f. So it might be sensible to 
make this change anyway?



But I really don't have deep enough an insight on this code
to judge, sorry.


I'm a bit surprised about the remark in the code stating that the choice 
not to coalesce multiple override's was made to save the cost of 
detecting them, as it does not seem to be a code path used heavily at all.


Lukas

Re: Updating alists

[Jean Abou Samra]

Le 30/12/2021 à 22:30, David Kastrup a écrit :

An empty list does not have a last cdr.




Of course. Thanks.

Re: Updating alists

[David Kastrup]

Jean Abou Samra  writes:

> Le 30/12/2021 à 12:36, Lukas-Fabian Moser a écrit :
>> It's much worse than that: It's not the first time _I've_ been
>> tripped up by this (previously it was with sort!). I'll just have to
>> write 100 copies of
>>
>> "The exclamation mark in something! does not mean the function is
>> guaranteed to make the desired change in-place."
>>
>> on my wall.
>
>
> :-)
>
> For assoc-set! and friends, I actually wonder why this
> is since when the function has exhausted the alist in
> its search for a matching pair, it could well set the
> last cdr to add the new pair at the end.

An empty list does not have a last cdr.

-- 
David Kastrup

Re: Making a Lilypond donation (again)

[eBooks]

I’ve contributed to David’s efforts in the past. I think this is an excellent 
idea.

> On Dec 30, 2021, at 2:23 PM, Ivan Kuznetsov  
> wrote:
> 
> I would like to make a onetime donation toward
> the development of Lilypond.
> 
> I have searched the archives of this list, and
> over and over again, it has been stated that
> there is no clear way to do this.
> 
> At https://www.gnu.org/software/, Lilypond
> is listed as a "current GNU package", but
> can one donate money to GNU/Free Software
> Foundation with the money being earmarked
> specifically for Lilypond development ?
> 
> A few places, it is suggested that since
> David Kastrup  is currently
> the only full time developer of Lilypond
> (is this still true?) and since he has
> asked for denotations in the past, that
> sending a donation directly to Mr. Kastrup
> is one way to go.  Is that what people
> are doing?
> 
> Thank you for your help.
> 

Making a Lilypond donation (again)

[Ivan Kuznetsov]

I would like to make a onetime donation toward
the development of Lilypond.

I have searched the archives of this list, and
over and over again, it has been stated that
there is no clear way to do this.

At https://www.gnu.org/software/, Lilypond
is listed as a "current GNU package", but
can one donate money to GNU/Free Software
Foundation with the money being earmarked
specifically for Lilypond development ?

A few places, it is suggested that since
David Kastrup  is currently
the only full time developer of Lilypond
(is this still true?) and since he has
asked for denotations in the past, that
sending a donation directly to Mr. Kastrup
is one way to go.  Is that what people
are doing?

Thank you for your help.

Re: Updating alists (was: Tenuto marking too close to note)

[Jean Abou Samra]

Le 30/12/2021 à 12:36, Lukas-Fabian Moser a écrit :
It's much worse than that: It's not the first time _I've_ been tripped 
up by this (previously it was with sort!). I'll just have to write 100 
copies of


"The exclamation mark in something! does not mean the function is 
guaranteed to make the desired change in-place."


on my wall.



:-)

For assoc-set! and friends, I actually wonder why this
is since when the function has exhausted the alist in
its search for a matching pair, it could well set the
last cdr to add the new pair at the end. That would make
the interface somewhat more convenient. But libguile/alist.c
writes them as, for example,

SCM_DEFINE (scm_assq_set_x, "assq-set!", 3, 0, 0,
    (SCM alist, SCM key, SCM val),
[...]
{
  SCM handle;

  handle = scm_sloppy_assq (key, alist);
  if (scm_is_pair (handle))
    {
  scm_set_cdr_x (handle, val);
  return alist;
    }
  else
    return scm_acons (key, val, alist);
}

which conses the new pair at the beginning instead.


But more seriously: Thanks! And also for advertising ice-9 match - 
it's really a different coding style from the more commonly seen (if 
pair? ...) constructs.



I have been really liking pattern matching since
I started to more seriously program in OCaml. It
clarifies code by showing what the programmer thinks
in a visual way. More and more languages support
it in some form these days, e.g. Rust has it (OK,
ML-inspired language), and more recently Python gained
it (with one small syntax suggestion from yours
truly).



* * *

Another question: With the (hopefully) upcoming changes in the 
script-alist structure (using symbols instead of strings as keys), 
we're quite close to being able to simply do


\version "2.23.6"

myScripts = \default-script-alist
myScripts.tenuto.padding = 5

\layout {
  \context {
    \Score
    scriptDefinitions = #myScripts
  }
}

{
  a--
}

(One might also skip defining a new variable and instead change 
default-script-alist directly, but it has to be re-read in a \layout 
block anyway.)


But at the moment, this does not work because the changed key is not 
being replaced in the alist but added at the beginning. If I see 
things correctly, this is the remark about "not coalescing multiple 
overrides of the same property" in nested_property_alist(...) in 
ily/nested-property.cc.


Re-enabling the outcommented branch in that function (taking care to 
use assoc_tail instead of assq_tail and correcting the order of 
arguments to that call) basically works, but there's trouble ahead in 
the case where one does


variable.entry = 15
variable.entry.first = #'i-ve-decided-i-want-a-sublist-after-all

which unfortunately is what happens if one \override's a nested 
property given by a callback (e.g. 
VerticalAxisGroup.staff-staff-spacing), or worse


variable.entry = #'(some . pair)
variable.entry.first = #'i-ve-decided-i-want-a-sublist-after-all

since an entry that is a pair looks like the beginning of a sublist.



Both of these cases seem to work the same as in
current versions if I do

diff --git a/lily/nested-property.cc b/lily/nested-property.cc
index 9c158561b1..69d8219f2a 100644
--- a/lily/nested-property.cc
+++ b/lily/nested-property.cc
@@ -49,7 +49,7 @@ partial_list_copy (SCM lst, SCM tail, SCM newtail)
 SCM
 assq_tail (SCM key, SCM alist, SCM based_on = SCM_EOL)
 {
-  for (SCM p = alist; !scm_is_eq (p, based_on); p = scm_cdr (p))
+  for (SCM p = alist; scm_is_pair (p) && scm_is_pair (scm_car (p)) && 
!scm_is_eq (p, based_on); p = scm_cdr (p))

 {
   if (scm_is_eq (scm_caar (p), key))
 return p;
@@ -60,7 +60,7 @@ assq_tail (SCM key, SCM alist, SCM based_on = SCM_EOL)
 SCM
 assv_tail (SCM key, SCM alist, SCM based_on = SCM_EOL)
 {
-  for (SCM p = alist; !scm_is_eq (p, based_on); p = scm_cdr (p))
+  for (SCM p = alist; scm_is_pair (p) && scm_is_pair (scm_car (p)) && 
!scm_is_eq (p, based_on); p = scm_cdr (p))

 {
   if (scm_is_true (scm_eqv_p (scm_caar (p), key)))
 return p;
@@ -75,7 +75,7 @@ assoc_tail (SCM key, SCM alist, SCM based_on = SCM_EOL)
 return assq_tail (key, alist, based_on);
   if (scm_is_number (key) || scm_is_true (scm_char_p (key)))
 return assv_tail (key, alist, based_on);
-  for (SCM p = alist; !scm_is_eq (p, based_on); p = scm_cdr (p))
+  for (SCM p = alist; scm_is_pair (p) && scm_is_pair (scm_car (p)) && 
!scm_is_eq (p, based_on); p = scm_cdr (p))

 {
   if (ly_is_equal (scm_caar (p), key))
 return p;
@@ -156,12 +156,12 @@ nested_property_alist (SCM alist, SCM prop_path, 
SCM value)

 }
   // Outcommented code would coalesce multiple overrides of the same
   // property
-#if 0
-  SCM where = assq_tail (alist, key);
+  //#if 0
+  SCM where = assoc_tail (key, alist);
   if (scm_is_true (where))
 return scm_acons (key, value,
   partial_list_copy (alist, where, scm_cdr (where)));
-#endif
+  //#endif
   return scm_acons (key, value, alist);
 }


But I really don't have deep enough a

Re: 2.23.5 and poly-mark-engraver https://lsr.di.unimi.it/LSR/Item?id=976

[Dan Eble]

On Dec 30, 2021, at 14:24, Lukas-Fabian Moser  wrote:
> 
> Hi Joel,
> 
>> Several of the scores used poly-mark-engraver from 
>>  (see also 
>> ), 
>> and this now fails with
>> 
>>> fatal error: cannot find music object: MarkEvent
>> 
>> (Minimal example below signature; the demonstration included in 
>>  also fails the same way.)
>> 
>> This is both a bug-report if anyone’s maintaining the snippet, and a 
>> question whether there’s now a better way to write da capo, al segno, and 
>> other coda-like repeats.
> 
> Indeed there is. There's heavy ongoing (or by now maybe even finished?) work 
> by Dan Eble on precisely this group of features.

MarkEvent was split into RehearsalMarkEvent and AdHocMarkEvent in the summer of 
2021.  You might try replacing MarkEvent with AdHocMarkEvent and see whether it 
works for you.

LilyPond 2.23.6 will support some D.C., D.S., al Fine, and alla Coda repeat 
structures automatically using "\repeat segno" with the same syntax as "\repeat 
volta".
— 
Dan

Re: 2.23.5 and poly-mark-engraver https://lsr.di.unimi.it/LSR/Item?id=976

[Valentin Petzel]

Hello Joel,

With 2.23 the MarkEvent gets replaced by the RehearsalMarkEvent and the 
AdHocMarkEvent, where the latter is meant for labeled and uncounted marks.

This means that you you should replace 'MarkEvent in the polyMark function 
for 'AdHocMarkEvent or 'RehearsalMarkEvent, depending on the kind of 
labeling. Of course the polymark engraver does not differentiate between these 
two things.

Cheers,
Valentin

Am Donnerstag, 30. Dezember 2021, 18:07:10 CET schrieb Joel C. Salomon:
> I'm returning to an old project (last touched in 2016) on a new 
> computer, and I’m running 2.23.5 on Windows 11.
> 
> Several of the scores used poly-mark-engraver from 
>  (see also 
> ), 
> and this now fails with
> 
> 
> > fatal error: cannot find music object: MarkEvent
> 
> 
> (Minimal example below signature; the demonstration included in 
>  also fails the same way.)
> 
> This is both a bug-report if anyone’s maintaining the snippet, and a 
> question whether there’s now a better way to write da capo, al segno, 
> and other coda-like repeats.
> 
> —Joel C. Salomon
> 
>  \version "2.23.5"
>  \language "english"
> 
>  \include "poly-mark-engraver.ly" % 
> http://lsr.di.unimi.it/LSR/Item?id=976
> 
>  \score {
>\new PianoStaff
><<
>  \new Staff = "upper" \relative c'' { c c c c | }
>  \new Dynamics = "dynamics" {
>s4*4
>\polyMark #'DCFine \markup \italic "Segue"
>\bar "|."
>  }
>  \new Staff = "lower" \relative c { \clef bass c c c c | }
> 
>>>
> 
>  }


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

slash-only chords

[Flaming Hakama by Elaine]

Hi,

I'm looking for a way to print a chord symbol which is a slash chord,
but where the top part (above the slash) is blank.

So, I only want to print the slash + root note.

The usage for this is when the previous chord repeats,
and only the bass note changes.

Here is an MWE for a progression where I would like to use it.


\version "2.19.83"

myChords = \chordmode {
d2:m d:m/cis | d:m/c d:m/b
}
melody = \relative c' {
\key d \minor
f2 a | c d |
}

<<
\new ChordNames  { \myChords }
\new Staff {
\mark "Default"
\melody
}
>>



Does anyone have suggestions for how to obtain this?

I've tried using <>  and spacers as the chord,
both of which produce "syntax error, unexpected /"

myChords = \chordmode {
d2:m <>/cis | <>/c <>/b
}

myChords = \chordmode {
d2:m s/cis | s/c s/b
}

Is there some chord syntax notation that allows this?



I was also considering, since I am already using my own chord exceptions,
is there a way to define an exception to specify to only print the slash
part?

While you can define a chord treatment such that it does not have anything
in it,
it seems that lily always prints the root and slash + bass note,
as shown in this second example:


myChordExceptions = {
1-\markup { }
}
chordExceptions = #(append (sequential-music-to-chord-exceptions
myChordExceptions #t) ignatzekExceptions)

<<
\new ChordNames {
\set chordNameExceptions = #chordExceptions
\myChords
}
\new Staff {
\mark "Empty"
\melody
}
>>



As this second example demonstrates, the chord exceptions
are only applied to what is before the slash.

Which is to say, I defined the treatment for a minor chord,
but it is used in all the slash chords that are minor,
not just the root position chord.

Perhaps then all I need would be to hide the root of the chord?
Is that approach possible?

If just hiding the root of the chord were possible,
I would be able to define a chord spec to identify these chords,
as in the following example where only the first (non-slash) chord has the
minor chord symbol.

I realize, and am ok with the fact,
that defining non-semantic chord types like this
means it would be a print-only approach,
since I would need different chords for MIDI.

%}

hackChordExceptions = {
1-\markup { }
}
chordExceptions = #(append (sequential-music-to-chord-exceptions
hackChordExceptions #t) ignatzekExceptions)

hackChords = \chordmode {
d2:m d:1.3-.5.8+/cis | d:1.3-.5.8+/c d:1.3-.5.8+/b
}

<<
\new ChordNames {
\set chordNameExceptions = #chordExceptions
\hackChords
}
\new Staff {
\mark "Hack"
\melody
}
>>



Please let me know if you have any thoughts.

Thanks!


Elaine Alt
415 . 341 .4954   "*Confusion is
highly underrated*"
ela...@flaminghakama.com
Producer ~ Composer ~ Instrumentalist ~ Educator
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-


>

Re: point-and-click default

[David Kastrup]

Lukas-Fabian Moser  writes:

> Hi David,
>> I've been using Lilypond for a few years, and only yesterday learned
>> about the point-and-click feature in pdf output.  In particular, I had
>> no idea that by default Lilypond includes absolute pathnames to local
>> source files on my system as metadata in the pdf output files.  So when
>> I uploaded a couple of files to IMSLP recently, that metadata was
>> available for all to see.
>
> The Notation Reference states
> (https://lilypond.org/doc/v2.23/Documentation/usage/configuring-the-system-for-point-and-click):
>
> "Point and click functionality is enabled by default when creating PDF
> or SVG files."
>
> "Note: You should always turn off point and click in any LilyPond
> files to be distributed to avoid including path information about your
> computer in the PDF file, which can pose a security risk."
>
> I agree that these statements make for a gloomy combination by today's
> standards of increased awareness for computer security issues.
>
> Wouldn't it be more reasonable to switch point-and-click off by
> default?

My personal idea would be to use relative links anyway, but that might
possibly not work with the kind of "URL helper" setup that typically
ends up calling lilypond-invoke-editor .

-- 
David Kastrup

Re: 2.23.5 and poly-mark-engraver https://lsr.di.unimi.it/LSR/Item?id=976

[Lukas-Fabian Moser]

Hi Joel,

Several of the scores used poly-mark-engraver from 
 (see also 
), 
and this now fails with



fatal error: cannot find music object: MarkEvent


(Minimal example below signature; the demonstration included in 
 also fails the same way.)


This is both a bug-report if anyone’s maintaining the snippet, and a 
question whether there’s now a better way to write da capo, al segno, 
and other coda-like repeats.


Indeed there is. There's heavy ongoing (or by now maybe even finished?) 
work by Dan Eble on precisely this group of features. I write this here 
because (if I'm not mistaken) Dan is one of the few developers who do 
not follow the lilypond-user list.


Lukas

Re: point-and-click default

[Lukas-Fabian Moser]

Hi David,

I've been using Lilypond for a few years, and only yesterday learned
about the point-and-click feature in pdf output.  In particular, I had
no idea that by default Lilypond includes absolute pathnames to local
source files on my system as metadata in the pdf output files.  So when
I uploaded a couple of files to IMSLP recently, that metadata was
available for all to see.


The Notation Reference states 
(https://lilypond.org/doc/v2.23/Documentation/usage/configuring-the-system-for-point-and-click):


"Point and click functionality is enabled by default when creating PDF 
or SVG files."


"Note: You should always turn off point and click in any LilyPond files 
to be distributed to avoid including path information about your 
computer in the PDF file, which can pose a security risk."


I agree that these statements make for a gloomy combination by today's 
standards of increased awareness for computer security issues.


Wouldn't it be more reasonable to switch point-and-click off by default? 
My argument would be that in Frescobaldi, it's trivial to accommodate 
such a change, and non-Frescobaldi users who are able to set up a 
point-and-click-ready system of their own should also be perfectly able 
to make point-and-click the default on their system if they want to. 
Even more so since there's \pointAndClickOn, making it trivial to enable 
the feature for individual files without having to mess with command 
line parameters.


Lukas

Re: point-and-click default

[David Zelinsky]

David Zelinsky  writes:

> Tom Sgouros  writes:
>
>> For those of us just catching up, can someone explain how to see the
>> metadata? I guess this is more of a PDF question, but while I have some
>> experts' attention...
>>
>> Thank you,
>>
>>  -Tom
>
> I can only tell you about evince, the pdf reader I use.  But I expect it
> should be the same in most pdf readers.
>
> If you hover the mouse pointer over a notehead, it displays the URI that
> will be looked up when you click there.  It will look like this:
>
>   textedit
>
> where  is the absolute path to the lilypond source
> file, and  and  are the starting and ending
> positions of the text defining the note in question.
>
> -David

Sorry, I meant to say also that  is the line number in the source
file where the note definition appears.

In evince on my Ubuntu system, clicking on the note elicits an error,
because evince does not know what to do with a "textedit:..." link.
Section 4.1 of the Usage Manual (under 4. External Programs) explains
how to make it work.

-David

Re: \trill fails barcheck with articulate.ly

[Joel C. Salomon]

On 12/30/2021 6:40 AM, Lukas-Fabian Moser wrote:


Am 30.12.21 um 04:10 schrieb Joel C. Salomon:


Minimal example:

\version "2.23.1"
\include "articulate.ly"
\articulate {
    c''1\trill |
}

Is this something addressed between 2.23.1 (which I have installed)
and 2.23.5 (current)?


Yes, there's no warning with 2.23.3 or higher.


Thank you.  Upgraded to 2.23.5 and this went away.  (To be replaced with 
a different problem, which I’ve posted in its own thread.)


—Joel

2.23.5 and poly-mark-engraver https://lsr.di.unimi.it/LSR/Item?id=976

[Joel C. Salomon]

I'm returning to an old project (last touched in 2016) on a new 
computer, and I’m running 2.23.5 on Windows 11.


Several of the scores used poly-mark-engraver from 
 (see also 
), 
and this now fails with



fatal error: cannot find music object: MarkEvent


(Minimal example below signature; the demonstration included in 
 also fails the same way.)


This is both a bug-report if anyone’s maintaining the snippet, and a 
question whether there’s now a better way to write da capo, al segno, 
and other coda-like repeats.


—Joel C. Salomon

\version "2.23.5"
\language "english"

\include "poly-mark-engraver.ly" % 
http://lsr.di.unimi.it/LSR/Item?id=976


\score {
  \new PianoStaff
  <<
\new Staff = "upper" \relative c'' { c c c c | }
\new Dynamics = "dynamics" {
  s4*4
  \polyMark #'DCFine \markup \italic "Segue"
  \bar "|."
}
\new Staff = "lower" \relative c { \clef bass c c c c | }
  >>
}


OpenPGP_0xE30370FF977A1B52.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: point-and-click default

[David Zelinsky]

Tom Sgouros  writes:

> For those of us just catching up, can someone explain how to see the
> metadata? I guess this is more of a PDF question, but while I have some
> experts' attention...
>
> Thank you,
>
>  -Tom

I can only tell you about evince, the pdf reader I use.  But I expect it
should be the same in most pdf readers.

If you hover the mouse pointer over a notehead, it displays the URI that
will be looked up when you click there.  It will look like this:

  textedit

where  is the absolute path to the lilypond source
file, and  and  are the starting and ending
positions of the text defining the note in question.

-David

Re: point-and-click default

[David Zelinsky]

Knute Snortum  writes:

> On Wed, Dec 29, 2021 at 7:13 PM David Zelinsky  wrote:
> [...]
>> But even if it is configured to work, it seems like a REALLY BAD IDEA to
>> have this feature enabled *by default*.  Or, if it is to be the default,
>> it ought to be mentioned VERY PROMINENTLY, so anyone installing and
>> using Lilypond will see it.  As far as I could tell, it is not even
>> mentioned in the Learning Manual.
>>
>> The reference manual does admonish users to disable the feature when
>> producing pdf output for public distribution.  But that warning is
>> totally useless if a user does not happen to read that (rather obsure)
>> section of the manual.
>
> My vote would be to leave the point-and-click as the default and put a
> mention of how to publish a PDF in the Learning Manual, with any
> necessary warnings.  In Frescobaldi, I use this feature all the time
> and there is an easy way to publish PDFs without point-and-click.  I
> didn't know about the absolute path names in the metadata, but that
> makes sense.  Thanks for pointing that out.

Yes, keeping it the default but including documentation in the Learning
Manual sounds like a reasonable solution.  But there should also be
instructions for setting it up, or a pointer to the part of the
Reference Manual that discusses it.  Although apparently point-and-click
works out of the box in Frescobaldi, not everyone uses Frescobaldi, and
it requires some setup to work with other pdf readers (e.g. evince), at
least in my vanilla Ubuntu distribution.  This is all extensively
documented in the Reference Manual, but not in a place anyone is likely
to see it unless they know to search for point-and-click.

-David

Re: point-and-click default

[Tom Sgouros]

For those of us just catching up, can someone explain how to see the
metadata? I guess this is more of a PDF question, but while I have some
experts' attention...

Thank you,

 -Tom

On Thu, Dec 30, 2021 at 10:25 AM Knute Snortum  wrote:

> On Wed, Dec 29, 2021 at 7:13 PM David Zelinsky 
> wrote:
> [...]
> > But even if it is configured to work, it seems like a REALLY BAD IDEA to
> > have this feature enabled *by default*.  Or, if it is to be the default,
> > it ought to be mentioned VERY PROMINENTLY, so anyone installing and
> > using Lilypond will see it.  As far as I could tell, it is not even
> > mentioned in the Learning Manual.
> >
> > The reference manual does admonish users to disable the feature when
> > producing pdf output for public distribution.  But that warning is
> > totally useless if a user does not happen to read that (rather obsure)
> > section of the manual.
>
> My vote would be to leave the point-and-click as the default and put a
> mention of how to publish a PDF in the Learning Manual, with any
> necessary warnings.  In Frescobaldi, I use this feature all the time
> and there is an easy way to publish PDFs without point-and-click.  I
> didn't know about the absolute path names in the metadata, but that
> makes sense.  Thanks for pointing that out.
>
>
> --
> Knute Snortum
>
>

Re: point-and-click default

[Knute Snortum]

On Wed, Dec 29, 2021 at 7:13 PM David Zelinsky  wrote:
[...]
> But even if it is configured to work, it seems like a REALLY BAD IDEA to
> have this feature enabled *by default*.  Or, if it is to be the default,
> it ought to be mentioned VERY PROMINENTLY, so anyone installing and
> using Lilypond will see it.  As far as I could tell, it is not even
> mentioned in the Learning Manual.
>
> The reference manual does admonish users to disable the feature when
> producing pdf output for public distribution.  But that warning is
> totally useless if a user does not happen to read that (rather obsure)
> section of the manual.

My vote would be to leave the point-and-click as the default and put a
mention of how to publish a PDF in the Learning Manual, with any
necessary warnings.  In Frescobaldi, I use this feature all the time
and there is an easy way to publish PDFs without point-and-click.  I
didn't know about the absolute path names in the metadata, but that
makes sense.  Thanks for pointing that out.


--
Knute Snortum

Re: Updating alists

[Lukas-Fabian Moser]

\version "2.23.6"

myScripts = \default-script-alist
myScripts.tenuto.padding = 5

\layout {
   \context {
     \Score
     scriptDefinitions = #myScripts
   }
}

{
   a--
}

(One might also skip defining a new variable and instead change
default-script-alist directly, but it has to be re-read in a \layout
block anyway.)

But at the moment, this does not work because the changed key is not
being replaced in the alist but added at the beginning.

Why would that not work?

Because I tested it wrongly. Sorry for the noise.

I'm still unsure if the result of

violin.I = { a }
violin.I = { gis }

\void \displayScheme \violin

is "what it should be" (i.e. if one wouldn't rather expect the second 
assignment overwriting the first one), but I see that changing this has 
problematic implications.


Lukas

Re: Updating alists

[David Kastrup]

David Kastrup  writes:

> For stuff like
>
>
> midiDrumPitches.ridecymbal = fis,,
> midiDrumPitches.ridecymbala = b
> midiDrumPitches.ridecymbalb = a
> midiDrumPitches.crashcymbal = g
>
>
> \midi
> {
>   \context {
> \Score
> drumPitchTable = #(alist->hash-table midiDrumPitches)
>   }
> }
>
> you'll get across-session bleed of assignments when making them
> destructive.  Another option is, of course, to do what amounts to an
> in-place modification of a structural copy.

As a note aside regarding this code excerpt: we should really support
more than just the default drum kit of the MIDI2.0 standard.  The
standard defines something like 10 different drum kits.

And as a note very much aside: an arranger manual from Ketron confused
me without end with a "special parameter" SysEx entry (apparently a
translation oversight) listed as "selezione mappa batteria" with the
possibilities "new MS series" and "old MS series" because the obvious
translation "battery" is also corroborated by web translators.  I think
it was at least a year after I first puzzled over this entry that I
thought of the different meaning "battery" may have in English (and
"Batterie" in German hasn't) to figure out the manual was talking about
a drum kit selection.

-- 
David Kastrup

Re: Updating alists

[David Kastrup]

Lukas-Fabian Moser  writes:

> Another question: With the (hopefully) upcoming changes in the
> script-alist structure (using symbols instead of strings as keys),
> we're quite close to being able to simply do
>
> \version "2.23.6"
>
> myScripts = \default-script-alist
> myScripts.tenuto.padding = 5
>
> \layout {
>   \context {
>     \Score
>     scriptDefinitions = #myScripts
>   }
> }
>
> {
>   a--
> }
>
> (One might also skip defining a new variable and instead change
> default-script-alist directly, but it has to be re-read in a \layout
> block anyway.)
>
> But at the moment, this does not work because the changed key is not
> being replaced in the alist but added at the beginning.

Why would that not work?

> If I see things correctly, this is the remark about "not coalescing
> multiple overrides of the same property" in nested_property_alist(...)
> in ily/nested-property.cc.
>
> Re-enabling the outcommented branch in that function (taking care to
> use assoc_tail instead of assq_tail and correcting the order of
> arguments to that call) basically works, but there's trouble ahead in
> the case where one does
>
> variable.entry = 15
> variable.entry.first = #'i-ve-decided-i-want-a-sublist-after-all
>
> which unfortunately is what happens if one \override's a nested
> property given by a callback
> (e.g. VerticalAxisGroup.staff-staff-spacing), or worse
>
> variable.entry = #'(some . pair)
> variable.entry.first = #'i-ve-decided-i-want-a-sublist-after-all
>
> since an entry that is a pair looks like the beginning of a sublist.
>
> On the other hand, I would expect people who are using
>
> Violin.I = { \someMusic }
> Violin.I = { \someNewMusic }
>
> would indeed like to be their first definition to actually be replaced
> (even if using \Violin.I in a score happens to produce only the most
> recent entry).
>
> Thoughts?

For stuff like


midiDrumPitches.ridecymbal = fis,,
midiDrumPitches.ridecymbala = b
midiDrumPitches.ridecymbalb = a
midiDrumPitches.crashcymbal = g


\midi
{
  \context {
\Score
drumPitchTable = #(alist->hash-table midiDrumPitches)
  }
}

you'll get across-session bleed of assignments when making them
destructive.  Another option is, of course, to do what amounts to an
in-place modification of a structural copy.

-- 
David Kastrup

Re: \trill fails barcheck with articulate.ly

[Lukas-Fabian Moser]

Hi Joel,

Am 30.12.21 um 04:10 schrieb Joel C. Salomon:

Minimal example:

\version "2.23.1"
\include "articulate.ly"
\articulate {
c''1\trill |
}

Is this something addressed between 2.23.1 (which I have installed)
and 2.23.5 (current)?


Yes, there's no warning with 2.23.3 or higher.

Lukas

Re: Relative Tempo Markings in Lilypond 2.22

[David M. Boothe, CAS]

Thanks, Carl. I didn't think about convert-ly. It's been a while since I
needed it.

dB

On Wed, Dec 29, 2021, 11:10 PM Carl Sorensen  wrote:

>
>
> convert-ly will fix this for you.
>
> The argument for \note changed from a string ( #"8")  to a duration
> ({8}).  See http://lilypond.org/doc/v2.22/Documentation/changes/
>
> HTH,
>
> Carl
>
>
>

Updating alists (was: Tenuto marking too close to note)

[Lukas-Fabian Moser]

Hi Jean, (CCing devel because of the stuff below the asterisks)

Although this approach manipulates internal data structures of 
LilyPond, it has the advantage of dealing with your issue at the root 
and not causing side effects for other scripts. Unfortunately, this 
approach does not work directly for the (still experimental) LilyPond 
builds using Guile2.


Be mindful that assoc-set! is not guaranteed to
mutate its input. You're not the first one tripped
up by this API quirk :-)


It's much worse than that: It's not the first time _I've_ been tripped 
up by this (previously it was with sort!). I'll just have to write 100 
copies of


"The exclamation mark in something! does not mean the function is 
guaranteed to make the desired change in-place."


on my wall.

But more seriously: Thanks! And also for advertising ice-9 match - it's 
really a different coding style from the more commonly seen (if pair? 
...) constructs.


* * *

Another question: With the (hopefully) upcoming changes in the 
script-alist structure (using symbols instead of strings as keys), we're 
quite close to being able to simply do


\version "2.23.6"

myScripts = \default-script-alist
myScripts.tenuto.padding = 5

\layout {
  \context {
    \Score
    scriptDefinitions = #myScripts
  }
}

{
  a--
}

(One might also skip defining a new variable and instead change 
default-script-alist directly, but it has to be re-read in a \layout 
block anyway.)


But at the moment, this does not work because the changed key is not 
being replaced in the alist but added at the beginning. If I see things 
correctly, this is the remark about "not coalescing multiple overrides 
of the same property" in nested_property_alist(...) in 
ily/nested-property.cc.


Re-enabling the outcommented branch in that function (taking care to use 
assoc_tail instead of assq_tail and correcting the order of arguments to 
that call) basically works, but there's trouble ahead in the case where 
one does


variable.entry = 15
variable.entry.first = #'i-ve-decided-i-want-a-sublist-after-all

which unfortunately is what happens if one \override's a nested property 
given by a callback (e.g. VerticalAxisGroup.staff-staff-spacing), or worse


variable.entry = #'(some . pair)
variable.entry.first = #'i-ve-decided-i-want-a-sublist-after-all

since an entry that is a pair looks like the beginning of a sublist.

On the other hand, I would expect people who are using

Violin.I = { \someMusic }
Violin.I = { \someNewMusic }

would indeed like to be their first definition to actually be replaced 
(even if using \Violin.I in a score happens to produce only the most 
recent entry).


Thoughts?

Lukas

Re: point-and-click default

[Kevin Barry]

>
>
> This point-and-click seems like a useful feature for editing, *if* it's
> configured to work on your system.  But it apparently is not usually set
> up that way by default, at least on most Linux systems.  (I do
> appreciate the instructions in the manual for configuring it, and plan
> to do that.)
>

I think pretty much everyone uses point-and-click. The most popular editor
(Frescobaldi) is available on Linux (I use it) - often packaged for you by
the distro, so I think you are not correct about how it is typically used
there. If you were in the dark about this until now I think you are an
outlier. Working with LilyPond is much harder without it.

Re the greater point about whether it should be on by default: I personally
like it as is and wouldn't want to have to enable it each time or make new
users do it. And I think that is more important than the potential downside
of someone not knowing to use publish (or forgetting), and then making a
pdf available that reveals their system username. But that is only my
opinion, and I understand your view.

Kevin