Re: Primo/secondo layout

[Abraham Lee]

On Tue, Mar 21, 2023 at 12:06 PM Jean Abou Samra  wrote:

> Le mardi 21 mars 2023 à 12:00 -0600, Abraham Lee a écrit :
>
> I think the only thing that Dorico has advertised that I haven't figured
> out how to do automagically in LP is the Primo/Secondo layout for
> multi-person piano scores (or similar). Does anyone know of a way?
>
> There's a long-standing feature request about it, #902
> <https://gitlab.com/lilypond/lilypond/-/issues/902>.
>
Yep.


> It'd be tough to do in Scheme since it touches the page breaking stuff,
> which is essentially C++-only. It's *probably* not hard to implement in
> the C++ code, just a bit tedious.
>
I am amazed that you have enough insight into the code to make that
observation. Like I said, not a huge problem for me. A person could create
this score format manually and piece them together with PDF manipulation
tools, but an automated solution would be extremely satisfying.

Re: Is it time to update the Finale 2008 sample in Essay?

[Abraham Lee]

On Mon, Mar 20, 2023 at 4:11 PM David Kastrup  wrote:

> Han-Wen Nienhuys  writes:
>
> > On Mon, Mar 20, 2023 at 5:27 PM Abraham Lee 
> wrote:
> >
> >> Thanks, Jean, for doing that. I was hoping for a more public discussion
> to
> >> see if creating an issue is even warranted. The essay is a historical
> >> document, to be sure, so updating the comparison files might not be
> needed
> >> at all.
> >
> > I agree to this. It is better to simply put a small intro to the essay
> > that gives the context.
> >
> > We could then add an updated preface/postscriptum that puts it in
> > context for 2023. To note, a lot of modern music engravers have taken
> > inspiration from the LilyPond attitude to engraving. The Dorico blog
> > posts have been quite explicit about it, and maybe we could ask the
> > MuseScore folks for comments too.
>
> For better or worse, I think the main selling point of LilyPond these
> days is not as much quality as workflow.
>

I think the engraving quality aspect is definitely still there in many
ways, but maybe a bit more nuanced and not so obvious to the casual user
(i.e., only if you know what to look for).

I do, agree, however, that the workflow is a HUGE reason I still use LP for
anything and everything I need to create, especially when I know someone
else is going to use it. Is LP always the fastest method to enter content?
No it's not, but does it allow some of the most amazing flexibility when
creating multiple kinds of scores using the same source content?
Unequivocally yes! No other software comes even close. I think the only
thing that Dorico has advertised that I haven't figured out how to do
automagically in LP is the Primo/Secondo layout for multi-person piano
scores (or similar). Does anyone know of a way? It's not a big deal to me
since I almost never create them, but would be cool to figure out at some
point.

Best,
Abraham

Re: Is it time to update the Finale 2008 sample in Essay?

[Abraham Lee]

On Mon, Mar 20, 2023 at 3:25 PM Jean Abou Samra  wrote:

> Le lundi 20 mars 2023 à 10:26 -0600, Abraham Lee a écrit :
>
> Thanks, Jean, for doing that. I was hoping for a more public discussion to
> see if creating an issue is even warranted. The essay is a historical
> document, to be sure, so updating the comparison files might not be needed
> at all. It just feels a bit odd to read "we have chosen Finale 2008, which
> is one of the most popular commercial score writers". This was absolutely
> true... once upon a time. Reading it now makes it sound like we had to dig
> way back in order to pretend to make it seem like Finale isn't good
> enough and that LilyPond does it right. How does
> Finale/Sibelius/Dorico/etc. do nowadays? Do they get it right now? I'm
> certain folks have asked this question.
>
> For comparison, I just entered the two systems in the essay into MuseScore
> 4 and got a practically perfect output. Entering one voice at a time (voice
> 1, then voice 2), all existing pitches were maintained in voice 1 despite
> making alterations in voice 2 (like that omitted flat that Finale 2008
> leaves out). I didn't have to correct or add anything that was missing.
> Maybe I just got lucky because of how I entered the passage. Arguments can
> be made about other layout decisions, but I think it's hard to argue
> against what MS4 has done compared to the hand-engraved examples:
>
> So, maybe all that's needed is a different wording in this section to
> reflect why *at the time* this comparison made sense (like what is
> described at the beginning of the essay)? That would certainly be simpler
> than recreating the comparison (which might not come to the original
> conclusion like it used to).
>
> LilyPond too has evolved a lot in 15 years. You could take a more complex
> example than this relatively simple (in terms of notation) Bach excerpt,
> and re-do the comparison. I'm not sure Finale/Sibelius/Dorico/MuseScore
> would use skylines for spacing objects as opposed to simple boxes.
>
It most certainly has, in so many excellent ways. I've used all of these
major apps to some degree over the past number of years and I have
discovered there are many things about how each app lays out a page that
really frustrate me, some completely hiding the control to force things
onto a specific page/system/etc. This is one big reason I continue to use
LP after all these years. The layout control is simply superb! My only
complaint here is that there isn't a great mechanism to finely control the
system placement on a page (or staves/lyrics/etc. within a system) aside
from explicit vertical placement, which I avoid completely. I wish there
was a more convenient way to do a similar thing like \once \override
TextScript.X-offset = #5 to shift a grob and then have things re-flow
around it (as opposed to what extra-offset does). Sorry, off on a tangent
there.

I read that a while ago, Urs Liska organized a "music engraving contest"
> where scores were compared in different score writers, probably for the
> scores of beauty blog. That blog is now defunct, but you could try to dig
> into the list archives. It's old, but not 15 years old, and the chosen
> samples could be recompared today.
>
Yes, those were good times lol. I actively participated in those, partially
from the sidelines, but some on the front lines. Those contests were
difficult to run in a controlled way. Meaning, what is actually being
compared? How do you know who wins? How "out of the box" are we comparing
other software to LP? With LP, it's easy, just don't use any overrides and
you get default behavior. In other apps, the way things show up are very
dependent on how the entry takes place. And an expert user of software X
can do just as well a job as an expert user of software Y. So, what
actually is being compared in the end? Time to get to a specific result?
One user's ability to use their favorite software against another's? This
seemed to be the challenge we ran into because these were always the
questions that came up. Complaints one way or the other were always about
nuanced differences in output or expectations rather than gross errors by
the application despite a user's best effort. I'm not against this, but I'm
not sure how to make this a practically useful activity, either.

Re: Is it time to update the Finale 2008 sample in Essay?

[Abraham Lee]

On Mon, Mar 20, 2023 at 3:13 PM Han-Wen Nienhuys  wrote:

> On Mon, Mar 20, 2023 at 5:27 PM Abraham Lee 
> wrote:
> >
> > On Sat, Mar 18, 2023 at 6:17 AM Jean Abou Samra 
> wrote:
> >
> > > Le mercredi 15 mars 2023 à 00:57 +0100, Jean Abou Samra a écrit :
> > >
> > > Le mardi 14 mars 2023 à 17:44 -0600, Abraham Lee a écrit :
> > >
> > > At the time I started with LP, the Finale 2008 example wasn't that old
> > > in the Essay section. Is it really fair for us to continue showing this
> > > since quite a few versions have been released since then? I mean,
> Finale 27
> > > has been out since June 2021 and is now at 27.3. I'm not saying the
> > > example is bad, nor doesn't it illustrate a historical
> > > piece of evidence clarifying why LP was needed. I guess I'm wondering
> if
> > > it's worth creating a new set of examples to show why it's *still*
> needed,
> > > even after all these years? Thoughts?
> > >
> > > I suggest you open a tracker issue.
> > >
> > > I have done it now, https://gitlab.com/lilypond/lilypond/-/issues/6547
> > >
> >
> > Thanks, Jean, for doing that. I was hoping for a more public discussion
> to
> > see if creating an issue is even warranted. The essay is a historical
> > document, to be sure, so updating the comparison files might not be
> needed
> > at all.
>
> I agree to this. It is better to simply put a small intro to the essay
> that gives the context.
>
> We could then add an updated preface/postscriptum that puts it in
> context for 2023. To note, a lot of modern music engravers have taken
> inspiration from the LilyPond attitude to engraving. The Dorico blog
> posts have been quite explicit about it, and maybe we could ask the
> MuseScore folks for comments too.
>

