Re: Scheme question

[Urs Liska]

Am Dienstag, den 14.01.2020, 17:20 -0800 schrieb Aaron Hill:
> On 2020-01-14 5:11 pm, Arle Lommel wrote:
> > Is that feature explained anywhere in the documentation? I don’t
> > recall seeing anything like that anywhere and searching for
> > “quasi-quote scheme Lilypond” doesn’t return anything relevant.
> > 
> > If it isn’t there, this seems like rather a nice thing to have in
> > the
> > documentation.
> 
> This is more a Scheme feature than a LilyPond one.  Urs' created a
> site 
> [1] that offers help for Scheme.  

Especially https://scheme-book.ursliska.de/scheme/quoting/ and
following pages.

> I also keep a copy of the Guile 1.8 
> docs as a PDF [2], which I use for additional reference.

Thanks for that. I'm always struggling to locate the correct manual on
the web, so this may be something I can work with.

Urs

> 
> [1]: https://scheme-book.ursliska.de/
> [2]: https://1drv.ms/b/s!AnEPVISZ-Wlbj5tzMF32JKKQnVavjg?e=zObsAq
> 
> 
> -- Aaron Hill
> 

Re: Trying to locate files

[Freeman Gilmore]

On Wed, Jan 15, 2020 at 12:33 AM Aaron Hill 
wrote:

> On 2020-01-14 9:27 pm, Freeman Gilmore wrote:
> > On Wed, Jan 15, 2020 at 12:19 AM Aaron Hill 
> > wrote:
> >
> >> On 2020-01-14 8:53 pm, Freeman Gilmore wrote:
> >> > On Tue, Jan 14, 2020 at 11:04 PM Aaron Hill  >
> >> > wrote:
> >> >
> >> >> On 2020-01-14 7:47 pm, Freeman Gilmore wrote:
> >> >> > What is the name of the file that translate text to Unicode?
> >> >>
> >> >> I am uncertain about this ask.  Could you expand on it?
> >> >>
> >> > It is my understanding that LP uses Unicode.   i sharp symbol has a
> >> > Unicode.Some were there is a file were the text is converted to
> >> > Unicode.
> >>
> >> Ah, LilyPond handles UTF-8 parsing within the lexer.  See lexer.ll and
> >> in particular the function Lily_lexer::YYText_utf8.
> >>
> > Searched for lexer.ll. no mach?
>
> It is in the source code [1] for LilyPond, not the binary distribution.
>
> [1]:
>
> https://git.savannah.gnu.org/cgit/lilypond.git/tree/lily/lexer.ll?h=release/2.19.83-1=c9134465360dfb53419f749747d28c6d04d23839#n1171
>
> (The link assumes you are working from 2.19.83.)
>
Thank you, I would have though the conversion to Unicode would be at the
out put not the lexer; but what do I know.
ƒg

>
> -- Aaron Hill
>
>

Re: Trying to locate files

[Aaron Hill]

On 2020-01-14 9:27 pm, Freeman Gilmore wrote:

On Wed, Jan 15, 2020 at 12:19 AM Aaron Hill 
wrote:


On 2020-01-14 8:53 pm, Freeman Gilmore wrote:
> On Tue, Jan 14, 2020 at 11:04 PM Aaron Hill 
> wrote:
>
>> On 2020-01-14 7:47 pm, Freeman Gilmore wrote:
>> > What is the name of the file that translate text to Unicode?
>>
>> I am uncertain about this ask.  Could you expand on it?
>>
> It is my understanding that LP uses Unicode.   i sharp symbol has a
> Unicode.Some were there is a file were the text is converted to
> Unicode.

Ah, LilyPond handles UTF-8 parsing within the lexer.  See lexer.ll and
in particular the function Lily_lexer::YYText_utf8.


Searched for lexer.ll. no mach?


It is in the source code [1] for LilyPond, not the binary distribution.

[1]: 
https://git.savannah.gnu.org/cgit/lilypond.git/tree/lily/lexer.ll?h=release/2.19.83-1=c9134465360dfb53419f749747d28c6d04d23839#n1171


(The link assumes you are working from 2.19.83.)


-- Aaron Hill

Re: Trying to locate files

[Aaron Hill]

On 2020-01-14 8:53 pm, Freeman Gilmore wrote:

On Tue, Jan 14, 2020 at 11:04 PM Aaron Hill 
wrote:


On 2020-01-14 7:47 pm, Freeman Gilmore wrote:
> What is the name of the file that translate text to Unicode?

I am uncertain about this ask.  Could you expand on it?


It is my understanding that LP uses Unicode.   i sharp symbol has a
Unicode.Some were there is a file were the text is converted to
Unicode.


Ah, LilyPond handles UTF-8 parsing within the lexer.  See lexer.ll and 
in particular the function Lily_lexer::YYText_utf8.



-- Aaron Hill

Re: Distance of a grob from its reference point

[Kieren MacMillan]

Hi all,

On Jan 14, 2020, at 10:50 PM, Aaron Hill  wrote:
> I very much need LilyPond to be able to make the smart decisions on my behalf.

Me, too.

> That is why I am trying to defend getting the automatic parts working better

I think that’s an important goal.

> I would disagree with the notion that everyone has to do fine tuning.

If I’m correctly interpreting her abstract, I’m pretty sure Elaine Gould will 
speak exactly to this issue in her keynote session this Friday in Salzburg. 
Very much looking forward to that, and the discussion that will follow.

Best,
Kieren.


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

Re: Unusual cross-staff stem in Bartók

[Kieren MacMillan]

Hi Andrew,

> Not at all uncommon.

Agreed.

> for the case with the notehead on the opposite, you now have lots o good 
> solutions.

Well… I wouldn’t necessarily call my hack a good solution. It would be nice to 
have some syntactic sugar that would handle these kinds of cases gracefully, 
allowing the user to (e.g.) dictate notehead direction something like #'(-1 1 1 
-1 0), etc.

But we do what we can with what we have on hand!

Best,
Kieren.


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

Re: Trying to locate files

[Aaron Hill]

On 2020-01-14 7:47 pm, Freeman Gilmore wrote:
Is there a file like makam.ly for the standard accidentals? If so what 
is

its name?


You should review lily-library.scm (near the top) and 
define-note-names.scm, as those files contain the functional equivalent 
to makam.ly.



What is the name of the file that translate text to Unicode?


I am uncertain about this ask.  Could you expand on it?


-- Aaron Hill

Re: Distance of a grob from its reference point

[Carl Sorensen]

From: Paolo Prete 
Date: Tuesday, January 14, 2020 at 8:10 PM
To: Aaron Hill 
Cc: Lilypond-User Mailing List 
Subject: Re: Distance of a grob from its reference point




I really can't count how many times I had to to that in so many scores. And 
there's no way to do that automagically. Really no way.
Otherwise I would not have asked what I'm asking.
Then I'm forced to use the extra-offset property for now.
Hope that someone could solve this issue. I'm sure there's a way for doing 
that, without changing the code and whole Lilypond would have a great benefit 
from it.

I’m sure that within the current code base there is no way to solve this issue 
in the means you have proposed.  When the Y-offset property of a grob is an 
unpure-pure-container, final positioning is done *after* \offset is applied to 
the unpure-pure-container value.  And then collision avoidance is applied, 
along with “automagic” placement. So the only way to solve this problem with 
the current code base is to use extra-offset.  But then you also get to do your 
own collision avoidance.

I’m sorry, but I think this is the current state of LilyPond’s placement 
algorithms.  And that’s why I prefer to find ways to tweak the placement 
algorithms, as opposed to tweaking the grobs.

Thanks,

Carl

Re: Distance of a grob from its reference point

[Aaron Hill]

On 2020-01-14 7:10 pm, Paolo Prete wrote:
On Tue, Jan 14, 2020 at 9:08 PM Aaron Hill  
wrote:

 I am not connected to the world of modern notation, but I
cannot envision any musical meaning for the exact vertical position of
an OttavaBracket.


This is not true. There are many and many cases in which you need to 
tune

the position of the ottava bracket as well as any other bracket.
And I'm not talking about modern notation. Even in nineteenth century
notation this is absolutely necessary.
The first obvious example is when you have slurs near brackets. Which
happen *very frequently*
In this cases a common algo is to:

1) choose which of the two objects has to be placed above (there's not 
a

rule for that: it depends on aesthetical choices)


That was what I suspected.  This is aesthetics, not semantics.  The 
vertical position of a bracket carries no musical intention; unlike how 
the vertical position of a note head relates to pitch.  In my mind, 
LilyPond syntax is largely about communicating the musical content and 
letting the software deal with putting the right ink on the page in the 
right spot.


That is not to say that aesthetics does not matter, and LilyPond should 
strive to meet what is generally considered good and pleasing to the 
eye.  But in order for aesthetics to be codified, one just needs to 
surface all of the important aspects and constraints, and it sounds like 
LilyPond does not yet have that level of information.  As such, you are 
finding it necessary to step in and shift things around.


Side note: I should be clear that I am not "against" the prospect of 
manual tweaking tools.  Even if it were just your life that was made 
easier--and it is clear you are not the only one who would benefit--then 
such tools are justified.  But my view and practice of software 
engineering is largely focused on automation and getting the computer to 
do the heavy lifting.  I dislike manual tweaking, as I have wasted away 
many hours on such details.  For my own sanity and productivity, I have 
to restrain myself.  As such, I very much need LilyPond to be able to 
make the smart decisions on my behalf.  That is why I am trying to 
defend getting the automatic parts working better; but I need to be more 
mindful to not hinder progress on the manual parts.



2) move them according to decision 1) and then *tune* their coordinates
(which is tedious even with WYSIWYG editors, and requires 
trial-and-error

even with them!).
Please note that you can't simply say: "ok, let's move this up and this
down and all is done". You have to make heavy micro-tuning as a 
consequence.


I would disagree with the notion that everyone has to do fine tuning.  I 
certainly do nothing of the sort in my work, but I do not work on the 
same type of projects.  My needs and requirements are quite likely much 
less strict.  When it comes to the matter of manual tweaking, my use 
cases are largely irrelevant.  I should, therefore, really bow out of 
this conversation as I am not the target audience and am probably doing 
a better job of muddying the waters.



-- Aaron Hill

Re: Syntax highlighting

[Craig Dabelstein]

Federico,

Is it just me or is the documentation for Pygments really hard to
understand? I can't even find anywhere they discuss the setup.py file.

I've opened a repo (https://github.com/craigdab/pygments-lilypond-test) and
cut and paste from other peoples repositories as a start, but I really have
no idea what I'm doing.

Craig


On Wed, 15 Jan 2020 at 10:38, Craig Dabelstein 
wrote:

> Thank you gentlemen,
>
> I'll have a go at taking the python-ly work and seeing if I can use it
> work to make syntax highlighting with pygments. It's highly possible that I
> will totally fail, but I'll give it a try.
>
> Craig
>
>
> On Tue, 14 Jan 2020 at 23:38, Federico Bruni  wrote:
>
>> Il giorno mar 14 gen 2020 alle 12:34, Urs Liska 
>> ha scritto:
>> > Pygments is also what Pandoc uses for its syntax highlighting, so that
>> > would also make sense for that (e.g. generating PDF documentation from
>> > Markdown).
>>
>> Are you sure?
>> I think that pygments is the name of the default style in Pandoc, but
>> the highlight library is a Haskell library called skylighting:
>> https://pandoc.org/MANUAL.html#syntax-highlighting
>> https://github.com/jgm/skylighting
>>
>> It seems Wilbert contributed the definitions for lilypond syntax:
>>
>> https://github.com/KDE/syntax-highlighting/blob/master/data/syntax/lilypond.xml
>>
>> About 10 days ago I wanted to share this in the open issue in
>> Frescobaldi tracker but I forgot to do it.
>> I remember I found the lilypond file definition somewhere else...
>>
>>
>>
>>
>
> --
> Craig Dabelstein
> Owner
> Maxime's Music
> M: 0404884173
> A: 19 Twelfth Ave,  Kedron QLD 4031, Australia
> W: concertbandmusicstore.com E:
> cr...@concertbandmusicstore.com 
> 
> 
>
> 
>
>


-- 
Craig Dabelstein
Owner
Maxime's Music
M: 0404884173
A: 19 Twelfth Ave,  Kedron QLD 4031, Australia
W: concertbandmusicstore.com E:
cr...@concertbandmusicstore.com 

Re: # and $ (was Re: metronome-mark-alignment)

[David Kastrup]

Aaron Hill  writes:

> On 2020-01-14 5:18 pm, David Kastrup wrote:
>> No, it's that \notes is identical to $notes (apart from the syntax) in
>> that it creates a copy.  So whenever you write \something and do
>> something with it, whatever you do with it will not affect the original
>> stuff stored in the Scheme variable something .  Basically the idea is
>> that you get a copy whenever you reference a variable, but the music
>> passed around in expressions and from one function to another does not
>> get copied unless you need more than one version of it.
>
> Ah, that makes sense.  Thanks!

The whole #/$/\ thing in its current form has not been around for all
that long and basically started with

commit 2a07e6101abd393b88f22309dcda0c7ed032d85c
Merge: ccebc5251f ccc485525e
Author: David Kastrup 
Date:   Thu Nov 10 15:41:41 2011 +0100

Let #{ ... #} pass its $ handling to environment cloning and run convert-ly

in version 2.15.18 with a few later amendments.  # was there before
that, but stuff inside of #{ ... #} was rather icky with some different
meaning of $ in there and things like closures not working across
#{ ... #} layers and internals bleeding out whenever something went
wrong, and partly even when it went right.  Similar to like LaTeX bleeds
TeX internals whenever something unexpected happens.

The effects of $ were previously achieved with #(ly:export ...) but the
timing was unpredictable and all # expressions were evaluated early like
now only the $ (and \ ) expressions are.

The whole treatise in the extension guide might read like a complicated
mess but the basic semantics are rather few and work dependably in spite
of significant magic behind the scenes.  Another such thing are music
functions: they were quite limited at one time (no default arguments,
hardwiring of a lot of argument type predicates) and lots of LilyPond
elements these days implemented with music functions were instead
hardwired into the parser, making extensions in LilyPond functionality
require tampering with the parser and recompiling.

Again, the tutorials and documentation make this appear awfully
complicated but it is in a completely different ballpark to what it once
was.

Making that appreciatable will probably require a few generations of
power users just taken some things for granted and learning from the
previous generation and not obsessing in the kind of internals-heavy
detail I tend to fall into when writing documentation.

-- 
David Kastrup

RE: Three short questions from Bartók around fingering, about 90% there

[Mark Stephen Mrotek]

Arle,

 

Very welcome.

Had the same issue in a Mozart Piano Sonata and someone on the list provided 
the commands.

 

Mark

 

From: Arle Lommel [mailto:arle.lom...@gmail.com] 
Sent: Tuesday, January 14, 2020 5:02 PM
To: Mark Stephen Mrotek 
Cc: Lilypond-User Mailing List 
Subject: Re: Three short questions from Bartók around fingering, about 90% there

 

 





On Jan 14, 2020, at 18:05, Mark Stephen Mrotek mailto:carsonm...@ca.rr.com> > wrote:

 

Arle,

 

Add these before the b!

 

\once \override Accidental.extra-offset = #'(3 . 0)

\once \override NoteColumn.force-hshift = #2.5

 

Mark

 

Thanks. I’m finding I have to play around with the numbers a bit and add an 
Accidental.extra-offset elsewhere, but this is really useful.

 

-Arle

Re: # and $ (was Re: metronome-mark-alignment)

[Aaron Hill]

On 2020-01-14 5:18 pm, David Kastrup wrote:

No, it's that \notes is identical to $notes (apart from the syntax) in
that it creates a copy.  So whenever you write \something and do
something with it, whatever you do with it will not affect the original
stuff stored in the Scheme variable something .  Basically the idea is
that you get a copy whenever you reference a variable, but the music
passed around in expressions and from one function to another does not
get copied unless you need more than one version of it.


Ah, that makes sense.  Thanks!

-- Aaron Hill

Re: Scheme question

[Aaron Hill]

On 2020-01-14 5:11 pm, Arle Lommel wrote:

Is that feature explained anywhere in the documentation? I don’t
recall seeing anything like that anywhere and searching for
“quasi-quote scheme Lilypond” doesn’t return anything relevant.

If it isn’t there, this seems like rather a nice thing to have in the
documentation.


This is more a Scheme feature than a LilyPond one.  Urs' created a site 
[1] that offers help for Scheme.  I also keep a copy of the Guile 1.8 
docs as a PDF [2], which I use for additional reference.


[1]: https://scheme-book.ursliska.de/
[2]: https://1drv.ms/b/s!AnEPVISZ-Wlbj5tzMF32JKKQnVavjg?e=zObsAq


-- Aaron Hill

Re: # and $ (was Re: metronome-mark-alignment)

[David Kastrup]

Aaron Hill  writes:

> On 2020-01-14 2:39 pm, David Kastrup wrote:
>> Ok, let me try again.
>> # and $ differ in several respects.  # inserts Scheme constructs in
>> places where LilyPond can decide how they fit into its syntax without
>> looking at their value first.  In that case, evaluation of those Scheme
>> expressions is done at the time the expression is being actually used
>> which tends to be what one expects.  In contrast, $ can be used in
>> places where the value of the expression will have an impact on just
>> how
>> LilyPond will put them into context.  For example, a $ expression
>> evaluating to a duration may be combined with a preceding pitch to form
>> a note, while having it evaluate to another pitch in the same place
>> will
>> form a separate note.
>> This syntactic flexibility may lead to the expression getting
>> evaluated
>> at an unexpectedly early point of time, namely when LilyPond needs to
>> know its type in order to decide that it does not actually combine with
>> the preceding expression.
>
> Many thanks for the clearer picture.
>
> Would you be able to clarify how # and $ differ with regards to making
> copies of music?  Consider:

# does no processing of its own, $ creates a copy when given music.

> 
> \version "2.19.83"
>
> notes = \fixed c' { g4 fis8 g a2 }
>
> test = #(define-music-function (which music) (symbol? ly:music?)
>   (define (red-notes music)
> (if (memq 'note-event (ly:music-property music 'types))
>   (set! (ly:music-property music 'tweaks) '((color 1 0 0
> music)
>   (case which
> ((hash) #{ {
> #music % will be red
> $music % will NOT be red
> \musicMap #red-notes #music % modifies music
> #music % will be red
> $music % will be red
>   } #})
> ((dollar) #{ {
> #music % will NOT be red
> $music % will NOT be red
> \musicMap #red-notes $music % modifies a copy of music
> #music % will NOT be red
> $music % will NOT be red
>   } #})))
>
> \test hash \notes
> \test dollar \notes
> 
>
> The resulting behavior largely makes sense with one exception:
>
> Why does the use of \musicMap against #music in the first \test not
> have an impact on \notes itself?  Is there an implicit copy of \notes
> when invoking the \test function that goes beyond the use of # and $
> within?

No, it's that \notes is identical to $notes (apart from the syntax) in
that it creates a copy.  So whenever you write \something and do
something with it, whatever you do with it will not affect the original
stuff stored in the Scheme variable something .  Basically the idea is
that you get a copy whenever you reference a variable, but the music
passed around in expressions and from one function to another does not
get copied unless you need more than one version of it.

-- 
David Kastrup

Re: Scheme question

[Arle Lommel]

> Since you have a variable, you would need the quasi-quote feature if you 
> wanted the shorthand: `(,padding . 0)  But, (cons padding 0) should 
> work.
> 
> 
> -- Aaron Hill

Thank you, Aaron. The quasi-quote version did it.

Is that feature explained anywhere in the documentation? I don’t recall seeing 
anything like that anywhere and searching for “quasi-quote scheme Lilypond” 
doesn’t return anything relevant.

If it isn’t there, this seems like rather a nice thing to have in the 
documentation.

-Arle

Re: Scheme question

[Aaron Hill]

On 2020-01-14 5:01 pm, Arle Lommel wrote:

I am a total neophyte to Scheme, but not to coding. I’ve written a
simple function, but it does not work (I’ve reduced it to just the
problematic lines. Can anyone tell me how to write the line indicated
below?

shifter =
#(define-music-function
  (parser location padding)
  (number?)
  #{
\once \override Accidental.extra-offset = #(cons padding . 0) %<- 
THIS LINE

  #}
)

The relevant errors it throws when invoked are:

error: GUILE signaled an error for the expression beginning here
warning: type check for `extra-offset' failed; value `#'
must be of type `pair of numbers’

The closest thing I can find to explaining how this works is here:
http://lilypond.org/doc/v2.18/Documentation/extending/scheme-function-definitions

But I’m apparently missing something very obvious.


A pair of numbers would be (cons 1 2) or '(1 . 2) as the quoted 
shorthand.


Since you have a variable, you would need the quasi-quote feature if you 
wanted the shorthand: `(,padding . 0)  But, (cons padding 0) should 
work.



-- Aaron Hill

Re: Three short questions from Bartók around fingering, about 90% there

[Arle Lommel]

> On Jan 14, 2020, at 18:05, Mark Stephen Mrotek  wrote:
> 
> Arle,
>  
> Add these before the b!
>  
> \once \override Accidental.extra-offset = #'(3 . 0)
> \once \override NoteColumn.force-hshift = #2.5
>  
> Mark

Thanks. I’m finding I have to play around with the numbers a bit and add an 
Accidental.extra-offset elsewhere, but this is really useful.

-Arle

Scheme question

[Arle Lommel]

I am a total neophyte to Scheme, but not to coding. I’ve written a simple 
function, but it does not work (I’ve reduced it to just the problematic lines. 
Can anyone tell me how to write the line indicated below?

shifter =
#(define-music-function
  (parser location padding)
  (number?)
  #{
\once \override Accidental.extra-offset = #(cons padding . 0) %<- THIS LINE
  #}
)

The relevant errors it throws when invoked are:

error: GUILE signaled an error for the expression beginning here
warning: type check for `extra-offset' failed; value `#' must be 
of type `pair of numbers’

The closest thing I can find to explaining how this works is here: 
http://lilypond.org/doc/v2.18/Documentation/extending/scheme-function-definitions

But I’m apparently missing something very obvious.

-Arle

Re: Distance of a grob from its reference point

[Paolo Prete]

On Tue, Jan 14, 2020 at 10:10 PM kieren_macmillan kieren_macmillan <
kieren_macmil...@sympatico.ca> wrote:

> Hi Paolo (et al.),
>
> > Why do I need to move a grob?
> > For the simple fact that any score, in order to have a * professional *
> > appearance, needs HUNDREDS of these adjustments.
> > Even the simplest ones.
>
> I think we all agree on that.
>
> Now… At one end of a philosophical spectrum lies the point where everyone
> spends
> all their energy, time, and brainpower trying to make Liypond do all of
> those
> adjustments automagically; at the other end lies the point where we say
> "It’s
> good enough now; let’s build a tool by which the user can make the
> necessary
> adjustments."; and somewhere in between is the spot where energy, time, and
> brainpower goes into both those efforts. That last spot is different for
> each of
> us — some want to spend more time improving Lilypond’s decision-making
> capabilities, some want to spend more time giving users tools to fix what
> LIlypond doesn’t do perfectly.
>
>
Hello Kieren

There's a misunderstood of that, I think.
I did not make my editor for fixing what Lilypond doesn't do perfectly.
Really not.
I made the editor for doing:

1) placements that CANNOT be done automagically  in *any case*. I can
assure (and totally convinced) that even with a *perfect* Lilypond, too
many things still have to be adjusted manually.
Even with the most sophisticated A.I (artificial intelligence) or a neural
network you cannot adjust many things automagically. It's simply
impossible.
It's like you say: "I want a tool that automagically write a romance".
Impossible. You have to deal with too many things, and you must have an
*aesthetic* perspective of things that a calculator won't have nor now nor
in the next 500 years (at least)

2) my editor doesn't fix anything that Lilypond doesn't do perfectly. It
only maps the same properties that you are forced to hand-write by using a
*RULER* (with staff-space units).
And it reports them on the text score. Exactly as you do by hand-writing.
Please understand that this is absolutely not a WYSIWYG editor. Instead,
it's an *assistant* for text-writing. It assists the user in avoiding the
trial-and-error-process. This is common feature for many *text* editors,
not for WYSIWYG ones.
That's all. Sorry if I have to insist on that, but there seems to be a
general big misunderstood of what I'm doing.

I don't like WYSIWYG editors for music. And I don't want to use them. I
think they end in slowing down the editing process. That's only my opinion
(some other experienced people do prefer WYSIWYG stuff). And that's why I
would not use Finale even if it becomes GPL/Linux fully supported.

Anyway, as said before, I'm not trying to convince anyone about what I
think. Simply: I don't have time to join endless discussions. Then, I do
what I need for my scores, and share it, hoping it can be useful for other
people too (so to receive support as feedback, which speeds up the
development of the editor project). This is how FSF works.

That said, I really thank you for your support so far and hope we can find
a solution for the starting offset problem.

Best,
Paolo

>
>

Re: Syntax highlighting

[Craig Dabelstein]

Thank you gentlemen,

I'll have a go at taking the python-ly work and seeing if I can use it work
to make syntax highlighting with pygments. It's highly possible that I will
totally fail, but I'll give it a try.

Craig


On Tue, 14 Jan 2020 at 23:38, Federico Bruni  wrote:

> Il giorno mar 14 gen 2020 alle 12:34, Urs Liska 
> ha scritto:
> > Pygments is also what Pandoc uses for its syntax highlighting, so that
> > would also make sense for that (e.g. generating PDF documentation from
> > Markdown).
>
> Are you sure?
> I think that pygments is the name of the default style in Pandoc, but
> the highlight library is a Haskell library called skylighting:
> https://pandoc.org/MANUAL.html#syntax-highlighting
> https://github.com/jgm/skylighting
>
> It seems Wilbert contributed the definitions for lilypond syntax:
>
> https://github.com/KDE/syntax-highlighting/blob/master/data/syntax/lilypond.xml
>
> About 10 days ago I wanted to share this in the open issue in
> Frescobaldi tracker but I forgot to do it.
> I remember I found the lilypond file definition somewhere else...
>
>
>
>

-- 
Craig Dabelstein
Owner
Maxime's Music
M: 0404884173
A: 19 Twelfth Ave,  Kedron QLD 4031, Australia
W: concertbandmusicstore.com E:
cr...@concertbandmusicstore.com 

Extending manual (was Re: metronome-mark-alignment)

[Daniel Rosen]

> -Original Message-
> From: David Kastrup [mailto:d...@gnu.org]
> Sent: Tuesday, January 14, 2020 5:39 PM
> To: Thomas Morley 
> Cc: Daniel Rosen ; lilypond-user Mailing List (lilypond-
> u...@gnu.org) ; David Nalesnik
> 
> Subject: Re: metronome-mark-alignment
> 
> 
> Ok, let me try again.
> 
> # and $ differ in several respects.  # inserts Scheme constructs in places
> where LilyPond can decide how they fit into its syntax without looking at
> their value first.  In that case, evaluation of those Scheme expressions is
> done at the time the expression is being actually used which tends to be
> what one expects.  In contrast, $ can be used in places where the value of
> the expression will have an impact on just how LilyPond will put them into
> context.  For example, a $ expression evaluating to a duration may be
> combined with a preceding pitch to form a note, while having it evaluate to
> another pitch in the same place will form a separate note.
> 
> This syntactic flexibility may lead to the expression getting evaluated at an
> unexpectedly early point of time, namely when LilyPond needs to know its
> type in order to decide that it does not actually combine with the preceding
> expression.
> 
> --
> 
> So no talk about lexer and parser and lookahead and tokens.

This is better, but I still have trouble grasping precisely what it means, and 
I think that has to do with my lack of knowledge about how the program actually 
works. I've been using LilyPond for a long time so I have a pretty good grasp 
of the syntax for creating a score, and I know how to find the stuff I don't 
know off the top of my head; but my understanding of what happens once I've 
finished the text file(s) runs more or less like this:

1. Click "Compile" button in Frescobaldi (or run program from command line)
2. *magic*
3. PDF exists

So it occurs to me that an overview "for Dummies(r)" of what really happens 
during "step 2," on a conceptual level, might be helpful for someone like me. I 
don't know if such an overview exists, or whether anyone has the time and 
ability to write one; and, moreover, depending on how much basic computer 
science it would need to cover, it might be outside the scope of this 
community---I have no idea, I'm just spitballing. But if it is doable, I 
suspect it would go a long way towards making the manual more readable for 
non-programmers. (Obviously if it does exist, someone please point me to it.)

DR

Re: metronome-mark-alignment

[David Kastrup]

Thomas Morley  writes:

> Am Di., 14. Jan. 2020 um 23:39 Uhr schrieb David Kastrup :
>>
>> Thomas Morley  writes:
>>
>> > Am Mo., 13. Jan. 2020 um 07:14 Uhr schrieb Daniel Rosen 
>> > :
>> >>
>> >> > The hash mark # method of embedding Scheme is a natural fit for this 
>> >> > system.
>> >> > Once the lexer sees a hash mark, it calls the Scheme reader to read one 
>> >> > full Scheme
>> >> > expression (this can be an identifier, an expression enclosed in
>> >> > parentheses, or several
>> >> > other things). After the Scheme expression is read, it is stored
>> >> > away as the value for an
>> >> > SCM_TOKEN in the grammar. Once the parser knows how to make use of this 
>> >> > token, it
>> >> > calls Guile for evaluating the Scheme expression. Since the parser
>> >> > usually requires a bit
>> >> > of lookahead from the lexer to make its parsing decisions, this
>> >> > separation of reading
>> >> > and evaluation between lexer and parser is exactly what is needed to 
>> >> > keep the
>> >> > execution of LilyPond and Scheme expressions in sync. For this
>> >> > reason, you should use
>> >> > the hash mark # for calling Scheme whenever this is feasible.
>> >>
>> >> mostly goes over my head.
>> >
>> > Would it have been more helpful, reading something at the lines of
>> > (mostly a reorder of sentences):
>> >
>> > "You should use the hash mark # for calling Scheme whenever this is 
>> > feasible.
>> >
>> > Here some details, skip them until you think you need them:
>> >
>> > The hash mark # method of embedding Scheme is a natural fit for this
>> > system. Once the lexer sees a hash mark, it calls the Scheme reader to
>> > read one full Scheme expression (this can be an identifier, an
>> > expression enclosed in parentheses, or several other things). After
>> > the Scheme expression is read, it is stored away as the value for an
>> > SCM_TOKEN in the grammar. Once the parser knows how to make use of
>> > this token, it calls Guile for evaluating the Scheme expression. Since
>> > the parser usually requires a bit of lookahead from the lexer to make
>> > its parsing decisions, this separation of reading and evaluation
>> > between lexer and parser is exactly what is needed to keep the
>> > execution of LilyPond and Scheme expressions in sync."
>>
>> Ok, let me try again.
>>
>> # and $ differ in several respects.  # inserts Scheme constructs in
>> places where LilyPond can decide how they fit into its syntax without
>> looking at their value first.  In that case, evaluation of those Scheme
>> expressions is done at the time the expression is being actually used
>> which tends to be what one expects.  In contrast, $ can be used in
>> places where the value of the expression will have an impact on just how
>> LilyPond will put them into context.  For example, a $ expression
>> evaluating to a duration may be combined with a preceding pitch to form
>> a note, while having it evaluate to another pitch in the same place will
>> form a separate note.
>>
>> This syntactic flexibility may lead to the expression getting evaluated
>> at an unexpectedly early point of time, namely when LilyPond needs to
>> know its type in order to decide that it does not actually combine with
>> the preceding expression.
>>
>> --
>>
>> So no talk about lexer and parser and lookahead and tokens.
>>
>> --
>> David Kastrup
>
> Hi David,
>
> I like this, though I like current explanations in Extending as well.
> Both give detailed infos about the topic, though, imho, for a novice
> it's kind of TMI.
>
> Let me go back some time, I started my first coding attempts somewhere
> at 2.14. or such.
> Extending Manual for 2.14 reads
> "
> 1.2.1 LilyPond Scheme syntax
>
> The Guile interpreter is part of LilyPond, which means that Scheme can
> be included in LilyPond input files. The hash mark # is used to tell
> the LilyPond parser that the next value is a Scheme value.
>
> Once the parser sees a hash mark, input is passed to the Guile
> interpreter to evaluate the Scheme expression. The interpreter
> continues to process input until the end of a Scheme expression is
> seen.
> [...]
> "
> Is this wrong? Well, incomplete, at least nowadays... but not that bad
> for a first approximation.
>
> What I'm trying to say: I'd prefer some simplified/summarized info at
> first sight with the option to read up more, if wished and/or needed.
>
> WDYT?

We need to put out the difference between # and $ even for beginners.
Basically # can only be used for stuff where you can figure out the
meaning in context without even looking at the Scheme expression
involved.  Which has the advantage that the Scheme expression does not
get looked at earlier than expected.  While $ (like \ ) can change the
interpretation of stuff around it depending on what it evaluates to but
that means that LilyPond may try evaluating it earlier than expected.

The typical problem case we have is

blabla = something
\blabla

when LilyPond is not sure that something is a complete 

# and $ (was Re: metronome-mark-alignment)

[Aaron Hill]

On 2020-01-14 2:39 pm, David Kastrup wrote:

Ok, let me try again.

# and $ differ in several respects.  # inserts Scheme constructs in
places where LilyPond can decide how they fit into its syntax without
looking at their value first.  In that case, evaluation of those Scheme
expressions is done at the time the expression is being actually used
which tends to be what one expects.  In contrast, $ can be used in
places where the value of the expression will have an impact on just 
how

LilyPond will put them into context.  For example, a $ expression
evaluating to a duration may be combined with a preceding pitch to form
a note, while having it evaluate to another pitch in the same place 
will

form a separate note.

This syntactic flexibility may lead to the expression getting evaluated
at an unexpectedly early point of time, namely when LilyPond needs to
know its type in order to decide that it does not actually combine with
the preceding expression.


Many thanks for the clearer picture.

Would you be able to clarify how # and $ differ with regards to making 
copies of music?  Consider:



\version "2.19.83"

notes = \fixed c' { g4 fis8 g a2 }

test = #(define-music-function (which music) (symbol? ly:music?)
  (define (red-notes music)
(if (memq 'note-event (ly:music-property music 'types))
  (set! (ly:music-property music 'tweaks) '((color 1 0 0
music)
  (case which
((hash) #{ {
#music % will be red
$music % will NOT be red
\musicMap #red-notes #music % modifies music
#music % will be red
$music % will be red
  } #})
((dollar) #{ {
#music % will NOT be red
$music % will NOT be red
\musicMap #red-notes $music % modifies a copy of music
#music % will NOT be red
$music % will NOT be red
  } #})))

\test hash \notes
\test dollar \notes


The resulting behavior largely makes sense with one exception:

Why does the use of \musicMap against #music in the first \test not have 
an impact on \notes itself?  Is there an implicit copy of \notes when 
invoking the \test function that goes beyond the use of # and $ within?



-- Aaron Hill

Re: metronome-mark-alignment

[Thomas Morley]

Am Di., 14. Jan. 2020 um 23:39 Uhr schrieb David Kastrup :
>
> Thomas Morley  writes:
>
> > Am Mo., 13. Jan. 2020 um 07:14 Uhr schrieb Daniel Rosen 
> > :
> >>
> >> > The hash mark # method of embedding Scheme is a natural fit for this 
> >> > system.
> >> > Once the lexer sees a hash mark, it calls the Scheme reader to read one 
> >> > full Scheme
> >> > expression (this can be an identifier, an expression enclosed in
> >> > parentheses, or several
> >> > other things). After the Scheme expression is read, it is stored
> >> > away as the value for an
> >> > SCM_TOKEN in the grammar. Once the parser knows how to make use of this 
> >> > token, it
> >> > calls Guile for evaluating the Scheme expression. Since the parser
> >> > usually requires a bit
> >> > of lookahead from the lexer to make its parsing decisions, this 
> >> > separation of reading
> >> > and evaluation between lexer and parser is exactly what is needed to 
> >> > keep the
> >> > execution of LilyPond and Scheme expressions in sync. For this reason, 
> >> > you should use
> >> > the hash mark # for calling Scheme whenever this is feasible.
> >>
> >> mostly goes over my head.
> >
> > Would it have been more helpful, reading something at the lines of
> > (mostly a reorder of sentences):
> >
> > "You should use the hash mark # for calling Scheme whenever this is 
> > feasible.
> >
> > Here some details, skip them until you think you need them:
> >
> > The hash mark # method of embedding Scheme is a natural fit for this
> > system. Once the lexer sees a hash mark, it calls the Scheme reader to
> > read one full Scheme expression (this can be an identifier, an
> > expression enclosed in parentheses, or several other things). After
> > the Scheme expression is read, it is stored away as the value for an
> > SCM_TOKEN in the grammar. Once the parser knows how to make use of
> > this token, it calls Guile for evaluating the Scheme expression. Since
> > the parser usually requires a bit of lookahead from the lexer to make
> > its parsing decisions, this separation of reading and evaluation
> > between lexer and parser is exactly what is needed to keep the
> > execution of LilyPond and Scheme expressions in sync."
>
> Ok, let me try again.
>
> # and $ differ in several respects.  # inserts Scheme constructs in
> places where LilyPond can decide how they fit into its syntax without
> looking at their value first.  In that case, evaluation of those Scheme
> expressions is done at the time the expression is being actually used
> which tends to be what one expects.  In contrast, $ can be used in
> places where the value of the expression will have an impact on just how
> LilyPond will put them into context.  For example, a $ expression
> evaluating to a duration may be combined with a preceding pitch to form
> a note, while having it evaluate to another pitch in the same place will
> form a separate note.
>
> This syntactic flexibility may lead to the expression getting evaluated
> at an unexpectedly early point of time, namely when LilyPond needs to
> know its type in order to decide that it does not actually combine with
> the preceding expression.
>
> --
>
> So no talk about lexer and parser and lookahead and tokens.
>
> --
> David Kastrup

Hi David,

I like this, though I like current explanations in Extending as well.
Both give detailed infos about the topic, though, imho, for a novice
it's kind of TMI.

Let me go back some time, I started my first coding attempts somewhere
at 2.14. or such.
Extending Manual for 2.14 reads
"
1.2.1 LilyPond Scheme syntax

The Guile interpreter is part of LilyPond, which means that Scheme can
be included in LilyPond input files. The hash mark # is used to tell
the LilyPond parser that the next value is a Scheme value.

Once the parser sees a hash mark, input is passed to the Guile
interpreter to evaluate the Scheme expression. The interpreter
continues to process input until the end of a Scheme expression is
seen.
[...]
"
Is this wrong? Well, incomplete, at least nowadays... but not that bad
for a first approximation.

What I'm trying to say: I'd prefer some simplified/summarized info at
first sight with the option to read up more, if wished and/or needed.

WDYT?

Cheers,
  Harm

RE: Three short questions from Bartók around fingering, about 90% there

[Mark Stephen Mrotek]

Arle,

 

Add these before the b!

 

\once \override Accidental.extra-offset = #'(3 . 0)

\once \override NoteColumn.force-hshift = #2.5

 

Mark

 

 

From: lilypond-user [mailto:lilypond-user-bounces+carsonmark=ca.rr@gnu.org] 
On Behalf Of Arle Lommel
Sent: Tuesday, January 14, 2020 2:30 PM
To: Lilypond-User Mailing List 
Subject: Three short questions from Bartók around fingering, about 90% there

 

Got two more small issues from Bartók. I’m trying to recreate things like this:

 



 

In the example on the left, he is using the bracket to make it clear that the 
B♭ and B♮ are played simultaneously with two different fingers.

In the example on the right

 

 I’ve got a minimum example that comes very close to what I need, but

 

\version "2.19.83"

\score {

  <<

\new Staff \relative c' {

  \key c \major

  << 

{

  \once \override NoteColumn.force-hshift = #2.5

  b'!16[ cis16 d8] d4

} 

  \\ 

{ 

  \override Fingering.staff-padding = #'()

  \once \override Fingering.extra-offset = #'(1.3 . 0) bes2^\finger 
\markup "⎴"^\finger "1"^\finger "2" 

} 

  >> 

  r2 |

  \set fingeringOrientations = #'(left)

  \once \override Fingering.extra-offset = #'(3 . 0.5)

  \stemUp 8

}

  >>

  \layout { }

}

 

 

This yields the following, which is almost right:

 



 

So here are the questions:

 

1. For the horizontal bracket it’s too narrow because I’m using a Unicode box 
character to generate the bracket. Is there a better alternative that will 
scale properly to encompass the notes?

 

2. The natural sign is stuck on the wrong side of the B♭.  I’ve searched for a 
while, but I don’t find anything to tell me how to make the natural stick with 
its note. What do I do here?

 

3. Is there a better alternative for the bracket in the right example? I had to 
manually tweak it a bit to get it to look almost, but it still isn’t optimal. I 
know I could use more complex markup objects to adjust it, but I’m wondering if 
there is a better way to do this

 

-Arle

Re: metronome-mark-alignment

[David Kastrup]

Thomas Morley  writes:

> Am Mo., 13. Jan. 2020 um 07:14 Uhr schrieb Daniel Rosen :
>>
>> > The hash mark # method of embedding Scheme is a natural fit for this 
>> > system.
>> > Once the lexer sees a hash mark, it calls the Scheme reader to read one 
>> > full Scheme
>> > expression (this can be an identifier, an expression enclosed in
>> > parentheses, or several
>> > other things). After the Scheme expression is read, it is stored
>> > away as the value for an
>> > SCM_TOKEN in the grammar. Once the parser knows how to make use of this 
>> > token, it
>> > calls Guile for evaluating the Scheme expression. Since the parser
>> > usually requires a bit
>> > of lookahead from the lexer to make its parsing decisions, this separation 
>> > of reading
>> > and evaluation between lexer and parser is exactly what is needed to keep 
>> > the
>> > execution of LilyPond and Scheme expressions in sync. For this reason, you 
>> > should use
>> > the hash mark # for calling Scheme whenever this is feasible.
>>
>> mostly goes over my head.
>
> Would it have been more helpful, reading something at the lines of
> (mostly a reorder of sentences):
>
> "You should use the hash mark # for calling Scheme whenever this is feasible.
>
> Here some details, skip them until you think you need them:
>
> The hash mark # method of embedding Scheme is a natural fit for this
> system. Once the lexer sees a hash mark, it calls the Scheme reader to
> read one full Scheme expression (this can be an identifier, an
> expression enclosed in parentheses, or several other things). After
> the Scheme expression is read, it is stored away as the value for an
> SCM_TOKEN in the grammar. Once the parser knows how to make use of
> this token, it calls Guile for evaluating the Scheme expression. Since
> the parser usually requires a bit of lookahead from the lexer to make
> its parsing decisions, this separation of reading and evaluation
> between lexer and parser is exactly what is needed to keep the
> execution of LilyPond and Scheme expressions in sync."

Ok, let me try again.

# and $ differ in several respects.  # inserts Scheme constructs in
places where LilyPond can decide how they fit into its syntax without
looking at their value first.  In that case, evaluation of those Scheme
expressions is done at the time the expression is being actually used
which tends to be what one expects.  In contrast, $ can be used in
places where the value of the expression will have an impact on just how
LilyPond will put them into context.  For example, a $ expression
evaluating to a duration may be combined with a preceding pitch to form
a note, while having it evaluate to another pitch in the same place will
form a separate note.

This syntactic flexibility may lead to the expression getting evaluated
at an unexpectedly early point of time, namely when LilyPond needs to
know its type in order to decide that it does not actually combine with
the preceding expression.

--

So no talk about lexer and parser and lookahead and tokens.

-- 
David Kastrup

Re: Running LilyPond on Amazon Linux 2

[Peter Anglea]

I know I’m not the first to run LilyPond in a Lambda function. For instance, 
LilyBin (http://lilybin.com ) has been using Lambda and S3 
for a while to power their website. I took some cues from their site (which is 
open source on Github), but ultimately went my own route and made a custom 
Lambda function for my purposes.

I have started a website focused on engraving hymns for church music called 
Doxology. https://doxology.app . It allows users to 
generate custom sheet music for hymns, whether it be for piano, guitar, non-C 
instruments, or for projection. I use LilyPond to make the engravings which are 
customizable and transposable. The music files and dependencies (including 
LilyPond itself) are part of my Lambda function. The user customizations (ie. 
key signature, formatting, etc.) are fed into a Scheme evaluation that 
customizes the main template file for the song, if that makes sense. 

Since generating a score in LilyPond takes a good bit of bandwidth, I decided 
to offload that portion of my site to the cloud. I estimate I may be able to 
generate up to 100,000 hymn scores a month without exceeding the free tier. I’m 
still in “beta” so we’ll see if it really works over time. But so far, I’m 
happy with it.

> On Jan 14, 2020, at 1:14 PM, Saul Tobin  wrote:
> 
> I'm curious to know about your use case/workflow for running Lilypond in AWS 
> Lambda. Seems interesting.
> 
> Saul
> 
> On Tue, Jan 14, 2020, 6:34 AM Peter Anglea  > wrote:
> I think I got it fixed… recording this here for anyone else who stumbles upon 
> the same issue as I did.
> 
> I downloaded an RPM containing libcrypt.so.1, extracted the file, and put it 
> inside LilyPond’s /usr/lib/ directory. I made sure to include the LilyPond 
> directory as part of the include path for my function. Probably not the best 
> long-term fix… if I update LilyPond in the future, I’ll need to remember to 
> re-add libcrypt... but for now it works and my testing has generated scores 
> without issue.
> 
> It should be noted that I am not a Linux pro, and am a little out of my depth 
> on this one. So if there’s a more obvious fix, I’d love to hear about it.
> 
> > On Jan 11, 2020, at 12:07 PM, Peter Anglea  > > wrote:
> > 
> > I’ve been running LilyPond on AWS Lambda for some time now, but recently 
> > have been forced to upgrade my runtime from Node 8.x to Node 12.x due to 
> > Node 8.x becoming deprecated. However, in my testing, LilyPond does not 
> > work in either the Node 10.x or Node 12.x runtimes. I get the following 
> > error:
> > 
> > lilypond: error while loading shared libraries: libcrypt.so.1: cannot open 
> > shared object file: No such file or directory
> > 
> > Note: I have been using the binary for GNU/Linux 64: LilyPond 2.19.83-1
> > 
> > From what I can tell, the difference is that AWS Lambda’s Node 12.x runtime 
> > uses the “Amazon Linux 2” distro instead of regular “Amazon Linux” distro 
> > used with the Node 8.x runtime. Also, my research seems to indicate the 
> > error is related to Amazon Linux 2 using a different version of openssl 
> > from before… but that’s about the limit of what I understand.
> > 
> > Is anyone else successfully running LilyPond on AWS Lambda Node 12.x? Is 
> > there another binary better suited to that particular distro? Any other 
> > suggestions for overcoming the error message above?
> > 
> > Thanks in advance for any help. I’m kinda stuck here, but this mailing list 
> > has proven helpful many times, so… fingers crossed! :)
> 
> 

Re: Unusual cross-staff stem in Bartók

[Andrew Bernard]

Hi Arie,

Not at all uncommon. In the New Complexity scores that I engrave for a
colleague composer we have this continuously, in the piano music. It's
actually a fairly standard modernist notation, and true enough indicates
the distribution of hands but also that this is a single dyadic chord
event, not multiple voices. I didn't answer yet as we tend to have the
noteheads on the same side, but for the case with the notehead on the
opposite, you now have lots o good solutions. So don;t think this is just
Bartok.

Andrew

Re: metronome-mark-alignment

[Thomas Morley]

Am Mo., 13. Jan. 2020 um 07:14 Uhr schrieb Daniel Rosen :
>
> > -Original Message-
> > From: Thomas Morley [mailto:thomasmorle...@gmail.com]
> > Sent: Sunday, January 12, 2020 6:04 PM
> > To: Daniel Rosen 
> > Cc: David Nalesnik ; lilypond-user Mailing List
> > (lilypond-user@gnu.org) 
> > Subject: Re: metronome-mark-alignment
> >
> > Though, I've already heard about difficulties about using scheme to write
> > own extension pretty often.
> > Just like you say:
> >
> > Am So., 12. Jan. 2020 um 22:19 Uhr schrieb Daniel Rosen
> > :
> > > I want to express how grateful I am to this list for being so helpful
> > > with this issue, since I have zero knowledge about how to use Scheme.
> > > (I've tried to tackle the Extending manual on multiple occasions, but
> > > I find it extremely difficult to understand, probably because I have
> > > no programming experience.)
> >
> > I have the suspicion it's not, because guile is difficult, at least so far 
> > as the
> > scheme-tutorial reaches out, but because it's difficult to find a way to 
> > modify
> > LilyPond's default with scheme. In the sense of:
> > What am I supposed to do with my new basic guile-knowledge?
> > Note that most used tools in David's and my coding are _not_ native guile-
> > procedures, but are defined in the LilyPond-source.
> > Therefore I think the problem is more poor documentation of those lily-
> > defined tools and/or the lack of commented code-examples using them.
> >
> > Could you confirm or is it something else preventing you from starting to
> > code on your own?
>
> The most important thing preventing me from starting to code on my own is 
> simple: I don't have to. LilyPond natively supports so many different 
> notational constructs that I run into problems relatively infrequently. And 
> in the cases when I do, between the manuals, the LSR, and this list 
> (primarily the archives, and occasionally responses to my own submissions), 
> I've been able to simply copy-paste my way out of practically any jam I've 
> found myself in for as long as I've used LilyPond (which must be almost ten 
> years).
>

Well, does this mean LilyPond is too good, the Documentation
overwhelming nice and the mailing-list far too active and helpful?
LOL

> As far as the Extending manual goes, though... I could be wrong, but it seems 
> to assume a basic working knowledge of how computer programs and programming 
> languages work that I simply don't have. Going through it, I think to myself 
> that I would need to have one-on-one tutoring sessions with someone in order 
> to really understand it. Take 1.2.1 
> (http://lilypond.org/doc/v2.19/Documentation/extending/lilypond-scheme-syntax)
>  as an example. This paragraph
>
> > The hash mark # method of embedding Scheme is a natural fit for this system.
> > Once the lexer sees a hash mark, it calls the Scheme reader to read one 
> > full Scheme
> > expression (this can be an identifier, an expression enclosed in 
> > parentheses, or several
> > other things). After the Scheme expression is read, it is stored away as 
> > the value for an
> > SCM_TOKEN in the grammar. Once the parser knows how to make use of this 
> > token, it
> > calls Guile for evaluating the Scheme expression. Since the parser usually 
> > requires a bit
> > of lookahead from the lexer to make its parsing decisions, this separation 
> > of reading
> > and evaluation between lexer and parser is exactly what is needed to keep 
> > the
> > execution of LilyPond and Scheme expressions in sync. For this reason, you 
> > should use
> > the hash mark # for calling Scheme whenever this is feasible.
>
> mostly goes over my head. I like to think I understand the basic idea, but I 
> can never be sure because I'm unfamiliar with so much of the language: 
> "lexer," "Scheme reader," "SCM_TOKEN," "parser." And the rest of the page is 
> no better. So while I'm sure that you're right about the manual's 
> ineffectiveness in helping readers transfer their knowledge of Guile into 
> practice within LilyPond, in my case the issue lies even deeper than 
> that---I'm never sure whether I'm really understanding what the manual is 
> trying to tell me.
>
> Of course, it may be that the manual isn't meant to be aimed at a complete 
> novice like myself; but if it is, then it definitely needs an overhaul.
>
> DR

Hi,

David answered already, let me add my 2 cents.

Part of the problem is the need to adress both, novices _and_
experienced programmers...

Would it have been more helpful, reading something at the lines of
(mostly a reorder of sentences):

"You should use the hash mark # for calling Scheme whenever this is feasible.

Here some details, skip them until you think you need them:

The hash mark # method of embedding Scheme is a natural fit for this
system. Once the lexer sees a hash mark, it calls the Scheme reader to
read one full Scheme expression (this can be an identifier, an
expression enclosed in parentheses, or several other things). 

Re: Distance of a grob from its reference point

[kieren_macmillan kieren_macmillan]

Hi Paolo (et al.),

> Why do I need to move a grob?
> For the simple fact that any score, in order to have a * professional *
> appearance, needs HUNDREDS of these adjustments.
> Even the simplest ones.

I think we all agree on that.

Now… At one end of a philosophical spectrum lies the point where everyone spends
all their energy, time, and brainpower trying to make Liypond do all of those
adjustments automagically; at the other end lies the point where we say "It’s
good enough now; let’s build a tool by which the user can make the necessary
adjustments."; and somewhere in between is the spot where energy, time, and
brainpower goes into both those efforts. That last spot is different for each of
us — some want to spend more time improving Lilypond’s decision-making
capabilities, some want to spend more time giving users tools to fix what
LIlypond doesn’t do perfectly.

> This type of music requires so many adjustments that it is impossible to
> achieve with Lilypond, unless you spend a very very very long time with the
> trial and error process.

The point is that Lilypond v1 required many, many times more adjustments than
Lilypond v2.19.83 does, because people took the time to improve Lilypond’s
engines and algorithms and decision-making functions. If everyone had spent
their time building a fabulous GUI on top of [stagnated] Lilypond v1, we’d be in
the same boat now that Finale and Sibelius are in: data entry is really no
faster than in Lilypond, but it takes hours and hours of tweaking just to get to
Lilypond’s default output.

> Without having to use the combination with Inkscape, because it also has many
> disadvantages.

For the record, I do all my engraving and drawing in Lilypond (leveraging the
edition-engraver), and never take it out to Inkscape — even when I’m drawing
things like Tonnetz graphs (e.g.,
https://www.mail-archive.com/lilypond-user@gnu.org/msg131758/Inte__gral32_ProtoHarmony_Ex8c.pdf).

> Try making these micro- (or big) adjustments with just the text editor. You
> will go crazy.

I do hope you make your tool able to generate tweaks that go into presentation
code/files that are separate from the content code. I use the edition-engraver
for all my Lilypond scores, and as non-crazy-making as that is by itself, I
would love to have the option of using a tool like yours to calculate, write
out, and modify the tweak code.

Cheers,
Kieren.

Re: Distance of a grob from its reference point

[Paolo Prete]

Sorry,  broken link
Here's the correct one:

https://filebin.net/sy6z7b39fcounb5j



>
> I am a convinced open source developer and already 10 years ago I used
> Lilypond to create my scores, because I wanted to avoid Finale, Sibelius
> and other proprietary software (which I used before). In the end, I was
> forced to use the Lilypond + Inkscape combination, and here is an example
> of my scores:
>
> https://file.io/a5phCU
>
>
>>

Re: Distance of a grob from its reference point

[Paolo Prete]

Hi Aaron,

thanks for the detailed reply.

Why do I need to move a grob?
For the simple fact that any score, in order to have a * professional *
appearance, needs HUNDREDS of these adjustments.
Even the simplest ones.
I am a convinced open source developer and already 10 years ago I used
Lilypond to create my scores, because I wanted to avoid Finale, Sibelius
and other proprietary software (which I used before). In the end, I was
forced to use the Lilypond + Inkscape combination, and here is an example
of my scores:

https://file.io/a5phCU

This type of music requires so many adjustments that it is impossible to
achieve with Lilypond, unless you spend a very very very long time with the
trial and error process. But I can assure you that the same adjustments are
also necessary for nineteenth-century scores, if you want to give them a
professional look. I can show you many and many examples.

This year I started writing music again and I didn't want to abandon the
idea of using Lilypond. Because I needed something less time consuming than
Finale, because I don't use proprietary software and because I use Linux.
So I decided to go back to Lilypond by writing an editor that allows you to
make all these adjustments and at the same time guarantees you the power of
Lilypond. Without having to use the combination with Inkscape, because it
also has many disadvantages. Fortunately, thanks to the script I created
for the curves, I understood that my idea could also be extended to the
other grobs. So I dedicated myself to the LilyJSSVG editor.

Here is what came out:

https://github.com/paolo-prete/LilyJSSVG/blob/master/LilyJSSVG.gif

Try making these micro- (or big) adjustments with just the text editor. You
will go crazy.

Note one * very important * thing. This Editor adds nothing and nothing to
Lilypond's logic. And it doesn't add any new feature. None at all. It
simply allows you to modify the properties of the grobs * exactly as you do
with Lilypond *. Except that the positions of these properties are
calculated with the mouse instead of the tedious trial and error method.

Then, in your .ly file you will have

\ jsBeam "id" "positions" # '(1. 3)

instead of

\ override Beam.positions = # '(1 .3)

TBH I don't understand what's strange or what's "misuse" in all of this
(I'm not referring to you: it's a general discussion). And in any case, I
continue on my way, even if I will not receive general support for the
project: in fact I am already using this project for my compositions and I
am getting a result absolutely identical to that of the above pdf extract
of my score.

A GUI for cross-staff editing has already been implemented in the editor.
And in the next few days I will show you how it is possible to edit very
complex piano scores with this feature.

Now, going back to my initial question, since you have given me very kind
help, I am trying to pull out from Lilypond (and put in my editor) also
properties like X-offset, padding etc. I can accomplish all this in a short
time. I just need to know what is the offset of the objects from their
reference point, depending on the property.

It is also very important to me if someone helps me clean up the Scheme
code, because I don't have time to learn the details of the language. The
code works, but needs to be cleaned up of very noisy (and long) statements
which can be replaced by better syntax.

And of course it is also useful if someone helps me prepare the
documentation for the editor. But first of all, I want to implement the
properties discussed above.

Thanks again.
Best
P

On Tue, Jan 14, 2020 at 9:35 AM Aaron Hill  wrote:

> On 2020-01-13 7:05 pm, Paolo Prete wrote:
> > 1) its *calculated* distance from its reference point? (from what I
> > see,
> > the reference Y of an OttavaBracket is the middle line of the
> > associated
> > staff...)
> > I tried ly:grob-staff-position (see the snippet below), but it doesn't
> > seem
> > to give this info (and it's not documented)
>
> Well, "staff-position" is likely not the metric you want, as its units
> appear to be in half staff-spaces rather than staff-spaces like other
> metrics, making its result twice as much as you might expect.  It might
> even be impacted by things like \magnifyStaff, making its value even
> less useful.
>
> But put that aside.  If we borrow some of the underlying logic, we get
> the following:
>
> 
> \version "2.19"
>
> drawRelativePosition = #(define-music-function
>(grob-path) (symbol-list?)
>(define (proc grob)
>  (let* ((ss (ly:grob-object grob 'staff-symbol))
> (refp (ly:grob-common-refpoint grob ss Y))
> (y (- (ly:grob-relative-coordinate grob refp Y)
>   (ly:grob-relative-coordinate ss refp Y)))
> (orig (ly:grob-property grob 'stencil))
> (sten (grob-interpret-markup grob #{
>   \markup \with-dimensions-from \stencil #orig
> \overlay { \stencil #orig \with-color #red
>   

Re: Distance of a grob from its reference point

[kieren_macmillan kieren_macmillan]

Hi Aaron,

> > My mind was a little blown by the result of changing that to
> You and me both.

Well, that at least makes me feel a little better. #miserylovescompany

> > Hence the ability to offset (e.g.) an OttavaBracket precisely X staff
> > spaces while still [re-]engaging the spacing engine is neither an
> > unreasonable request, nor something that Lilypond could (or even
> > should!) try to manage automagically.
> 
> I suppose my sticking point is the need to be so precise with positioning.

As a deeply fussy engraver, I do a lot of grob-pushing in the final stages of
the process. My workflow, equipment, and eye are attuned enough that I can
easily estimate offsets with accuracy of 0.125 staff spaces at 100% page view.
Given how long compiling can take with large scores, it’s really frustrating to
try to offset a grob 0.5 spaces (through means other than extra-offset),
recompile [and go get coffee], only to come back and find that because of some
weird interaction or bug the grob only moved 0.125 spaces (or worse didn’t get
moved at all).

> I cannot envision any musical meaning for the exact vertical position of 
> an OttavaBracket. Rather, an engraver should simply desire it 
> positioned so the performer is able to notice it without distraction. 
> If it sits too close to other elements, then additional padding may be 
> necessary. And vice versa, perhaps the bracket needs to sit very 
> snuggly in some cases to look right.

Yes. But if attempts to move it by X don’t actually move it by *precisely* X,
the workflow gets slowed/interrupted.

> Moving an offending bracket as mentioned above *should* be doable
> with Y-offset or any one of the various padding properties.

That would be great — I like to leave 'extra-offset for the last possible
resort.

> That said, I have noticed that slur-padding seems to have no effect on
> OttavaBrackets. That is either 
> yet another bug or just a figment of my misunderstanding.

I also wish that every grob had a separate padding parameter for above and
below… but that’s a whole 'nother thing.

Thanks,
Kieren.

Re: Distance of a grob from its reference point

[Aaron Hill]

On 2020-01-14 7:16 am, Kieren MacMillan wrote:

My mind was a little blown by the result of changing that to

\override $grob-path .before-line-breaking = #proc

Doing so made it *deeply* and *immediately* clear that, despite being
a serious power-user of Lilypond for almost twenty years, I know
almost nothing of how it actually works.


You and me both.  I am still trying to understand what is happening, but 
just querying for relative coordinates is enough to cause problems with 
the bracket's extents as well as the Beam of all things.  I suspect that 
since ly:grob-relative-coordinate caches information behind the scenes, 
that calling it during before-line-breaking is possibly not 
well-supported.


Here is a hopefully minimal example for filing an issue:


\version "2.19.83"

{
  % Break things by calling ly:grob-relative-coordinate.
  \override Staff.OttavaBracket.before-line-breaking
= #(lambda (grob)
 (ly:grob-relative-coordinate grob
   (ly:grob-parent grob Y) Y))

  % Highlighting the beam only for clarity.
  \override Beam.color = #red

  \ottava #1 g''8 8 4
}



Hence the ability to offset (e.g.) an OttavaBracket precisely X staff
spaces while still [re-]engaging the spacing engine is neither an
unreasonable request, nor something that Lilypond could (or even
should!) try to manage automagically.


I suppose my sticking point is the need to be so precise with 
positioning.  I am not connected to the world of modern notation, but I 
cannot envision any musical meaning for the exact vertical position of 
an OttavaBracket.  Rather, an engraver should simply desire it 
positioned so the performer is able to notice it without distraction.  
If it sits too close to other elements, then additional padding may be 
necessary.  And vice versa, perhaps the bracket needs to sit very 
snuggly in some cases to look right.


Ultimately, if an appropriate tool exists but is broken in some way, it 
is best to fix that tool than invent a new one.  Moving an offending 
bracket as mentioned above *should* be doable with Y-offset or any one 
of the various padding properties.  That said, I have noticed that 
slur-padding seems to have no effect on OttavaBrackets.  That is either 
yet another bug or just a figment of my misunderstanding.



-- Aaron Hill

Re: hide Stuff

[bb]

Thank you very much for the detailed examples. I think I can make it now.

regards

Re: Running LilyPond on Amazon Linux 2

[Saul Tobin]

I'm curious to know about your use case/workflow for running Lilypond in
AWS Lambda. Seems interesting.

Saul

On Tue, Jan 14, 2020, 6:34 AM Peter Anglea  wrote:

> I think I got it fixed… recording this here for anyone else who stumbles
> upon the same issue as I did.
>
> I downloaded an RPM containing libcrypt.so.1, extracted the file, and put
> it inside LilyPond’s /usr/lib/ directory. I made sure to include the
> LilyPond directory as part of the include path for my function. Probably
> not the best long-term fix… if I update LilyPond in the future, I’ll need
> to remember to re-add libcrypt... but for now it works and my testing has
> generated scores without issue.
>
> It should be noted that I am not a Linux pro, and am a little out of my
> depth on this one. So if there’s a more obvious fix, I’d love to hear about
> it.
>
> > On Jan 11, 2020, at 12:07 PM, Peter Anglea 
> wrote:
> >
> > I’ve been running LilyPond on AWS Lambda for some time now, but recently
> have been forced to upgrade my runtime from Node 8.x to Node 12.x due to
> Node 8.x becoming deprecated. However, in my testing, LilyPond does not
> work in either the Node 10.x or Node 12.x runtimes. I get the following
> error:
> >
> > lilypond: error while loading shared libraries: libcrypt.so.1: cannot
> open shared object file: No such file or directory
> >
> > Note: I have been using the binary for GNU/Linux 64: LilyPond 2.19.83-1
> >
> > From what I can tell, the difference is that AWS Lambda’s Node 12.x
> runtime uses the “Amazon Linux 2” distro instead of regular “Amazon Linux”
> distro used with the Node 8.x runtime. Also, my research seems to indicate
> the error is related to Amazon Linux 2 using a different version of openssl
> from before… but that’s about the limit of what I understand.
> >
> > Is anyone else successfully running LilyPond on AWS Lambda Node 12.x? Is
> there another binary better suited to that particular distro? Any other
> suggestions for overcoming the error message above?
> >
> > Thanks in advance for any help. I’m kinda stuck here, but this mailing
> list has proven helpful many times, so… fingers crossed! :)
>
>
>

Re: Unusual cross-staff stem in Bartók

[Arle Lommel]

> The more things interact unnecessarily, the harder it becomes doing
> things reliably.  The more we manage to get LilyPond to behave to naive
> expectations, the more useable power the average user has at their
> convenience.
> 
> So we should not try overexercising the "music is complex, so LilyPond
> can be expected to behave in unexpected ways" excuse more than
> necessary.  I don't have enough of an overview of the problem discussed
> here to figure out whether this is the case here.
> 
> -- 
> David Kastrup



David,

Thanks for responding this thoughtfully. I may try to create a minimal example 
of this later.

In this case, the steps required weren’t obvious to naive expectations, but I 
don’t know if they could be made easier.

A construct like the following will, I think, always be an unusual one (ignore 
the bad spacing on the fingering, which I have’t yet fixed).



Why Bartók didn’t simply show the bottom D in the treble clef is an interesting 
question. I think he was trying to keep the relationship between the hands 
clear, but couldn’t quite include the upper D in a way that made sense without 
splitting it like this. Had he put the lower D in the treble clef where it more 
apparently belongs, it might have led to confusion about which hand was to play 
it.

But this is all speculation, and I’m not sure there actually is a naive way to 
expect this to work because it’s an unusual approach.

The two things in this that didn’t make sense naively are: 

1. Why I couldn’t use something like " \once \override Stem.length = #8” in a 
set of beamed notes to adjust the length of the second stem, but this did work:

\stemUp \once \override Beam.positions = #'(7 . 8) 8-.[ d!8]

I’m sure there is a good reason for this, but that one really doesn’t work the 
way a naive user would expect.

2. Why a gap appeared in a complex example that didn’t appear in Kieren’s 
example (which is what necessitated the solution above). This is what I was 
referring to with the comment about various things interacting. But I suspect 
that it would be complex to find the source of that small gap, which persisted 
when I increased the stem length of the non-beamed note to try to make them 
meet. So I’m not worried here and I think no naive answer would be possible 
here just because this is weird, and trying to account for an unusual edge case 
like this probably isn’t worth the effort.

Best,

-Arle

Re: Getting readline to work in scheme-sandbox

[Michael Käppler]

This is weird. Seems that strace does not recognize the shebang in the
lilypond script.
Could you please to try to execute the steps in the startup script directly?
I assume you used the vanilla lilypond installer and installed to your
home directory
/home/knute/:

export LD_LIBRARY_PATH="/home/knute/lilypond/usr/lib"
strace -o readlinedebug.log /home/knute/lilypond/usr/bin/lilypond
scheme-sandbox.ly



Am 14.01.2020 um 16:36 schrieb Knute Snortum:

It looks like I get an error in strace.  The sandbox is never executed:

execve("/home/knute/bin/lilypond", ["lilypond", "scheme-sandbox.ly"],
0x7ffe4792c428 /* 53 vars */) = -1 ENOEXEC (Exec format error)
strace: exec: Exec format error
+++ exited with 1 +++

---
Knute Snortum
(via Gmail)

On Mon, Jan 13, 2020 at 10:59 PM Michael Käppler  wrote:

Hi Knute,
I'm currently working on this problem. A library called
libguilereadline, that comes with guile,
does provide the interface to the libreadline library. The version we
ship with our packages, however,
seems to be broken somehow.
There are some ways to get around this. Do you have
guile-2.2-libs installed, too?
If installing guile-2.2-libs does not help either, please send me the output
of

strace -o readlinedebug.log lilypond scheme-sandbox.ly

where you type the mentioned commands for activating readline.

Regards,
Michael

Am 14.01.2020 um 01:31 schrieb Knute Snortum:

I recently discovered the scheme-sandbox in LilyPond and I want to get
line editing to work.  In scheme-sandbox.ly the comments say:

% One typical thing you might want to put there is
% (use-modules (ice-9 readline))
% (activate-readline)
% in order to activate command line editing for interactive sessions.

I'm assuming that these are commands to type into the sandbox.  But
when I do this I get an error:

guile> (use-modules (ice-9 readline))
ERROR: readline is not provided in this Guile installation
ABORT: (misc-error)

When I search for installed packages at the Linux command line, I see this:

libreadline8/eoan,now 8.0-3 amd64 [installed,automatic]

Any idea why readline is not available?

My system is Ubuntu 19.10, Guile is 2.2 and LilyPond is 2.19.83.

---
Knute Snortum
(via Gmail)

Re: Unusual cross-staff stem in Bartók

[David Kastrup]

Arle Lommel  writes:

>> Hope that helps more!
>> Kieren.
>
>
> Thanks much. One of the challenging things for folks like me who dip
> in and out is keeping track of all the different ways that things can
> be done and how all the elements interact. But that is inherent to
> this: Music notation is orders of magnitude more complex than printed
> text.
>
> There is a continual learning curve, but I keep coming back to
> Lilypond because of all the things I *can’t* reliably do in other
> software. It’s great stuff!

The more things interact unnecessarily, the harder it becomes doing
things reliably.  The more we manage to get LilyPond to behave to naive
expectations, the more useable power the average user has at their
convenience.

So we should not try overexercising the "music is complex, so LilyPond
can be expected to behave in unexpected ways" excuse more than
necessary.  I don't have enough of an overview of the problem discussed
here to figure out whether this is the case here.

-- 
David Kastrup

Re: Getting readline to work in scheme-sandbox

[Knute Snortum]

It looks like I get an error in strace.  The sandbox is never executed:

execve("/home/knute/bin/lilypond", ["lilypond", "scheme-sandbox.ly"],
0x7ffe4792c428 /* 53 vars */) = -1 ENOEXEC (Exec format error)
strace: exec: Exec format error
+++ exited with 1 +++

---
Knute Snortum
(via Gmail)

On Mon, Jan 13, 2020 at 10:59 PM Michael Käppler  wrote:
>
> Hi Knute,
> I'm currently working on this problem. A library called
> libguilereadline, that comes with guile,
> does provide the interface to the libreadline library. The version we
> ship with our packages, however,
> seems to be broken somehow.
> There are some ways to get around this. Do you have
> guile-2.2-libs installed, too?
> If installing guile-2.2-libs does not help either, please send me the output
> of
>
> strace -o readlinedebug.log lilypond scheme-sandbox.ly
>
> where you type the mentioned commands for activating readline.
>
> Regards,
> Michael
>
> Am 14.01.2020 um 01:31 schrieb Knute Snortum:
> > I recently discovered the scheme-sandbox in LilyPond and I want to get
> > line editing to work.  In scheme-sandbox.ly the comments say:
> >
> > % One typical thing you might want to put there is
> > % (use-modules (ice-9 readline))
> > % (activate-readline)
> > % in order to activate command line editing for interactive sessions.
> >
> > I'm assuming that these are commands to type into the sandbox.  But
> > when I do this I get an error:
> >
> > guile> (use-modules (ice-9 readline))
> > ERROR: readline is not provided in this Guile installation
> > ABORT: (misc-error)
> >
> > When I search for installed packages at the Linux command line, I see this:
> >
> > libreadline8/eoan,now 8.0-3 amd64 [installed,automatic]
> >
> > Any idea why readline is not available?
> >
> > My system is Ubuntu 19.10, Guile is 2.2 and LilyPond is 2.19.83.
> >
> > ---
> > Knute Snortum
> > (via Gmail)
> >
>
>

Re: Unusual cross-staff stem in Bartók

[Arle Lommel]

> Hope that helps more!
> Kieren.


Thanks much. One of the challenging things for folks like me who dip in and out 
is keeping track of all the different ways that things can be done and how all 
the elements interact. But that is inherent to this: Music notation is orders 
of magnitude more complex than printed text.

There is a continual learning curve, but I keep coming back to Lilypond because 
of all the things I *can’t* reliably do in other software. It’s great stuff!

-Arle

Re: How to increase shift dynamic and end of hairpin

[David Kastrup]

Kieren MacMillan  writes:

> Hi David,
>
>> It's kind of embarrassing after that accolade that this particular
>> solution (the \after function) is probably the least brilliant and
>> involved of all.
>
> Sometimes, the most brilliant solutions are the most elegant ones. In
> particular, your \after function was the first time I ever saw the
> Bottom context directly addressed, and became aware of the power of
> doing so.

It's just something included in the definition to avoid things behaving
unexpectedly in some situations (like first thing in a StaffGroup or
so).  I don't think you'd see it outside of definitions.

>> We probably should include it in LilyPond
>
> I think that’s a great idea.

Noted.

-- 
David Kastrup

Re: Distance of a grob from its reference point

[Kieren MacMillan]

Hi Aaron,

> If we borrow some of the underlying logic, we get the following:

Wow… You are my patronus of late.  =)

>  #{ \override $grob-path .after-line-breaking = #proc #})

My mind was a little blown by the result of changing that to

\override $grob-path .before-line-breaking = #proc

Doing so made it *deeply* and *immediately* clear that, despite being a serious 
power-user of Lilypond for almost twenty years, I know almost nothing of how it 
actually works.

> Going back to your prior ask of "how do I move a grob?", I think we need to 
> shift perspective on the issue.  It is less important to dwell on *how* to 
> move something; rather, we should inquire of you *why* you want to move 
> something.  What purpose does it serve, for instance, to move an 
> OttavaBracket upward precisely two staff spaces?  (I apologize if that is 
> coming across sarcastically, but I am afraid I lack better wordsmithing.)
> The goal of such questioning is to best improve how LilyPond's layout engine 
> works without user intervention.  There likely exists sufficient logic within 
> LilyPond to accommodate your needs; but it is certainly possible such logic 
> still needs to be invented.  However, I think focusing on details like final 
> grob positioning might be putting the cart before the horse.

I often need to do such things in my engraving work — especially complicated 
"non-traditional" engraving (Schenker graphs, etc.). Usually, I just use the 
edition-engraver to tweak the position, and usually it’s with padding and/or 
extra-offset. A few times, I’ve had to use other tweaks to push objects or 
staves further away before repositioning the grob itself.

Hence the ability to offset (e.g.) an OttavaBracket precisely X staff spaces 
while still [re-]engaging the spacing engine is neither an unreasonable 
request, nor something that Lilypond could (or even should!) try to manage 
automagically.

Cheers,
Kieren.


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

Re: How to increase shift dynamic and end of hairpin

[Kieren MacMillan]

Hi David,

> It's kind of embarrassing after that accolade that this particular
> solution (the \after function) is probably the least brilliant and
> involved of all.

Sometimes, the most brilliant solutions are the most elegant ones. In 
particular, your \after function was the first time I ever saw the Bottom 
context directly addressed, and became aware of the power of doing so.

> We probably should include it in LilyPond

I think that’s a great idea.

Thanks,
Kieren.


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

Re: Lyric misalignment solved. Was Re: Lyric misalignment and beaming?

[David Kastrup]

Carl Sorensen  writes:

> On 1/14/20, 6:58 AM, "Arle Lommel"  wrote:
>
> So schrieb David:
> 
> > Either way is acting as it should.
> > 
> > The manual has an index entry "beam, with lyrics" for the chapter
> > "Setting automatic beam behavior" but there is no usable reference
> > whatsoever in that chapter.  I actually find rather little elsewhere
> > either, there are mostly just some allusions to manual beaming and
> > lyrics that don't make it into a definitive statement about LilyPond's
> > behavior rather than a general typesetting practice.
> > 
> > It's sort of an "everyone knows this except the manual" situation
> > apparently.
> 
> 
> Thanks for the explanation, which makes sense. Where should I
> suggest that this be made more prominent in the documentation? It
> think it ought to be mentioned in the section on Lyrics where slurs
> are discussed so that both options are evident to people like me, who
> dip in and out of Lilypond on a semi-regular basis but aren’t quite up
> on all the details.
>
> Well, in NR 2.1.1, under Multiple notes to one syllable
> (http://lilypond.org/doc/v2.19/Documentation/notation/common-notation-for-vocal-music#multiple-notes-to-one-syllable),
> we read of five different ways to accomplish this.  One of them is
> manual beaming:
>
> "Notes are considered a melisma if they are manually beamed, providing
> automatic beaming is switched off. See Setting automatic beam
> behavior"
>
> There is also a subsection that describes how melismaBusyProperties
> can be tuned to control how melismata are decided.
>
> Perhaps this is a place that more clarity could be added, but
> personally, this has worked well for me understanding this issue.  I
> don't really see a need to add more here.
>
> Maybe we need to improve the indexing.

And definitely the cross-referencing.  If there is a single sentence
summarising the behavior with a link to the extensive explanation in
most locations where one would expect to see it, that should help a lot.
Particularly when there already is a handwaving statement of the "it was
customary for syllables to match manually placed beams" kind.

-- 
David Kastrup

Re: Lyric misalignment solved. Was Re: Lyric misalignment and beaming?

[Carl Sorensen]

On 1/14/20, 6:58 AM, "Arle Lommel"  wrote:

So schrieb David:

> Either way is acting as it should.
> 
> The manual has an index entry "beam, with lyrics" for the chapter
> "Setting automatic beam behavior" but there is no usable reference
> whatsoever in that chapter.  I actually find rather little elsewhere
> either, there are mostly just some allusions to manual beaming and
> lyrics that don't make it into a definitive statement about LilyPond's
> behavior rather than a general typesetting practice.
> 
> It's sort of an "everyone knows this except the manual" situation
> apparently.


Thanks for the explanation, which makes sense. Where should I suggest that 
this be made more prominent in the documentation? It think it ought to be 
mentioned in the section on Lyrics where slurs are discussed so that both 
options are evident to people like me, who dip in and out of Lilypond on a 
semi-regular basis but aren’t quite up on all the details.

Well, in NR 2.1.1, under Multiple notes to one syllable 
(http://lilypond.org/doc/v2.19/Documentation/notation/common-notation-for-vocal-music#multiple-notes-to-one-syllable),
 we read of five different ways to accomplish this.  One of them is manual 
beaming:

"Notes are considered a melisma if they are manually beamed, providing 
automatic beaming is switched off. See Setting automatic beam behavior"

There is also a subsection that describes how melismaBusyProperties can be 
tuned to control how melismata are decided.

Perhaps this is a place that more clarity could be added, but personally, this 
has worked well for me understanding this issue.  I don't really see a need to 
add more here.

Maybe we need to improve the indexing.

Thanks,

Carl




 

Re: Lyric misalignment solved. Was Re: Lyric misalignment and beaming?

[David Kastrup]

Arle Lommel  writes:

> So schrieb David:
>
>> Either way is acting as it should.
>> 
>> The manual has an index entry "beam, with lyrics" for the chapter
>> "Setting automatic beam behavior" but there is no usable reference
>> whatsoever in that chapter.  I actually find rather little elsewhere
>> either, there are mostly just some allusions to manual beaming and
>> lyrics that don't make it into a definitive statement about LilyPond's
>> behavior rather than a general typesetting practice.
>> 
>> It's sort of an "everyone knows this except the manual" situation
>> apparently.
>
>
> Thanks for the explanation, which makes sense. Where should I suggest
> that this be made more prominent in the documentation? It think it
> ought to be mentioned in the section on Lyrics where slurs are
> discussed so that both options are evident to people like me, who dip
> in and out of Lilypond on a semi-regular basis but aren’t quite up on
> all the details.

As a handwaving guess, where

git grep autoBeamOff Documentation

spits out material outside of the translations.  It's in both the
Learning and Notation manual in several places.

-- 
David Kastrup

Re: Running LilyPond on Amazon Linux 2

[Peter Anglea]

I think I got it fixed… recording this here for anyone else who stumbles upon 
the same issue as I did.

I downloaded an RPM containing libcrypt.so.1, extracted the file, and put it 
inside LilyPond’s /usr/lib/ directory. I made sure to include the LilyPond 
directory as part of the include path for my function. Probably not the best 
long-term fix… if I update LilyPond in the future, I’ll need to remember to 
re-add libcrypt... but for now it works and my testing has generated scores 
without issue.

It should be noted that I am not a Linux pro, and am a little out of my depth 
on this one. So if there’s a more obvious fix, I’d love to hear about it.

> On Jan 11, 2020, at 12:07 PM, Peter Anglea  wrote:
> 
> I’ve been running LilyPond on AWS Lambda for some time now, but recently have 
> been forced to upgrade my runtime from Node 8.x to Node 12.x due to Node 8.x 
> becoming deprecated. However, in my testing, LilyPond does not work in either 
> the Node 10.x or Node 12.x runtimes. I get the following error:
> 
> lilypond: error while loading shared libraries: libcrypt.so.1: cannot open 
> shared object file: No such file or directory
> 
> Note: I have been using the binary for GNU/Linux 64: LilyPond 2.19.83-1
> 
> From what I can tell, the difference is that AWS Lambda’s Node 12.x runtime 
> uses the “Amazon Linux 2” distro instead of regular “Amazon Linux” distro 
> used with the Node 8.x runtime. Also, my research seems to indicate the error 
> is related to Amazon Linux 2 using a different version of openssl from 
> before… but that’s about the limit of what I understand.
> 
> Is anyone else successfully running LilyPond on AWS Lambda Node 12.x? Is 
> there another binary better suited to that particular distro? Any other 
> suggestions for overcoming the error message above?
> 
> Thanks in advance for any help. I’m kinda stuck here, but this mailing list 
> has proven helpful many times, so… fingers crossed! :)

Re: Unusual cross-staff stem in Bartók

[Kieren MacMillan]

Hi Arle,

> That did indeed help. It got me 90% of the way there. When I actually applied 
> it in the piece I’m setting, I found that the length of the overridden stem 
> was pushing the other staff away. It didn’t do this in the example you made, 
> so I’m not sure what was interfering

You could always remove it from the spacing engine’s calculations:

\version "2.19.83"

ignoreH =
   \propertyTweak horizontal-skylines ##f
   \propertyTweak extra-spacing-width #empty-interval
   \etc

ignoreV =
   \propertyTweak vertical-skylines ##f
   \propertyTweak extra-spacing-height #empty-interval
   \etc

ignore = \ignoreH \ignoreV \etc

{
  \new PianoStaff <<
\new Staff {
  bes'8[ ]
}
\new Staff {
  \clef bass
  \voiceOne
  \autoBeamOff
  \crossStaff { \once \ignore Stem \tweak NoteColumn.X-offset #-1.175 
\tweak Stem.length 7 bes8 s }
  \autoBeamOn
}
  >>
}

Hope that helps more!
Kieren.


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

Re: Unusual cross-staff stem in Bartók

[Arle Lommel]

Írta Kieren:

> p.s. Maybe this helps?


That did indeed help. It got me 90% of the way there. When I actually applied 
it in the piece I’m setting, I found that the length of the overridden stem was 
pushing the other staff away. It didn’t do this in the example you made, so I’m 
not sure what was interfering (maybe something with multiple voices going on). 
But I found that if I tweaked the other beamed notes with something like \once 
\override Beam.positions = #'(7 . 8), that allowed me to close the small gap by 
brute-forcing the stems and beam where I wanted them.

Thanks very, very much.

-Arle

Re: Lyric misalignment solved. Was Re: Lyric misalignment and beaming?

[Arle Lommel]

So schrieb David:

> Either way is acting as it should.
> 
> The manual has an index entry "beam, with lyrics" for the chapter
> "Setting automatic beam behavior" but there is no usable reference
> whatsoever in that chapter.  I actually find rather little elsewhere
> either, there are mostly just some allusions to manual beaming and
> lyrics that don't make it into a definitive statement about LilyPond's
> behavior rather than a general typesetting practice.
> 
> It's sort of an "everyone knows this except the manual" situation
> apparently.


Thanks for the explanation, which makes sense. Where should I suggest that this 
be made more prominent in the documentation? It think it ought to be mentioned 
in the section on Lyrics where slurs are discussed so that both options are 
evident to people like me, who dip in and out of Lilypond on a semi-regular 
basis but aren’t quite up on all the details.

-Arle

Re: hide Stuff

[Malte Meyn]

Please keep all conversation on the list.

Am 14.01.20 um 11:36 schrieb bb:

Thanks for reply. Works only partially.

1st there stays a Staff artefact


This is because you tagged only the music inside the staff, not the 
staff itself.



2nd ther is no midi sound for the hidden notes

I need the midi sound, but not the grafics.

Is there a solution?


You’ll need two scores for both of the following solutions:

Either you don’t put \metronome into the \layout score.

\version "2.19.83"

metronome = { 4 4 4 4 }
music = \relative { c' d e f }

\score {
  \new Staff \music
  \layout { }
}

\score {
  <<
\new Staff \metronome
\new Staff \music
  >>
  \midi { }
}


Or you use the same score for both \score blocks and remove the 
metronome by using \tag.


\version "2.19.83"

metronome = { 4 4 4 4 }
music = \relative { c' d e f }
everything = <<
  \tag metronome \new Staff \metronome
  \new Staff \music
>>

\score {
  \everything
  \layout { }
}

\score {
  \removeWithTag metronome \everything
  \midi { }
}

Re: Lyric misalignment solved. Was Re: Lyric misalignment and beaming?

[David Kastrup]

Arle Lommel  writes:

> Thanks very much to Carl Sorenson for a response that got me to start paring 
> things
> down even more and led me to find the problem in my score where I didn’t
> previously look. Took a while
>
> Basically, if autoBeam is off (somehow I’d turned it off outside a
> variable where I was defining things), the Lyrics somehow follow the
> manual beaming to guide their placement rather than slurs, but if it
> is on, they ignore it and act as they should.

Either way is acting as it should.

The manual has an index entry "beam, with lyrics" for the chapter
"Setting automatic beam behavior" but there is no usable reference
whatsoever in that chapter.  I actually find rather little elsewhere
either, there are mostly just some allusions to manual beaming and
lyrics that don't make it into a definitive statement about LilyPond's
behavior rather than a general typesetting practice.

It's sort of an "everyone knows this except the manual" situation
apparently.

Generally, with \autoBeamOff, beams indicate melismata.  With
\autoBeamOn, they don't, not even manual beams.  That's actually also
important in MIDI where syllables are put into the music as well, so
changes made to autobeaming should be done identically in MIDI.

So if you want to have beaming be independent from lyric syllables, you
need to keep \autoBeamOn but override the default beaming with your own
beams.

-- 
David Kastrup

Re: Syntax highlighting

[Federico Bruni]

Il giorno mar 14 gen 2020 alle 12:34, Urs Liska  
ha scritto:

Pygments is also what Pandoc uses for its syntax highlighting, so that
would also make sense for that (e.g. generating PDF documentation from
Markdown).


Are you sure?
I think that pygments is the name of the default style in Pandoc, but 
the highlight library is a Haskell library called skylighting:

https://pandoc.org/MANUAL.html#syntax-highlighting
https://github.com/jgm/skylighting

It seems Wilbert contributed the definitions for lilypond syntax:
https://github.com/KDE/syntax-highlighting/blob/master/data/syntax/lilypond.xml

About 10 days ago I wanted to share this in the open issue in 
Frescobaldi tracker but I forgot to do it.

I remember I found the lilypond file definition somewhere else...

Re: hide Stuff

[bb]

Am 14.01.20 um 11:36 schrieb bb:
> Thanks for reply. Works only partially.
>
> 1st there stays a Staff artefact
>
> 2nd ther is no midi sound for the hidden notes
>
> I need the midi sound, but not the grafics.
>
> Is there a solution?
>
> \version "2.19.2"
>   metronome = \tag #'A  {\relative c''' {{c4 c c c}}}
> \score  {  <<
>   \new Voice = "first"{ c' d e f g }
>   %\new Staff {\metronome}
>   \new Staff {  \removeWithTag #'A \metronome}
>
>     >>
>   \layout { }
>   \midi { }
> }
>

Re: How to increase shift dynamic and end of hairpin

[Xavier Scheuer]

On Tue, 7 Jan 2020 at 23:23, Guy Stalnaker  wrote:
>
> Sorry, Knute -- Harm's suggestion is less work LOL

Hi,

Even less work would be to change Hairpin.minimum-length.

%% MWE
\version "2.19"
\language "english"

\layout {
  \context {
\Voice
\override Hairpin.minimum-length = #8
  }
}

\score {
  <<
\new Staff \with {
  \dynamicUp
} {
  c'2\< a2 c'2\mf\> f'2\p
  c'2\< a2 c'2\mf\> f'2\p
}
\new Staff \with {
  \dynamicUp
} {
  a2\< f2 a2\mf\> c'4( bf)\p
  a2\< f2 a2\mf\> c'4( bf)\p
}
\addlyrics {
  Al -- le -- lu -- ia
  Al -- le -- lu -- ia
}
  >>
}
%%

It works. Although it would be better if Hairpin #'minimum-length would
apply to REAL length of the hairpin.
https://sourceforge.net/p/testlilyissues/issues/2207/

Cheers,
Xavier

-- 
Xavier Scheuer 

Re: Syntax highlighting

[Urs Liska]

Am Dienstag, den 14.01.2020, 12:27 +0100 schrieb Federico Bruni:
> 
> Il giorno mar 14 gen 2020 alle 09:13, Craig Dabelstein 
>  ha scritto:
> > Hi all,
> > 
> > I'd like to add LilyPond syntax highlighting to highlight.js ( 
> > https://highlightjs.readthedocs.io/en/latest/ ) so that I can 
> > experiment with documentation tools such as mkDocs/readthedocs.
> > Does 
> > anyone have any experience with this? Would it just be a matter of 
> > getting one of the current syntax packages (such as 
> > https://github.com/yrammos/SubLilyPond or 
> > https://github.com/yrammos/AtLilyPond , and trying to modify them?
> > 
> > 
> 
> I don't have any experience with highlight.js.
> Some years ago I started writing a Pygments definition for LilyPond
> but 
> then I gave up or simply forgot about it.
> 
> The Sublimetext and Atom packages might be useful as a reference, but
> I 
> guess that highlight.js will need its own syntax so you'd better
> start 
> from scratch.
> 
> The problem with syntax highlighting is maintainance. LilyPond
> syntax 
> changes and a manually compiled list must be updated manually for
> every 
> new stable release.
> 
> See also python-ly:
> https://github.com/frescobaldi/python-ly/blob/master/ly/words.py
> 

I'm not sure where and how, but there is also a substantial part of
python-ly's knowledge that is retrieved directly from LilyPond (either
from the sources or by running some LilyPond code). As far as I know
python-ly is the most comprehensive syntax highlighting solution on the
market (although still 2.18.2), and I think it would be good to find a
way use that “knowlegde” to generate syntax highlighting for arbitrary
other highlighters from that set of data.

> 
> Personally I'd be more interested in adding lilypond to Pygments.
> Pygments can be easily exported to chroma¹ (for Hugo² static site 
> generator).
> And it seems Pygments may be used also in Mkdocs, see this
> discussion:
> https://github.com/mkdocs/mkdocs/issues/1588

Pygments is also what Pandoc uses for its syntax highlighting, so that
would also make sense for that (e.g. generating PDF documentation from
Markdown).

Urs

> 
> ¹ https://github.com/alecthomas/chroma
> ² https://gohugo.io/content-management/syntax-highlighting/
> 
> 
> 
> 

Re: Syntax highlighting

[Federico Bruni]

Il giorno mar 14 gen 2020 alle 09:13, Craig Dabelstein 
 ha scritto:

Hi all,

I'd like to add LilyPond syntax highlighting to highlight.js ( 
https://highlightjs.readthedocs.io/en/latest/ ) so that I can 
experiment with documentation tools such as mkDocs/readthedocs. Does 
anyone have any experience with this? Would it just be a matter of 
getting one of the current syntax packages (such as 
https://github.com/yrammos/SubLilyPond or 
https://github.com/yrammos/AtLilyPond , and trying to modify them?





I don't have any experience with highlight.js.
Some years ago I started writing a Pygments definition for LilyPond but 
then I gave up or simply forgot about it.


The Sublimetext and Atom packages might be useful as a reference, but I 
guess that highlight.js will need its own syntax so you'd better start 
from scratch.


The problem with syntax highlighting is maintainance. LilyPond syntax 
changes and a manually compiled list must be updated manually for every 
new stable release.


See also python-ly:
https://github.com/frescobaldi/python-ly/blob/master/ly/words.py


Personally I'd be more interested in adding lilypond to Pygments.
Pygments can be easily exported to chroma¹ (for Hugo² static site 
generator).

And it seems Pygments may be used also in Mkdocs, see this discussion:
https://github.com/mkdocs/mkdocs/issues/1588

¹ https://github.com/alecthomas/chroma
² https://gohugo.io/content-management/syntax-highlighting/

Users of scholarly.choice or scholarly.editorial-markup?

[Urs Liska]

Hi all,

does anyone know if the openLilyLib modules scholarly.choice and
scholarly.editorial-markup are actually used by people?

The reason I'm asking is that I have the impression that I should
rename the command \editorialMarkup to something different and would
like to know if this would significantly affect users.

I am putting the following code on a slide for a presentation, and it
just doesn't feel right:

\relative {
  ...

  \choice variants {
\editorialMarkup lemma \with { source = "1756" } {
  c8 [ e d g, ]
  |
  e'16 [ d c8 ] r4
}
\editorialMarkup reading \with { source = "1769" } {
  c8 [ e ] d4
}
  }

  ...
}

This encodes two alternative versions of music, as found in two
different sources. Through a configuration variable it can be decided
which readings to use in the engraving (well, this is pretty closely
related to using tags).

What the naming actually describes is that I *use* editorial markup to
encode one version as a "lemma" and another as a "reading". But that's
not what *should* be there. Actually I want to encode the versions "as"
lemma and reading.
For that it would of course be more straightforward to directly use
\lemma and \reading, but the concept is very flexible, has a number of
cases preconfigured and allows to define arbitrary types of
alternatives to be encoded.
[And just if anyone is interested: the "variants" type for choice is
defined to require two or more music variables from type "lemma" or
"reading", zero or one lemma.]

Urs

Re: How to increase shift dynamic and end of hairpin

[David Kastrup]

Kieren MacMillan  writes:

> Hi Guy,
>
>> You sir are a gentleman and a scholar!
>
> Well, ½ of each means I’m a total of 1.  ;)
>
>> I didn't want to say anything, but each of the three previous
>> suggestions worked for the MWE, but when applied to my score either
>> either did not work at all, or only worked for some of the areas
>> that needed the extended hairpin decrescendo. This function,
>> however, worked perfectly in all the places I used it.
>
> All the credit belongs to the brilliant and always-helpful David Kastrup.

It's kind of embarrassing after that accolade that this particular
solution (the \after function) is probably the least brilliant and
involved of all.  We probably should include it in LilyPond before any
of the tweaks done to it in response to "this doesn't work, again"
reports gets lost.

-- 
David Kastrup

Re: Distance of a grob from its reference point

[Aaron Hill]

On 2020-01-13 7:05 pm, Paolo Prete wrote:
1) its *calculated* distance from its reference point? (from what I 
see,
the reference Y of an OttavaBracket is the middle line of the 
associated

staff...)
I tried ly:grob-staff-position (see the snippet below), but it doesn't 
seem

to give this info (and it's not documented)


Well, "staff-position" is likely not the metric you want, as its units 
appear to be in half staff-spaces rather than staff-spaces like other 
metrics, making its result twice as much as you might expect.  It might 
even be impacted by things like \magnifyStaff, making its value even 
less useful.


But put that aside.  If we borrow some of the underlying logic, we get 
the following:



\version "2.19"

drawRelativePosition = #(define-music-function
  (grob-path) (symbol-list?)
  (define (proc grob)
(let* ((ss (ly:grob-object grob 'staff-symbol))
   (refp (ly:grob-common-refpoint grob ss Y))
   (y (- (ly:grob-relative-coordinate grob refp Y)
 (ly:grob-relative-coordinate ss refp Y)))
   (orig (ly:grob-property grob 'stencil))
   (sten (grob-interpret-markup grob #{
 \markup \with-dimensions-from \stencil #orig
   \overlay { \stencil #orig \with-color #red
 \translate #(cons 0 (- y)) \path #0.1 #`(
   (moveto -1 ,y) (lineto 1 ,y)
   (moveto 0 ,y) (lineto 0 0)
   (moveto -1 0) (lineto 1 0)
   (moveto -0.5 1) (lineto 0 0) (lineto 0.5 1))
   } #})))
  (ly:grob-set-property! grob 'stencil sten)))
  #{ \override $grob-path .after-line-breaking = #proc #})

{
  \drawRelativePosition Staff.OttavaBracket
  \ottava #1 c8 c \ottava 0 c'''4
  \ottava #1 a'''8 a''' \ottava 0 a''4
  \ottava #1 a'''8( a''' \ottava 0 a''4)
}


The above would seem to "fail" on the third bracket.  This is because 
the slur pushes the bracket out of the way at a time *after* 
after-line-breaking.  This suggests it is unlikely for user code to 
reliably discern the truly final position of a grob.


While I would never claim to fully grok all of the wily machinations of 
LilyPond, this particular detail does make some sense to me.


Consider that the layout engine has to be able to draw a line in the 
sand and say "That's it!  All grobs are in the place where they'll be.  
Let's just write this thing to a file and be done with it."  As such, it 
becomes uninteresting to allow user logic to run after that point since 
nothing is permitted to change.


In fact, the layout engine seems to draw a few such lines during its 
work, with line breaking being another example.  The 
before-line-breaking procedure allows user code to manipulate items that 
could impact how lines eventually break.  But after-line-breaking 
happens once lines are locked in and only content within the line could 
still be adjusted.




Going back to your prior ask of "how do I move a grob?", I think we need 
to shift perspective on the issue.  It is less important to dwell on 
*how* to move something; rather, we should inquire of you *why* you want 
to move something.  What purpose does it serve, for instance, to move an 
OttavaBracket upward precisely two staff spaces?  (I apologize if that 
is coming across sarcastically, but I am afraid I lack better 
wordsmithing.)


The goal of such questioning is to best improve how LilyPond's layout 
engine works without user intervention.  There likely exists sufficient 
logic within LilyPond to accommodate your needs; but it is certainly 
possible such logic still needs to be invented.  However, I think 
focusing on details like final grob positioning might be putting the 
cart before the horse.


Consider the recent work done on curve editing.  (By the way, that is a 
*very* cool contribution; and if I can find time, I may be able to help 
with Scheme and JavaScript should that still be required.)  Having such 
a nice curve editor should in no way be a replacement for improving 
LilyPond.  Ideally, the software will engrave beautiful curves without 
the user needing to lift a finger.  At the very least, the user might 
have to provide a few hints to get the job done to their satisfaction.  
Only as a last resort should one have to position curve points manually.




Sorry for my long ramblings.  At this rate, I should become a novelist 
or something.  (:



-- Aaron Hill