Hey, Han-wen! Thanks for chiming in! You would certainly know better than
anyone the context of the statements/examples in the essay. And, yes, the
other apps certainly have taken inspiration from LP's output, which is part
of why I wasn't sure which the right answer would be. I am strongly leaning
towards modifying the context of what's there to keep things in the
appropriate perspective with the competition.

Best,
Abraham

Re: Is it time to update the Finale 2008 sample in Essay?

[Abraham Lee]

On Sat, Mar 18, 2023 at 6:17 AM Jean Abou Samra  wrote:

> Le mercredi 15 mars 2023 à 00:57 +0100, Jean Abou Samra a écrit :
>
> Le mardi 14 mars 2023 à 17:44 -0600, Abraham Lee a écrit :
>
> At the time I started with LP, the Finale 2008 example wasn't that old
> in the Essay section. Is it really fair for us to continue showing this
> since quite a few versions have been released since then? I mean, Finale 27
> has been out since June 2021 and is now at 27.3. I'm not saying the
> example is bad, nor doesn't it illustrate a historical
> piece of evidence clarifying why LP was needed. I guess I'm wondering if
> it's worth creating a new set of examples to show why it's *still* needed,
> even after all these years? Thoughts?
>
> I suggest you open a tracker issue.
>
> I have done it now, https://gitlab.com/lilypond/lilypond/-/issues/6547
>

Thanks, Jean, for doing that. I was hoping for a more public discussion to
see if creating an issue is even warranted. The essay is a historical
document, to be sure, so updating the comparison files might not be needed
at all. It just feels a bit odd to read "we have chosen Finale 2008, which
is one of the most popular commercial score writers". This was absolutely
true... once upon a time. Reading it now makes it sound like we had to dig
way back in order to pretend to make it seem like Finale isn't good
enough and that LilyPond does it right. How does
Finale/Sibelius/Dorico/etc. do nowadays? Do they get it right now? I'm
certain folks have asked this question.

For comparison, I just entered the two systems in the essay into MuseScore
4 and got a practically perfect output. Entering one voice at a time (voice
1, then voice 2), all existing pitches were maintained in voice 1 despite
making alterations in voice 2 (like that omitted flat that Finale 2008
leaves out). I didn't have to correct or add anything that was missing.
Maybe I just got lucky because of how I entered the passage. Arguments can
be made about other layout decisions, but I think it's hard to argue
against what MS4 has done compared to the hand-engraved examples:

[image: image.png]

So, maybe all that's needed is a different wording in this section to
reflect why *at the time* this comparison made sense (like what is
described at the beginning of the essay)? That would certainly be simpler
than recreating the comparison (which might not come to the original
conclusion like it used to).

Best,
Abraham

Is it time to update the Finale 2008 sample in Essay?

[Abraham Lee]

At the time I started with LP, the Finale 2008 example wasn't that old
in the Essay section. Is it really fair for us to continue showing this
since quite a few versions have been released since then? I mean, Finale 27
has been out since June 2021 and is now at 27.3.

I'm not saying the example is bad, nor doesn't it illustrate a historical
piece of evidence clarifying why LP was needed. I guess I'm wondering if
it's worth creating a new set of examples to show why it's *still* needed,
even after all these years?

Thoughts?

Best,
Abraham

Re: fetaBraces

[Abraham Lee]

On Tue, Mar 14, 2023 at 10:55 AM Jean Abou Samra  wrote:

> Le mardi 14 mars 2023 à 06:54 -0600, Abraham Lee a écrit :
>
> I hear you there. Any custom music font I'm aware of has a matching brace
> font. So, my guess is that they are choosing Emmentaler deliberately,
> though I suppose it's possible that someone just might not be aware that
> they need to select the brace font explicitly.
>
> It's not difficult to mix and match fonts for groups of symbols (like
> clefs or noteheads) within the same document, though, I'd expect the number
> of users doing this to be far fewer than those using a single custom font
> for everything. The mechanism isn't that obvious to someone who hasn't
> dabbled in some Scheme.
>
> For example, if one wanted to register multiple fonts, here's what I've
> done that worked very well for me when I was wildly into it (don't shame
> me, I'm no Scheme expert lol):
>
> %<
>
> #(define-public (add-notation-font fontnode name music-str brace-str
> factor)
>   (begin
> (add-music-fonts fontnode
>   name music-str brace-str
>   feta-design-size-mapping factor)
> fontnode))
>
> \paper {
>   #(define notation-fonts
> (list
>   (list 'capriccio "capriccio" "emmentaler")
>   (list 'emmentaler "emmentaler" "emmentaler")
>   (list 'gonville "gonville" "gonville")
>   (list 'lilyjazz "lilyjazz" "lilyjazz")
>   (list 'mtf-arnold "mtf-arnold" "mtf-arnold")
>   (list 'mtf-beethoven "mtf-beethoven" "mtf-beethoven")
>   (list 'mtf-cadence "mtf-cadence" "mtf-cadence")
>   (list 'mtf-gutenberg "mtf-gutenberg1939" "mtf-gutenberg1939")
>   (list 'mtf-haydn "mtf-haydn" "mtf-haydn")
>   (list 'mtf-improviso "mtf-improviso" "mtf-improviso")
>   (list 'mtf-ross "mtf-ross" "mtf-ross")
>   (list 'mtf-scorlatti "mtf-scorlatti" "mtf-scorlatti")
> ))
>
>   #(begin
> (for-each
>   (lambda (tup)
> (add-notation-font fonts
>   (car tup) ; font identifier
>   (cadr tup) ; notation font
>   (caddr tup) ; brace font
>   (/ staff-height pt 20)))
>   notation-fonts))
> }
>
> %<
>
> Then, whenever the user wanted to change the font of a specific grob (like
> Notehead), then all they'd need to do is use (for example)
>
> \override Notehead.font-family = #'gonville
>
> which, of course, can be done at the Score level or spontaneously
> mid-Score.
>
> Well, the way I currently envision the new font system, it would break
> that Scheme code, but also make it trivial to achieve the same thing
> without Scheme code.
>
> Unifying feta and fetaBraces would therefore still allow selecting a
> different music font for your SystemStartBraces. What it would not directly
> allow is *also* changing the font that is used for \markup \left-brace
> and \markup \right-brace. Probably not a big problem.
>
> I'm not yet 100% sure that it will actually simplify things to unify feta
> and fetaBraces, but if it does, I think I'll submit it.
>

Probably not a big deal either way since most users *aren't* using custom
fonts anyway, and I almost always only use a single music font for
everything (no mixing like in the method I proposed above). However, for
those that are using a custom font (like me), as long as the new mechanism
is easy to follow, I can't say I am against whatever changes you are
proposing. Thanks for all your excellent work!

Re: fetaBraces

[Abraham Lee]

On Tue, Mar 14, 2023 at 6:38 AM Jean Abou Samra  wrote:

> Le mardi 14 mars 2023 à 06:15 -0600, Abraham Lee a écrit :
>
> Hi, Jean!
>
> I am aware of individuals that appreciate the ability to mix and match
> fonts, including the brace font. In fact, I would guess that the more
> common combo is to use another music font with Emmentaler braces. I do
> believe this is a corner case and maybe it should be changed with some
> logic that assumes that #:brace is supposed to match #:music, since that is
> far more common, and then when someone wants to mix and match, they have to
> do it explicitly?
>
> Do people do that because they prefer Emmmentaler's braces, or because
> their chosen font doesn't have braces?
>
> Is this specific to braces, or would there be a point in allowing to mix
> (say) clefs from one font and note heads from another?
>
> The reason for asking is that font selection and searching is pretty much
> a mess right now, and I'm trying to understand what its ideal state would
> be before trying to overhaul it.
>

I hear you there. Any custom music font I'm aware of has a matching brace
font. So, my guess is that they are choosing Emmentaler deliberately,
though I suppose it's possible that someone just might not be aware that
they need to select the brace font explicitly.

It's not difficult to mix and match fonts for groups of symbols (like clefs
or noteheads) within the same document, though, I'd expect the number of
users doing this to be far fewer than those using a single custom font for
everything. The mechanism isn't that obvious to someone who hasn't dabbled
in some Scheme.

For example, if one wanted to register multiple fonts, here's what I've
done that worked very well for me when I was wildly into it (don't shame
me, I'm no Scheme expert lol):

%<

#(define-public (add-notation-font fontnode name music-str brace-str factor)
  (begin
(add-music-fonts fontnode
  name music-str brace-str
  feta-design-size-mapping factor)
fontnode))

\paper {
  #(define notation-fonts
(list
  (list 'capriccio "capriccio" "emmentaler")
  (list 'emmentaler "emmentaler" "emmentaler")
  (list 'gonville "gonville" "gonville")
  (list 'lilyjazz "lilyjazz" "lilyjazz")
  (list 'mtf-arnold "mtf-arnold" "mtf-arnold")
  (list 'mtf-beethoven "mtf-beethoven" "mtf-beethoven")
  (list 'mtf-cadence "mtf-cadence" "mtf-cadence")
  (list 'mtf-gutenberg "mtf-gutenberg1939" "mtf-gutenberg1939")
  (list 'mtf-haydn "mtf-haydn" "mtf-haydn")
  (list 'mtf-improviso "mtf-improviso" "mtf-improviso")
  (list 'mtf-ross "mtf-ross" "mtf-ross")
  (list 'mtf-scorlatti "mtf-scorlatti" "mtf-scorlatti")
))

  #(begin
(for-each
  (lambda (tup)
(add-notation-font fonts
  (car tup) ; font identifier
  (cadr tup) ; notation font
  (caddr tup) ; brace font
  (/ staff-height pt 20)))
  notation-fonts))
}

%<

Then, whenever the user wanted to change the font of a specific grob (like
Notehead), then all they'd need to do is use (for example)

\override Notehead.font-family = #'gonville

which, of course, can be done at the Score level or spontaneously mid-Score.

For what it's worth,
Abraham

Re: fetaBraces

[Abraham Lee]

Hi, Jean!

I am aware of individuals that appreciate the ability to mix and match
fonts, including the brace font. In fact, I would guess that the more
common combo is to use another music font with Emmentaler braces. I do
believe this is a corner case and maybe it should be changed with some
logic that assumes that #:brace is supposed to match #:music, since that is
far more common, and then when someone wants to mix and match, they have to
do it explicitly?

My 2 cents,
Abraham

On Tue, Mar 14, 2023 at 3:31 AM Jean Abou Samra  wrote:

> Hi,
>
> Quick question : is there any use case for passing a different brace font
> than the general music font to set-global-fonts? Would it make sense to
> get rid of this #:brace parameter, or at least make it default to the
> #:music parameter?
>
> Thanks,
>
> Jean
>

Re: GSoC 2023

[Abraham Lee]

On Fri, Feb 3, 2023 at 8:20 AM Jean Abou Samra  wrote:

> On 03/02/2023 16:10, Werner LEMBERG wrote:
> >
> >> Aah, thanks, now I remember: LilyPond, being part of GNU, doesn't have
> >> to apply separately (or should we?); instead, we are using the GNU
> >> umbrella and get slots from the there.
> >
> > Hmm, this probably is no longer correct.  I now remember that GNU was
> > rejected as an GSoC organization in 2021,
>
>
> (Given https://www.gnu.org/proprietary/malware-google.html
> I am actually surprised that GNU to be accepted for the
> previous years...)


I can be on hand to consult/advise, but I’m afraid I’m not available enough
to fill the mentor role right now.

Best,
Abraham

>

Re: Prioriziting a directory

[Abraham Lee]

On Tue, Dec 20, 2022 at 1:50 PM Jean Abou Samra  wrote:

>
>
> Le 18/12/2022 à 22:27, Jean Abou Samra a écrit :
> > Le 18/12/2022 à 22:22, Abraham Lee a écrit :
> >>
> >> By the way, is there already an issue for your request in the
> >> LilyPond
> >> tracker?
> >>
> >>
> >> No, I haven't submitted an issue about this. I've tolerated it for
> >> long enough that I just keep forgetting about it lol.
> >
> >
> > Then I suggest to create one.
>
> Well, I ended up creating it.
>
> https://gitlab.com/lilypond/lilypond/-/issues/6486


Thanks so much, Jean! It's been too long since I posted an official "issue"
as the place has moved around over the years and I lost track.

Best,
Abraham

Re: Prioriziting a directory

[Abraham Lee]

On Sun, Dec 18, 2022 at 2:16 PM Jean Abou Samra  wrote:

> Le 18/12/2022 à 22:03, Abraham Lee a écrit :
> > Great questions, Jean.
> >
> > As a font creator (both text and music) and semi-power user, I've
> > always hated that LilyPond only looks within its own data folder for
> > music fonts. This has required me to duplicate all my fonts to the
> > data directory of every new version of LilyPond I install to make them
> > accessible to that version. It's tolerable, yes, but feels a bit
> > needless duplicating the same files over and over, IMHO. So, while
> > we're on this topic, is there any chance the music fonts can get the
> > same treatment as text fonts? In other words, if the music font family
> > doesn't exist in the data directory, search the system's folder? Would
> > love to be able to install them like a normal font and use them
> > with any version. Pretty sure I wouldn't be the only one who
> > appreciates that. My two cents.
> >
>
>
> Abraham, this is a sensible request that I have thought about at times,
> but the context of my question is very different. LilyPond uses
> Fontconfig only to look up glyphs in Emmentaler if the font-encoding is
> 'fetaText, for dynamic texts, fingering digits and the like, but for
> most glyphs it uses an entirely different internal mechanism. Here, I am
> concerned with fixing the problem reported at
> https://lists.gnu.org/archive/html/lilypond-devel/2022-12/msg00024.html,
> which means preventing LilyPond from finding its fonts externally in
> 'fetaText (and hopefully there is a way to do this and still make the
> music font searched elsewhere if it's *not* in the datadir). Satisfying
> your request would mean touching a different area, the code that looks
> up music fonts in 'fetaMusic and 'fetaBraces encoding.
>

Appreciate the quick reply and I apologize for not realizing the difference
between your original question and my semi-related request.


> By the way, is there already an issue for your request in the LilyPond
> tracker?
>

No, I haven't submitted an issue about this. I've tolerated it for long
enough that I just keep forgetting about it lol.

Best,
Abraham

Re: Prioriziting a directory

[Abraham Lee]

Great questions, Jean.

As a font creator (both text and music) and semi-power user, I've always
hated that LilyPond only looks within its own data folder for music fonts.
This has required me to duplicate all my fonts to the data directory of
every new version of LilyPond I install to make them accessible to that
version. It's tolerable, yes, but feels a bit needless duplicating the same
files over and over, IMHO. So, while we're on this topic, is there any
chance the music fonts can get the same treatment as text fonts? In other
words, if the music font family doesn't exist in the data directory, search
the system's folder? Would love to be able to install them like a normal
font and use them with any version. Pretty sure I wouldn't be the only one
who appreciates that. My two cents.

Much thanks,
Abraham

On Sun, Dec 18, 2022 at 12:22 PM Jean Abou Samra  wrote:

> Hi,
>
> Is there a way to express this in a Fontconfig configuration
> file: "If you find a matching font in this directory given
> as relative path, ignore other matches and choose that one"?
>
> Context: LilyPond (the GNU music typesetter) uses Fontconfig via
> Pango for finding text fonts, but also for music fonts in some
> cases. The music fonts are developed together with LilyPond,
> and a given LilyPond installation should never look outside
> of its data directory for finding music fonts. However, text
> fonts should be findable on the system.
>
> If this isn't possible, I'll use two FcConfigs with Pango,
> and restrict one of them to LilyPond's datadir only, but
> currently LilyPond sets up a fallback to normal text fonts
> for its special fonts, and it would be nice to preserve
> that. I hope that's clear.
>
> Thanks,
> Jean
>
>

Re: Slanted Beams thickness

[Abraham Lee]

Hey, Valentin!

On Thu, Mar 24, 2022 at 6:46 PM Valentin Petzel  wrote:

> Hello,
>
> Lilypond handles slanted Beams in a geometrically weird way, that is, the
> thickness is not measured as the shortest distance between the opposing
> sides
> of the boundary, but as vertical distance. This results in Beams getting
> optically thinner and closer the higher the slope is. But we can very
> easily
> factor this out by adjusting the thickness to the slope. In fact if we
> want to
> achieve a real thickness theta the adjusted thickness would need to be
> theta·sqrt(1 + slope²). See attached an experimental example.
>
> Cheers,
> Valentin


I attempted to do this some years ago, but with my limited Scheme
abilities, I dropped it. In addition to the beam thickness correction, it
would probably be prudent to have the beam spacing corrected as well so the
white space between beams stays the same. Maybe? Just a thought.

Best,
Abraham

Need to remove links to lilypondblog.org

[Abraham Lee]

Hey, LP team!

I went to the LP website and saw a link in the "Pondings" section that said
that lilypondblog.org was live! I wondered if something had come up that
brought it back and clicked on the link only to learn that the address is
now a gambling site. So, not exactly the kind of impression we want to give
to newcomers, I think. Perhaps we should remove references to that address
now? Just a thought.

Best,
Abraham

Re: SMuFL support: matching glyph names 1

[Abraham Lee]

This is great, Owen! One thing to keep in mind is that most applications
don’t access glyphs by name like LilyPond does. They access by codepoint.
So, in the vein of making Emmentaler SMuFL compliant, codepoint will be
more import than name. You may already be taking this into account, but if
not, aside from name mapping, you ought to consider how the glyphs should
be remapped to the SMuFL code points. LilyPond doesn’t care if the glyphs
even have a codepoint. I’ve created numerous fonts with extra symbols that
don’t have a codepoint at all and it works wonderfully.

That all said, I’d recommend this: use LilyPond’s recognized names, use
SMuFL code points. That may simplify the effort somewhat.

Keep up the awesome work!

Best,
Abraham

On Thu, Apr 8, 2021 at 3:00 PM Owen Lamb  wrote:

> Hi all!
>
> I've been working on matching Emmentaler's glyphs to SMuFL glyph names,
> and I'd appreciate some input on what I have so far.
>
> Attached is a spreadsheet with my plans for naming the Clef, Time
> Signature, Number, and Accidental glyph categories, as enumerated at
> http://lilypond.org/doc/v2.23/Documentation/notation/the-emmentaler-font.
> The SMuFL names were taken from the Standard Music Font Layout
> Specification, v1.4, found at https://w3c.github.io/smufl/latest, under
> the Glyph Tables heading.
>
> I'm looking especially for input from folks who have experience with the
> Stockhausen accidental system, as well as whoever knows the background
> behind and usage of our accidentals.mirroredflat.backslash and
> accidentals.flatflat.slash glyphs. Everyone's advice is welcome, though!
>
> If all goes well, this message will be the first of several like it, as
> I determine what to name every Emmentaler glyph under the SMuFL system.
>
> (As a reminder, this will /not/ override the current glyph naming
> scheme; it /will /be providing an alternate way of locating glyphs
> within LilyPond and give other programs a way to access Emmentaler's
> glyphs via the SMuFL system.)
>
> After a few days, if no one's made any objections, I'll move on to the
> next few glyph categories.
>
> Regards,
> Owen
>
>

Re: "Well, here's another nice mess I've gotten myself into!" Previously Please test new lilypond installers

[Abraham Lee]

Hi, Michael!

On Thu, Jan 31, 2019 at 10:28 AM Michael Hendry 
wrote:

> > On 29 Jan 2019, at 19:00, Urs Liska  wrote:
> >
> > If you use alternative notation fonts you have to "install" them for
> every new LilyPond installation.
>
> [With apologies to Laurel & Hardy].
>
> Having successfully installed 2.21.0, I’ve tried to install Lilyjazz
> according to the instructions here:
>
> https://github.com/lyp-packages/lilyjazz





> I’m probably missing something obvious - can anyone help, please?
>

I don't use LYP for personal reasons, but it seems nice. The errors suggest
that some of the core functions (e.g., \require, \pinclude, etc.) are not
being found, which further suggests that whatever files define those are
not in LilyPond's include-path. You'll have to forgive me for not knowing
how to fix it since, again, I don't use it, but that should at least point
you in the right direction.

The alternative would be to download the lilyjazz files directly from that
repo and include them yourself.

HTH,
Abraham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Please test new lilypond installers

[Abraham Lee]

Hi, Knut, et al!

On Tue, Jan 29, 2019 at 2:19 AM Knut Petersen 
wrote:

> Hi everybody
>
> Urs Liska provides installers for branch master of lilypond, generated by
> an updated version of our build system GUB:
>
> https://cloud.ursliska.de/s/QPINwLqJNeVslCu
>
> There you'll find
> ...
> lilypond-2.21.0-1.mingw.exe
> ...
> Please test if those files provide valid lilypond installations and report
> success / failure by replying to this thread if no identical test results
> already have been posted.
>
> Knut
>

Installation + Compile works on my Windows 8.1 (64-bit) machine.

Best,
Abraham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Skylines and certain grob properties (rotation, extra-offset)

[Abraham Lee]

On Fri, Apr 20, 2018 at 12:17 PM, Werner LEMBERG  wrote:

> >> What do you think about making skylines consider the grob
> >> properties rotation and extra-offset?
> >>
> >> (1) keep everything as it is
> >> (2) skylines should reflect both grob rotation and grob extra-offset
> >> (3) skylines should reflect grob rotation only
> >> (4) skylines should reflect grob extra-offset only
> >>
> >> Obviously, (1) is sub-optimal and (2) and (4) would make
> >> extra-offset useless in many standard cases because it has been
> >> designed for arbitrary shifting around and shouldn't be hampered by
> >> skylines and it should be possible to make grobs overlap by using
> >> extra-offset.
> >>
> >> But skylines taking grob rotation into account would be a good
> >> idea, wouldn't it?
> >
> > Yeah, (3) seems good.
>
> I agree.


Me as well. extra-offset should remain an after-the-fact adjustment.

Best,
Abraham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

True Hand-engraved Dashed Slurs

[Abraham Lee]

Greetings, Devs!

I have always wondered why dashed slurs look the way they do, especially
when compared to the Barenreiter snippets found in the essay. The current
dashes look better than they used to, but I still think they look a bit odd
compared to the fairly uniform thickness of the hand-engraved Barenreiter
ones. Is there any historical reason they don't look that way? I'd be
curious to know if there is because I very much like the look of the
hand-engraved dashed slurs over the current LP dashed slurs.

In any case, I'm wondering what the right way to go about changing them to
look more like the Barenreiter ones is. I've cobbled together some PS code
that takes the Tie/Slur/PhrasingSlur control points and then generates a
separate stencil using those, but with a single dashed curve. This seems to
work just fine, but I'm wondering if there's a better internal way of
getting the same dashed curve without resorting to pure PS code?

You'll find my code and a comparison PDF attached.

All the best,
Abraham


old-style-dashed-slur.ly
Description: Binary data


old-style-dashed-slur.pdf
Description: Adobe PDF document
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Micro release feature list

[Abraham Lee]

Awesome Devs,

I'm wondering if there's a semi-convenient way to look through the 2.19.*
micro releases to see which features were added at which point. Any
suggestions for getting the info this way? It's not a critical thing, I'm
just curious to see when things came to be. I'm certainly aware of the
Changes page, but that seems to be more of a running list without a
connection to micro versions and doesn't account for all the spectacular
updates/features since 2.19 started.

Best and much thanks,
Abraham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: music function to be included somewhere in scm/*

[Abraham Lee]

On Tue, Dec 20, 2016 at 7:41 AM, Paul  wrote:

> Hi Knut, Werner, Alexander, and everyone,
>
> On 12/20/2016 08:47 AM, Knut Petersen wrote:
>
>> Hi Werner!
>>
>>>   (length-limit-or-forced-length ,ly:dimension? "An automatically
 generated lyric extender is suppressed if it would be shorter than
 this length. A forced lyric extender is given this length if
 possible.")

>>> Sorry, but I strongly dislike collapsing two properties into one, even
>>> if the values for the two properties are always the same.  So please
>>> use `collapse-length' (`suppress-threshold', etc.) and
>>> `forced-length'.
>>>
>>
>> I'll implement whatever the majority agrees upon.
>>
>> Nevertheless: two parameters would obfuscate the fact that
>> the internal logic would always decide to use only one  of those
>> lengths and to ignore the other.
>>
>> For the case of two parameters I like best:
>>
>> (forced-length ,ly:dimension? "A forced lyric extender
>> is given this length if possible.")
>> (collapse-length ,ly:dimension? "An automatically generated
>> lyric extender is suppressed if it would be shorter than
>> this length.")
>>
>> Paul?
>>
>
> I'm fine with using two properties, as Werner prefers, and as in this
> suggestion from Knut.
>
> When I suggested using fewer properties I didn't fully understand all the
> details.  (The music I typeset rarely involves lyric extenders.)
> Alexander's explanation and further discussions have helped me get it, but
> I hadn't had a chance to reply sooner.
>
> Thanks again for working on this,
>

Yes, thanks for making this possible! It will be a great addition.

One question I have about having the two properties is how will the two be
reconciled in actual use? In other words, if collapse-length is larger than
forced-length, will there still be the same amount of space between
syllables even without the extender (to the amount of forced-length)?

Maybe the question I really have is this: what does "given this length _if
possible_" mean and what governs this possibility? I can totally understand
how they work individually, I'm just trying to understand how I can use
them well together since it seems that forced-length contradicts
collapse-length.

Thanks,
Abraham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Stepping down and moving on

[Abraham Lee]

David,

On Wed, Nov 9, 2016 at 10:09 AM, David Kastrup <d...@gnu.org> wrote:
>
> Thanks for making me stay in the pond as long as I did!
>

I think it would be grossly insufficient to just say "thank you" for what
you've done, but thank you. Your expertise has enabled and improved a great
many things that everyone has benefitted from. I wish I had more time to
get into the thick of things myself, and perhaps I'll be able to. I hope
so. In any case, your contributions have taught me a great deal.

And congratulations on the new employment! I hope you find great
satisfaction through it! Please don't stay too far away.

Best,
Abraham Lee
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

[Bug] Incorrect cross-staff spacing from optical corrections

[Abraham Lee]

Devs,

Two things in this report.

1) The following minimal example shows inconsistent horizontal spacing
_between_ cross-staff beamed groups, even though the optically corrected
spacing _within_ each group is excellent.

2) The beams should also be flat, shouldn't they, since there is no net
vertical movement across the beamed group?

%%%

\version "2.19.36"

cu = \change Staff = "up"
cd = \change Staff = "dn"

upper = {
  \key d \major
  \repeat unfold 8 {
fis''16 \cd cis'' \cu
  }
}

lower = {
  \key d \major
  s1
}

\score {
  \new PianoStaff <<
\new Staff = "up" \upper
\new Staff = "dn" \lower
  >>
  \header { piece = "Incorrect spacing" }
}

%%%

The spacing/beaming can be corrected pretty easily like this:

%%%

upper_corrected = {
  \key d \major
  \override Beam.concaveness = #1
  \repeat unfold 4 {
fis''16 \cd cis'' \cu fis'' \cd cis'' \cu

% this is for the fis'' in the next group
\once \override NoteColumn.X-offset = #1.1
  }
}

\score {
  \new PianoStaff <<
\new Staff = "up" \upper_corrected
\new Staff = "dn" \lower
  >>
  \header { piece = "Correct spacing" }
}

%%%

Turning OFF the optical corrections (via the NoteSpacing layout object)
results in correct rhythmic spacing in both staves (at the expense of stem
placement, obviously).

Best,
Abraham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

[Feature Request] Make LSR #888 the default for calculating X-offset of lyrics with punctuation

[Abraham Lee]

Dev Team,

I really appreciate LSR #888: Center Lyric Syllables (ignoring
punctuation). Since most of what I engrave has lyrics, I can't think of any
reason why I wouldn't want this to be on all the time. Is it possible that
such a situation exists where I wouldn't want the punctuation to be
ignored? Perhaps, but I'd dare say they are much less likely.

Not sure how much more work would be needed to incorporate it officially,
but I'm wondering if this can be considered for inclusion into the core
code.

Thanks!

- Abraham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

[Feature Request] Align lyrics to middle of font 'x-height' instead of baseline

[Abraham Lee]

Dev Team,

I was wondering if you have any insight concerning the possibility
of/complications with changing the default Y-offset of LyricText to
be aligned on vertical center of the font's x-height. The Dynamics
characters do something similar already (roughly aligned on the vertical
center of Emmentaler's "m" glyph[1]), so why not lyrics? Seems like this
would bring a visual improvement over the current Y-offset of zero (i.e.,
the font's baseline).

The "x-height" is a standard font metric found in the metadata of the text
font, so you normally wouldn't need to calculate it on-the-fly (assuming
the designer set it correctly), but maybe calculating it on-the-fly would
be better, only reverting to the metadata value should the font not contain
the "x" glyph (rare, I'm sure)?

I guess this might only be helpful when you want the lyrics to be
vertically centered between two staves (like in a hymnal), so maybe there's
a better way to do this, like the Dynamics do, keeping its context mid-way
between staves?

Just some thoughts. Here's the relevant doc reference:

http://lilypond.org/doc/v2.19/Documentation/notation/flexible-vertical-spacing-within-systems#within_002dsystem-spacing-properties

Thanks for all you do!
- Abraham

P.S. Also, why is LyricText.font-size = #1 by default? Why not #0? Not
complaining. Just trying to understand.

[1] I say "roughly" because DynamicText doesn't actually query the Y-extent
of the "m" glyph. It has a hard-coded value that is close enough to match
the mid-height of Emmentaler's "m" (see line 857 of scm/define-grobs.scm
and line 972 of scm/output-lib.scm).
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

How to update an LSR snippet (Was: Use a straight tick (single straight quote) for a breath mark)

[Abraham Lee]

There's a lot about that snippet (LSR #195, and I imagine others) that I
think could really use an update/clean-up. I am wondering what the "policy"
is for updating existing snippets that I didn't create, if any? I've got an
LSR account already, so I'm happy to dive in and do it, but I can't seem to
change much as I'm not the original author).

Thanks,
Abraham

On Mon, Mar 21, 2016 at 10:39 AM, Joseph N. Srednicki-2 [via Lilypond] <
ml-node+s1069038n188765...@n5.nabble.com> wrote:

> Thanks, Thomas.
>
> This works.
>
> Joe Srednicki
>
> -Original Message-
> From: Thomas Morley [mailto:[hidden email]
> ]
> Sent: Monday, March 21, 2016 11:06 AM
> To: Joseph N. Srednicki <[hidden email]
> >
> Cc: lilypond-user <[hidden email]
> >
> Subject: Re: Use a straight tick (single straight quote) for a breath mark
>
> 2016-03-21 15:53 GMT+01:00 Joseph N. Srednicki <[hidden email]
> >:
>
> > Hello:
> >
> >
> >
> > I found the snippet that shows how to change symbol for the \breathe
> > command. See http://lsr.di.unimi.it/LSR/Snippet?id=195
> >
> >
> >
> > Can someone tell me how to change the script value to a straight tick,
> > similar to the straight single-quote character? Would it also be
> > possible to make this tick bold?
> >
> >
> >
> > Thanks for your help.
> >
> >
> >
> > Joe Srednicki
>
> Something like below?
>
> {
> a'1
> \override BreathingSign.text = \markup \vcenter \bold "'"
> \breathe
> b'
> }
> Cheers,
>   Harm
>
>
> ___
> lilypond-user mailing list
> [hidden email] 
> https://lists.gnu.org/mailman/listinfo/lilypond-user
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://lilypond.1069038.n5.nabble.com/Use-a-straight-tick-single-straight-quote-for-a-breath-mark-tp188758p188765.html
> To start a new topic under User, email ml-node+s1069038n...@n5.nabble.com
> To unsubscribe from Lilypond, click here
> 
> .
> NAML
> 
>
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Lose the tagline (permanently)

[Abraham Lee]

On Fri, Mar 4, 2016 at 11:27 AM, David Kastrup  wrote:

> I'm fine with making it classier rather than flashy.  But removing it is
> not doing us a favor.
>

Even though I don't love having print by default, there are times when I do
leave it and having it classier is a wonderful idea.

- Abraham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

OT: Using built-in ghostscript by itself

[Abraham Lee]

Devs,

I'm using Windows 7. I realize I can just download and install ghostscript
in the "normal" system location for what I want to do (which I've done),
but I was wondering if there's someone who understands the way that
LilyPond uses its built-in ghostscript command to do its job.

My question is this: How do I use the built-in ghostscript functionality by
itself?

I couldn't figure it out. When I call [LP_dir]/usr/bin/gs.exe I get the
error that it can't find gs_init.ps which is located in
[LP_dir]/usr/share/ghostscript/9.15/Resource/Init/. How do I tell gs.exe
where to find its files? Am I even using the right command?

Any help is welcome!

Best,
Abraham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Music function for arrow directions in arpeggios

[Abraham Lee]

On Tue, Feb 23, 2016 at 8:04 AM, Malte Meyn  wrote:

>
>
> Am 23.02.2016 um 15:52 schrieb Caio Giovaneti de Barros:
>
>> I'm trying to write a function to make easier for me to change arrow
>> directions in arpeggios.
>>
>
> I would prefer an event function with a tweak:
>
> \version "2.19.36"
>
> arpeggioUp = \tweak arpeggio-direction #UP \arpeggio
>
> \relative c' { \arpeggioUp }
>

I like this a lot and I feel like I've seen this exact discussion before,
but it didn't result in any core changes.

Dev Team,

Any reason \arpeggioArrowUp and \arpeggioArrowDown can't be defined this
way from the beginning? Is there a use-case where the "\arpeggioArrowUp  \arpeggio" way is necessary?

Best,
Abraham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Lose the tagline (permanently)

[Abraham Lee]

On Tue, Feb 23, 2016 at 7:00 AM, David Kastrup <d...@gnu.org> wrote:

> "Phil Holmes" <m...@philholmes.net> writes:
>
> > - Original Message -
> > From: "Abraham Lee" <tisimst.lilyp...@gmail.com>
> > To: "LilyPond Development Team" <lilypond-devel@gnu.org>
> > Sent: Tuesday, February 23, 2016 12:56 PM
> > Subject: Lose the tagline (permanently)
> >
> >
> >> Dear Dev team,
> >
> > [snip]
> >
> > I'd vote to keep it.
>
> Same here.  When people don't mind, it gives us exposure and
> reassurance.  When people mind, it's reasonably straightforward to turn
> off or change.
>
> Mutopia tended to have a severely overengineered tagline, I think they
> toned it down by now.  I do agree that it should be unobtrusive, but I
> think that the LilyPond tagline meets that bar.
>

Thanks, everyone, for your honest opinions (especially about the old
Mutopia tagline, which I agree with--it looks much cleaner now). I
appreciate that. I guess there will always be someone who does/doesn't like
this kind of thing. As long as it remains simple and unobtrusive and can be
deactivated at will, I suppose that will do.

On Tue, Feb 23, 2016 at 6:11 AM, James <p...@gnu.org> wrote:

> I think it should stay, we document how to turn it off. I always leave
> mine in. I might tweak the size or change the text slightly but only that.
>
> It is not that offensive, and actually in my own opinion having used it
> for scores in an orchestra I used to play in when I did disable it, I
> was asked if I used Sibelius or Finale to produce the scores.
>

I would doubt this was due to an apparent level of quality, but more of a
"Well, everyone seems to use S/F, so which did you use?" kind of thing. I'd
be willing to bet it was a question of expectation rather than accusation.


> So I left it back in and it generated a bit of interest.
>

Like I said, it definitely catches the reader's attention, which at least
makes people think about the program.


> Were we a huge FOSS project the size of Libre Office or MS Word - which
> by the way pops up a huge MS Word Screen Flash every time I run the
> program (that I cannot turn off) then I could possibly see the point.
>

That's my point exactly. Sibelius suffers from a similar case of narcissism
with its fanfare-filled startup (that thankfully can be turned off). Maybe
have it pop up the first time, but it's really not necessary/wanted after
that.


> I don't see it as cocky or a turn-off. It is what it is, and I expect
> that Music Publishers also have their own 'tagline' on every page of a
> score they produce - if only as a copyright, but often with their own
> name on it. What is the difference there?
>

I see what you're saying, but that's a little different. This is the user
imposing their own tagline, not the program. I have no problem with the
publisher putting on their own stamp, which I've usually seen as very
unobtrusive, almost not even there on the actual music pages. There
probably is *someone* out there that does this, but I don't think this is
that common.


> I am quite proud when I see that tagline on any score I 'find in the wild'.
>

I agree, I just hope we get to the point that we, too, can say "that score
looks so good, it must have been done with LP!" rather than relying on the
tagline to tell us.


> Historically see:
> http://lists.gnu.org/archive/html/lilypond-devel/2005-02/msg00279.html


Thanks for pointing to that thread. Nice to see what the original
motivation was.

Have a great day, everybody! You're all the best! Very grateful for all you
do to keep the LP wheels turning and improving.

- Abraham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Lose the tagline (permanently)

[Abraham Lee]

Dear Dev team,

I don't know if this discussion has come up before, but I thought I'd bring
something up that's been on my mind. I'd like to propose that we remove the
tagline variable (or at least its default value). For a while now (and
spurred on by some recent comments on other forums), I've felt that the
automatic presence of the tagline "Music engraving by LilyPond
X.Y.Z--www.lilypond.org" is annoying, a little bit cocky and a real
turn-off to those who don't use LP. Naturally, it attracts attention, but
shouldn't the engraving quality of the score speak for itself?

In any new score I create, it has become second nature for me to set
tagline = ##f because it gets in the way of the finished product. I don't
even think about it anymore, I just do it. I think this is also true for
most other power users. However, for those who are new, those who use it
occasionally, casually, etc., they may not think to turn this off in their
scores and users of other programs don't take them seriously. Instead of
the LP user implying "My score looks better than yours because I used LP to
do it," I'd rather have it be the non-LP user thinking "Wow! That looks so
good! What program did they use?" and then come to learn it was done with
LP. I say that because I've experienced both and the latter is way more
fulfilling (and door-opening) than the first.

Am I the only one who feels this way? I realize that the tagline has had a
specific purpose, but I don't really think I've seen another program do
anything like it--and for good reason. As a comparison, if LibreOffice
(which I use all the time), or better yet, Microsoft Office, automatically
put in their own tagline at the bottom of the last page of a document, I'D
GO CRAZY and immediately search to find out how to turn it off permanently.
I wouldn't want to have to turn it off for each document. That would get
old real quick. Get the program out of the way and let the music do the
talking. That's all I'm saying.

I'm not saying we should necessarily do away with the variable altogether,
but just have no default value unless the user wants one there like all the
other header variables. I can see that having something like the current
default value printed to the page during regression tests could be useful,
but really, what's the point anywhere else? I'm not sure what prompted
Han-wen or Jan or whoever to set a default value to it, but I wonder if
it's time for it to go?

Just some thoughts. I love the quality of LP scores. Removing the default
tagline value would make it even more professional (to me, at least), even
for the budding new users. Feel free to shoot now. What do you all think
about my proposal?

Best Regards,
Abraham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: LilyPond as a service

[Abraham Lee]

This sounds a lot like lilybin.com...

- Abraham

On Wed, Feb 17, 2016 at 2:45 PM, Urs Liska  wrote:

> I know this has been discussed in various flavors over the years, but I
> need to raise the issue once more. Please note that this actually
> encloses two questions.
>
> Would it be possible to make LilyPond work in a server mode where the
> whole Guile environment is loaded only once and the running server would
> be listening and accepting files to compile (or maybe piped .ly input or
> even Scheme music expressions)?
>
> I assume this could provide significant improvements in a number of use
> cases.
>
> How fundamentally would one have to turn LilyPond's architecture upside
> down for this? Is this conceptually impossible, just difficult or simply
> too big to have been tackled so far?
>
> Is this a task that could *somehow* be estimated in developer
> weeks/months if one would dream of a paid developer?
>
>
> ###
>
> A second idea is not directly related but would rely on the first. If
> LilyPond *could* run as a server, would there be a chance to keep the
> parsed document (i.e. not the engraving) in memory?
> This may seem nonsensical, but if I'm not mistaken this would open up
> the possibility to recompile a document with changed edition-engraver
> mods. As these could also comprise skipTypesetting commands this would
> make it possible to recompile an arbitrary excerpt (e.g. the current
> system) of a score while tweaking, without LilyPond having to parse the
> whole score over and over again.
>
> Same questions as above: conceptually possible at all, any estimate on
> the size of such an endeavour?
>
> Thanks
> Urs
>
> ___
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-devel
>
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Doc section name change proposition

[Abraham Lee]

Docs Team,

I noticed this a while back, but I thought I might as well bring it up.
Subsubsection 4.5.2  in NR is called "New spacing area", but the command it
introduces is called "\newSpacingSection". In favor of not changing the
command name, can we rename the section to match the command? In other
words, I am wondering if anyone is against changing the section name to
"New spacing section"?

On the other hand, is it conceivable that \newSpacingSection should be
renamed instead? I have no problem with that either.

Thanks everyone!
- Abraham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: LilyPond boolean syntax? \true and \false

[Abraham Lee]

On Tuesday, January 5, 2016, Paul Morris  wrote:

> Thanks to David Kastrup’s work there’s now much less need to use scheme
> syntax in overrides etc. (e.g. the dot syntax instead of #' and no longer
> needing # for numbers).  This has really simplified things for users.
>
> As another small step along these lines, would it make sense to free
> booleans from the ##t and ##f syntax?  Compare:
>
>   \override Context.Grob.property = ##t
>
>   \override Context.Grob.property = ##f
>
>   \override Context.Grob.property = \true
>
>   \override Context.Grob.property = \false
>
> Providing \true and \false would (1) allow users to stay in familiar
> LilyPond syntax (avoiding the awkward double ## that’s unintuitive to new
> users) and (2) improve readability by using the whole word.  (I for one
> find it hard to quickly see the difference between ##f and ##t at a glance.)
>
> Implementation would be trivial, of course:
>
>   true = ##t
>   false = ##f
>
> Thoughts?
> -Paul
>
> P.S. Guile 2.0 introduces #true and #false as alternatives to #t and #f
> per R7RS, presumably for better readability:
> https://www.gnu.org/software/guile/manual/html_node/Booleans.html
>

+1

I love this idea. I remember my own confusion with this when I was getting
my feet wet. Seems like a logical (pun intended) addition.

- Abraham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Typo about LilyDev image size

[Abraham Lee]

Documentation Writers,

I was just reading through the 2.19.31 contributors "Quick Start" guide
(Section 2.1) and it says this:

*"The LilyDev disk image can also be written to a USB device or ‘burnt’ to
a DVD – it is approximately 900 GB in size – and installed just like any
standard GNU/Linux distribution."*

Now, I don't know about anyone else, but I don't think I've ever seen a
Linux distribution that required 900 GB ;-) I'm pretty sure it should say
"900 *M*B" instead.

Best,
Abraham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

TextScript automatically italic in Dynamics context

[Abraham Lee]

Why is that? I see no reason that text in this context *must* be italic 
by default (and I know it can be changed back). Can someone help me 
understand the logic there?


- Abraham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Music glyph design choices

[Abraham Lee]

On 8/10/2015 10:32 AM, tisimst wrote:

On 8/9/2015 10:38 PM, Werner LEMBERG [via Lilypond] wrote:

The same as with the double-flat: we need evidence from real-world
scores to decide this.

Do you have time to check this?

A quick scan through IMSLP:

1. (Breikopf  Hartel, 1880) Chopin, Polonaise in B-flat minor:
Identical flats
2. (Peters, 1895) Grieg, Piano Concerto in A-minor (for piano 4 hands):
Identical flats
3. (Universal, 1920) Bartok, Studies for Piano, Op. 18: Identical flats

This is in way definitive, but seems like nice evidence for using
identical flats. I'd be very interested in seeing a score where they
were intentionally /not/ identical.

- Abraham


Here's another one:

(Barenreiter, 1970) Liszt, Études d'exécution transcendante, S.139: 
Identical flats


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

LilyPond Serif/Sans Serif/Monospace Text Fonts?

[Abraham Lee]

Greetings, Dev Team!

I was just browsing through some of the latest code (in scm/font.scm) and I
noticed that the default text font names are now LilyPond Serif, LilyPond
Sans Serif, and LilyPond Monospace. Do such fonts actually exist or are
these just place holders? It looks like the fontconfig allows for a
fallback fonts anyway. It's not a big deal. I was just curious. Looks like
Masamichi Hosoda made these changes.

http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=28f58ecc2271956e9377dc61e5135ce3ade4abbd

Thanks for everything you all do to make this program what it is today!

- Abraham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

[wish] Remove \skip duration in Lyrics

[Abraham Lee]

All,

I've seen lately a handful of users using (and suggesting to others) the
single underscore _ syntax to skip syllables in lyrics instead of \skip
X, which I think is a mistake when it's obvious they did not intend to
make a melisma. It works, except the lyrics get left-aligned to the first
note.

I am wondering if anyone has a better suggestion for a pure skipped
syllable to replace \skip X since the duration X doesn't matter at all.
It's easy enough to create a replacement macro like:

space = { \skip 4 }

or something like that. I was just thinking about a complimentary syntax to
the usual spacer note s when inputting notes.

I'm not sure what the magic word might be, but hopefully something as
simple, or simpler, than \skip would be handy so users don't have to put a
duration after it.

OR, it could use the number to say *how many syllables to skip* instead of
a duration. I'm thinking about the instances where I've seen (and used)
something like:

skipFour = \repeat unfold 4 { \skip 4 }

What do you all think?

- Abraham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: es means ees???

[Abraham Lee]

Richard,

AFAIK, it's not documented, but you can find all available note names in the 
file scm/define-note-names.scm, in which you'll find that both es and ees work 
for writing e-flat. 

Regards,
Abraham

Sent from my iPhone

 On Oct 6, 2014, at 5:12 AM, Richard Shann rich...@rshann.plus.com wrote:
 
 In the lilypond 2.19 installed file
 
 usr/share/lilypond/current/ly/chord-modifiers-init.ly
 
 I see the following at line 27
 
  c es ges-\markup { \super o } % should be $\circ$ ?
 
 
 Here, instead of ees, is written es.
 
 I've tried this out, and it appears to be a synonym, but I don't see
 this documented. Anyone know what's going on?
 
 Richard
 
 
 
 
 ___
 lilypond-devel mailing list
 lilypond-devel@gnu.org
 https://lists.gnu.org/mailman/listinfo/lilypond-devel

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: See the new music fonts in action

[Abraham Lee]

On Sat, Aug 2, 2014 at 4:46 AM, Alexander Kobel n...@a-kobel.de wrote:

On 08/02/2014 09:00 AM, David Kastrup wrote:
Well, looking at the definition of set-global-staff-size would seem 
to

indicate how the size is being set.  I suspect that calculating the
relevant module in that manner and then looking up output-scale in 
it

might do the trick.  But I haven't really understood the output scale
business anyway.  It's not clear to me how it works in every
circumstance.

That's not quite what I wanted to hear...  If /you/ say that, it 
makes me wonder whether a) the entire business is seriously broken by 
design or b) it's waaay above what I'll ever understand.
I agree that looking up the relevant module seems to be the missing 
link.  Anyway, I'll have a look after Aug, 10.



Best,
Alexander


Well, my question is this. If I can do something like:

#(set-global-staff-size 18)

\paper {
 #(define fonts (make-pango-font-tree ... (/ staff-height pt 20)))
}

where staff-height gets referenced _outside_ of the 
set-global-staff-size call, then why can't we just reference it 
directly within the make-pango-font-tree syntax? It appears that the 
variable/property is stored somewhere, but where? and why can I 
reference it, but make-pango-font-tree can't?


-Abraham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Allow changing of notation fonts (issue 115590043 by lilyli...@googlemail.com)

[Abraham Lee]

On Sat, Aug 2, 2014 at 10:40 AM, lilyli...@googlemail.com wrote:

Reviewers: ,

Message:
This is the current state of Abraham's approach to make music fonts
switchable. The patch is incomplete in a few senses, but Abraham wants
an official review for that current state:

- there's no documentation
  - We'll take care of that once the user interface
 has been fixed
- there's no convert-ly rule
  - ditto, this should pose no problems.
- the patch will somehow have to be integrated with
  Alexander's work on the text font selection interface,
  but Alexander considers it not too problematic.

See
http://lists.gnu.org/archive/html/lilypond-user/2014-08/msg00016.html

Description:
Allow changing of notation fonts

This commit changes the behaviour of make-pango-font-tree in the
following ways:

- Make all arguments optional key/value pairs
  keeping the current default values (emmentaler/Century Schoolbook)
- Allow changing of music fonts too.

Currently alternative music fonts have to be present in the font
directory besides Emmentaler fonts, and they have to be manually
installed.
But now there are a number of alternative and compatible fonts
available.

Please review this at https://codereview.appspot.com/115590043/

Affected files (+42, -6 lines):
  M scm/font.scm


Index: scm/font.scm
diff --git a/scm/font.scm b/scm/font.scm
index 
867612ae11529c3426a795498a6dc5168481f427..e177a055edb31ca56bcc4030718b2b759da75c4a 
100644

--- a/scm/font.scm
+++ b/scm/font.scm
@@ -147,7 +147,7 @@

 ;; Each size family is a vector of fonts, loaded with a delay.  The
 ;; vector should be sorted according to ascending design size.
-(define-public (add-music-fonts node name family design-size-alist 
factor)
+(define-public (add-music-fonts node family name brace 
design-size-alist factor)

   Set up music fonts.

 Arguments:
@@ -156,12 +156,15 @@ Arguments:
 @var{node} is the font tree to modify.

 @item
+@var{family} is the family name of the music font.
+
+@item
 @var{name} is the basename for the music font.
 @file{@var{name}-designsize.otf} should be the music font,
-@file{@var{name}-brace.otf} should have piano braces.

 @item
-@var{family} is the family name of the music font.
+@var{brace} is the basename for the brace font.
+@file{@var{brace}-brace.otf} should have piano braces.

 @item
 @var{design-size-alist} is a list of @code{(rounded . designsize)}.
@@ -199,7 +202,7 @@ used.  This is used to select the proper design 
size for the text fonts.

)))
  (fetaBraces ,(ly:pt 20.0)
  #(,(delay (ly:system-font-load
-(format #f ~a-brace name)
+(format #f ~a-brace brace)
  )))

 (define-public (add-pango-fonts node lily-family family factor)
@@ -229,9 +232,40 @@ used.  This is used to select the proper design 
size for the text fonts.

   (add-node 'italic 'normal)
   (add-node 'italic 'bold))

+; This function allows the user to change the specific fonts, 
leaving others
+; to the default values. This way, make-pango-font-tree's syntax 
doesn't

+; have to change from the user's perspective.
+;
+; Usage:
+;   \paper {
+; #(define fonts
+;   (set-global-fonts
+;#:music gonville  ; (the main notation font)
+;#:roman FreeSerif ; (the main/serif text font)
+;   ))
+;   }
+;
+; Leaving out #:brace, #:sans, and #:typewriter leave them at
+; emmentaler, sans-serif, and monospace, respectively. All 
fonts are
+; still accesible through the usual scheme symbols: 'feta, 'roman, 
'sans, and

+; 'typewriter.
+(define*-public (set-global-fonts #:key
+  (music emmentaler)
+  (brace emmentaler)
+  (roman Century Schoolbook L)
+  (sans sans-serif)
+  (typewriter monospace)
+  (factor 1))
+  (let ((n (make-font-tree-node 'font-encoding 'fetaMusic)))
+(add-music-fonts n 'feta music brace feta-design-size-mapping 
factor)

+(add-pango-fonts n 'roman roman factor)
+(add-pango-fonts n 'sans sans factor)
+(add-pango-fonts n 'typewriter typewriter factor)
+n))
+
 (define-public (make-pango-font-tree roman-str sans-str 
typewrite-str factor)

   (let ((n (make-font-tree-node 'font-encoding 'fetaMusic)))
-(add-music-fonts n emmentaler 'feta feta-design-size-mapping 
factor)
+(add-music-fonts n 'feta emmentaler emmentaler 
feta-design-size-mapping factor)

 (add-pango-fonts n 'roman roman-str factor)
 (add-pango-fonts n 'sans sans-str factor)
 (add-pango-fonts n 'typewriter typewrite-str factor)
@@ -240,7 +274,9 @@ used.  This is used to select the proper design 
size for the text fonts.

 (define-public (make-century-schoolbook-tree factor)
   (make-pango-font-tree
Century Schoolbook L
-   sans-serif monospace factor))
+   sans-serif
+   monospace
+   factor))

 (define-public all-text-font-encodings
   '(latin1))



___
lilypond-devel mailing list
lilypond-devel@gnu.org

Re: See the new music fonts in action

[Abraham Lee]

On Fri, Aug 1, 2014 at 3:51 PM, Alexander Kobel n...@a-kobel.de wrote:


factor is relevant if you set the global staff size to something 
different than 20, the default.  The usual rule-of-tree used to be 
something like

  myStaffSize = #17.82
  #(set-global-staff-size myStaffSize)
  #(define fonts (make-pango-font-tree ... (/ myStaffSize 20)))

BTW, I never really understood whether it is technically possible to 
automatically figure out factor at the point where 
make-pango-font-tree is called?  If not, why?  And if yes, is there 
any reason why it is not done?



Best,
Alexander

Ah, yes. I knew there was a reason for the syntax (/ staff-height pt 
20) or its equivalent. I just tried to play around with 
make-pango-font-tree and I couldn't seem to figure out how to reference 
the staff-height variable within this function. 


David Kastrup? Anyone? Any ideas?

Regards,
Abraham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Next step for easier custom music font switching

[Abraham Lee]

Janek,

Thanks for your thoughts.

On Sun, Jul 20, 2014 at 3:47 AM, Janek Warchoł 
janek.lilyp...@gmail.com wrote:

Btw, just to make sure: have you seen
https://code.google.com/p/lilypond/issues/detail?id=4014 ?



Yeah, I saw that and I think it's awesome!


A thought: i'm missing the possibility to set the weight of the music
font used by LilyPond for a particular score.  In other words: let's


‘2’
Yeah, that makes sense. That's exactly how Feta (Emmentaler) is 
designed. Each optical size has a different weight, where heavier 
ones are designed for smaller print sizes and lighter ones are 
designed for larger print sizes. In the font files, they are actually 
the same size. 

The challenge here is how each of the glyphs get heavier or 
lighter. This is a non-trivial design problem. I guess we could use 
FontForge's ability to uniformly change a font's weight, but I think 
this automagic change might not be what we really want (maybe it is). 
If you look at what changes the weights of the different optical text 
fonts, you'll find it's more than just making all the lines thicker 
(which is what FontForge does). Even Feta doesn't change like this 
through the different sizes. It changes more in some places than in 
others, preserving certain features and highlighting others. It's a 
complicated task. I really, REALLY like the idea of optical fonts, but 
I'm not sure if they should be required due to the design challenge 
associated with them. By comparison, you won't find many optical text 
fonts out there for this very reason.


Originally, when I was making Cadence, this is what I wanted to do, and 
maybe I still will, but it takes a TON more effort to make eight 
different fonts that differ by intentional weight changes than just 
using the same one. Not the ideal result, I agree, but I'm not sure 
what else to do about that. 

If we wanted to spend the time to really design the optical sizes for 
each font family, then, yeah, being able to specify a heavier optical 
weight at a size that differs from its intended size might be helpful, 
but just ask Han-wen, et al. about the effort that went into making all 
the different optical sizes for Feta. I'm not sure if this capability 
would be useful for some time.


Regards,
Abraham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: LilyPond meeting 2014?

[Abraham Lee]

Oh, I wish I could go! Unfortunately it's kind of a huge expense to fly
from the USA :(. Enjoy, whoever goes!

Regards,
Abraham


On Sun, Jul 13, 2014 at 7:50 AM, David Kastrup d...@gnu.org wrote:

 Janek Warchoł janek.lilyp...@gmail.com writes:

  2014-07-13 10:53 GMT+02:00 Marc Hohl m...@hohlart.de:
  Am 12.07.2014 19:58, schrieb Mike Solomon:
  I’d love to meet up but I am in gig mode as well towards the end of the
  summer and we have a newborn in the house.
 
 
  Hey, congratulations! The nights are quiet, yes? ;-)
  All the best for all of you!
 
  I suppose at nights they're rehearsing the Queen of the Night
 coloraturas ;-)

 Oh, lots of time.  One would already call
 URL:https://www.youtube.com/watch?v=F9ijwfRTv0o a young performer.
 There is also URL:https://www.youtube.com/watch?v=sF0zePMxxys but
 frankly, I cannot understand a word.

 --
 David Kastrup

 ___
 lilypond-devel mailing list
 lilypond-devel@gnu.org
 https://lists.gnu.org/mailman/listinfo/lilypond-devel

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Slashed notehead collision

[Abraham Lee]

Anyone know what's causing this?

On Wed, May 28, 2014 at 3:45 PM, tisimst tisi...@gmail.com wrote:
I just noticed a peculiar collision that I couldn't make go away 
between the

noteheads.s0slash glyph and a tie. Here's a minimal snippet:

\new Staff {
  \new Voice \with {
\consists Pitch_squash_engraver
  }
  \relative c' {
\improvisationOn
f1 ~
f2
  }
}

http://lilypond.1069038.n5.nabble.com/file/n162855/slashednoteheadcollision.png 

A slur works doesn't clash, but a tie does. Seems like a bug that 
needs some

serious squashin' though I'm not sure where to attack this one :) Just
thought I'd bring it up.

-Abraham



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Slashed-notehead-collision-tp162855.html

Sent from the Dev mailing list archive at Nabble.com.

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel