Re: Future of openLilyLib

[Urs Liska]

Well, despite two of today's statements arguing otherwise I must say I
have come to a different conclusion. I have given myself exactly two
weeks to make a determination, and I realized I have obviously
overestimated the value and impact of my pet project openLilyLib. The
two weeks until yesterday since my (I think pretty strong and explicit)
statement did not trigger *anything* except one stupid and off-topic
discussion. So I realize there is no substantial need for openLilyLib,
and I don't have the resources left (in terms of time and mental or
physical energy) to push it forward without community support. And to
be honest, to include \shapeII into LilyPond or not is definitely not a
matter of having openLilyLib or not.

So today I copied all the relevant repositories to my own Git server
and removed myself from the corresponding Github organizations. I will
use what is there to complete three substantial projects I still have
on my desktop. Everything that is necessary to use and improve the
library and the packages is still freely available and appropriately
licensed, so if anybody considers it worth the effort they can do with
it whatever seems suitable. 

Best
Urs

PS:
Those few who know more about the background shouldn't worry too much
about the final character of this statement ...

Am Montag, den 21.09.2020, 17:24 +0200 schrieb Urs Liska:
> Hi all,
> 
> to begin with, I am of the (biased) opinion that openLilyLib is a
> powerful and useful extension infrastructure for LilyPond. There are
> a
> number of versatile and extended ready-to-use packages available,
> most
> notably probably edition-engraver, scholarLY and anaLYsis. But also
> the
> underlying oll-core is versatile and powerful, providing numerous
> building blocks without which I would not start any large-scale
> project
> anymore.
> 
> I can understand why this view is not shared by everyone, most likely
> simply because too much about OLL is obscure or unknown, lacking
> proper
> documentation, although the general introduction at 
> https://openlilylib
> .org should be a good start (and there are substantial manuals for
> the
> scholarLY and stylesheets packages, but only in (undocumentedly)
> self-
> compilable form).
> 
> At this point openLilyLib is completely dependent on my availability,
> at least because I am the only person with knowledge of the basic
> code
> in oll-core. 
> 
> For several reasons which I won't discuss publicly I will have to
> reduce my availablity to work on openLilyLib (and other stuff) and
> may
> be forced to completely withdraw at any point within the next years.
> 
> I would find it a pity if that would mean the end for openLilyLib.
> Therefore I'm looking not for a new maintainer but for more people
> engaging in the project, to build a community around it that can at
> some point continue without my aid.
> 
> The aspects needing support most urgently AFAICT are (in descending
> order):
> 
>  * getting more people familiar with oll-core (using the opportunity
> to
>maybe improve the coding where appropriate)
>  * complete the documentation system in order to make a more complete
>documentation feasible (here the most crucial part is integrating
>consistently scalable score examples in the web site output).
>  * getting more people familiar with the coding of scholarLY
>  * do maintenance of everything, maybe throwing out some less-than-
>useful packages
>  * write a Frescobaldi extension for managing (installing, updating
> the
>library or individual packages, preparing documents) openLilyLib
> and
>providing an API for secondary extensions (e.g. an annotation
>editor/viewer or a tool to graphically insert editionMods).
> 
> If anything of this looks like your cup of tea you are welcome to
> contact me privately or discuss stuff on-list. Of course I am more
> than
> willing to help with any of these tasks.
> 
> Best
> Urs
> 
> 

Re: Future of openLilyLib

[Urs Liska]

Am Dienstag, den 22.09.2020, 17:29 +1000 schrieb Andrew Bernard:
> What would the difference be should _lilypond_ use LGPL instead of
> GPL? I'm sorry, I think the OP amounts to a type of elaborate
> trolling
> of the community. Nothing needs changing.

I think so too.

> 
> This has all been gone through. I can only perceive this as an
> attempt
> to damage openlilylib in people's minds (heavens, why?). 

I will not further engage in this discussion. But I'm sure this is not
intended trolling but a sincere although misguided belief.

> Really,
> enough now.

+1

Urs
> 
> 
> Andrew
> 
> On Tue, 22 Sep 2020 at 16:40, Jacques Menu 
> wrote:
> > Hello everybody,
> > 
> > The legal subtleties of public licensing never made their way into
> > my mind, sorry for being limited…
> > What would the difference be, should openLilyLib use LGPL instead
> > of GPL?
> > 
> > 

Future of openLilyLib

[Urs Liska]

Hi all,

to begin with, I am of the (biased) opinion that openLilyLib is a
powerful and useful extension infrastructure for LilyPond. There are a
number of versatile and extended ready-to-use packages available, most
notably probably edition-engraver, scholarLY and anaLYsis. But also the
underlying oll-core is versatile and powerful, providing numerous
building blocks without which I would not start any large-scale project
anymore.

I can understand why this view is not shared by everyone, most likely
simply because too much about OLL is obscure or unknown, lacking proper
documentation, although the general introduction at https://openlilylib
.org should be a good start (and there are substantial manuals for the
scholarLY and stylesheets packages, but only in (undocumentedly) self-
compilable form).

At this point openLilyLib is completely dependent on my availability,
at least because I am the only person with knowledge of the basic code
in oll-core. 

For several reasons which I won't discuss publicly I will have to
reduce my availablity to work on openLilyLib (and other stuff) and may
be forced to completely withdraw at any point within the next years.

I would find it a pity if that would mean the end for openLilyLib.
Therefore I'm looking not for a new maintainer but for more people
engaging in the project, to build a community around it that can at
some point continue without my aid.

The aspects needing support most urgently AFAICT are (in descending
order):

 * getting more people familiar with oll-core (using the opportunity to
   maybe improve the coding where appropriate)
 * complete the documentation system in order to make a more complete
   documentation feasible (here the most crucial part is integrating
   consistently scalable score examples in the web site output).
 * getting more people familiar with the coding of scholarLY
 * do maintenance of everything, maybe throwing out some less-than-
   useful packages
 * write a Frescobaldi extension for managing (installing, updating the
   library or individual packages, preparing documents) openLilyLib and
   providing an API for secondary extensions (e.g. an annotation
   editor/viewer or a tool to graphically insert editionMods).

If anything of this looks like your cup of tea you are welcome to
contact me privately or discuss stuff on-list. Of course I am more than
willing to help with any of these tasks.

Best
Urs

Re: Scrape around rim

[Urs Liska]

Am Dienstag, den 15.09.2020, 09:09 +1000 schrieb Andrew Bernard:
> No, but you can use SMuFL glphys with a package from openlilylib.
>   I use it all the time for exotic accidentals. All the SMuFL
> glyphs
>   are available. It's easy.
> 
> 
> 
> You can search the archives for how to install and use
>   openlilylib. It's not hard. I think Urs has a page where he has
>   written instructions also, but I don;'t know where.

https://op id="-x-evo-selection-start-marker">enlilylib.org ;-)
It only covers the basics yet (nothing of individual packages), but
getting and installing is covered.
BestUrs
> 
> 
> 
> 
> Andrew
> 
> 
> 
> 
> 
> On 15/09/2020 12:52 am, Martín Rincón
>   Botero wrote:
> 
> 
> 
> >   
> >   
> > Does Lilypond have this symbol natively? 
> > https://www.smufl.org/version/latest/glyph/pictScrapeAroundRim/
> > 
> > 
> >   
> > 
> 
>   
> 

Re: lilyglyphs issue?

[Urs Liska]

Am Mittwoch, den 09.09.2020, 00:55 -0500 schrieb Fernando Gil:
> I'm sorry if this question does not belong here:
> I'm sorry if this question does not belong here.

It's OK to post this here, although 
https://github.com/uliska/lilyglyphs/issues would be the canonical
place.

> I'm trying to use lilyglyphs with TeX but no matter if it's a large
> code or a small one like this one below, it prints a square as you
> can see in the attachment.
> 
> I've tried changing the text font but with no luck.

This is a known issue and has been fixed in
https://github.com/uliska/lilyglyphs/commit/06aa0a6db6b1710f3a276fd36ffe2bd6688087b0
but not included in a release yet.

Unfortunately there's a bigger issue with using outdated Python 2 code,
due to which lilyglyphs has been removed from TeX Live on several Linux
distributions.

If I find the time to fix that (or if anybody would volunteer with that
- should be pretty easy), I'll certainly release an update including
your issue with the square.

Urs

> %%
> 
> 
> 
> 
> 
> 
> \documentclass[10pt]{article}
> 
> \usepackage{fontspec}
> 
> \usepackage{lilyglyphs}
> 
> \usepackage{babel}
> 
>   
> 
> \begin{document}
> 
> Hello \natural{} this is another \flatflat{} text.
> 
> \end{document}
> %%
> 
> After hours, I discovered another issue: When using lilyglyphs with
> babel package with a language option like this:
> \usepackage[spanish]{babel} the document does not compile, because of
> an interaction between these two packages that I don't understand.
> 
> I'm on mac (TeXLive 2020)
> 
> Hoping Urs or any other have a potential solution,
> 
> Cheers,
> Fernando

Handling quoted lists

[Urs Liska]

I'm feeling totally stupid, but after hours of nightly poking and
ly:message "debugging" around I'm at least at a point where I can ask
concrete questions instead of an MWE.

In 
https://github.com/openlilylib/oll-core/blob/master/internal/properties.scm#L566-L611
 (may not be the latest state!) I'm trying to create a macro and get
messed up with quoting etc.

In 
https://github.com/openlilylib/oll-core/blob/master/usage-examples/properties.ly#L10
 a symbol list demo.props is created and properly handled.

But in 
https://github.com/openlilylib/oll-core/blob/master/usage-examples/properties.ly#L50-L51
 a (quasi)quoted list isn't managed correctly. I would now use 
  '(demo props)
here to create a regular symbol list, but this ends up as
  (quote (demo props))
in the macro. When used later in
https://github.com/openlilylib/oll-core/blob/master/internal/properties.scm#L20
  (append '(_propsets) propset-path))
will result in
  (list (quote _propsets) (quote quote) (list (quote demo) (quote
props)))

Spo the question must be simple and me stupid, but how can I add the
symbol list as an argument in Scheme (in the macro invication) so the
last  call will result in a flat symbol list?

Thanks for any pointer, hint or solution!
Urs

Re: Incorrect cropping when integrating score with lyluatex

[Urs Liska]

So this is an issue with manual vertical spacing in LilyPond, not wirt
lyluatex.
Unfortunately I've never really been familiar with this, so someone
else should step in.
The underlying issue is that LilyPond isn't really aware of the actual
extent of the system when cropping. This happens when you move items
around by overridindǵ their extra-offset properties but seems an issue
too ehen pushing around the staves themselves.
I don't know if overriding the Y-extent of the dynamics will help here.
ursHTH anyway

Am Sonntag, den 30.08.2020, 11:57 +0200 schrieb Claire Meyer:
> Hi Urs,
> 
> Huh ! 
> > This will give you one cropped pdf plus a number of indexed pdf 
> files for each system. The cropping issues should be visible there
> too 
> and might give some more clues for understanding the issue.
> Yep, a 100%. I attached the outputs for one system where the problem
> is visible; one from lilypond, one from lilypond + lyluatex. The
> cropped pdf with all systems has no cropping issue.
> 
> Is there anything else I can provide  ?
> Claire
> 
> On Sun, Aug 30, 2020 at 11:26 AM Urs Liska 
> wrote:
> > Hi Claire,
> > I'm not sure how the manual vertical positioning interacts with the
> > cropping, but you can test further  by inserting   \include
> > "lilypond-book-preamble.ly" in your file.This will give you one
> > cropped pdf plus a number of indexed pdf files for each system. The
> > cropping issues should be visible there too and might give some
> > more clues for understanding the issue.
> > The most common cause for such cropping issues would be (not in
> > your case) moving stuff with extra-offset, which is then not
> > included in the obkjects' X/Y-extent.
> > Urs
> > Am Sonntag, den 30.08.2020, 11:12 +0200 schrieb Claire Meyer:
> > > Hi all,
> > > 
> > > I'm integrating a score with latex via lyluatex. The .ly file is
> > > finished, and gives no error; the score produced looks good, and
> > > I'm at the step where I just integrate with latex, and touch up
> > > the things that need retouching. I insert system by system, and
> > > unfortunately, some dynamics are mostly cropped out :
> > > 
> > > 
> > > The scribble between the two systems is a dynamic mark that
> > > applies to the lower system. I looked in the temporary files
> > > generated by lyluatex, and the pdfs are cropped in such a manner
> > > that all my higher-placed-within-the-system dynamics are mostly
> > > removed.
> > > 
> > > Those dynamics are all custom dynamic marks that I constructed
> > > like :
> > > 
> > > mydyn = \tweak DynamicText.self-alignment-X #LEFT
> > >   #(make-dynamic-script
> > >   (markup
> > >   #:with-dimensions '(0 . 5) '(0 . 0) #:line
> > >   (#:normal-text #:italic " > > mark says>")))
> > > 
> > > They were badly placed with automatic placement (overlapping with
> > > the phrasing slurs, mostly), so I specified in my score for those
> > > dynamics that :
> > > 
> > > 
> > >   \new Dynamics \with {
> > >   \override VerticalAxisGroup.nonstaff-
> > > relatedstaff-spacing =
> > >   #'((basic-distance . 6)
> > >   (minimum-distance . 5)
> > >   (padding . 3)
> > >   (stretchability . 6))
> > >   } { \dynamicsA }
> > > 
> > > 
> > > Any idea how to solve that problem ? I tried to include
> > > everything relevant to not just code dump things here, but ask
> > > away if I forgot something.
> > > 
> > > Thanks,
> > > Claire
> > > 

Re: Incorrect cropping when integrating score with lyluatex

[Urs Liska]

Hi Claire,
I'm not sure how the manual vertical positioning interacts with the
cropping, but you can test further  by inserting   \include "lilypond-
book-preamble.ly" in your file.This will give you one cropped pdf plus
a number of indexed pdf files for each system. The cropping issues
should be visible there too and might give some more clues for
understanding the issue.
The most common cause for such cropping issues would be (not in your
case) moving stuff with extra-offset, which is then not included in the
obkjects' X/Y-extent.
Urs
Am Sonntag, den 30.08.2020, 11:12 +0200 schrieb Claire Meyer:
> Hi all,
> 
> I'm integrating a score with latex via lyluatex. The .ly file is
> finished, and gives no error; the score produced looks good, and I'm
> at the step where I just integrate with latex, and touch up the
> things that need retouching. I insert system by system, and
> unfortunately, some dynamics are mostly cropped out :
> 
> 
> The scribble between the two systems is a dynamic mark that applies
> to the lower system. I looked in the temporary files generated by
> lyluatex, and the pdfs are cropped in such a manner that all my
> higher-placed-within-the-system dynamics are mostly removed.
> 
> Those dynamics are all custom dynamic marks that I constructed like :
> 
> mydyn = \tweak DynamicText.self-alignment-X #LEFT
>   #(make-dynamic-script
>   (markup
>   #:with-dimensions '(0 . 5) '(0 . 0) #:line
>   (#:normal-text #:italic " mark says>")))
> 
> They were badly placed with automatic placement (overlapping with the
> phrasing slurs, mostly), so I specified in my score for those
> dynamics that :
> 
> 
>   \new Dynamics \with {
>   \override VerticalAxisGroup.nonstaff-
> relatedstaff-spacing =
>   #'((basic-distance . 6)
>   (minimum-distance . 5)
>   (padding . 3)
>   (stretchability . 6))
>   } { \dynamicsA }
> 
> 
> Any idea how to solve that problem ? I tried to include everything
> relevant to not just code dump things here, but ask away if I forgot
> something.
> 
> Thanks,
> Claire
> 

Re: lilyglyphs not found in ubuntu packages 20.04

[Urs Liska]

Am Samstag, den 29.08.2020, 14:14 +0200 schrieb bart deruyter:
> Thanks for the update, I'll look into how I can change my document so
> it uses lyluatex only. I used lyluatex to include complete scores in
> my document, not for single musical signs, for that I used
> lilyglyphs. 

That's the idea, yes.
A workaround is to use lyluatex with insert=bare-inline, which includes
the music without a staff.
The significant advantage of this approach is that it doesn't have to
choose between Emmentaler glyphs and composed music.
> Actually I'm considering to drop the latex road and switch to
> libreoffice, for one big important reason: epub, and I need the epub
> format because of the pandemic. I expect more Covid-19 related
> shutdowns of the schools I work for, and my students use mobile
> devices very often. On these pdf's are often not good, they don't
> scale good, epub does.
> 
> There is one important reason to keep lilyglyphs: compatibility with
> older documents. 

Indeed. I would prefer keeping lilyglyphs available. But I'm afraid
there are issues beyond the Python dependency (which shouldn't be too
complicated after all). I had started fiddling around with a LuaLaTeX-
only version making use of new functionality, and IIRC I got stuck with
various issues. Maybe the best way to go forward would be to reset
lilyglyphs to the last released version and simply update the Python
stuff ...
I hope to find the time to look inzto that.
Urs
> If I get what I need from lyluatex it's OK for me personally to drop
> support for it, I haven't used it that often, I can handle fixing
> that, but I doubt I'm the only one having documents using
> lilyglyphs. 
> I do revisit older files too and when my pdf's fail to compile
> because of issues like these, needing to update something urgently, I
> think everybody can agree that is not a very happy moment.
> I was lucky it was not urgent. I really can't believe I'm the only
> one having used lilyglyphs, so I'm afraid, dropping support for it
> all together will result in many 'not very happy moments'.
> 
> grtz,
> Bart
> https://esmiltania.be
> On Twitter
> On Google+
> 
> 
> Op vr 28 aug. 2020 om 22:06 schreef Urs Liska 
> :
> > Hi Bart,
> > thanks for reminding.
> > Am Freitag, den 28.08.2020, 21:20 +0200 schrieb bart deruyter:
> > > Hi all,
> > > I would need to start working on my project again, using luatex,
> > > lilypond, lyluatex and lilyglyphs. But lilyglyphs appears to be
> > > missing from the ubuntu packages. This summer I upgraded to 20.04
> > > though, and I found out to my surprise, lilyglyphs is missing. It
> > > is present in 'eoan' though.
> > > 
> > > I already contacted the developer but only heard from him it is
> > > missing indeed and he did not know why either.
> > > Maybe someone here knows what has been going on.
> > 
> > I asked on the texlive mailing list, and I got an answer, but I
> > didn't manage following through
> > Am Freitag, den 03.07.2020, 07:41 +0900 schrieb Norbert Preining:
> > > > Hi Urs,
> > > > 
> > > > 
> > > > 
> > > > > > Someone posted an issue that lilyglyphs.sty seems to be
> > > > missing in
> > > > > > TeX
> > > > > > Live after updating to Ubuntu 20.04.
> > > > 
> > > > 
> > > > And in Debian. Because it depends on Python2 the last time I
> > > checked,
> > > > 
> > > > and Python2 programs are not acceptable anymore in Debian and
> > > Ubuntu:
> > > > 
> > > > 
> > > > 
> > > > From my Debian package building config file (ignore the syntax
> > > > around)
> > > > 
> > > > # python3 purge - blacklist all packages that don't
> > > have py3
> > > > support
> > > > 
> > > > blacklist;tpm;ebong;*
> > > > 
> > > > blacklist;tpm;de-macro;*
> > > > 
> > > > blacklist;tpm;lilyglyphs;*
> > > > 
> > > > blacklist;tpm;pygmentex;*
> > > > 
> > > > blacklist;tpm;sympytexpackage;*
> > > > 
> > > > 
> > > > 
> > > > Update to Python3 version of the scripts is necessary.
> > 
> > So the workaround would be to either update the helper scripts to
> > Python 3 or to drop these scripts. Off the top of my head I don't
> > know how important these scripts actually are or how complex it
> > would be to update them.
> > They are used to create sets of new notation elements. IIRC.My
> > personal gut feeling would be to drop support for lilyglyphs
> > altogether because lyluatex can do everything lilyglyphs can, and
> > better - i.e. without the need for pre-compiled PDFs. But - and
> > that's a big but - the advantage of lilyglyphs is that it doesn't
> > need to run LilyPond. *I* will always have LilyPond around, but for
> > a general audience this would be a major limitation, I think.
> > Opinions?
> > Urs
> > > https://esmiltania.be
> > > On Twitter
> > > On Google+
> > > 

Re: lilyglyphs not found in ubuntu packages 20.04

[Urs Liska]

Hi Bart,
thanks for reminding.
Am Freitag, den 28.08.2020, 21:20 +0200 schrieb bart deruyter:
> Hi all,
> I would need to start working on my project again, using luatex,
> lilypond, lyluatex and lilyglyphs. But lilyglyphs appears to be
> missing from the ubuntu packages. This summer I upgraded to 20.04
> though, and I found out to my surprise, lilyglyphs is missing. It is
> present in 'eoan' though.
> 
> I already contacted the developer but only heard from him it is
> missing indeed and he did not know why either.
> Maybe someone here knows what has been going on.

I asked on the texlive mailing list, and I got an answer, but I didn't
manage following through
Am Freitag, den 03.07.2020, 07:41 +0900 schrieb Norbert Preining:
> > Hi Urs,
> > 
> > 
> > 
> > > > Someone posted an issue that lilyglyphs.sty seems to be missing
> > in
> > > > TeX
> > > > Live after updating to Ubuntu 20.04.
> > 
> > 
> > And in Debian. Because it depends on Python2 the last time I
> checked,
> > 
> > and Python2 programs are not acceptable anymore in Debian and
> Ubuntu:
> > 
> > 
> > 
> > From my Debian package building config file (ignore the syntax
> > around)
> > 
> > # python3 purge - blacklist all packages that don't have
> py3
> > support
> > 
> > blacklist;tpm;ebong;*
> > 
> > blacklist;tpm;de-macro;*
> > 
> > blacklist;tpm;lilyglyphs;*
> > 
> > blacklist;tpm;pygmentex;*
> > 
> > blacklist;tpm;sympytexpackage;*
> > 
> > 
> > 
> > Update to Python3 version of the scripts is necessary.

So the workaround would be to either update the helper scripts to
Python 3 or to drop these scripts. Off the top of my head I don't know
how important these scripts actually are or how complex it would be to
update them.
They are used to create sets of new notation elements. IIRC.My personal
gut feeling would be to drop support for lilyglyphs altogether because
lyluatex can do everything lilyglyphs can, and better - i.e. without
the need for pre-compiled PDFs. But - and that's a big but - the
advantage of lilyglyphs is that it doesn't need to run LilyPond. *I*
will always have LilyPond around, but for a general audience this would
be a major limitation, I think.
Opinions?
Urs
> https://esmiltania.be
> On Twitter
> On Google+
> 

Re: Spacing of systems while using lyluatex

[Urs Liska]

Am Mittwoch, den 26.08.2020, 10:08 +0200 schrieb Claire Meyer:
> @ Fernando and Urs : Thanks for the additional explanations.
> 
> > What you didn't tell us is whether you include the systems by
> system or by pages.
> > In the latter case all the page layout  is done by LilyPond  while
> in the former
> > each system is cropped and included in the document as a paragraph.
> I... hadn't even thought that it could impact, that's my bad. I
> include system by system :\usepackage[nofragment,
> insert=systems]{lyluatex}So the staffsize is computed by lyluatex,
> right ?

No.The staffsize is *always* calculated by lyluatex if you don't set it
explicitly.
The difference is in the page layout.With insert=systems LilyPond
uses \include "lilypond-book-preamble.ly"which produces individual
systems without any notion of page layout. The resulting systems are
cropped and inserted in the text document one after another - which can
in certain situations lead to the systems being cramped too close
together (the opposite of your problem).
insert=fullpage OTOH lets LilyPond engrave the full score with all its
page layout decisions and includes the pages as fullpage PDFs.
> > 20 is the deafault for LilyPond. lyluatex calculates the default
> staffsize
> > in relation to the effective text fontsize if you don't set it
> explicitly.
> 
> So this explains that. The font size of the document at the location
> of the score is 10 pt. I've tried giving a look at the lyluatex
> package documentation to see what staffsize 10 pt in latex produces,
> but it doesn't say (I'm just curious on this one, but I can live
> without that knowledge). 

It doesn't say in the manual. IISC the default staffsize is calculated
here: 
https://github.com/jperon/lyluatex/blob/master/lyluatex.lua#L118-L120,
and I suspect the actual value has been determined by trial and error
to produce a good-looking default.Git blame points to me for this line,
but that wasn't the actual implementation but only some refactoring
regarding moving code to external libraries.
HTHUrs
> @Jacques :
> 
> > I use Linux too, and so any hint is welcome!
> 
> On linux :
> 1) I make sure I have the texlive-core package along with the
> texlive-music, texlive-latexextra and texlive-fontsextra packages
> installed (I'm not sure which ones are strictly necessary, but I have
> the room for it and the usage is bound to happen eventually, so)
> 2) I make sure I have the lyluatex-git package installed
> 3) as Samuel has said before, I also make sure I use LuaLaTex with
> the shell-escape option. Since I use texstudio, my exact command is
> lualatex --shell-escape % | txs:///view-pdf-internal --embedded,
> but  lualatex --shell-escape % is enough.
> 4) I have also to pay attention to the local, so I open texstudio
> from the terminal with LC_ALL=C texstudio, because my local is a
> clusterfuck, because I want the dates to be displayed the japanese
> way, my language to be english, and some regional settings according
> to my living situation, so if you have weird regional settings on
> your linux install, pay attention to that as well. 
> 
> If you have followed steps 1 to 3, you should be able to have a
> my_tex_document.tex that would look like :
> \documentclass[]{article}
> \usepackage[nofragment, insert=systems]{lyluatex}
> 
> \begin{document}
> 
> \lilypondfile[]{your_score.ly}
> 
> \end{document}
> 
> 
> And compile it using LC_ALL=C lualatex --shell-escape
> my_tex_document.tex via the terminal (in the correct directory). If
> that works (with correct namefile and a valid lilypond file), then
> you're good to go and your install is correct. I may have forgotten
> something (but obviously, if that's the case, I don't know what).
> 
> On Tue, Aug 25, 2020 at 10:33 PM Fr. Samuel Springuel <
> rpspring...@gmail.com> wrote:
> > > On 25 Aug, 2020, at 3:20 PM, Jacques Menu 
> > wrote:
> > 
> > > 
> > 
> > > Hello,
> > 
> > > 
> > 
> > > I’m using Mac TexLive 2020 with all updates.
> > 
> > > TeXShop proposes only Lilypond and Lilypond-LaTeX as reasonable-
> > looking engines.
> > 
> > > 
> > 
> > 
> > 
> > Neither of these are correct for use with lyluatex.
> > 
> > 
> > 
> > > 
> > 
> > > \documentclass[12pt,a4paper]{article}
> > 
> > > 
> > 
> > > \usepackage{lyluatex}
> > 
> > > 
> > 
> > > % -
> > 
> > 
> > > \begin{document}
> > 
> > > % -
> > 
> > 
> > >  
> > 
> > > \begin{lilypond} 
> > 
> > > \version "2.20.0"
> > 
> > > 
> > 
> > > music = \relative {
> > 
> > >   c d e
> > 
> > > }
> > 
> > > 
> > 
> > > \score {
> > 
> > >   \new ChoirStaff \with {
> > 
> > > instrumentName = "2 Fl."
> > 
> > >   } 
> > 
> > >   <<
> > 
> > >   \new Staff {
> > 
> > >   \transpose c c' \music 
> > 
> > >   }
> > 
> > >   \new Staff {
> > 
> > >   \clef 

Re: Spacing of systems while using lyluatex

[Urs Liska]

Am Dienstag, den 25.08.2020, 18:30 +0200 schrieb Claire Meyer:
> @Gilles Sadowski :
> Thanks, it works! Interestingly, though, I had to iterate down to 16,
> because 19, 18, 17 and 20 produce bigger outputs than default. They
> all produce 5 pages. And yet, 20 is the default. If anyone can
> explain, I'd be more than happy (I imagine it's an interaction with
> lyluatex).

20 is the deafault for LilyPond. lyluatex calculates the default
staffsize in relation to the effective text fontsize if you don't set
it explicitly.
> @Brian Barker :
> 
> Thank you for your input, and for confirming what a system is (so I
> won't be in doubt anymore).

What you didn't tell us is whether you include the systems by system or
by pages. In the latter case all the page layout  is done by LilyPond
 while in the former each system is cropped and included in the
document as a paragraph.
> @David Wright :
> 
> ragged-last-bottom = ##f only works for the last system of the score,
> not the last system of the page, so it doesn't do what I was looking
> for, but thank you very much.
> 
> 
> @Jacques Menu :
> 
> Sorry, I'm a linux user myself, so I have no idea how to make it work
> on mac.

Not related to OS, but the manual is pretty comprehensive, I'd say: 
http://mirrors.ctan.org/support/lyluatex/lyluatex.pdf or `texdoc
lyluatex` typically in a terminal.
HTHUrs
> On Tue, Aug 25, 2020 at 5:55 PM Jacques Menu 
> wrote:
> > Hello Claire,
> > 
> > 
> > 
> > Can’t help you, since I’ve never been able to use lyluatex.
> > 
> > 
> > 
> > Do you know of a tutorial about it’s use? I have Mac TexLive and
> > LilyPond 2.20 installed.
> > 
> > 
> > 
> > Thanks!
> > 
> > 
> > 
> > JM
> > 
> > 
> > 
> > > Le 25 août 2020 à 17:37, David Wright 
> > a écrit :
> > 
> > > 
> > 
> > > On Tue 25 Aug 2020 at 17:08:12 (+0200), Claire Meyer wrote:
> > 
> > >> 
> > 
> > >> Let me preface with the fact that I'm not sure that a system is
> > what I
> > 
> > >> think it is, for me, it's a "line" of all the staves of my
> > score.
> > 
> > >> I'm using lyluatex to embed my music within a latex file, and on
> > page 3,
> > 
> > >> the inter-system spacing seems off to me. Especially, I feel
> > like I could
> > 
> > >> fit four systems on that page, and I only fit three, while on
> > page 2
> > 
> > >> lyluatex fits four systems without problem. On one hand, the
> > systems have
> > 
> > >> roughly the same height, on the other hand, it might be that the
> > four
> > 
> > >> systems together are just too big of a teeny tiny bit.
> > 
> > >> 
> > 
> > >> [image: image.png]
> > 
> > >> 
> > 
> > >> If someone could confirm that I can do nothing about it, or on
> > the
> > 
> > >> contrary, how to make it fit the four systems, I'd be very
> > grateful :)
> > 
> > > 
> > 
> > > Would adding (or merging)
> > 
> > > 
> > 
> > > \paper {
> > 
> > >  ragged-last-bottom = ##f
> > 
> > > }
> > 
> > > 
> > 
> > > produce a satisfactory layout over four pages for you?
> > 
> > > 
> > 
> > > If you squeeze a fourth system onto page 3, you're left with
> > 
> > > two systems on page 4. To set the piece over three pages, you'd
> > 
> > > need to shrink the score to 11 systems, which is rather a lot.
> > 
> > > 
> > 
> > > Cheers,
> > 
> > > David.
> > 
> > > 
> > 
> > 
> > 

Re: Beam breaking

[Urs Liska]

Hi Andrew,

sorry that I was confused by your example (which actually was *not*
"minimal", with the excess information being actively misleading. The
keyword "breakable" in combination with the explicit beams made me
think you were after a broken beam, not also about the line break.)

OK: You can only break lines at barlines, which you took care of with
the Timing command.
But you can also only break lines at a musical event, not at some point
between. In the example you gave the first c'' would occur at some
point within the measure after the line break, which is of course
pretty ambiguous and which I assume LilyPond won't accept for that
reason.

You can get LilyPond to break by adding an event like this:

%%%

\version "2.21.3"
\paper {
  system-count = 2
}

{
  \time 7/8
  \set Timing.measureLength = #(ly:make-moment 1/4)
  \override Beam.breakable = ##t
  \tuplet 7/8 {
b'16 b' b' b'32 ~
\break
b'32
c''16 c'' c''
  } |
}

%%%

and fake the appearance with some trickery:

%%%

{
  \time 7/8
  \set Timing.measureLength = #(ly:make-moment 1/4)
  \override Beam.breakable = ##t
  \tuplet 7/8 {
b'16 b' b' b'16*1/2 ~
\break
s32
c''16 c'' c''
  } |
}

%%%

HTH
Urs

Am Sonntag, den 02.08.2020, 14:03 +1000 schrieb Andrew Bernard:
> Ah, is it to do with the tuplet not being breakable?
> 
> On Sun, 2 Aug 2020 at 14:00, Andrew Bernard  > wrote:
> > Sorry, but if you remove the explicit beam the same issue remains.
> > I
> > am stumped. I am unable to understand your comment about 'at note
> > heads. Surely the break can only occur between notes?
> > 
> > On Sun, 2 Aug 2020 at 13:37, Urs Liska 
> > wrote:
> > > Ah no, much simpler: If you ask LilyPond to print an explicit
> > > beam it
> > > will print an explicit beam ;-)
> > > 
> > > Am Sonntag, den 02.08.2020, 05:35 +0200 schrieb Urs Liska:
> > > > Am Sonntag, den 02.08.2020, 13:32 +1000 schrieb Andrew Bernard:
> > > > > \version "2.21.4"
> > > > > 
> > > > > 
> > > > > 
> > > > > {
> > > > > 
> > > > >   \time 7/8
> > > > > 
> > > > >   \set Timing.measureLength = #(ly:make-moment 1/4)
> > > > > 
> > > > >   \override Beam.breakable = ##t
> > > > > 
> > > > >   \tuplet 7/8 {
> > > > > 
> > > > > b'16[ b' b' b'
> > > > > 
> > > > > \break
> > > > > 
> > > > > c'' c'' c'']
> > > > > 
> > > > >   } |
> > > > > 
> > > > > }
> > > > 
> > > > I'm not sure, but I'd suppose that even "breakable" will only
> > > > let you
> > > > break beams *at* note heads and not as some point between two
> > > > notes.
> > > > 
> > > > Urs
> > > > 
> > > > 

Re: Beam breaking

[Urs Liska]

Ah no, much simpler: If you ask LilyPond to print an explicit beam it
will print an explicit beam ;-)

Am Sonntag, den 02.08.2020, 05:35 +0200 schrieb Urs Liska:
> Am Sonntag, den 02.08.2020, 13:32 +1000 schrieb Andrew Bernard:
> > \version "2.21.4"
> > 
> > 
> > 
> > {
> > 
> >   \time 7/8
> > 
> >   \set Timing.measureLength = #(ly:make-moment 1/4)
> > 
> >   \override Beam.breakable = ##t
> > 
> >   \tuplet 7/8 {
> > 
> > b'16[ b' b' b'
> > 
> > \break
> > 
> > c'' c'' c'']
> > 
> >   } |
> > 
> > }
> 
> I'm not sure, but I'd suppose that even "breakable" will only let you
> break beams *at* note heads and not as some point between two notes.
> 
> Urs
> 
> 

Re: Beam breaking

[Urs Liska]

Am Sonntag, den 02.08.2020, 13:32 +1000 schrieb Andrew Bernard:
> \version "2.21.4"
> 
> 
> 
> {
> 
>   \time 7/8
> 
>   \set Timing.measureLength = #(ly:make-moment 1/4)
> 
>   \override Beam.breakable = ##t
> 
>   \tuplet 7/8 {
> 
> b'16[ b' b' b'
> 
> \break
> 
> c'' c'' c'']
> 
>   } |
> 
> }

I'm not sure, but I'd suppose that even "breakable" will only let you
break beams *at* note heads and not as some point between two notes.

Urs

Re: Understanding scope of functions in Scheme modules

[Urs Liska]

I thought I had a good idea, but it got me into hot water, with no
border in sight yet...

I thought I could do the following:

 * Define-public my "internal" procedures in a module _my-module
 * Use that module in my-module

All the stuff defined in _my-module will be visible in my-module, and
all the stuff defined publicly in my-module will be seen in later
LilyPond files. If some later Scheme module needs access to it it can
use my-module.

While I have the impression this actually works I run into situations I
wouldn't have expected. Unfortunately I can't really provide an MWE for
it.

But could someone give me a hint how I can bring myself in a situation
to get
  Unbound variable: define-void-function
?
This is defined in music-functions.scm, and it should in any case have
been loaded before I ever issue an \include "oll-core/package.ily",
isn't it?

Probably the real issue is totally somewhere else, but I just have to
shoot in the dark here, hoping for some reflections ...

BestUrs

Am Samstag, den 25.07.2020, 10:28 +0200 schrieb Urs Liska:
> Hi,
> 
> I'm trying to clean up some code in openLilyLib, most of which had
> been
> added when I was just starting to understand the topics I had to deal
> with at any point ...
> 
> One thing I'm right now struggling with and that I'd like to get
> right
> this time is the scoping of code within Scheme modules.
> 
> My observation at this point seems to be:
> 
>  * I can define procedures or variables in a Scheme module
> equivalently
>with (define-public my-proc) or (define my-proc) (export my-proc)
>  * I can include such a module in a .ly file with (use-modules (my-
>module)) (if it's in the Guile path).
>  * my-proc will then be available for any later LilyPond code (i.e.
>also in other files that are later in that compilation's parsing)
>  * my-proc will *not* be available in other .scm files, in these I
>would have to explicitly include my-module with use-modules.
> 
> Is this correct so far?
> If so is there a way to make names from modules only available within
> the LilyPond file that uses the module?
> 
> I would like to have more encapsulation, so that the helper functions
> needed for the implementation are only visible where needed to have
> less clutter in the global namespace, like in many other languages
> where you have to explicitly import modules you want to use within
> each
> file.
> 
> I think it will already be progress just to have the code *organized*
> like that, the camelCase-d user-facing LilyPond functions in the .ily
> file and the Scheme-define-d helper code in a separate .scm file. But
> if there were a way for real scoping it would be better.
> 
> Any suggestions available?
> 
> Thanks
> Urs
> 
> 

Understanding scope of functions in Scheme modules

[Urs Liska]

Hi,

I'm trying to clean up some code in openLilyLib, most of which had been
added when I was just starting to understand the topics I had to deal
with at any point ...

One thing I'm right now struggling with and that I'd like to get right
this time is the scoping of code within Scheme modules.

My observation at this point seems to be:

 * I can define procedures or variables in a Scheme module equivalently
   with (define-public my-proc) or (define my-proc) (export my-proc)
 * I can include such a module in a .ly file with (use-modules (my-
   module)) (if it's in the Guile path).
 * my-proc will then be available for any later LilyPond code (i.e.
   also in other files that are later in that compilation's parsing)
 * my-proc will *not* be available in other .scm files, in these I
   would have to explicitly include my-module with use-modules.

Is this correct so far?
If so is there a way to make names from modules only available within
the LilyPond file that uses the module?

I would like to have more encapsulation, so that the helper functions
needed for the implementation are only visible where needed to have
less clutter in the global namespace, like in many other languages
where you have to explicitly import modules you want to use within each
file.

I think it will already be progress just to have the code *organized*
like that, the camelCase-d user-facing LilyPond functions in the .ily
file and the Scheme-define-d helper code in a separate .scm file. But
if there were a way for real scoping it would be better.

Any suggestions available?

Thanks
Urs

Re: Is it possible to import scores generated by Lilypond to other softwares?

[Urs Liska]

Am Donnerstag, den 23.07.2020, 15:33 +0200 schrieb Martín Rincón
Botero:
> "Frescobaldi can export a MusicXML version of your score. Many music
> programs can import 
> that format".
> 
> 
> I had no idea this was possible!

This is considered experimental, and therefore you have to activate
"experimental features" in Frescobaldi's Preferences dialog.Be warned
that this is considered experimental for a reason, though.
Urs
> El El jue, 23 jul 2020 a las 15:05,  escribió:
> > On 23 Jul 2020 at 14:27, Parviz Farnia wrote:
> > 
> > 
> > 
> > > 
> > 
> > > Hello,
> > 
> > > 
> > 
> > > Recently, I've started learning Lilypond (I'm completely a newbie
> > in this field). I'm impressed by the 
> > 
> > > excellent quality of the scores one can produce via Lilypond. I
> > was wondering whether it is 
> > 
> > > possible to import scores generated by Lilypond to professional
> > softwares allowing to play music. 
> > 
> > 
> > 
> > Frescobaldi can export a MusicXML version of your score. Many music
> > programs can import 
> > 
> > that format.
> > 
> > 
> > 

Re: Springs and rods

[Urs Liska]

Hi Andrew,

thanks for raising this question I have always been too afraid to ask
;-)

Urs

Am Donnerstag, den 23.07.2020, 19:15 +1000 schrieb Andrew Bernard:
> There are some things in lilypond that I just think are not explained
> anywhere. What is this springs-and-rods business? For Hairpins, I
> read
> this?
> 
> minimum-length (dimension, in staff space):
> 2.0
> 
> Try to make a spanner at least this long, normally in the horizontal
> direction. This requires an appropriate callback for the
> springs-and-rods property. If added to a Tie, this sets the minimum
> distance between noteheads.
> 
> And:
> springs-and-rods (boolean):
> ly:spanner::set-spacing-rods
> 
> Dummy variable for triggering spacing routines.
> 
> 
> With all due respect to our fantastic developers, I find this
> unintelligible and less than helpful. What is springs-and-rods
> supposed to be set to: ly:spanner::set-spacing-rods, or ##t, or ##f
> and when, and why? What exactly is meant by 'dummy' in this context?
> I use that word to mean a temporary placeholder, but there are many
> usages. WHat is 'an appropriate callback'? No example is provided.
> 
> If I had any idea at all about this I would write a small section in
> the NR on it and submit it, but I am stumped. if this _is_ in the NR,
> please let me know.
> 
> 
> Andrew
> 

openLilyLib documentation

[Urs Liska]

Hi all,

recently I found out that in February I had already given a substantial
shot at an openLilyLib website. I just stopped because I was looking
for something better that could conveniently create HTML and PDF pages.

Right now, while working on a new area of the main code base, I decided
to move forward in that direction, and now you have the first shell of
openLilyLib documentation neatly available at https://openlilylib.org. 
I hope this will give many a good first idea about what this obscure
framework is and what it can be used for.

Note: the website is prepared for holding subpages for all the
packages, and of *that* nothing has been added yet, not even for oll-
core, which is arguably essential for a deeper understanding of
openLilyLib as a whole.

Nevertheless I hope this is a useful resource and convinces a number of
people of diving into it.

Best
Urs

PS: If you want to try anything out you should checkout the branch
'properties` because that's what I'm currently working on.

Re: 2.21 and OLL

[Urs Liska]

Am Donnerstag, den 16.07.2020, 22:50 +0200 schrieb Simon Albrecht:
> Hi Urs et al.,
> 
> On 15.07.20 08:15, Urs Liska wrote:
> > MWE please, and the error message.
> 
> This one is very minimal :-)
> 

Indeed.

>  \version "2.21.0" \include "oll-core/package.ily" 
> 
> 
> =>
> 
> Starting lilypond 2.21.0 [Untitled]... Processing 
> `/tmp/frescobaldi-ux6dspgj/tmpa64z83u_/document.ly' Parsing... 
> /home/simon/openlilylib/oll-core/package.ily:57:2: error: GUILE
> signaled 
> an error for the expression beginning here # (if (not (defined? 
> 'openlilylib-root)) Value out of range 0 to 18446744073709551615: -1 
> fatal error: failed files: 
> "/tmp/frescobaldi-ux6dspgj/tmpa64z83u_/document.ly" Exited with
> return 
> code 1.
> 
> Best, Simon
> 

I could not reproduce this with 2.21.3, which I just downloaded. Could
you please try that too? If it's something that was present from 2.21.0
to 2.21.2 but not now anymore I wouldn't bother investigating more
closely.

BestUrs

Re: Two optional arguments

[Urs Liska]

Am Mittwoch, den 15.07.2020, 13:08 +0200 schrieb David Kastrup:
> Urs Liska  writes:
> 
> > Am Dienstag, den 14.07.2020, 22:57 +0200 schrieb David Kastrup:
> > > That is an incorrect description.  This only happens when you
> > > comment
> > > out only the first value.  When you comment out both optional
> > > values,
> > > the first value that is seen is "bar" which is a valid value for
> > > a
> > > symbol.  If you instead write #"bar" instead, this can only
> > > become a
> > > string argument and not a symbol and consequently both optional
> > > arguments are replaced by their default.
> > 
> > This is something I didn't know and which I find surprising. I
> > would
> > really expect using quotation marks indicates something is a
> > string.
> 
> Quotation marks form words (and symbols from there as needed)
> independent of other syntactic considerations.
> 
> Something like
> 
> "\\(" = #(make-span-event 'PhrasingSlurEvent START)
> 
> in ly/declarations-init.ly defines a symbol consisting of the letters
> \
> and ( .  As opposed to symbols that happen to meet LilyPond word
> syntax,
> you cannot sensible do so without quote marks.  You can invoke that
> symbol as
> 
> \"\\("
> 
> if you want to.

OK. Totally clear once you're aware of it.

> 
> > I find it practical that a value without quotes can be parsed as
> > string or symbol if the parser knows the expectations, but
> > explicitly
> > adding the quotes would seem like an explicit statement.
> 
> It is.  It is a statement about lexical word boundaries.  Scheme and
> LilyPond have different conventions here.  Using quote marks, you can
> mostly punch through in case of need.
> 
> > But I assume much thought has gone into these considerations, so I
> > won't question it.
> 
> Criticising but not questioning it has connotations of
> passive-aggressiveness.

Let me rephrase my sentence, in case this is a serious comment (I tend
to sometimes forget that sometimes you have to be really exact on this
list): "I withdraw any explicit or implicit criticism of LilyPond's
current parser behaviour with regard to optional arguments because I
assume much thought has gone into these considerations, which I don't
question."

Urs

Re: 2.21.3 and Frescobaldi and documentation

[Urs Liska]

Am 15. Juli 2020 22:01:12 MESZ schrieb Wilbert Berendsen :
>Op Wed, 15 Jul 2020 08:12:05 +0200
>Urs Liska  schreef:
>
>> >[Is there an active Frescobaldi forum any more?]  
>> 
>> Not really. Thst would be lilypond-user, I guess.
>
>There is a mailing list at
>http://groups.google.com/group/frescobaldi

I think the question was about *active* forum ;-)



>
>Best!
>Wilbert

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Re: Two optional arguments

[Urs Liska]

Hi Aaron,

Am Mittwoch, den 15.07.2020, 07:09 -0700 schrieb Aaron Hill:
> On 2020-07-15 3:07 am, Urs Liska wrote:
> > It would be nice if the user could write each of these (all in the
> > context of my other discussion about
> > presets/configuration/subsets):
> > 
> > \myFramec'
> > \myFrame analogyc'
> > \myFrame \with { color = #red } c'
> > \myFrame analogy \with { color = #red } c'
> > 
> > It seems I would have to put a mandatory argument between the
> > symbol
> > and the \with block here, which seems like a bad interface.
> > 
> > The solution I'll probably have to take is pulling the symbol
> > inside
> > the \with block:
> > 
> > \myFrame \with {
> >   configuration = analogy
> >   color = #red
> > }
> > 
> > This forces the user to write a \with block when all they want is
> > to
> > load a configuration. But that's not a *bad* interface, only
> > inconvenient, so clearly the lesser evil.
> 
> What about using a compound type predicate with alteration?

Thank you, this was a terrific idea which seems to get me over the goal
line.

> 
> 
> \version "2.20.0"
> 
> asdf =
> #(begin
>(define (context-mod-assign-alist context-mod)
>  (map
>(lambda (mod) (cons (cadr mod) (caddr mod)))
>(filter
>  (lambda (mod) (eq? 'assign (car mod)))
>  (ly:get-context-mods context-mod
> 
>(define (symbol-or-context-mod? arg)
>  (or (symbol? arg)
>  (ly:context-mod? arg)))
> 
>(define-scheme-function
>  (opt-arg mus-arg)
>  ((symbol-or-context-mod? #{ \with {} #})
>   ly:music?)
> 
>  (if (symbol? opt-arg)
>(set! opt-arg
>  #{ \with { symbol = $opt-arg } #}))
>  #{
>\markup \column {
>  \line { \bold \typewriter "\asdf" invoked: }
>  $@(map
>(lambda (elem) #{ \markup {
>  with \bold #(symbol->string (car elem)) =
>  \typewriter #(format #f "~s" (cdr elem)) } #})
>(context-mod-assign-alist opt-arg))
>  \line { \score { #mus-arg } }
>}
>  #}))
> 
> hline =
> \markup \column {
>\vspace #0.5
>\override #'(span-factor . 1/4) \draw-hline
>\vspace #0.5
> }
> 
> \asdf  g' \hline
> \asdf  foo g' \hline
> \asdf \with {  baz = 2/3 } g' \hline
> \asdf \with { symbol = foo baz = 2/3 } g'
> 
> 

The actual implementation will be totally different, given what I
already have and that all this happens inside a macro, but I could
translate the idea without problems.

> 
> While not exactly your original syntax, this does permit a user to 
> shorthand "\with { symbol = foo }" as simply "foo" providing they do
> not 
> need to use the \with block.

Yes, this is not my original syntax, but that doesn't matter.
My wish was to spare the user to write a \with block for just that
symbol. But when the user has to write that anyway it's no hassle to
provide that symbol as a regular property within the \with block.

So this solution allows me to work around the fact that I can't use the
two optional arguments.

Best
Urs

> 
> 
> -- Aaron Hill

Re: Naming RFC: Properties, property sets, presets

[Urs Liska]

Am Montag, den 13.07.2020, 11:05 +0100 schrieb Wols Lists:
> > However, I agree that it would be unfortunate to have "set" in such
> > different meanings in "property set" and "preset".
> 
> Except I'm a native speaker. To use the word "preset" in this context
> 
> jars *horribly*. The implicit assumptions built into the mind of a
> 
> native speaker will make this a lilypond "special case" use of
> language
> 
> and while non-native speakers will simply learn it, native speakers
> will
> 
> have great difficulty unlearning the normal meaning of the word.
> 
> 


Out of curiousity: How do you feel about the use of "preset" in
synthesizers, radios or audio processors like equalizers or effects (to
name just a few I know of)?

Urs

> 
> Cheers,
> 
> Wol

Re: Two optional arguments

[Urs Liska]

Am Dienstag, den 14.07.2020, 22:57 +0200 schrieb David Kastrup:
> Urs Liska  writes:
> 
> > Hi all,
> > 
> > is it correct that you can't write a music function with two
> > optional
> > arguments in a row?
> 
> No, it isn't correct.  But you know yourself, quoting the respective
> passages from the manual.

OK, is that wording better? You can't write a music function with two
optional arguments in a row and expect the argument to behave
independently as optional arguments, regardless of which argument(s)
are left out in a call.

> 
> > If so:
> > 
> > * is that on purpose?
> 
> Yes.
> 
> > * is that inevitable?
> 
> I don't know what you call "inevitable".

With that I mean what you explain below starting with "That would be a
complete nightmare" - which amounts to a "yes" to my question.

> 
> > * is there a workaround for my use case (below)?
> > 
> > Consider this function
> > 
> > twoOpts =
> > #(define-void-function (one two three)((symbol? 'foo) (number? 5)
> > string?)
> >(ly:message "one: ~a
> > two: ~a
> > three: ~a" one two three))
> > 
> > and this call
> > 
> > \twoOpts
> > hey 
> > 4
> > "bar"
> > 
> > This works correctly, and when I comment out the 4 it properly
> > picks
> > the default value 5.
> > However, when I comment out both or only the first value it fails
> > with
> > 
> > error: wrong type for argument 3.  Expecting string, found 4
> 
> That is an incorrect description.  This only happens when you comment
> out only the first value.  When you comment out both optional values,
> the first value that is seen is "bar" which is a valid value for a
> symbol.  If you instead write #"bar" instead, this can only become a
> string argument and not a symbol and consequently both optional
> arguments are replaced by their default.

This is something I didn't know and which I find surprising. I would
really expect using quotation marks indicates something is a string. I
find it practical that a value without quotes can be parsed as string
or symbol if the parser knows the expectations, but explicitly adding
the quotes would seem like an explicit statement.
But I assume much thought has gone into these considerations, so I
won't question it.

> 
> > This behavious is consistent with the extending manual 
> > http://lilypond.org/doc/v2.21/Documentation/extending/index_7#Scheme-functions
> > 
> > "Once an optional argument predicate does not match an argument,
> > LilyPond skips this and all following optional arguments, replacing
> > them with their specified default, and ‘backs up’ the argument that
> > did
> > not match to the place of the next mandatory argument. Since the
> > backed
> > up argument needs to go somewhere, optional arguments are not
> > actually
> > considered optional unless followed by a mandatory argument."
> > 
> > So in 
> > 
> > \twoOpts
> > %hey 
> > 4
> > "bar"
> > 
> > The 4 doesn't match the first symbol? predicate, so all optional
> > arguments receive their defaults and the 4 is "backed-up" to the
> > next
> > mandatory argument which happens to be a string? that now fails.
> 
> Yes.
> 
> > It does work (also consistent with the docs) when each optional
> > argument is followed by its "own" backup mandatory argument.
> > 
> > So far, so bad. What I don't understand is why in case of a missing
> > optional argument (detected by a failed type check) LilyPond has to
> > skip "this and all following optional arguments". Couldn't LilyPond
> > just skip "this" and back up the failed argument to the next
> > (mandatory
> > *or* optional) argument to cascade through all available arguments.
> 
> That would be a complete nightmare because LilyPond's large number of
> default conversions (which you already got hit with when writing
> \twoOpts "bar" which then interprets "bar" as a symbol) would very
> likely make _some_ match in an unexpected place.  

Indeed, *this* is what makes the issue clear for me. You can jump from
predicate to predicate if each test is unambiguous, but if a value
might match different predicates it's of course impossible to have a
completely generic parsing system.

> By only checking
> against a single optional argument, when things blow up around your
> ears, it at least happens in a somewhat predictable place.
> 
> > In the call
> > 
> > \twoOpts 4 "bar"
> > 
&

Re: 2.21 and OLL

[Urs Liska]

Am 15. Juli 2020 01:36:48 MESZ schrieb Simon Albrecht :
>Hello everybody,
>
>apologies if the question is redundant—I haven’t been able to follow
>the 
>lists recently.
>
>With 2.21.0, I have GUILE throwing an error message for 
>oll-core/package.ily:57 that doesn’t appear with 2.19.84.
>
>Is that a known problem? 

No.

>Should I try isolating it?

Yes.
MWE please, and the error message.

>
>Best, Simon

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Re: 2.21.3 and Frescobaldi and documentation

[Urs Liska]

Am 15. Juli 2020 07:34:52 MESZ schrieb Andrew Bernard 
:
>With the new 2.21.3 release, I unpacked the documentation in the
>normal place. Here:
>
>/home/acb/lilypond/usr/share/doc/lilypond
>
>Where /home/acb is my home directory.
>
>Now Frescobaldi says 'Your file was not found'. Has something changed?
>This worked fine up to an including 2.21.2.
>

I would retry once the LilyPond website issues have been sorted out.

>Andrew
>
>[Is there an active Frescobaldi forum any more?]

Not really. Thst would be lilypond-user, I guess.

Urs

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Two optional arguments

[Urs Liska]

Hi all,

is it correct that you can't write a music function with two optional
arguments in a row? If so:

* is that on purpose?
* is that inevitable?
* is there a workaround for my use case (below)?

Consider this function

twoOpts =
#(define-void-function (one two three)((symbol? 'foo) (number? 5)
string?)
   (ly:message "one: ~a
two: ~a
three: ~a" one two three))

and this call

\twoOpts
hey 
4
"bar"

This works correctly, and when I comment out the 4 it properly picks
the default value 5.
However, when I comment out both or only the first value it fails with

error: wrong type for argument 3.  Expecting string, found 4


This behavious is consistent with the extending manual 
http://lilypond.org/doc/v2.21/Documentation/extending/index_7#Scheme-functions

"Once an optional argument predicate does not match an argument,
LilyPond skips this and all following optional arguments, replacing
them with their specified default, and ‘backs up’ the argument that did
not match to the place of the next mandatory argument. Since the backed
up argument needs to go somewhere, optional arguments are not actually
considered optional unless followed by a mandatory argument."

So in 

\twoOpts
%hey 
4
"bar"

The 4 doesn't match the first symbol? predicate, so all optional
arguments receive their defaults and the 4 is "backed-up" to the next
mandatory argument which happens to be a string? that now fails.

It does work (also consistent with the docs) when each optional
argument is followed by its "own" backup mandatory argument.

So far, so bad. What I don't understand is why in case of a missing
optional argument (detected by a failed type check) LilyPond has to
skip "this and all following optional arguments". Couldn't LilyPond
just skip "this" and back up the failed argument to the next (mandatory
*or* optional) argument to cascade through all available arguments.

In the call

\twoOpts 4 "bar"

 * 4 wouldn't match symbol?
 * so one would get the default value 'foo
 * then the 4 is checked against the next predicate, which works
 * so two gets the 4
 * finally three gets "bar"

In the call

\twoOpts "bar"

 * "bar" wouldn't match symbol?
 * so one gets the default 'foo
 * "bar" is then checked against the next predicate, which fails too
 * so two gets the default 5
 * finally "bar" matches the mandatory argument's predicate

I totally understand that it is absolutely necessary to have an
unambiguous order of predicates when optional arguments are involved,
but couldn't it be possible to have multiple optional ones following
after another.

I would really like to write a function with a symbol? and a
ly:context-mod? argument and have both of them optional.

Is there any possible workaround currently?
Would this be a legitimate feature request?
Is there anything I've overlooked that makes this impossible?

ThanksUrs

Re: Naming RFC: Properties, property sets, presets

[Urs Liska]

Hi Elaine,

Am Montag, den 13.07.2020, 15:31 -0700 schrieb Flaming Hakama by
Elaine:
> 
> Yes, I did understand it to be more complex than my MWE.
> 
> But the two things I wanted to validate are that
> 
> * The preset is something you pass as part of a function invocation
>  \myFunction \with  { preset = style-two }
> 
> * The preset resolves to a set of property/value pairs.

Yes, it does.

> 
> Yes, I can see that since the property set has defaults, using
> "default" here would be inappropriate.  Also, since they are only
> used in the context of a call to \myFunction, they are not really
> acting like defaults.
> 
> I'm not sure how much this concept is tied to appearance, but a set
> of styling properties is generally called a style sheet, like in CSS.
> 
> In fact, the "default"-like character of this is really more similar
> to cascading style sheets.

The inheritance model is in fact borrowed from CSS.
But while probably 90% of usage will be about appearance the concept
itself is completely not tied to that, so I really don't want to imply
anything like that in the naming. Although I was pleasantly surprised
about "theme".

Property sets might as well define which statistical data from a
compilation to log, or how to construct output names, whether to
include git status info in the file's metadata or filename, whether to
base your composing algorithm on the weather forecast or stock market
data - or actually anything you like.

Therefore I won't follow your suggestion here. Right now I'm pondering
property subsets and property configurations.

BestUrs

> 
> 
> So, 
> 
> \definePropertySet my-function.appearance
> #`((thickness ,number? 1)
>(color ,color? ,red)
>(label ,markup? "")
>(extra-width ,number-pair? (0 . 0))
>(Y-position ,integer? 0))
> 
> myFunction =
> #(with-property-set define-music-function (mus)(ly:music?)
>   '(my-function appearance)
>   #{
> \once \override NoteHead.color = #(property 'color)
> #mus
>   #})
> 
> \defineStylesheet \with {
> parent = default
> color = #magenta
> } my-function.appearance style-two
> {
> \myFunction \with { 
> stylesheet = style-two 
> } c'
> }
> 
> If you wanted to reserve "stylesheet" for something more complete,
> another other word in use for interchangeable style configurations is
> "theme"
> 
> 
> \defineTheme \with {
> parent = default
> color = #magenta
> } my-function.appearance style-two
> {
> \myFunction \with { 
> theme = style-two 
> } c'
> }
> 
> 
> HTH,
> 
> Elaine Alt
> 415 . 341 .4954   "Confusion
> is highly underrated"
> ela...@flaminghakama.com
> Producer ~ Composer ~ Instrumentalist ~ Educator
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> =-=-=-=-=-=-=-=-=-=-=-=-=- 

Re: Naming RFC: Properties, property sets, presets

[Urs Liska]

Am Montag, den 13.07.2020, 19:02 +1000 schrieb Andrew Bernard:
> Property subset is good.
> 

In a way, yes, namely by keeping within the semantic domain.
However, while a property set actually defines the available properties
(along with predicates and default values) the "preset" is concerned
with *values* for a subset of the property set.

After some thinking I disagree with the notion that preset is wrong in
itself. The thing I'm referring to isn't a wrongly-worded mathematical
set but a set of values to preset (in the ordinary English meaning of
setting in advance) a subset of available properties.

However, I agree that it would be unfortunate to have "set" in such
different meanings in "property set" and "preset".

> I also thought of 'selection' - a set of items selected from a larger
> group.

This has the same issue as the "property subset". What I implemented as
\definePreset is not concerned with defining the subset as a set but
with setting values to specific properties.

Urs

> 
> Andrew
> 

Re: Naming RFC: Properties, property sets, presets

[Urs Liska]

Am Montag, den 13.07.2020, 16:47 +1000 schrieb Andrew Bernard:
> No to flavor - US spelling! Color is bad enough. Heigh ho and a tra
> la 
> la. :-)
> 

LOL.

> I don't think the particle analogy holds either.

I don't think this analogy is needed. The colloquial meaning of
different flavo(u)rs of, say, milk shakes, frames, or harmonic function
symbols seems quite natural to me.

Best
Urs

> 
> cheerio!
> 
> Andrew
> 
> 
> 

Re: Naming RFC: Properties, property sets, presets

[Urs Liska]

Am Sonntag, den 12.07.2020, 23:18 -0700 schrieb Flaming Hakama by
Elaine:
> > -- Forwarded message --
> > From: Urs Liska 
> > To: "lilypond-user@gnu.org" 
> > Date: Sun, 12 Jul 2020 15:38:03 +0200
> > Subject: Naming RFC: Properties, property sets, presets
> > Hi all,
> > 
> > 
> > 
> > I'm writing some documentation for the new openLilyLib feature set
> > of
> > 
> > properties, and I think this is the (last) moment to clarify some
> > of
> > 
> > the naming.
> > 
> > 
> > 
> > I have implemented the concept of a set of properties, which is a
> > place
> > 
> > to store typed variables. I'm pretty confident that the terms
> > 
> > "property" and "property set" are appropriate. To demonstrate:
> > 
> > 
> > 
> > \definePropertySet my-function.appearance
> > 
> > #`((thickness ,number? 1)
> > 
> >(color ,color? ,red)
> > 
> >(label ,markup? "")
> > 
> >(extra-width ,number-pair? (0 . 0))
> > 
> >(Y-position ,integer? 0))
> > 
> > 
> > 
> > This defines the set of properties applicable for my-function,
> > along
> > 
> > with type predicates and default values.
> > 
> > 
> > 
> > Property values can (if necessary) be retrieved with
> > 
> >   \getProperty my-function.appearance.label
> > 
> > and changed with
> > 
> >   \setProperty my-function.appearance.color #green
> > 
> >   \setProperty my-function.appearance.color "blue" % fails type
> > check
> > 
> > 
> > 
> > The actual use of properties is from within functions:
> > 
> > 
> > 
> > myFunction =
> > 
> > #(with-property-set define-music-function (mus)(ly:music?)
> > 
> >   '(my-function appearance)
> > 
> >   #{
> > 
> > \once \override NoteHead.color = #(property 'color)
> > 
> > #mus
> > 
> >   #})
> > 
> > 
> > 
> > Within a function created with the with-property-set macro a
> > function
> > 
> > (property ) is available to produce the current value of the
> > 
> > property (which can be the currently set global value or a value
> > passed
> > 
> > in the function
> > 
> > 
> > 
> > {
> > 
> >   \myFunction c' % => (property 'color) => red
> > 
> >   \setProperty my-function.appearance.color #blue
> > 
> >   \myFunction c' % => (property 'color) => blue
> > 
> >   \myFunction \with { color = #green } c' % => (property 'color) =>
> > 
> > #green
> > 
> > }
> > 
> > 
> > 
> > ###
> > 
> > 
> > 
> > So far I'm pretty sure property and property set is the right
> > naming.
> > 
> > However, there's one more step, and here I have been suggested to
> > 
> > reconsider the naming.
> > 
> > 
> > 
> > Properties can not only be changed globally or per instance but
> > also
> > 
> > through something I so far call "presets". Alternative suggestions
> > for
> > 
> > that concept were "contexts" or "environment", but I'm really not
> > 
> > convinced about them. So I'm looking for either common support for
> > 
> > either name or a better suggestion.
> > 
> > 
> > 
> > A "preset" is a subset of a property set with individual property
> > 
> > values. When invoking the function a preset can be requested while
> > 
> > properties not included in the preset are left unchanged. Presets
> > can
> > 
> > inherit to create cascading structures.
> > 
> > 
> > 
> > \definePreset \with {
> > 
> >   thickness = 3
> > 
> >   Y-position = 2
> > 
> > } my-function.appearance default
> > 
> > 
> > 
> > \definePreset \with {
> > 
> >   parent = default
> > 
> >   color = #green
> > 
> > } my-function.appearance style-one
> > 
> > 
> > 
> > \definePreset \with {
> > 
> >   parent = default
> > 
> >   color = #magenta
> > 
> > } my-function.appearance style-two
> > 
> > 
> > 
> > Using it the properties included in the preset are used while
> > others
> > 
> > keep the current global value. Additionally arbitrary properties
> > can be
> &g

Re: Naming RFC: Properties, property sets, presets

[Urs Liska]

reaks down because we have a style property for lines and
> noteheads.  And this seems like a little bit too narrow a concept to
> use the word "stylesheet".

Indeed. Anything relating to "style" is too narrowly hinting at visual
appearance, which is not necessarily the case.

> Running through a thesaurus, I came across the word "trait".  
> I'm not sure I like it yet, but I think it's better than "style" or
> "override".  And probably better than "preset" .  But I'm not opposed
> to using "preset" if nothing else is proposed that jumps out at you.

I'll have to ponder over that a bit. It's just too unfamiliar (at least
for me). But OTOH that ensures it won't conflict with anything we
already have.

> "quality" is also a possibility.

I don't particularly like that - it's too general and doesn't hint in
the right direction. 

> With a nod to particle physics, we might want to consider the word
> "flavor", which is used to distinguish particles such as quarks as a
> collection of properties.  

That might be nice. I can imagine having different "flavors" of a
frame, for example.


Thanks again for all the input. I won't have time to actually *do*
anything about it today and tomorrow, so I'll let it sink in or digest
any additional suggestions that may come in.
My favourites so far are "configuration" and "flavor".

BestUrs


Am Sonntag, den 12.07.2020, 15:38 +0200 schrieb Urs Liska:
> Hi all,
> 
> I'm writing some documentation for the new openLilyLib feature set of
> properties, and I think this is the (last) moment to clarify some of
> the naming.
> 
> I have implemented the concept of a set of properties, which is a
> place
> to store typed variables. I'm pretty confident that the terms
> "property" and "property set" are appropriate. To demonstrate:
> 
> \definePropertySet my-function.appearance
> #`((thickness ,number? 1)
>(color ,color? ,red)
>(label ,markup? "")
>(extra-width ,number-pair? (0 . 0))
>(Y-position ,integer? 0))
> 
> This defines the set of properties applicable for my-function, along
> with type predicates and default values.
> 
> Property values can (if necessary) be retrieved with
>   \getProperty my-function.appearance.label
> and changed with
>   \setProperty my-function.appearance.color #green
>   \setProperty my-function.appearance.color "blue" % fails type check
> 
> The actual use of properties is from within functions:
> 
> myFunction =
> #(with-property-set define-music-function (mus)(ly:music?)
>   '(my-function appearance)
>   #{
> \once \override NoteHead.color = #(property 'color)
> #mus
>   #})
> 
> Within a function created with the with-property-set macro a function
> (property ) is available to produce the current value of the
> property (which can be the currently set global value or a value
> passed
> in the function
> 
> {
>   \myFunction c' % => (property 'color) => red
>   \setProperty my-function.appearance.color #blue
>   \myFunction c' % => (property 'color) => blue
>   \myFunction \with { color = #green } c' % => (property 'color) =>
> #green
> }
> 
> ###
> 
> So far I'm pretty sure property and property set is the right naming.
> However, there's one more step, and here I have been suggested to
> reconsider the naming.
> 
> Properties can not only be changed globally or per instance but also
> through something I so far call "presets". Alternative suggestions
> for
> that concept were "contexts" or "environment", but I'm really not
> convinced about them. So I'm looking for either common support for
> either name or a better suggestion.
> 
> A "preset" is a subset of a property set with individual property
> values. When invoking the function a preset can be requested while
> properties not included in the preset are left unchanged. Presets can
> inherit to create cascading structures.
> 
> \definePreset \with {
>   thickness = 3
>   Y-position = 2
> } my-function.appearance default
> 
> \definePreset \with {
>   parent = default
>   color = #green
> } my-function.appearance style-one
> 
> \definePreset \with {
>   parent = default
>   color = #magenta
> } my-function.appearance style-two
> 
> Using it the properties included in the preset are used while others
> keep the current global value. Additionally arbitrary properties can
> be
> overridden locally:
> 
> {
>   \myFunction \with {
> preset = style-two
> label = "Foo"
> thickness = 2 % properties from presets can be overridden too
>   } c'
> }
> 
> ###
> 
> So, to cut a long story short: What do you think this "is", i.e this
> should be named: presets, contexts, environments, something else? If
> you should think about styles, this has been discussed before, but a
> property set isn't necessarily limited to matters of appearance, it
> could configure arbitrary things, e.g. export target, lyrics
> language,
> composition algorithm parameters, anything.
> 
> Actually I'd prefer one of two answers: A confirmation that I'm good
> to
> go with "preset", or a better suggestion that is so striking that I
> can
> immediately go with it.
> 
> Thanks
> Urs
> 
> 

Naming RFC: Properties, property sets, presets

[Urs Liska]

Hi all,

I'm writing some documentation for the new openLilyLib feature set of
properties, and I think this is the (last) moment to clarify some of
the naming.

I have implemented the concept of a set of properties, which is a place
to store typed variables. I'm pretty confident that the terms
"property" and "property set" are appropriate. To demonstrate:

\definePropertySet my-function.appearance
#`((thickness ,number? 1)
   (color ,color? ,red)
   (label ,markup? "")
   (extra-width ,number-pair? (0 . 0))
   (Y-position ,integer? 0))

This defines the set of properties applicable for my-function, along
with type predicates and default values.

Property values can (if necessary) be retrieved with
  \getProperty my-function.appearance.label
and changed with
  \setProperty my-function.appearance.color #green
  \setProperty my-function.appearance.color "blue" % fails type check

The actual use of properties is from within functions:

myFunction =
#(with-property-set define-music-function (mus)(ly:music?)
  '(my-function appearance)
  #{
\once \override NoteHead.color = #(property 'color)
#mus
  #})

Within a function created with the with-property-set macro a function
(property ) is available to produce the current value of the
property (which can be the currently set global value or a value passed
in the function

{
  \myFunction c' % => (property 'color) => red
  \setProperty my-function.appearance.color #blue
  \myFunction c' % => (property 'color) => blue
  \myFunction \with { color = #green } c' % => (property 'color) =>
#green
}

###

So far I'm pretty sure property and property set is the right naming.
However, there's one more step, and here I have been suggested to
reconsider the naming.

Properties can not only be changed globally or per instance but also
through something I so far call "presets". Alternative suggestions for
that concept were "contexts" or "environment", but I'm really not
convinced about them. So I'm looking for either common support for
either name or a better suggestion.

A "preset" is a subset of a property set with individual property
values. When invoking the function a preset can be requested while
properties not included in the preset are left unchanged. Presets can
inherit to create cascading structures.

\definePreset \with {
  thickness = 3
  Y-position = 2
} my-function.appearance default

\definePreset \with {
  parent = default
  color = #green
} my-function.appearance style-one

\definePreset \with {
  parent = default
  color = #magenta
} my-function.appearance style-two

Using it the properties included in the preset are used while others
keep the current global value. Additionally arbitrary properties can be
overridden locally:

{
  \myFunction \with {
preset = style-two
label = "Foo"
thickness = 2 % properties from presets can be overridden too
  } c'
}

###

So, to cut a long story short: What do you think this "is", i.e this
should be named: presets, contexts, environments, something else? If
you should think about styles, this has been discussed before, but a
property set isn't necessarily limited to matters of appearance, it
could configure arbitrary things, e.g. export target, lyrics language,
composition algorithm parameters, anything.

Actually I'd prefer one of two answers: A confirmation that I'm good to
go with "preset", or a better suggestion that is so striking that I can
immediately go with it.

Thanks
Urs

Re: Text spanner with centred text state of the art

[Urs Liska]

Here is the code I settled with in my project. I assume that some of it
is inferior to the code now in LilyPond, but I also think it provides
functionality not covered by the MeasureAttachedSpanner.

1)
https://github.com/ism-dme/lm-vs/blob/import-1756/examples/library/toolbox/brackets.ily

This provides brackets with and without text, centered over one or
multiple measures. It can also center text over multiple measures. I
suspect all of this can be achieved with the now-included spanner.

2)
https://github.com/ism-dme/lm-vs/blob/import-1756/examples/library/toolbox/center.ily

This provides a function to center arbitrary "music" in a measure, e.g.
notes, clefs or time signatures in a measure by replacing a
MultiMeasureRest with a score markup (stripped of most of the score
...). Currently it is hardcoded to enter a R1, but this could be easily
replaced by either a given duration or by determining the length of
some reference expression.

Optionally that centered stuff can be "annotated" by centered text
above and below the staff. To some extent it can also ensure such text
fits in the measure by setting the MMR's minimum-length property.

Best
Urs

PS:
The folder is an example of a "toolbox" that can be used with the
openLilyLib function
  \loadTool brackets
which would also accept options, and which I implemented for that
project.

Am Sonntag, den 12.07.2020, 11:35 +0200 schrieb Urs Liska:
> And now with attachments.
> 
> It shows three main items:
> 
>  * markup centered above one or multiple measures
>  * horizontal brackets aligned to (multiple) measures
>  * markup centered within a measure
> 
> BTW: My recollection of David Nalesnik continuing with the effort
> turned up these links:
> 
> https://lists.gnu.org/archive/html/lilypond-devel/2019-11/msg00107.html
> https://codereview.appspot.com/571180043/
> https://lists.gnu.org/archive/html/lilypond-devel/2019-11/msg00092.html
> 
> However, I'm not sure (and don't right now have the time to search
> for)
> whether this ended up in LilyPond itself.
> 
> Maybe this request has been mooted last November? ;-)
> 
> BestUrs
> 
> Am Sonntag, den 12.07.2020, 11:22 +0200 schrieb Urs Liska:
> > Am Sonntag, den 12.07.2020, 11:03 +0200 schrieb Urs Liska:
> > > Am 12. Juli 2020 10:04:08 MESZ schrieb Andrew Bernard <
> > > andrew.bern...@gmail.com>:
> > > > I'll rephrase that more precisely. The function I have is no
> > > > longer
> > > > working. 
> > > 
> > > And I'll rephrase that I *think* I have working code, which yi'll
> > > look up and zry ASAP.
> > > 
> > 
> > OK, first test shows the code still works with 2.20 and produces
> > among
> > others the attached results.
> > 
> > I'll dig into the code and provide some links. It will probably not
> > be
> > immediately usable because it is tied to the project setup and
> > depends
> > on openLilyLib functionality to some extent.
> > 
> > But it would be good to find something we can massage to being
> > integratable into LilyPond.
> > Urs
> > 
> > > Urs
> > > 
> > > 
> > > > It's not suitable for inclusion.  I am wondering if anybody
> > > > has something good, or indeed if lilypond 2.21 supports such a
> > > > technique (I was unable to see that).
> > > > 
> > > > Andrew

Re: Text spanner with centred text state of the art

[Urs Liska]

And now with attachments.

It shows three main items:

 * markup centered above one or multiple measures
 * horizontal brackets aligned to (multiple) measures
 * markup centered within a measure

BTW: My recollection of David Nalesnik continuing with the effort
turned up these links:

https://lists.gnu.org/archive/html/lilypond-devel/2019-11/msg00107.html
https://codereview.appspot.com/571180043/
https://lists.gnu.org/archive/html/lilypond-devel/2019-11/msg00092.html

However, I'm not sure (and don't right now have the time to search for)
whether this ended up in LilyPond itself.

Maybe this request has been mooted last November? ;-)

BestUrs

Am Sonntag, den 12.07.2020, 11:22 +0200 schrieb Urs Liska:
> Am Sonntag, den 12.07.2020, 11:03 +0200 schrieb Urs Liska:
> > Am 12. Juli 2020 10:04:08 MESZ schrieb Andrew Bernard <
> > andrew.bern...@gmail.com>:
> > > I'll rephrase that more precisely. The function I have is no
> > > longer
> > > working. 
> > 
> > And I'll rephrase that I *think* I have working code, which yi'll
> > look up and zry ASAP.
> > 
> 
> OK, first test shows the code still works with 2.20 and produces
> among
> others the attached results.
> 
> I'll dig into the code and provide some links. It will probably not
> be
> immediately usable because it is tied to the project setup and
> depends
> on openLilyLib functionality to some extent.
> 
> But it would be good to find something we can massage to being
> integratable into LilyPond.
> Urs
> 
> > Urs
> > 
> > 
> > > It's not suitable for inclusion.  I am wondering if anybody
> > > has something good, or indeed if lilypond 2.21 supports such a
> > > technique (I was unable to see that).
> > > 
> > > Andrew
> 
> 

Re: Text spanner with centred text state of the art

[Urs Liska]

Am Sonntag, den 12.07.2020, 11:03 +0200 schrieb Urs Liska:
> 
> Am 12. Juli 2020 10:04:08 MESZ schrieb Andrew Bernard <
> andrew.bern...@gmail.com>:
> > I'll rephrase that more precisely. The function I have is no longer
> > working. 
> 
> And I'll rephrase that I *think* I have working code, which yi'll
> look up and zry ASAP.
> 


OK, first test shows the code still works with 2.20 and produces among
others the attached results.

I'll dig into the code and provide some links. It will probably not be
immediately usable because it is tied to the project setup and depends
on openLilyLib functionality to some extent.

But it would be good to find something we can massage to being integratable 
into LilyPond.
Urs

> Urs
> 
> 
> > It's not suitable for inclusion.  I am wondering if anybody
> > has something good, or indeed if lilypond 2.21 supports such a
> > technique (I was unable to see that).
> > 
> > Andrew

Re: Text spanner with centred text state of the art

[Urs Liska]

Am 12. Juli 2020 10:04:08 MESZ schrieb Andrew Bernard 
:
>I'll rephrase that more precisely. The function I have is no longer
>working. 

And I'll rephrase that I *think* I have working code, which yi'll look up and 
zry ASAP.

Urs


> It's not suitable for inclusion.  I am wondering if anybody
>has something good, or indeed if lilypond 2.21 supports such a
>technique (I was unable to see that).
>
>Andrew

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Re: Text spanner with centred text state of the art

[Urs Liska]

Hi Andrew,

Am 12. Juli 2020 08:36:09 MESZ schrieb Andrew Bernard 
:
>This exact question was asked on the list some years ago, but worth
>asking again. What is the current best way/code for making text
>spanners with text centred in the middle?
>
>I have code developed by myself and Thomas Morley from a few years ago
>but it seems to be behaving strangely now with random changes of font
>size, something beyond my skill to debug. I hope there may be
>something newer.
>
>On this perennial topic, it would be great if this function could be
>in baseline lilypond. It's in countless scores, and I know people want
>it.
>


I assume that you are referring to discussions on my behalf. I'll look ASAP 
what the resulting code base looks like, and maybe there's sonething in it for 
general harvesting.

I agree that this should absolutely go not into openLilyLib but into LilyPond. 
This is a core unctionality, IMO.

However, I recall that someone (I think David Nalesnik) contiued somewhat after 
I closed my project, I think resulting in an engraver or spanner (I think I 
ended up with spmething like a stencil override),

Urs

PS in my collected function is also code to center arbitrary markup (e.g. clefs 
or time signatures within measures.



>Andrew

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Re: Naming question: \function

[Urs Liska]

Hi Lukas,
Am Donnerstag, den 09.07.2020, 13:55 +0200 schrieb Lukas-Fabian Moser:
> Hi Urs,
> 
> 
> >   I have the impression I have no choice but to follow Carl's
> > suggestion and add a clarifying adjective, although that
> > makes
> > for  quite "expansive" user interface. E.g.
> > \harmonicFunction
> > might be the best bet so far.
> > 
> 
> I agree. In Malte Meyn's original package he included helper
> functions that switch enconding of functions on for a whole
> context
> (\lyricsToFunctions etc.), which reduces the hassle of long
> keywords.
> 
> 
> >   The next question would be how to name the corresponding
> > commands in the other planned modules (roman numerals
> > analysis
> > and "Bassstufen", another system obviously tied to
> > German-speaking music theory - I didn't even find an
> > English
> > reference on Google. It is a system originally devised by
> > E.A.
> > Förster around 1800 (
> > https://en.wikipedia.org/wiki/Emanuel_Aloys_F%C3%B6rster)
> > and heavily built upon in certain very influential streams
> > of
> > German music theory since about 2000.)
> > 
> 
> That's not quite true, since the use of circled numbers for bass
>   (and, for that matter, also melody!) notes relative to a
>   scale/root is common in theory texts dealing with "Partimento"
>   practice, which is not restricted to German-speaking countries.

OK.
> To be honest, I think Holtmeier borrowed the idea of circling
>   bass steps from this field (Förster did not use circles), but
> I'm
>   not sure on that.

Well, when you want to reuse the idea of numbering the scale steps like
Förster but with different semantics then circling seems like a natural
choice.
> 
> 
> A standard English-language reference is Robert O. Gjerdingen's
>   "Music in the Galant Style", which I'm sure you can find in
> lots
>   of your friends' offices in Freiburg :-). I just include one
>   example:
> 
> 
> 
> (For what it's worth, this is one example of a standard textbook
>   in which the musical examples plainly insult my LilyPond-
> pampered
>   eyes.)
> 
> Hence ...
> 
> 
> 
> 
> >   Maybe this set?
> >   
> > \harmonicFunction
> > \romanNumeral
> > \bassStufe
> >   
> > 
> 
> ... I would prefer an English name here, but failed to come up
>   with a good one in the last few minutes. Maybe \bassDegree or
> just
>   \degree?

\degree is definitely too generic and has more non-musical  than
musical associations. The combination with "bass" seems to be good but
excludes the idea of numbering the melody too (which I didn't know,
honestly, but is something our package should cover as well). This
brings me back do "scale".
What do our native speaking friends think, how should one name the
numbers indicating certain positions in a scale?
\scaleDegree\scaleStepsomething different?
> 
> 
> I think it would be desirable to have multiple styles of circled
>   numbers especially when dealing with minor scales: I know
>   Holtmeier's up- and down arrows, but also something like b6 and
> #7
>   might be preferred by some (and obviously some applied-dominant
>   sonorities need this anyway). And for my personal crusades, I'd
>   even like to be able to completely customize the used numbering
>   (because I would like to write something like do/re/mi instead
> of
>   1/2/3.)
Making all this configurable to accomodate different schools/dialects
as well as personal preference and overall document layout will be
built in the foundation of the package. Actually this is why I have
implemented the property set functionality.
The property set for harmonic functions (so far) includes:
\definePropertySet analysis.harmony.functional#`((double-letter-offset
,number-pair? ,(cons 0.37  -0.37))   (number-size ,number? 0)   (arrow-
width ,number? 1.5)   (arrow-Y-offset ,number? 0)   (arrow-thickness
,number? 2)   (arrow-head-gap ,number? 0)   (arrow-head-filled
,boolean? #f)   )
I've only begun so that just gives a glimpse (I wanted to use it to
show the property set behaviour). You can configure the offset between
the letters of double functions ("DD") to change appearance or
accomodate different text fonts, the relative size of the numbers, and
various aspects of an arrow to indicate intermediate functions
("Zwischendominanten").
There will be lots of properties to configure, and presets to easily
reuse settings.
With regard to the circled numbers I didn't think of the inverted ones,
but there will be various options:
 * Circled, without circle
 * (Should be extensible to have other shapes if someone wants them)
 * Regular document font, Notation font numbers, arbitrary font
 * Dotted (Johannes Menke says, "1." "2." lends itself to spoken
language)
 * Direction indicated by arrows

Re: Naming question: \function

[Urs Liska]

Hi Lukas,
Am Donnerstag, den 09.07.2020, 10:08 +0200 schrieb Lukas-Fabian Moser:
> 
> 
> 
> >   
> > 
> >   
> > > 
> > > 
> > > But seriously, do you have a suggestion what to do
> > > when the
> > > "item" the
> > > 
> > > command is referencing *is* a function?
> > > 
> > >   
> > 
> >   
> > 
> >   
> >   Another good synonym for "function", especially if you
> > passing it as an argument, is "callback"
> > 
> >   
> > 
> 
> I think there's a misunderstanding here that is worth pointing
>   out.
> 
> The "functions" Urs is working on are not functions in the
>   computer science sense (and neither in the mathematical sense,
>   although some theorists disagree). It's about "harmonic
> functions"
>   in the sense of a certain theory of harmony that is common
>   especially in German-speaking countries.[1]
Which is one more argument for *not* naming the command \function.
Thank you for the following explanations which should make it clear for
everyone what we are talking about.
I have the impression I have no choice but to follow Carl's suggestion
and add a clarifying adjective, although that makes for  quite
"expansive" user interface. E.g. \harmonicFunction might be the best
bet so far.
The next question would be how to name the corresponding commands in
the other planned modules (roman numerals analysis and "Bassstufen",
another system obviously tied to German-speaking music theory - I
didn't even find an English reference on Google. It is a system
originally devised by E.A. Förster around 1800 (
https://en.wikipedia.org/wiki/Emanuel_Aloys_F%C3%B6rster) and heavily
built upon in certain very influential streams of German music theory
since about 2000.)
I think "Bassstufe" could be translated to "scale step" or "scale
degree" and could therefore be used as a command like \scaleDegree.
However, people having written roman numeral analysis code (I know of
David Nalesnik and Malte Meyn so far) used \scaleDegree for the roman
numerals. 
Maybe this set? * \harmonicFunction
 * \romanNumeral
 * \bassStufe

The latter would handle the fact that it's used in German contexts only
anyway. And it would nicely deal with the triple "s" ;-)
However, since we're still in a computing environment I'm afraid the
reference to roman numerals might be similarly problematic as
"function". What do you think?
Best
Urs
> General idea
> 
> 
> In that theory, some of the chords usually denoted by Roman
>   numerals have special namens and symbols (now called
> "Funktionen"
>   = functions): I is "T" (for "tonic"), IV is "S" (for
>   "subdominant"), V is "D" (for "dominant"). But the more
> important
>   half of the story is that in this theory, these three
> "functions"
>   are the _only_  basic chords, from which all other chords are
>   derived in some way. For instance, a vii° is regarded as a D⁷
> with
>   root omitted, a ii⁶ is (most often) interpreted as a S with its
>   fifth replaced by a sixth, and so on.
> The term "function" can, I think, be interpreted in two different
>   ways here:
> 
>   - In the mathematical sense that these functions map from the
> set
>   of key areas to the set of actual chords ("dominant(f major) =
> c
>   major-triad") [but this applies for roman numerals as well!]
> 
>   - In the musical sense that chords tend to express a "function"
>   for the harmonic progression of a piece: tonic chords have the
>   function of "being at home", so to speak, while dominant chords
>   express the function of "being only one step away from home",
> and
>   so on.
> 
> 
> Strenghts and weaknesses
> 
> 
> As can be expected, a theory with such a strong focus on harmonic
>   interpretation of chords has its strengths and weaknesses.
> For an example of what I consider a strengh, if you compare
>   cadence formulas ii⁶ V I and IV V I, it can be argued that it
>   might make more sense to "hear" the ii⁶ as a "kind of major"
> chord
>   since the major third f-a is the same in both progressions.
>   "German" function theory caters for this by writing S⁶.
> For examples of what I consider as weaknesses:
> - While a vii°⁶ quite often has the "function" of "wanting to
>   resolve to a tonic", it's highly awkward to explain it as a
>   "dominant seven with root omitted". First, from a historical
>   perspective, V and vii°⁶ both occur much earlier than an actual
>   V⁷, so the theory explains an old and well-known phenomenon
> from
>   (at the latest) early baroque music as being derived from
>   something basically unknown at that point in time. Second, from
>   the point of view of classical voice-leading, the seventh of a
> V⁷
>   has restrictions for its voice leading (the rule of moving
>  

Re: Naming question: \function

[Urs Liska]

Hi Andrew,

Am Donnerstag, den 09.07.2020, 00:04 +1000 schrieb Andrew Bernard:
> Hi Urs,
> 
> Function is such a significant and overloaded word in programming.
> Even 
> if not a keyword, this is a terrible name for, dare I say it, a
> function 
> or a command.

... which is exactly why I raised the issue here ;-)

But seriously, do you have a suggestion what to do when the "item" the
command is referencing *is* a function?

Urs

> 
> Andrew
> 
> 
> 

Naming question: \function

[Urs Liska]

Hi all,

I've started working on a package for displaying harmonic analysis
symbols. In the submodule for functional analysis I have (using the
original code of Malte Meyn) the main command \function, which gives
very obvious code like

  \function (D_3-7)=>

(for an intermediate dominant seventh with the "3" in bass position).

What do you guys here think: Could the use of "function" as a command
name lead a) to confusion by people mistaking it as a language keyword
or b) to issues down the road if at some point one might want to create
a core LilyPond procedure with that name?

Best
Urs

Re: Making markup functions parametric

[Urs Liska]

Hi Lukas,

Am Samstag, den 04.07.2020, 10:22 +0200 schrieb Lukas-Fabian Moser:
> Hi Urs,
> 
> > I have tried various things, but I don't seem to understand how
> > that
> > primitive-eval actually works here. Your solution does only work
> > when
> > the input is a simple markup (string), not when it is wrapped in
> > other
> > markup commands.
> 
> It seems to work quite robustly if you draw the given content markup 
> into a stencil and insert this stencil in the markup expression that 
> will be fly-evaluated:
> 
> \version "2.20"
> 
> #(define (get-scheme-markup-function func)
> (symbol-append 'make- func '-markup))
> 
> #(define-markup-command (enclose layout props func content)(symbol?
> markup?)
> (interpret-markup layout props
>   (primitive-eval
>(list 'markup
>  (list
>   (get-scheme-markup-function func)
>   `(make-stencil-markup ,(interpret-
> markup 
> layout props content)))
> 
> \markup \enclose #'box "C"
> \markup \enclose #'circle \italic \concat { "Camel" "Case" }
> \markup \enclose #'circle \enclose #'box \italic "E"
> 
> Does this help?
> 

Yes, indeed, thank you very much! With it I could for now complete my
function for a highly configurable object to denote the reference key
in harmonic analysis.

The following code produces the (non-sensical) attached result. It is
also a first demonstration of the new "properties/property
sets/presets" feature I'm right now finalizing for openLilyLib.
If you want to check it our yourself, the code is in oll-core (branch
'properties') and anaLYsis (branch 'harmony-initial'). The full
implementation of the function (also with property sets in action) can
be seen in 
https://github.com/openlilylib/analysis/blob/harmony-initial/harmony/ref-key.ily
When a function is created with the with-property-set macro arguments
are type-checked against the property set, defaults are given,
properties can be changed globally, in presets or locally in a call.
Within a function there's a function 'property' available to retrieve
the current property value. There's also a function 'use-preset' (not
used in this example, which works together with a set of preset filters
to determine whether a function should be "used" based on the given
presets. This can be used to selectively activate functions, for
example to hide them until needed or to highlight them on demand. The
Frames, Arrows, and Highlighters modules of anaLYsis are the first
real-world examples for this new functionality, which I'm pretty
excited about.

Best
Urs

\version "2.20.0"

\include "oll-core/package.ily"
\loadModule analysis.harmony

\definePreset \with {
  color = #red
  box-padding = 1
} analysis.harmony.ref-key default

\definePreset \with {
  parent = default
  box-type = ellipse
  box-padding = 0.3
  space-before-separator = 0.7
} analysis.harmony.ref-key one

\definePreset \with {
  parent = default
  accidental-size = 4
  space-before-accidental = -0.5
} analysis.harmony.ref-key two


{
  <<
\new Staff { c' d' e' f' g' a' b' c' }
\new Lyrics \lyricmode {
  \refKey  \with  { preset = one } C> T1
  \refKey  \with  { preset = two } F< S
}
  >>
}

(The complete list of (so far) configurable properties for \refKey can
be seen here: 
https://github.com/openlilylib/analysis/blob/harmony-initial/harmony/ref-key.ily#L20-L38
)

> Best
> Lukas
> 
> 

Re: Making markup functions parametric

[Urs Liska]

Am Samstag, den 04.07.2020, 05:28 +0200 schrieb Urs Liska:
> 
> Am 3. Juli 2020 23:33:42 MESZ schrieb Lukas-Fabian Moser 
> :
> > > #(define (get-scheme-markup-function func)
> > >(string->symbol
> > > (string-append "make-"
> > >(symbol->string func)
> > >"-markup")))
> > 
> > ... which should be replaced by
> > 
> > #(define (get-scheme-markup-function func)
> >(symbol-append 'make- func '-markup))
> > 
> 
> That's fantastic, thank you very much.
> (You'll soon see that code again, I assume ;-) ).

Oops, unfortunately it's not enough ...

I have tried various things, but I don't seem to understand how that
primitive-eval actually works here. Your solution does only work when
the input is a simple markup (string), not when it is wrapped in other
markup commands. 
Consider this:

\version "2.20"

#(define (get-scheme-markup-function func)
   (symbol-append 'make- func '-markup))

#(define-markup-command (enclose layout props func content)(symbol?
markup?)
   (ly:message "content: ~a" content)
   (interpret-markup layout props
 (primitive-eval
  (list 'markup
(list
 (get-scheme-markup-function func)
 content)

\markup \enclose #'box "C"
\markup \enclose #'circle \concat { "D" } 
\markup \enclose #'circle \italic "E"


While it works for the first case, both the \concat and the \italic
produce an error like
  Wrong type to apply: "D"

The content entering the markup command is printed as
  (# (D))
or
  (# E)

What will go there in the \enclose is a concatted and potentially
formatted markup expression.

I got one step further accepting a second symbol, which made the
\italic work:

\version "2.20"

#(define (get-scheme-markup-function func)
   (symbol-append 'make- func '-markup))

#(define-markup-command (enclose layout props func func2
content)(symbol? symbol? markup?)
   (ly:message "content: ~a" content)
   (interpret-markup layout props
 (primitive-eval
  (list 'markup
(list
 (get-scheme-markup-function func)
 (list (get-scheme-markup-function func2)
 content))

%\markup \enclose #'box "C"
%\markup \enclose #'circle #'concat \concat { "D" "e" }
\markup \enclose #'circle #'italic "E"


But with the \concat it still doesn't work.
Content prints
  (# Best
> Urs
> 
> > Sorry, I had not realized that symbol-append is available in Guile
> > 1.8.
> > 
> > Lukas

Re: Making markup functions parametric

[Urs Liska]

Am 3. Juli 2020 23:33:42 MESZ schrieb Lukas-Fabian Moser :
>
>> #(define (get-scheme-markup-function func)
>>    (string->symbol
>>     (string-append "make-"
>>    (symbol->string func)
>>    "-markup")))
>
>... which should be replaced by
>
>#(define (get-scheme-markup-function func)
>    (symbol-append 'make- func '-markup))
>

That's fantastic, thank you very much.
(You'll soon see that code again, I assume ;-) ).

Best
Urs

>Sorry, I had not realized that symbol-append is available in Guile 1.8.
>
>Lukas

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Re: After directory rename, Frescobaldi doesn't show PDF

[Urs Liska]

Am 4. Juli 2020 00:18:15 MESZ schrieb Davide Liessi :
>Dear David,
>
>Il giorno ven 3 lug 2020 alle ore 23:48 David F.  ha
>scritto:
>> Frescobaldi is having problems with file paths that have question
>marks and accented characters.
>
>tomorrow I'll test and get back to you.
>
>> This problem is not present in Frescobaldi 2.20.
>
>This is interesting.

May point to a Python 2/3 encoding issue.

Urs

>
>Best wishes.
>Davide

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Re: Making markup functions parametric

[Urs Liska]

Hi Robin,

Am Freitag, den 03.07.2020, 22:11 +0200 schrieb Robin Bannister:
> Urs Liska wrote:
> 
> > Unfortunately I don't really have an idea what "#:circle" actually
> > *is*, so I have no clue about getting where I need to.
> 
> I think it's a sort of macro thingy, trying to be easy to be used.
> 
> Look at 'Known issues and warnings' at the bottom of
> https://lilypond.org/doc/v2.20/Documentation/extending/markup-construction-in-scheme
> 
> So make-circle-markup would be equivalent.

Thanks a lot. That's exactly the kind of procedure I can store and
apply:

\version "2.20.0"

#(define-markup-command (dyna layout props func content)(symbol?
markup?)
   (let*
((funcs
  `((box . ,make-box-markup)
(circle . ,make-circle-markup
(interpret-markup layout props
  (markup 
   ((assq-ref funcs func) content)

\markup \dyna #'circle "C:"

\markup \dyna #'box "C:"

Best
Urs

> 
> 
> Cheers,
> Robin

Re: Making markup functions parametric

[Urs Liska]

Am Freitag, den 03.07.2020, 21:58 +0200 schrieb Ralf Mattes:
>  
> Am Freitag, 03. Juli 2020 21:52 CEST, Urs Liska <
> li...@openlilylib.org> schrieb: 
>  
> > Unfortunately I don't really have an idea what "#:circle" actually
> > *is*, so I have no clue about getting where I need to.
> 
> Syntacilally? That would be a scheme keyword. 

So that would be difficult to inject from a variable/argument, isn't
it?

I can of course do

  (cond
   ((eq? enclosure 'circle)
(markup #:circle "CC"))
   ((eq? enclosure 'box)
(markup #:box "CC)))

But I'd rather do something like

  (markup (assq-ref enclosures enclosure) "CC")

i.e. looking up the appropriate function instead of creating a
conditional chain.

Any ideas?

ThanksUrs

> 
>  Cheers, RalfD
>  
> > BestUrs
> > 
> > 
>  
>  
>  

Making markup functions parametric

[Urs Liska]

In the following markup command definition

#(define-markup-command (test layout props enclosure content)
  (scheme? markup?)
   (interpret-markup layout props (markup #:circle content)))

I would like to make the #:circle parametric, i.e. I want to pass
something into the function (e.g. as the 'enclosure' argument) and
apply the corresponding markup function within the markup expression.
The argument could be a function directly or a symbol from which it is
referenced.

Howeve, I would like to dynamically apply the markup function here
rather than create a structure that chooses a complete markup
expression based on the desirec markup type.

Unfortunately I don't really have an idea what "#:circle" actually
*is*, so I have no clue about getting where I need to.

BestUrs

Re: lilyglyphs.sty not found after upgrade to ubuntu 20.04

[Urs Liska]

Am Donnerstag, den 02.07.2020, 17:01 +0200 schrieb Urs Liska:
> Am Donnerstag, den 02.07.2020, 10:18 +0200 schrieb Urs Liska:
> > Am 2. Juli 2020 10:00:25 MESZ schrieb bart deruyter <
> > bart.deruy...@gmail.com>:
> > > Hi all,
> > > a bit off topic, but I thought maybe here someone would know
> > > something.
> > > I've recently upgraded to ubuntu 20.04 and tried to compile a
> > > luatex
> > > file
> > > containing lilypond material, using lyluatex and lilyglyphs.
> > > 
> > > Now my system complains about 'lilyglyphs.sty not found'.
> > > I thought it would have been upgraded too, but it seems like it
> > > has
> > > been
> > > removed from the system and repositories all together. I don't
> > > find
> > > anything related to lilyglyphs in the repository.
> > 
> > Thanks for the report. I don't know anything about it and will
> > investigate.
> 
> How did you install LaTeX? I assume you are using TeX Live? The
> versions from the Ubuntu packages or the downloaded TeX Live?
> 
> I assume you installed from the Ubuntu packages. If so, which actual
> packages did you install.
> https://packages.ubuntu.com/focal/all/texlive-music/filelist
> indicates
> lilyglyphs is (still) in the texlive-music collection.
> 
> Actually I'd be surprised if they had removed it. I'm aware of the
> possibility of compatibility issues, but I can't imagine they remove
> packages without warning/asking the maintainers first.

I just had a closer look and found that
a) lilyglyphs.sty is (now?) placed at tex/lualatex/lilyglyphs
which is somewhat strange and might xelatex not find it (I'm not sure,
but if you use lyluatex this can't be the issue anyway.

b)
I can't find lilyglyphs in the texlive package lists of Ubuntu and
Debian. I'll ask on the texlive mailing list.

Urs

> 
> BestUrs
> 
> > Urs
> > 
> > > thanks,
> > > Bart
> > > 
> > > https://esmiltania.be
> > > On Twitter <https://twitter.com/Bart_Issimo>
> > > On Google+ <https://plus.google.com/u/0/b/116379400376517483499/>
> 
> 

Re: lilyglyphs.sty not found after upgrade to ubuntu 20.04

[Urs Liska]

Am Donnerstag, den 02.07.2020, 10:18 +0200 schrieb Urs Liska:
> 
> Am 2. Juli 2020 10:00:25 MESZ schrieb bart deruyter <
> bart.deruy...@gmail.com>:
> > Hi all,
> > a bit off topic, but I thought maybe here someone would know
> > something.
> > I've recently upgraded to ubuntu 20.04 and tried to compile a
> > luatex
> > file
> > containing lilypond material, using lyluatex and lilyglyphs.
> > 
> > Now my system complains about 'lilyglyphs.sty not found'.
> > I thought it would have been upgraded too, but it seems like it has
> > been
> > removed from the system and repositories all together. I don't find
> > anything related to lilyglyphs in the repository.
> 
> Thanks for the report. I don't know anything about it and will
> investigate.

How did you install LaTeX? I assume you are using TeX Live? The
versions from the Ubuntu packages or the downloaded TeX Live?

I assume you installed from the Ubuntu packages. If so, which actual
packages did you install.
https://packages.ubuntu.com/focal/all/texlive-music/filelist indicates
lilyglyphs is (still) in the texlive-music collection.

Actually I'd be surprised if they had removed it. I'm aware of the
possibility of compatibility issues, but I can't imagine they remove
packages without warning/asking the maintainers first.

BestUrs

> 
> Urs
> 
> > thanks,
> > Bart
> > 
> > https://esmiltania.be
> > On Twitter <https://twitter.com/Bart_Issimo>
> > On Google+ <https://plus.google.com/u/0/b/116379400376517483499/>

Re: Notes switching Voices

[Urs Liska]

Hi Valentin,

this looks very interesting, and I'll definitely have a closer look
because I currently see the need to finally get my head around defining
new and switching between contexts.

Just one remark: You can remove the keepAliveWhile function and replace
it with a simple

  \new Voice = "bottomA" { #(skip-of-length bass) }

BestUrs

Am Donnerstag, den 02.07.2020, 11:52 +0200 schrieb Valentin Petzel:
> Hello,
> 
> I have recently found a way of having notes change context into a
> different 
> voice. This might be useful when you want to do things like
> condensing three 
> voices into two voices in a piano score. This is basically done by
> adding a 
> Notes-Context to the Voice-Context, which allows us the change the
> voice.
> 
> In the appended file there is a chorale condensed to a piano score
> using this 
> way. Note how in measure 5 the alto voice switches to the tenor
> voice.
> 
> This might matter, because it allows us to differentiate stronger
> what the 
> actual music is versus how it is notated, i.e. we can differentiate
> between 
> lilyponds notated voices and the voices that are actually in the
> music.
> 
> I hope some of you can profit from this, and if you like you can also
> put this 
> on LSR. I’m apparently far to stupid to do this, I cannot even
> properly 
> register a user.
> 
> Regards,
> Valentin

Re: lilyglyphs.sty not found after upgrade to ubuntu 20.04

[Urs Liska]

Am 2. Juli 2020 10:00:25 MESZ schrieb bart deruyter :
>Hi all,
>a bit off topic, but I thought maybe here someone would know something.
>I've recently upgraded to ubuntu 20.04 and tried to compile a luatex
>file
>containing lilypond material, using lyluatex and lilyglyphs.
>
>Now my system complains about 'lilyglyphs.sty not found'.
>I thought it would have been upgraded too, but it seems like it has
>been
>removed from the system and repositories all together. I don't find
>anything related to lilyglyphs in the repository.

Thanks for the report. I don't know anything about it and will investigate.

Urs

>
>thanks,
>Bart
>
>https://esmiltania.be
>On Twitter 
>On Google+ 

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Re: Humdrum **kern and LilyPond

[Urs Liska]

Am Dienstag, den 30.06.2020, 17:28 +0200 schrieb Jacques Menu:
> Hello folks,
> 
> I’ve been wondering : is Humdrum **kern in wide use, 

I don't know the answer to that question, but I do know it is *in use*,
and I'd be interested in any integration with LilyPond. Craig Sapp has
- not that long ago - written a kern-to-MEI converter, and there is the
VerovioHumdrum Viewer at https://verovio.humdrum.org/

> and do you know of any work or application involving both Humdrum
> **kern and LilyPond?
> 

I'm not sure about the state of affairs, but Jan-Peter has at least
started a proof-of-concept of a two-way kern-lilypond-kern converter.
He may not be currently monitoring the mailing lists too closely,
though.

Urs

> Thanks!
> 
> JM
> 
> 

New openLilyLib feature: properties

[Urs Liska]

Hi all,

triggered by a new analysis.highlighters module that Klaus Blum shared
with me last week I had a few feature/functionality wishes that I
implemented, especially a kind of stylesheet support and selective
activation of elements. I quickly realized that this should be
generalized and factored out, and today I've implemented a new tool for
the oll-core package (i.e. available for any documents using
openLilyLib): properties.

Properties are related to OLL's existing option handling, but probably
superior in every aspect, so I might one day deprecate the whole
options feature (although that might be hard on existing code, so I'm
not sure about that yet).

The main features of the new properties are:

 * properties are type-checked
 * grouping in property sets may allow better organization and
   encapsulation
 * nice support for cascading behaviour
 * support for selective activation

If you are interested you can check out the "properties" branch in the
oll-core repo and play around with the attached file (also available in
the usage-examples folder in oll-core).

A "property set" is a group of properties with names, type check
predicates, and values.
When defining a property set, "design time defaults" are specified,
which can be retrieved or changed at any point throughout a document.

A property set might group openLilyLib package options, project
options, or the available properties for a music/scheme/void-function.

A macro "with-propset" allows the definition of functions that rely on
a property set, that is:

 * When called without options the properties of the propset are
   available with their current values
 * It is possible to define "presets", which are (type-checked) subsets
   of a property set. When used its values override the current
   property values.
 * When called with a \with {} block individual properties can be
   overridden, whether from the original properties or from a preset
 * Presets can have parents (I have not transferred the implementation
   to that new code base, but I had it in place in the original code).
   This allows cascading stylesheets, for example a default preset
   specifying a line thickness for a given function, and several child
   presets with different colors.
 * Also not transferred yet is support for a logic to use/ignore items
   based on presets. This makes it possible to easily control which
   items are shown or not, for example when doing presentations or
   teaching.

As a first step I'll make use of this in the Frames, Arrows and
Highlighters modules of anaLYsis. Second I will use it in new anaLYsis
modules which I have wanted to realize for a very long time: support
for harmonic analysis symbols in analysis.harmony.functional,
analysis.harmony.roman, and analysis.harmony.scale-degrees.

This is both sort-of an announcement and a request for comments before
I start building heavily on the new code base.

Best
Urs
\version "2.20.0"

% Use oll-core from the 'properties' branch
\include "oll-core/package.ily"

% Define a property set
% Properties hold a name, a type predicate and a default value.
% The default value (as well as later assignments) are type-checked
% against the predicate
\definePropset demo.props
#`((text ,string? "bar")
   (color ,color? ,red)
   (index ,integer? 4)
   ;(use-case ,symbol? "fail") ; fails on typecheck
   )

% Retrieve the property
\markup \getProperty demo.props text

% Set a property, this will be the new "current" value of the property
\setProperty demo.props text "baz"
\markup \getProperty demo.props text

% Set a property with wrong type -> no change, will be skipped
%\setProperty demo.props text #green
\markup \getProperty demo.props text

% Define a named preset (for a specific propset).
% When used the included overrides will take precedence
% over the current property values.
% (type checking is active too
\definePreset \with {
  text = boo
  color = #blue
%  index = invalid % fails type-check
} demo.props my-preset

% Define a function with the propset
% - Due to the optional \with block at least one mandatory
%   argument is required.
% - Within the function all properties are accessible
%   through the local (property ') function
% - If validation is necessary the effective properties
%   (after merging) can be accessed through the
%   props variable
testFunc =
#(with-propset define-scheme-function (dummy)(boolean?)
   `(demo props)
(markup #:with-color
  (property 'color)
  (format "~a. ~a" (property 'index) (property 'text

% Invoke function with currently active properties
\testFunc ##t

% Invoke function with a preset
\testFunc \with {
  preset = my-preset
} ##t

% Invoke function with a preset plus individual override
\testFunc \with {
  preset = my-preset
  index = 5
  color = #magenta
} ##t

Re: Combine Text/Lyrics with bass figures

[Urs Liska]

Oops, somehow I managed to read only the top half of Lukas' post and
missed the interesting part :-(

Am Freitag, den 26.06.2020, 15:01 +0200 schrieb Lukas-Fabian Moser:
> Hi Urs, hi Moritz,
> 
> > > thanks for the improvements to my code! (I tend to stop thinking 
> > > about it as soon as it works for my case, which always leaves
> > > lots of 
> > > room for improvement.)
> > > 
> > Seems to be the opposite of my approach. I'm always starting to
> > think 
> > in terms of reusability and "packages" right away - leading to
> > working 
> > code much later than would be good ;-)
> When your default working mode is "I need this worksheet tomorrow by
> 9 
> o'clock", the approach of using the first sort-of viable solution 
> becomes much more tempting ;-).
> 
> > > (2) There might also be cases where you have more that one row of
> > > arabic
> > > numbers to indicate other options. My first intention here would
> > > be to have a
> > > single layer for every key, that is used in the analysis. If
> > > there’s an option
> > > to hide the layer where it is not used.
> > Each layer is a Lyrics or FiguredBass context, [...]
> 
> That's exactly what occurred to me over lunch: Everything we talked 
> about concerning spacing just expresses the fact that scale degrees
> and 
> bass figures should behave as if they were independent contexts (one 
> FiguredBass, one Lyrics).
> 
> So let's scrap the idea of inserting scale degrees artificially into 
> bass figures where they do not belong!
> 
> Hence:
> 
> \version "2.20.0"
> 
> #(define (scale-degree degree)
>(if (eqv? degree 0)
>(markup #:null)
>(markup #:circle #:small #:number (number->string
> degree
> 
> #(define (bass-degree? obj)
> "A bass degree is either a number between 1 and 7 or 0 (eqv. to
> nothing)!"
> (and (integer? obj) (> 8 obj) (< -1 obj)))
> 
> #(define (event-chord? obj)
> (and (ly:music? obj) (music-is-of-type? obj 'event-chord)))
> 
> 
> #(define (figure-signature? obj)
> "A figure signature is either an EventChord music or a duration."
> (or
>  (event-chord? obj)
>  (ly:duration? obj)))
> 
> duration-from-event-chord =
> #(define-scheme-function (chord) (event-chord?)
> (let ((els (ly:music-property chord 'elements)))
>   (ly:music-property (first els) 'duration)))
> 
> scaledeg =
> #(define-music-function (num signature) ((bass-degree? 0) figure-
> signature?)
> (let ((dur (if (ly:duration? signature)
> signature
> (duration-from-event-chord signature
>   #{
> <<
> #(if (ly:music? signature)
>  signature
>  #{ s $signature #})
> \context Lyrics = "scaleDegrees" \lyricmode
> {
>   \markup { #(scale-degree num) } $dur
> }
> >>
>   #}))
> 
> 
> 
> <<
>\new Staff {
>  \time 3/4
>  \clef bass
>  c4 d e f2 g4 as2^"or g sharp?" a4 b4 c'4 % Morgenlich leuchtend
> ...
>}
>\figures \with { \override 
> VerticalAxisGroup.nonstaff-nonstaff-spacing.padding = 1 } {
>  \scaledeg 1 4
>  \scaledeg 2 <4 3>4
>  \scaledeg 3 <6>4
>  \scaledeg 4 <7>4
>  \scaledeg 0 <6>
>  \scaledeg 5 4
>  \scaledeg 6 <6>2
>  \scaledeg 6 <6>4
>  \scaledeg 7 <6 5>4
>  \scaledeg 1 4
>}
>\new Lyrics = "scaleDegrees" { \skip 1*8 }
>  >>
> 
> 
> Of course this is just proof-of-concept: 

It looks like this is very extensible, and I'll definitely have a
closer look at it.

> The Lyrics context should be 
> created (and kept alive) automatically ... or, even better: it should
> be 
> user-settable with an interface like:
> 
> \figures {
> 
>\inject-scaledegrees-into-context "scaleDegrees"
> 
>...
> 
> }
> 
> which would enable all sorts of vertical configuration.

This can be done by defining the figures in a variable, say, figs and
then doing something like

makeDegrees = {
  <<
\new FiguredBass \with {
  \override VerticalAxisGroup.nonstaff-nonstaff-spacing.padding = 1
} \figs
\new Lyrics = "scaleDegrees" { #(skip-of-length figs) }
  >>
}

In the score definition we use \makeDegrees instead of explicitly
creating the contexts.

I think I'll really investigate how this can nicely be integrated in an
anlysis.harmony package.

BestUrs

> 
> Best
> Lukas
> 

Re: Combine Text/Lyrics with bass figures

[Urs Liska]

Am Freitag, den 26.06.2020, 15:01 +0200 schrieb Lukas-Fabian Moser:
> Hi Urs, hi Moritz,
> 
> > > thanks for the improvements to my code! (I tend to stop thinking 
> > > about it as soon as it works for my case, which always leaves
> > > lots of 
> > > room for improvement.)
> > > 
> > Seems to be the opposite of my approach. I'm always starting to
> > think 
> > in terms of reusability and "packages" right away - leading to
> > working 
> > code much later than would be good ;-)
> When your default working mode is "I need this worksheet tomorrow by
> 9 
> o'clock", the approach of using the first sort-of viable solution 
> becomes much more tempting ;-).
> 
> > > (2) There might also be cases where you have more that one row of
> > > arabic
> > > numbers to indicate other options. My first intention here would
> > > be to have a
> > > single layer for every key, that is used in the analysis. If
> > > there’s an option
> > > to hide the layer where it is not used.
> > Each layer is a Lyrics or FiguredBass context, [...]
> 
> That's exactly what occurred to me over lunch: Everything we talked 
> about concerning spacing just expresses the fact that scale degrees
> and 
> bass figures should behave as if they were independent contexts (one 
> FiguredBass, one Lyrics).
> 
> So let's scrap the idea of inserting scale degrees artificially into 
> bass figures where they do not belong!

Well, OK. But then let's take the opportunity to find a way to *encode*
things together that belong together. One thing I've been missing for
very long is an option (note: this is not a request for changing the
default behaviour) to add lyrics or figures to other contexts. In many
cases I would want to enter syllables (less likely) or bass figures or
analysis symbols to a note instead of having to count skips in a
separate context.
If it would be possible to inject something in a separate context
(similar to \change Staff) it might be interesting in this use case.

One thing I'd might test is if the edition-engraver can inject markup
in a Lyrics context. If so one could have an empty context that is
automatically filled with very short spacer rests which could then
serve as anchors for the edition-engrave.
This "external" encoding is also somewhat un-intuitive, especially when
the content of the music might change. But it could provide nice
options for showing/hiding layers or elements.

Urs

> 
> Hence:
> 
> \version "2.20.0"
> 
> #(define (scale-degree degree)
>(if (eqv? degree 0)
>(markup #:null)
>(markup #:circle #:small #:number (number->string
> degree
> 
> #(define (bass-degree? obj)
> "A bass degree is either a number between 1 and 7 or 0 (eqv. to
> nothing)!"
> (and (integer? obj) (> 8 obj) (< -1 obj)))
> 
> #(define (event-chord? obj)
> (and (ly:music? obj) (music-is-of-type? obj 'event-chord)))
> 
> 
> #(define (figure-signature? obj)
> "A figure signature is either an EventChord music or a duration."
> (or
>  (event-chord? obj)
>  (ly:duration? obj)))
> 
> duration-from-event-chord =
> #(define-scheme-function (chord) (event-chord?)
> (let ((els (ly:music-property chord 'elements)))
>   (ly:music-property (first els) 'duration)))
> 
> scaledeg =
> #(define-music-function (num signature) ((bass-degree? 0) figure-
> signature?)
> (let ((dur (if (ly:duration? signature)
> signature
> (duration-from-event-chord signature
>   #{
> <<
> #(if (ly:music? signature)
>  signature
>  #{ s $signature #})
> \context Lyrics = "scaleDegrees" \lyricmode
> {
>   \markup { #(scale-degree num) } $dur
> }
> >>
>   #}))
> 
> 
> 
> <<
>\new Staff {
>  \time 3/4
>  \clef bass
>  c4 d e f2 g4 as2^"or g sharp?" a4 b4 c'4 % Morgenlich leuchtend
> ...
>}
>\figures \with { \override 
> VerticalAxisGroup.nonstaff-nonstaff-spacing.padding = 1 } {
>  \scaledeg 1 4
>  \scaledeg 2 <4 3>4
>  \scaledeg 3 <6>4
>  \scaledeg 4 <7>4
>  \scaledeg 0 <6>
>  \scaledeg 5 4
>  \scaledeg 6 <6>2
>  \scaledeg 6 <6>4
>  \scaledeg 7 <6 5>4
>  \scaledeg 1 4
>}
>\new Lyrics = "scaleDegrees" { \skip 1*8 }
>  >>
> 
> 
> Of course this is just proof-of-concept: The Lyrics context should
> be 
> created (and kept alive) automatically ... or, even better: it should
> be 
> user-settable with an interface like:
> 
> \figures {
> 
>\inject-scaledegrees-into-context "scaleDegrees"
> 
>...
> 
> }
> 
> which would enable all sorts of vertical configuration.
> 
> Best
> Lukas
> 

Re: Combine Text/Lyrics with bass figures

[Urs Liska]

Hi Moritz,


Moritz Heffter – Fri, 26. June 2020 13:26
> Hi Urs, hi Lukas,
> That looks very good, Lukas. And thank for coming up with the idea of
> integrating arabic scale degree numbers in lilypond, Urs. I’ll join the lobby
> team if you want :).

Definitely!

> For the usage of the numbers I just have two remarks, that might be far from
> what is currently discussed. But I think it might be good to think about the
> requirements for the arabic numbers.
> Just two thoughts on that:(1) I wonder if it’s good to combine the arabic
> scale degrees with the figured bass in one layer. There might be reasons to
> put figure bass numbers above the bass line. I’m not so deep in the figured
> bass mode in lilypond (only use one layer to write the numbers) but I think in
> order to be flexibel in layout and in keeping information not too nestled it
> might be good, to separate these information.

There are situations where you'll want one or the other. However, it's easy to 
write arabic numbers in one layer and just leave out the figures to encode them 
separately. So having the option to use them combined doesn't get in the way of 
your suggestion.

> (2) There might also be cases where you have more that one row of arabic
> numbers to indicate other options. My first intention here would be to have a
> single layer for every key, that is used in the analysis. If there’s an option
> to hide the layer where it is not used.

Each layer is a Lyrics or FiguredBass context, and when there's no content it's 
simply not produced. So that's not an issue. What's more interesting as an 
option is to *hide* the elements in a layer. In that case it *will* use the 
space but keep it empty. With that you can prepare a sheet for 
presentatio/teaching and have it filled along the discussion (i.e. without 
initially confronting the students with overcrowded analysis sheets.

> I hope I’m not making things more complicated and got the intention right :).

No, you don't, and yes you did ;-)
(somewhat strange, though, to discuss this at this moment and in this place, 
isn't it?)

Best
Urs

> 
> Best,Moritz
> 
> > Am 26.06.2020 um 12:36 schrieb Urs Liska :
> Hi Lukas,
> 
> that's great, and I hope you'll stick with me when I try to work that
> out into a generally usable (i.e. sufficiently flexible) solution to
> lobby with the GMTH ;-)
> 
> Am Freitag, den 26.06.2020, 10:07 +0200 schrieb Lukas-Fabian Moser:
> > Hi Urs,
> 
> > Hey, that looks promising - I didn't know that.
> Now I'd only need a way to properly do the vertical alignment
> against
> the baseline of the lowest markup:
> 
> \figures {
> <6 4 \markup { \circle \number 5 }>
> <3+ \markup { \circle \number 6 }>
> }
> 
> 
> This might be achieved using an inversed stacking direction.
> 
> 
> Great.
> 
> > Harm's
> figure reversal function can then be used to enable the user to
> still
> enter bass figures in the "usual" way.
> 
> With a bit of syntactic sugar, this might look as below.
> 
> 
> I've started working on that, see below ...
> 
> > 
> Problems so far:
> 
> 1) The figures are still down-aligned. This might be remedied for
> instance by defining a "maximal" number of figures for which to
> leave
> space and inserting placeholders. (This reminds me of one of my
> long-time wishes, namely to have a dedicated "empty" figure for use
> in
> FiguredBass, which is sometimes needed to leave space for figures
> that
> are added later in a chord. I once patched my LilyPond to allow for
> this, but this was an ugly hack involving transparent figures...)
> 
> 
> I have *not* started working on this yet. I don't find transparent
> markups that offensive. It's a commonplace approach also for achieving
> consistent baselines for strings without as/descenders.
> 
> However, what we *actually* want is a common number of items *per
> system*, not for the whole score. What if we determine maximum number
> of entries of 3 and have many systems only use one - that would make
> for ugly whitespace all over the place.
> 
> The only remedy I can see right now would be to deal with this in an
> after-line-breaking stencil. From there we could iterate over the whole
> system and check the maximum number of actually used layers. The result
> should be cached so this process is done only once per system.
> However, this won't always work because the context may not have been
> pushed sufficiently far down in situations like the attached example.
> 
> > 
> 2) The "get-current-duration" function is simply awful: I didn't
> know
> how to find out which duration the parser would assign to a
> duration-less note/bass figure, so I just let it create

Re: Combine Text/Lyrics with bass figures

[Urs Liska]

Am Freitag, den 26.06.2020, 13:14 +0200 schrieb Lukas-Fabian Moser:
> Hi Urs,
> 
> thanks for the improvements to my code! (I tend to stop thinking
>   about it as soon as it works for my case, which always leaves
> lots
>   of room for improvement.)

Seems to be the opposite of my approach. I'm always starting to think
in terms of reusability and "packages" right away - leading to working
code much later than would be good ;-)
> 
> 
> 
> >   The only remedy I can see right now would be to deal with
> > this in anafter-line-breaking stencil. From there we could iterate
> > over the wholesystem and check the maximum number of actually used
> > layers. The resultshould be cached so this process is done only
> > once per system.However, this won't always work because the context
> > may not have beenpushed sufficiently far down in situations like
> > the attached example.
> > 
> 
> This exceeds my current understanding of LilyPond coding, I'm
> afraid.
> 
> 
> >   I've made a number of improvements to your code:
> > 1)reverseFigures creates a new music expression, from which you
> > laterretrieve the 'elements, which is unnecessary. (I renamed it to
> > parse-signature
> > 
> 
> Yes, thank you - I only wanted to "quickly re-use the existing
> code"
> without bothering about possible shortcuts.
> 
> >   2)The figures do have their durations included, so we can
> > retrieve them*here* and reuse that information later when
> > generating theBassFigureEvent for the bass step markup.
> > 
> 
> Yes, that occurred to me later. However, I think there is still a
>   problem (I was working on a similar problem when your code
>   arrived):
> 
> 
>   
> > 2a)Instead of \none I rewrote \scaledeg to accept either a
> > figuresignature or a duration. This gives a nice interface where
> > you can justspecify a duration for an empty figure.
> >   
> 
> 
> 
> <<
> 
> \new Staff { \clef bass c2 d4 e4~ e f2 g4 }
> 
> \figures {
> 
>   \scaledeg 1 <5 3>2
> 
>   \scaledeg 2 <6>4
> 
>   \scaledeg 3 2 
> 
>   \scaledeg 4 <6 5> % Here the user would expect to get a
>   duration of 2, but gets 4
> 
>   \scaledeg 4 <6 5>4
> 
> }
> 
>   >>
> 
> 
> 
> The parser does not seem to take notice of durations when they
>   are used as function parameters. 

Which is pretty plausible: How should LilyPond know what that duration
is used for and whether it should be considered for the next parsed
music or not. The function might as well convert that function argument
to a label and print it ...
> I do not know how to handle this
>   - it comes down to the question: How to read/write the "current
>   assumed duration" from the parser?
> 
> 

I would evade the issue by simply stating that one should *always* give
an explicit duration.
> 
> 
> As for lobbying with the music theory folks:
> 
> 
>   They are going to ask for "raised"/"lowered" scale steps.
> (Using arrows, flat/sharp etc.) I even used relative
> solmization
> syllables for this in my teching instead of numbers... ("fa
> with
> a 642").
>   The set of people interested in using this does not scale well
> with physical distance from the Freiburg theory department ;-
> ).
> It's not as widespread as one might be induced to believe
> from
> looking at their local practice... But maybe it's becoming
> more
> common over time. At least there's plenty of people with a
> Freiburg education getting teaching jobs elsewhere.

Well, my plan for it is to have a growing OLL module analysis.harmony
with submodules analysis.harmony.functional, analysis.harmony.förster,
analysis.harmony.roman-numerals etc. All of this should live within a
consistent user interface, and each module should be appropriately
configurable to accomodate the needs of different theorists.
Right now you can imagine that I have an incentive to please the
Freiburg incarnation of Förster's scale degree analysis (although I'd
in the same effort would provide the "pure" version too (which is of
course easier to achieve).The next GMTH congress will probably feature
a significant "digital" section or presentation, and I'm interested in
LilyPond taking a part in this.
Best
Urs
>   
> 
> Best
> 
>   Lukas
> 
> 
>   
> 

Re: Combine Text/Lyrics with bass figures

[Urs Liska]

Hi Lukas,

that's great, and I hope you'll stick with me when I try to work that
out into a generally usable (i.e. sufficiently flexible) solution to
lobby with the GMTH ;-)

Am Freitag, den 26.06.2020, 10:07 +0200 schrieb Lukas-Fabian Moser:
> Hi Urs,
> 
> > Hey, that looks promising - I didn't know that.
> > Now I'd only need a way to properly do the vertical alignment
> > against 
> > the baseline of the lowest markup:
> > 
> > \figures {
> >   <6 4 \markup { \circle \number 5 }>
> >   <3+ \markup { \circle \number 6 }>
> > }
> 
> This might be achieved using an inversed stacking direction. 

Great.

> Harm's 
> figure reversal function can then be used to enable the user to
> still 
> enter bass figures in the "usual" way.
> 
> With a bit of syntactic sugar, this might look as below.

I've started working on that, see below ...

> 
> Problems so far:
> 
> 1) The figures are still down-aligned. This might be remedied for 
> instance by defining a "maximal" number of figures for which to
> leave 
> space and inserting placeholders. (This reminds me of one of my 
> long-time wishes, namely to have a dedicated "empty" figure for use
> in 
> FiguredBass, which is sometimes needed to leave space for figures
> that 
> are added later in a chord. I once patched my LilyPond to allow for 
> this, but this was an ugly hack involving transparent figures...)

I have *not* started working on this yet. I don't find transparent
markups that offensive. It's a commonplace approach also for achieving
consistent baselines for strings without as/descenders.

However, what we *actually* want is a common number of items *per
system*, not for the whole score. What if we determine  maximum number
of entries of 3 and have many systems only use one - that would make
for ugly whitespace all over the place.

The only remedy I can see right now would be to deal with this in an
after-line-breaking stencil. From there we could iterate over the whole
system and check the maximum number of actually used layers. The result
should be cached so this process is done only once per system.
However, this won't always work because the context may not have been
pushed sufficiently far down in situations like the attached example.

> 
> 2) The "get-current-duration" function is simply awful: I didn't
> know 
> how to find out which duration the parser would assign to a 
> duration-less note/bass figure, so I just let it create a note and
> see 
> what its duration becomes. There must be a decent way to achieve
> this. 
> (I need to give the bassStufe-function a duration because otherwise
> it 
> does not work with figure \none.)

I've made a number of improvements to your code:

1)
reverseFigures creates a new music expression, from which you later
retrieve the 'elements, which is unnecessary. (I renamed it to parse-
signature

2)
The figures do have their durations included, so we can retrieve them
*here* and reuse that information later when generating the
BassFigureEvent for the bass step markup.

2a)
Instead of \none I rewrote \scaledeg to accept either a figure
signature or a duration. This gives a nice interface where you can just
specify a duration for an empty figure.

Apart from that I've just added a few predicates to make the input more
reliable and have typecheck warnings.

I think this is going into a nice direction!

Best
Urs

\version "2.20.0"

\layout {
  \override BassFigureAlignment.stacking-dir = #UP
}

#(define (parse-signature sig) ; based on \reverseFigures by Harm
   (if
;; sig is either an EventChord (music) or a duration
(ly:music? sig)
(let*
 ((reversed
   (reverse
(map
 (lambda (e)
   (cond ((and
   (eq? #t (ly:music-property e 'bracket-start))
   (eq? #t (ly:music-property e 'bracket-stop)))
  '())
 ((eq? #t (ly:music-property e 'bracket-start))
  (begin
   (ly:music-set-property! e 'bracket-start '())
   (ly:music-set-property! e 'bracket-stop #t)))
 ((eq? #t (ly:music-property e 'bracket-stop))
  (begin
   (ly:music-set-property! e 'bracket-stop '())
   (ly:music-set-property! e 'bracket-start #t
   e)
 (ly:music-property sig 'elements
  (duration (ly:music-property (first reversed) 'duration)))
 (cons duration reversed))
(cons sig '())
))

#(define (scale-degree degree duration)
   (let
((step-markup
  (if (eqv? degree 0)
  (markup #:null)
  (markup #:circle #:small #:number (number->string degree)
(make-musics
 'BassFigureEvent
 'duration
 duration
 'text
 (markup #:with-dimensions '(0 . 1) '(0 . 5) step-markup))
))

#(define (bass-degree? obj)
   "A bass degree is either a number between 1 and 7 or 0 (eqv. to
nothing)!"
   (and (integer? obj) (> 8 obj) (< -1 obj)))

#(define (figure-signature? obj)
   "A figure signature is either an 

Re: Combine Text/Lyrics with bass figures

[Urs Liska]

Hi Jean,
Am Donnerstag, den 25.06.2020, 18:22 +0200 schrieb Jean Abou Samra:
> 
>   
> > Hi all,
> > there's a method of harmonic analysis (»Bassstufen« in German)
> > thatworks by having numbers in a main layer plus option bass
> > figures ontop. There are at least two flavours or this analysis
> > markup: theoriginal one from the 18th century with bare numbers for
> > the basssteps, and at least one modern variant with additional
> > markup. Attachedyou'll find one example.
> > For a proper handling I need to combine this into *one* command
> > (theexample was created with separate Lyrics and BassFigures
> > contexts).
> > Is there a way to add arbitrary markup to bass figures or to add
> > bassfigures to markup (maybe the easier way round)? Of course I
> > know how toadd the music font numbers to a markup, but it would be
> > nice (and lesserror-prone) not having to reimplement LilyPond's
> > bass figuretypesetting.
> > Has anyone done that already? Thoughts?
> > BestUrs
> >   
> 
>   
> 
>   Hi Urs,
> 
> Not exactly sure that's what you're looking for, but
> bass figures
> 
> can contain surprisingly complex expressions, including
> markups.
> 
> 
> 
>   \figures {
> 
> <6 4 \markup { \vspace #1 \circle \number 5 }>

Hey, that looks promising - I didn't know that.Now I'd only need a way
to properly do the vertical alignment against the baseline of the
lowest markup:
\figures {  <6 4 \markup { \circle \number 5 }>  <3+ \markup { \circle
\number 6 }>}
Best
Urs
>   }
> Best,
> 
> Jean
> 
>   
>   
> 

Combine Text/Lyrics with bass figures

[Urs Liska]

Hi all,

there's a method of harmonic analysis (»Bassstufen« in German) that
works by having numbers in a main layer plus option bass figures on
top. There are at least two flavours or this analysis markup: the
original one from the 18th century with bare numbers for the bass
steps, and at least one modern variant with additional markup. Attached
you'll find one example.

For a proper handling I need to combine this into *one* command (the
example was created with separate Lyrics and BassFigures contexts).

Is there a way to add arbitrary markup to bass figures or to add bass
figures to markup (maybe the easier way round)? Of course I know how to
add the music font numbers to a markup, but it would be nice (and less
error-prone) not having to reimplement LilyPond's bass figure
typesetting.

Has anyone done that already? Thoughts?

Best
Urs

Re: Better support for Bravura in LilyPond

[Urs Liska]

Am Donnerstag, den 25.06.2020, 04:37 -0400 schrieb Daniel Benjamin
Miller:
> You're right, it does essentially replicate Dorico's style.
> 
> I don't think LilyPond should change what its default style is; 

I think what you suggested with this wasn't to change the defaults. But
I really like the idea of having choice. It is good that out-of-the-box 
scores are immediately recognizble (although I have the impression that
the *text* font is even more notable in this respect).

But people shouldn't be limited to that "personality" but have the
option to tweak the output to what they like. Generally speaking scores
shouldn't necessarily have the personality of the program but that of
the author/editor/publisher. Abraham Lee's efforts in making
alternative fonts properly available at all, and his collection of
fonts, was a huge step forware IMHO, and I really hope that Owen Lamb's
work of making LilyPond SMuFL-compliant will make that possibility of
choice even more fundmental.

Urs

> I don't 
> like the Emmentaler font myself (Simon Tatham put it best, though I 
> actually feel the same about Gonville: 
> https://www.chiark.greenend.org.uk/~sgtatham/gonville/ - "I designed
> it 
> because Lilypond's standard font (Feta) was not to my taste: I found
> it 
> to be (variously) over-ornate, strangely proportioned, and subtly
> not 
> like the music I was used to reading. Music set in Feta looks to me
> like 
> strangely stylised music; music set in Gonville just looks to me
> like 
> music, so I can read it without being distracted so much.)
> 
> But I also think that we should not try to change the defaults. But
> I 
> also think that almost nobody actually cares much about music 
> typography, really: only LilyPond and Dorico have really put effort
> into 
> creating their default fonts and appearances; MuseScore borrows its 
> fonts from both, and Finale and Sibelius' fonts are really clearly
> not 
> that seriously taken.
> 
> LilyPond is not static, but it should not really change in terms of
> its 
> defaults either. Much like TeX, we should not change the default
> fonts, 
> in my opinion (though of course Emmentaler and Feta are being
> expanded 
> as new features are added to LilyPond, and slight tweaks and 
> improvements are all well and good).
> 
> On 6/25/20 3:06 AM, Martin Tarenskeen wrote:
> > 
> > On Thu, 25 Jun 2020, Daniel Benjamin Miller wrote:
> > 
> > > I'd like to share something: 
> > > https://github.com/dbenjaminmiller/bmusicfonts
> > > I personally prefer the Bravura design to Emmentaler/Feta, and 
> > > there'd been
> > 
> > Thanks for this, I am going to try it for sure. I like Dorico's 
> > output, and this will sort of give a similar result for LilyPond if
> > I 
> > understand correctly?
> > 
> > Which leads to a more philosophic question. Do we want LilyPond
> > scores 
> > to have an immediately recognizable "personality" or are we slowly 
> > moving to a situation where everyone, including LilyPond, is trying
> > to 
> > look the same (when using default settings), and it will be hard
> > to 
> > see if a score was typeset in LilyPond, MuseScore, Dorico, Finale,
> > or 
> > Sibelius?
> > 
> > I hope LilyPond will always try to keep a distinct personality in
> > the 
> > default output, which is not a static thing but can be discussed
> > in 
> > the Lilypond user and developers community, changed, and improved 
> > continuously. But let not all our efforts go to looking as much as 
> > possible like "the other ones".
> > 
> > I know LilyPond is (almost) flexible and tweakable enough to have
> > it 
> > all, but what I am talking about is the default output.
> > 

Re: Indicating duration with lines

[Urs Liska]

Hi Harm,

thank you very much! This indeed is helping me to achieve what I'm
right now needing (see attached example).

For now I needed quite some manual tweaking of the right hand lenghts,
and if I'll need something like this more, I'd probably try to wrap it
in a way that a voice will have that attached to all notes
automatically. But I won't touch it anymore until tomorrow evening.

Best
Urs

Am Montag, den 22.06.2020, 22:58 +0200 schrieb Thomas Morley:
> Am Mo., 22. Juni 2020 um 11:46 Uhr schrieb Urs Liska <
> li...@openlilylib.org>:
> > I really don't seem to find useful search terms :-(
> > 
> > I'm trying to achieve horizontal lines "extending" the note head to
> > indicate its duration. The attachement is done by abusing
> > \glissando.
> > I'd be (mostly) happy with the appearance, but glissandi work only
> > in
> > place where a tie is. When there's a different note or a rest after
> > the
> > original note it doesn't.
> > 
> > What would be a term for this notation element, and is there a
> > ready-
> > made solution, e.g. in the LSR?
> > 
> > Thanks
> > Urs
> 
> Hi Urs,
> 
> how about attached?
> There are some features I needed for typesetting some avantgarde
> piece, not sure whether they are of use for your case, though.
> There are two functions defined durLine and durationLine, both have
> pros and cons ...
> 
> Cheers,
>   Harm

Re: Indicating duration with lines

[Urs Liska]

Am Montag, den 22.06.2020, 15:56 +0200 schrieb Pierre Perol-Schneider:
> Is there a maximum length value? Any tiny example?

The attached is what I did with \glissandoThe main problem with that
example is that it's hard to discern single notes from those with
(invisible) rests afterwards.
Best
Urs
> Cheers,
> Pierre
> 
> Le lun. 22 juin 2020 à 15:47, Urs Liska  a
> écrit :
> > Hi Pierre,
> > thank you for the nice suggestion. Do you (or anybody else) have an
> > idea how to make the length automatic? This looks nice, but of
> > course when the horizontal spacing of the music changes things will
> > go wrong.
> > Best
> > Urs
> > Am Montag, den 22.06.2020, 13:12 +0200 schrieb Pierre Perol-
> > Schneider:
> > > Hi Urs,
> > > How about:
> > > 
> > > \version "2.20.0"
> > > 
> > > ext =
> > > #(define-music-function (long) (number?)
> > >#{
> > >  \once\override NoteHead.stencil = 
> > >#(lambda (grob) 
> > >   (grob-interpret-markup grob 
> > >  (markup #:concat
> > > (#:musicglyph "noteheads.s2" #:hspace -0.85 
> > >  (#:override (cons (quote filled) #t)
> > >   (#:path 0 
> > > `((moveto 0 .543)
> > >   (rlineto ,long 0)
> > >   (rlineto -.4 -1.086)
> > >   (rlineto ,(* long -1) 0)
> > >   (closepath
> > >  #:hspace -0.85 #:musicglyph "noteheads.s2" 
> > >#})
> > > 
> > > %% Test:
> > > \layout {
> > >   \context {
> > > \Voice
> > > \omit Stem
> > >   }
> > > }
> > > 
> > > \fixed c' {
> > >   \ext #5 ais4 \ext #4 4 \ext #2 4 \ext #2 4 
> > > }
> > > 
> > > HTH, cheers,
> > > Pierre
> > > 
> > > Le lun. 22 juin 2020 à 11:47, Urs Liska  a
> > > écrit :
> > > > I really don't seem to find useful search terms :-(
> > > > 
> > > > 
> > > > 
> > > > I'm trying to achieve horizontal lines "extending" the note
> > > > head to
> > > > 
> > > > indicate its duration. The attachement is done by abusing
> > > > \glissando.
> > > > 
> > > > I'd be (mostly) happy with the appearance, but glissandi work
> > > > only in
> > > > 
> > > > place where a tie is. When there's a different note or a rest
> > > > after the
> > > > 
> > > > original note it doesn't.
> > > > 
> > > > 
> > > > 
> > > > What would be a term for this notation element, and is there a
> > > > ready-
> > > > 
> > > > made solution, e.g. in the LSR?
> > > > 
> > > > 
> > > > 
> > > > Thanks
> > > > 
> > > > Urs
> > > > 

Re: Indicating duration with lines

[Urs Liska]

Am Montag, den 22.06.2020, 16:00 +0200 schrieb Urs Liska:
Am Montag, den 22.06.2020, 15:56 +0200 schrieb Pierre Perol-Schneider:
Is there a maximum length value? Any tiny example?

The attached is what I did with \glissando
The main problem with that example is that it's hard to discern single notes 
from those with (invisible) rests afterwards.



Ehm, sorry for hitting "send" too fast. What I would want to do is
replace the sequences of equal pitches with one long line each.

> Best
> Urs
> > Cheers,
> > Pierre
> > 
> > Le lun. 22 juin 2020 à 15:47, Urs Liska  a
> > écrit :
> > > Hi Pierre,
> > > thank you for the nice suggestion. Do you (or anybody else) have
> > > an idea how to make the length automatic? This looks nice, but of
> > > course when the horizontal spacing of the music changes things
> > > will go wrong.
> > > Best
> > > Urs
> > > Am Montag, den 22.06.2020, 13:12 +0200 schrieb Pierre Perol-
> > > Schneider:
> > > > Hi Urs,
> > > > How about:
> > > > 
> > > > \version "2.20.0"
> > > > 
> > > > ext =
> > > > #(define-music-function (long) (number?)
> > > >#{
> > > >  \once\override NoteHead.stencil = 
> > > >#(lambda (grob) 
> > > >   (grob-interpret-markup grob 
> > > >  (markup #:concat
> > > > (#:musicglyph "noteheads.s2" #:hspace -0.85 
> > > >  (#:override (cons (quote filled) #t)
> > > >   (#:path 0 
> > > > `((moveto 0 .543)
> > > >   (rlineto ,long 0)
> > > >   (rlineto -.4 -1.086)
> > > >   (rlineto ,(* long -1) 0)
> > > >   (closepath
> > > >  #:hspace -0.85 #:musicglyph "noteheads.s2" 
> > > >#})
> > > > 
> > > > %% Test:
> > > > \layout {
> > > >   \context {
> > > > \Voice
> > > > \omit Stem
> > > >   }
> > > > }
> > > > 
> > > > \fixed c' {
> > > >   \ext #5 ais4 \ext #4 4 \ext #2 4 \ext #2 4 
> > > > }
> > > > 
> > > > HTH, cheers,
> > > > Pierre
> > > > 
> > > > Le lun. 22 juin 2020 à 11:47, Urs Liska 
> > > > a écrit :
> > > > > I really don't seem to find useful search terms :-(
> > > > > 
> > > > > 
> > > > > 
> > > > > I'm trying to achieve horizontal lines "extending" the note
> > > > > head to
> > > > > 
> > > > > indicate its duration. The attachement is done by abusing
> > > > > \glissando.
> > > > > 
> > > > > I'd be (mostly) happy with the appearance, but glissandi work
> > > > > only in
> > > > > 
> > > > > place where a tie is. When there's a different note or a rest
> > > > > after the
> > > > > 
> > > > > original note it doesn't.
> > > > > 
> > > > > 
> > > > > 
> > > > > What would be a term for this notation element, and is there
> > > > > a ready-
> > > > > 
> > > > > made solution, e.g. in the LSR?
> > > > > 
> > > > > 
> > > > > 
> > > > > Thanks
> > > > > 
> > > > > Urs
> > > > > 
> 
> 

Re: Indicating duration with lines

[Urs Liska]

Hi Pierre,
thank you for the nice suggestion. Do you (or anybody else) have an
idea how to make the length automatic? This looks nice, but of course
when the horizontal spacing of the music changes things will go wrong.
Best
Urs
Am Montag, den 22.06.2020, 13:12 +0200 schrieb Pierre Perol-Schneider:
> Hi Urs,
> How about:
> 
> \version "2.20.0"
> 
> ext =
> #(define-music-function (long) (number?)
>#{
>  \once\override NoteHead.stencil = 
>#(lambda (grob) 
>   (grob-interpret-markup grob 
>  (markup #:concat
> (#:musicglyph "noteheads.s2" #:hspace -0.85 
>  (#:override (cons (quote filled) #t)
>   (#:path 0 
> `((moveto 0 .543)
>   (rlineto ,long 0)
>   (rlineto -.4 -1.086)
>   (rlineto ,(* long -1) 0)
>   (closepath
>  #:hspace -0.85 #:musicglyph "noteheads.s2" 
>#})
> 
> %% Test:
> \layout {
>   \context {
> \Voice
> \omit Stem
>   }
> }
> 
> \fixed c' {
>   \ext #5 ais4 \ext #4 4 \ext #2 4 \ext #2 4 
> }
> 
> HTH, cheers,
> Pierre
> 
> Le lun. 22 juin 2020 à 11:47, Urs Liska  a
> écrit :
> > I really don't seem to find useful search terms :-(
> > 
> > 
> > 
> > I'm trying to achieve horizontal lines "extending" the note head to
> > 
> > indicate its duration. The attachement is done by abusing
> > \glissando.
> > 
> > I'd be (mostly) happy with the appearance, but glissandi work only
> > in
> > 
> > place where a tie is. When there's a different note or a rest after
> > the
> > 
> > original note it doesn't.
> > 
> > 
> > 
> > What would be a term for this notation element, and is there a
> > ready-
> > 
> > made solution, e.g. in the LSR?
> > 
> > 
> > 
> > Thanks
> > 
> > Urs
> > 

Indicating duration with lines

[Urs Liska]

I really don't seem to find useful search terms :-(

I'm trying to achieve horizontal lines "extending" the note head to
indicate its duration. The attachement is done by abusing \glissando.
I'd be (mostly) happy with the appearance, but glissandi work only in
place where a tie is. When there's a different note or a rest after the
original note it doesn't.

What would be a term for this notation element, and is there a ready-
made solution, e.g. in the LSR?

Thanks
Urs

Re: Harmonic reduction

[Urs Liska]

Hi Lukas,

Am Sonntag, den 21.06.2020, 19:10 +0200 schrieb Lukas-Fabian Moser:
> Hi Urs,
> 
> > The use case is the following: The example I attached shows a few
> > ways
> > to visualize the harmonic structure of (dodecaphonic) polyphonic
> > music.
> > But I would like to have this as a kind of live preview when
> > working
> > out counterpoints (with students). Therefore I don't need an
> > analysis
> > toolkit like Humdrum. Although: There actually might be tools to
> > analyze the resulting MIDI files from a LilyPond compilation, and
> > it
> > would be possible to write a script that takes the Humdrum output
> > to
> > generate some LilyPond code that is then compiled. Hm, while
> > writing
> > the previous sentence this looks like an intriguing idea, but it's
> > way
> > too short for being able to use that on Wednesday :-(
> 
> But I think it would be desirable to avoid using MIDI as an
> intermediate 
> step at all costs: For, as far as I know, MIDI only knows
> "chromatic" 
> pitches and has no way of distinguishing enharmonic equivalents.

Oh, that's a good point. Probably a major reason why the "keyscapes" I
created look only partially convincing. I'll redo these after
converting the Midi files to Humdrum (which seems reasonably possible
with two very short songs).

> 
> This might be sort-of acceptable for dodecaphonic music (I tend to 
> disagree: Dodecaphonic music has always been written by composers
> with a 
> strong background in classical diatonic theory, and it should not be 
> taken for granted that they just tossed a coin when deciding on the 
> enharmonic spelling of a given pitch), but it's obviously a no-go
> for 
> pieces governed by classical tonality.
> 
> 
> Moreover, your initial example manifestly exhibits what is known as
> the 
> "segmentation problem" in many flavours of musical analysis: Which
> notes 
> are to be grouped together in ordner to obtain a meaningful analysis
> of 
> harmony/voice leading/etc.?
> 
> For instance, it's quite hard to (algorithmically) decide which notes
> in 
> the attached Chopin are to be considered when analysing "the
> harmonic 
> progression" of the piece - except of course if you claim
> (erroneously, 
> I think) that "harmony" only lives in the lower staff here.
> 
> As another example, there's the famous bar in the first prelude of
> the 
> Well-Tempered Clavier (see attachmend) where, for the first (and 
> basically only) time in the piece, squashing all the pitches in a
> given 
> bar together does not yield a meaningful chord. (And in fact, there
> is 
> some debate on which pitch should be considered as part of the 
> underlying chord here: Many people say b, but there a strong reasons
> to 
> instead consider the c as a chord tone instead, hence regarding the 
> harmony as a 43 instead of a 642.)
> 
> Also, Schönberg gave (in his Harmonielehre) funny examples of 
> "impossible" sonorities taken from Bach's Motetten by just stopping
> the 
> music at the right (or wrong?) time, together with equally funny
> jibes 
> against the "aestheticians", or from Mozart's symphonies (also
> attached).
> 
> 
> Maybe all I'm saying here is that any such automated tool for
> "musical 
> analysis" would have to be highly configurable.

Very valid points, indeed. However, it seems I'm persistently not
making myself clear.
I'm not looking for musical interpretation/analysis, just for a
visualization of what is sounding at the same time, to get a visual
idea about the harmonies resulting from polyphonic settings.

Urs

> 
> Lukas
> 

Re: Harmonic reduction

[Urs Liska]

Hi Kevin,

thank you for this recommendation. Actually I will talk about Humdrum
(a little bit) in a presentation on Wednesday ;-) but it is definitely
not what I'm looking for here. (BTW it (at least some of the tools?)
also consumes MIDI files, so there's a direct path from LilyPond to
Humdrum.

The use case is the following: The example I attached shows a few ways
to visualize the harmonic structure of (dodecaphonic) polyphonic music.
But I would like to have this as a kind of live preview when working
out counterpoints (with students). Therefore I don't need an analysis
toolkit like Humdrum. Although: There actually might be tools to
analyze the resulting MIDI files from a LilyPond compilation, and it
would be possible to write a script that takes the Humdrum output to
generate some LilyPond code that is then compiled. Hm, while writing
the previous sentence this looks like an intriguing idea, but it's way
too short for being able to use that on Wednesday :-(

BestUrs

Am Sonntag, den 21.06.2020, 09:46 +0100 schrieb Kevin Barry:
> Hi Urs,
> 
> I'm not aware of any such tools for LilyPond, but there is a format,
> "**kern", that is used in music analysis and research. I don't know
> if
> it can do what you want, but it is designed to be friendly to any
> tools
> that can process plain text. You can find out more about it here:
> https://www.humdrum.org/index.html
> There is a whole toolkit for analysing files in that format.
> 
> Kevin
> 
> On Tue, Jun 16, 2020 at 11:42:01AM +0200, Urs Liska wrote:
> > Hi all,
> > 
> > did anyone so far create a tool for an automatic harmonic reduction
> > of
> > polyphonic music?
> > 
> > Attached you'll find one way how that could look like done
> > manually.
> > 
> > The task would be to
> > 
> >  * read an arbitrary number of voices (music expressions)
> >  * determine the moments where "something" happens (note/rest)
> >  * calculate the chords for each of these steps
> >  * construct the corresponding music
> > * a) at the absolute pitches
> > * b) squashed into one of two ranges (all notes within one
> > octave /
> >   "closest" setting but in order (this is not in the example)) 
> > 
> > I'm not fixated in *exactly* the output of the example but would
> > like
> > to know if there's something existing in that direction.
> > 
> > Thanks
> > Urs
> > \version "2.20.0"
> > 
> > %\include "oll-core/package.ily"
> > %\loadPackage notation-fonts
> > %\useNotationFont \with {
> > %  extensions = ##t
> > %} arnold
> > 
> > \paper {
> >   indent = 3\cm
> >   system-count = 1
> > }
> > 
> > \layout {
> >   \context {
> > \Score
> > \accidentalStyle dodecaphonic
> > \override InstrumentName.font-size = #-1
> >   }
> > }
> > 
> > voice = \relative {
> >   r4 r8 cis'4 d c8
> > 
> >   |
> > 
> >   c ( fis4. ~ fis8 ) es es f
> > }
> > 
> > pianoUp = \relative {
> >   \clef bass
> >   r8 b, ( a'4 -> ) r8 b, ( g'4 -> )
> > 
> >   |
> > 
> >   r8 g ( as,4 g'16-. ) r a,4 ( gis'8 )
> > }
> > 
> > pianoDown = \relative {
> >   \clef bass
> >   r8 g,4 ( gis,16-. ) r r8 a4 ( gis'16-. ) r
> > 
> >   |
> > 
> >   r8 a,-. [ a
> >   %-\arnoldStrongbeat
> >   ( b'16 )]  r r4 b
> > }
> > 
> > combOneUp = \relative {
> >   r4 r8 cis'16 ~ cis ~ cis8 d8 ~ d c16 ~ c
> > 
> >   |
> > 
> >   c8 fis ~ fis ~ fis16 ~ fis ~ fis ~ fis es8 ~ es f
> > }
> > 
> > combOneDown = \relative {
> >   \clef bass
> >   r8 8  16 a'' r8 8 ~  ~
> > 16 ~ g'
> > 
> >   |
> > 
> >   r8 8  ~ 16 ~ as g' r a,8 ~  ~  > gis'>
> > }
> > 
> > combTwo = \relative {
> >   r8 8 ~  ^~ 16 ~  ~ cis8
> >   8 ~  ~ 16 ~ 
> > 
> >   |
> > 
> >   c8  ~  16 ~  ~
> >~ fis 8 ~  ~ 
> > }
> > 
> > rhythm = \relative {
> >   r8 d'' d d16 d d8 d d d16 d
> > 
> >   |
> > 
> >   d8 d d d16 d d d d8 d d
> > }
> > 
> > \score {
> >   <<
> > \new Staff \with {
> >   instrumentName = "Voice, orig."
> > } \voice
> > \new PianoStaff \with {
> >   instrumentName = "Piano, orig."
> > } <<
> >   \new Staff \pianoUp
> >   \new Staff \pianoDown
> > >>
> > \new PianoStaff \with {
> >   instrumentName = "Comb. 1"
> >   \omit Stem
> >   \omit Flag
> >   \omit Beam
> >   \omit Rest
> >   \omit Dots
> > }
> > <<
> >   \new Staff \combOneUp
> >   \new Staff \combOneDown
> > >>
> > 
> > \new Staff \with {
> >\override StaffSymbol.line-count = 1
> >\autoBeamOff
> >\omit Clef
> >\omit NoteHead
> >\omit Accidental
> > } \rhythm
> > \new Staff \with {
> >   instrumentName = "Comb. squashed"
> >   \omit Stem
> >   \omit Flag
> >   \omit Beam
> >   \omit Rest
> >   \omit Dots
> > } \combTwo
> >   >>
> > }
> > 
> > 
> > 
> 
> 

Harmonic reduction

[Urs Liska]

Hi all,

did anyone so far create a tool for an automatic harmonic reduction of
polyphonic music?

Attached you'll find one way how that could look like done manually.

The task would be to

 * read an arbitrary number of voices (music expressions)
 * determine the moments where "something" happens (note/rest)
 * calculate the chords for each of these steps
 * construct the corresponding music
* a) at the absolute pitches
* b) squashed into one of two ranges (all notes within one octave /
  "closest" setting but in order (this is not in the example)) 

I'm not fixated in *exactly* the output of the example but would like
to know if there's something existing in that direction.

Thanks
Urs
\version "2.20.0"

%\include "oll-core/package.ily"
%\loadPackage notation-fonts
%\useNotationFont \with {
%  extensions = ##t
%} arnold

\paper {
  indent = 3\cm
  system-count = 1
}

\layout {
  \context {
\Score
\accidentalStyle dodecaphonic
\override InstrumentName.font-size = #-1
  }
}

voice = \relative {
  r4 r8 cis'4 d c8

  |

  c ( fis4. ~ fis8 ) es es f
}

pianoUp = \relative {
  \clef bass
  r8 b, ( a'4 -> ) r8 b, ( g'4 -> )

  |

  r8 g ( as,4 g'16-. ) r a,4 ( gis'8 )
}

pianoDown = \relative {
  \clef bass
  r8 g,4 ( gis,16-. ) r r8 a4 ( gis'16-. ) r

  |

  r8 a,-. [ a
  %-\arnoldStrongbeat
  ( b'16 )]  r r4 b
}

combOneUp = \relative {
  r4 r8 cis'16 ~ cis ~ cis8 d8 ~ d c16 ~ c

  |

  c8 fis ~ fis ~ fis16 ~ fis ~ fis ~ fis es8 ~ es f
}

combOneDown = \relative {
  \clef bass
  r8 8  16 a'' r8 8 ~  ~ 16 ~ g'

  |

  r8 8  ~ 16 ~ as g' r a,8 ~  ~ 
}

combTwo = \relative {
  r8 8 ~  ^~ 16 ~  ~ cis8
  8 ~  ~ 16 ~ 

  |

  c8  ~  16 ~  ~
   ~ fis 8 ~  ~ 
}

rhythm = \relative {
  r8 d'' d d16 d d8 d d d16 d

  |

  d8 d d d16 d d d d8 d d
}

\score {
  <<
\new Staff \with {
  instrumentName = "Voice, orig."
} \voice
\new PianoStaff \with {
  instrumentName = "Piano, orig."
} <<
  \new Staff \pianoUp
  \new Staff \pianoDown
>>
\new PianoStaff \with {
  instrumentName = "Comb. 1"
  \omit Stem
  \omit Flag
  \omit Beam
  \omit Rest
  \omit Dots
}
<<
  \new Staff \combOneUp
  \new Staff \combOneDown
>>

\new Staff \with {
   \override StaffSymbol.line-count = 1
   \autoBeamOff
   \omit Clef
   \omit NoteHead
   \omit Accidental
} \rhythm
\new Staff \with {
  instrumentName = "Comb. squashed"
  \omit Stem
  \omit Flag
  \omit Beam
  \omit Rest
  \omit Dots
} \combTwo
  >>
}





excerpt.pdf
Description: Adobe PDF document

Re: PDF not shown in Frescobaldi

[Urs Liska]

Am Dienstag, den 16.06.2020, 10:31 +0200 schrieb Noeck:
> > Well, the *package* is not by Wilbert, which may be the problem.
> > The
> > issue is that the package has to be built against exactly the
> > correct
> > Qt/SIP version used in the OS and Frescobaldi. It seems that this
> > is an
> > issue that occasionally pops up in distributions.
> 
> Well not the package, but the code. I looked at the github page¹ and
> it
> seems that the Ubuntu package (0.24.2 from 2015) is very old compared
> to
> recent releases on github (0.75.0 from 2019). Should I use 0.75.0
> instead?

That sounds very reasonable, given the massive Qt changes we had since
2015. As a service to everyone you might get in touch with the Ubuntu
package maintainers (both python3-poppler-qt and frescobaldi, if
they're different), file a bug and tell them that the packages must be
kept in sync.

Thanks
Urs

> 
> ¹: https://github.com/frescobaldi/python-poppler-qt5/releases
> 
> I will try and follow your building-python-poppler-qt5-from-source
> link
> later today.
> 
> Cheers,
> Joram

Re: PDF not shown in Frescobaldi

[Urs Liska]

Am Dienstag, den 16.06.2020, 10:23 +0200 schrieb Noeck:
> 
> Am 16.06.20 um 10:06 schrieb Urs Liska:
> > This may well be true, but the traceback looks like this one:
> > https://github.com/frescobaldi/frescobaldi/wiki/Run-Frescobaldi-3-on-Linux#workaround-building-python-poppler-qt5-from-source
> > and
> > https://github.com/frescobaldi/frescobaldi/issues/838
> 
> This explains the missing icon and how to add it to the application
> menu. But for the music view I am still a bit at a loss.
> 
> > I wonder if it's still possible today to have that problem with
> > Linux
> > packages. What distribution/desktop do you use exactly?
> 
> I use the latest Ubuntu 20.04 LTS with the default Gnome desktop.
> python3-poppler-qt5 is 0.24.2-3build7 (I did not know that this
> package
> is also by Wilbert Berendsen).
> 
> https://packages.ubuntu.com/focal/python3-poppler-qt5

Well, the *package* is not by Wilbert, which may be the problem. The
issue is that the package has to be built against exactly the correct
Qt/SIP version used in the OS and Frescobaldi. It seems that this is an
issue that occasionally pops up in distributions.

Urs

> 
> Cheers,
> Joram

Re: PDF not shown in Frescobaldi

[Urs Liska]

Am Dienstag, den 16.06.2020, 09:58 +0200 schrieb Noeck:
> Hi Urs,
> 
> Am 16.06.20 um 00:37 schrieb Urs Liska:
> 
> > Rhat diesn't seem too plausible, it looks more like a dependency
> > issue.
> 
> I looked at the dependencies of the frescobaldi package and now
> installed python3-poppler-qt5. Now Frescobaldi crashes at startup
> (see
> traceback below).
> 
> > What about the Tools menu? Can you manually open/close an (even
> > empty) Music View from there? If so, what does it look like?
> 
> The music view is there, it is empty (gray). The tools menu looks
> normal
> and I can choose the music view there and also deselect it.

OK, that means "the music view is gone" is not correct. It's that it
can't display anything. Which underlines the suspicion of the poppler
dependency issue.


> The SVG view
> works and shows the document (if I compile it to SVG). The PDF-
> document
> drop down in the symbols tool bar is gray and empty.
> 
> One other piece of information: I get this warning when starting
> frescobaldi in the terminal:
> 
> > Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use
> > QT_QPA_PLATFORM=wayland to run on Wayland anyway.
> 
> And the application has no icon in the Gnome menu. Could it be a
> Wayland
> issue? Using the second variable does not change anything obvious.

This may well be true, but the traceback looks like this one:
https://github.com/frescobaldi/frescobaldi/wiki/Run-Frescobaldi-3-on-Linux#workaround-building-python-poppler-qt5-from-source
and
https://github.com/frescobaldi/frescobaldi/issues/838

I wonder if it's still possible today to have that problem with Linux
packages. What distribution/desktop do you use exactly?

Best
Urs

> 
> Cheers
> Joram
> 
> 
> Here is the traceback with python3-poppler-qt5 installed:
> 
> > Traceback (most recent call last):
> >   File "frescobaldi-3.1.2/frescobaldi_app/plugin.py", line 79, in
> > instance
> > return _instances[cls][obj]
> >   File "/usr/lib/python3.8/weakref.py", line 383, in __getitem__
> > return self.data[ref(key)]
> > KeyError:  > (PanelManager)>
> > 
> > During handling of the above exception, another exception occurred:
> > 
> > Traceback (most recent call last):
> >   File "frescobaldi", line 28, in 
> > main.main() # Parse command line, create
> > windows etc
> >   File "frescobaldi-3.1.2/frescobaldi_app/main.py", line 210, in
> > main
> > win = mainwindow.MainWindow()
> >   File "frescobaldi-3.1.2/frescobaldi_app/mainwindow.py", line 129,
> > in __init__
> > self.createMenus()
> >   File "frescobaldi-3.1.2/frescobaldi_app/mainwindow.py", line
> > 1105, in createMenus
> > menu.createMenus(self)
> >   File "frescobaldi-3.1.2/frescobaldi_app/menu.py", line 61, in
> > createMenus
> > m.addMenu(menu_file(mainwindow))
> >   File "frescobaldi-3.1.2/frescobaldi_app/menu.py", line 95, in
> > menu_file
> > m.addMenu(snippet.menu.TemplateMenu(mainwindow))
> >   File "frescobaldi-3.1.2/frescobaldi_app/snippet/menu.py", line
> > 146, in __init__
> > self.addAction(self.tool().actionCollection.templates_manage)
> >   File "frescobaldi-3.1.2/frescobaldi_app/snippet/menu.py", line
> > 58, in tool
> > return panelmanager.manager(self.mainwindow()).snippettool
> >   File "frescobaldi-3.1.2/frescobaldi_app/panelmanager.py", line
> > 38, in manager
> > return PanelManager.instance(mainwindow)
> >   File "frescobaldi-3.1.2/frescobaldi_app/plugin.py", line 84, in
> > instance
> > result.__init__(obj)
> >   File "frescobaldi-3.1.2/frescobaldi_app/panelmanager.py", line
> > 70, in __init__
> > self.loadPanel("musicview.MusicViewPanel", "viewers")
> >   File "frescobaldi-3.1.2/frescobaldi_app/panelmanager.py", line
> > 107, in loadPanel
> > __import__(module_name)
> >   File "frescobaldi-3.1.2/frescobaldi_app/musicview/__init__.py",
> > line 52, in 
> > import pagedview
> >   File "frescobaldi-3.1.2/frescobaldi_app/pagedview.py", line 36,
> > in 
> > import popplerqt5
> > ValueError: PyCapsule_GetPointer called with incorrect name
> 
> 

Re: PDF not shown in Frescobaldi

[Urs Liska]

Am 15. Juni 2020 23:19:41 MESZ schrieb Noeck :
>> Are you using \bookOutputName / \bookOutputSuffix for controlling the
>> names of the pdf files?
>
>No. The PDF never appears, even with the most basic input like:
>
>\version "2.20.0"
>
>{ a }
>
>I guess, the problem is related to the fact that I did not install
>Frescobaldi properly but just run the Python file. 

Rhat diesn't seem too plausible, it looks more like a dependency issue.

What about the Tools menu? Can you manually open/close an (even empty) Music 
View from there? If so, what does it look like?

Urs


> But starting the
>installed version does not open up Frescobaldi at all...
>
>Joram

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Re: Polymeter, same tempo

[Urs Liska]

Am 14. Juni 2020 22:48:42 MESZ schrieb Stacy Fatemi :
>Hey list,
>
>I have a question about displaying polymeter. I need a staff that's
>playing
>a refrain in 11/4, and under it is a staff playing a melody in 4/4.
>They're
>the same tempo, so after 2.75 measures of the melody there's another
>measure of the refrain, and they keep going in this fashion with the
>barlines not lining up for a while. Is this possible to display in
>Lilypond? 

Definitely!

http://lilypondblog.org/2014/05/independent-meters/

and

http://lilypond.org/doc/v2.21/Documentation/notation/displaying-rhythms.html#polymetric-notation

HTH
Urs

> I've attached a somewhat crude drawing of the idea I have in
>my
>head (the dotted extended barlines are just for visualization). Thank
>you!

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Re: bach chorales

[Urs Liska]

Hi Phil,

Am Donnerstag, den 04.06.2020, 11:52 +0200 schrieb Ph. Hezaine:
> On 6/1/20, Rudi Guggt  wrote:
> 
> > > > There are some mistakes in the titles of the Bach-Chorales. Are
> > > > you
> > > > curious, what I have found?
> > > > 
> > > > #9, #102, #343 and #361: Ermuntre dich, mein schwa_ch_er Geist
> > > > #45 and #370: Kommt her zu mir, spricht Gottes S_o_hn
> > > > #50: old: In allen meine_n_ Taten
> > > > #101: Herr Christ, der einge Gottes-S_o_hn
> > > >  or: Herr Christ, der ein'ge Gott's Sohn
> > > > #148: Danket dem Herrn, heu_t_ und allzeit
> > > > #150: Welt, ade! ich bin dein m_ü_de
> > > > 
> > > > cheers
> > > > Rudi
> 
> Hello Rudi
> 
> I take due note of your proofreading. Really relevant. Thanks.
> I don't know when I will upgrade the sources to 2.21 exactly but
> it's 
> all right!

If you are planning to update this repository I would be happy if you
could coordinate this work with what we have started on Gitlab
recently. We did not set up this repository simply because we wanted to
make your great work more accessible but to actually *build* upon it.

Concretely I want to restructure the code so the voices are
independently available and then build an infrastructure around it to
allow more flexible typesetting, e.g. 

 * choosing between modern and old clefs
 * choose between real score or piano score
 * select voices to be engraved/hidden
 * allow additional analysis layers (harmonic analysis, figured bass,
   others) to be added

This will make it a terrific resource for pedagogical/academic work. I
have been lobbying for LilyPond in the musicological and music theory
communities for quite some time, and one of the main obstacles
(particularly in the latter) is the need to give them something that
can be used immediately (because the horizon of the average music
theory teacher is typically "I do have to provide material to my four
courses tomorrow"). Having a corpus like the Bach chorales readily
available seems like a really great incentive to dangle in front of
their noses. I hope to find the time to write a Frescobaldi extension
for this repertoire, maybe even with an interface for letting students
write their own solutions right into the material.

So far I have not touched the files uploaded in the Gitlab repository
because you had indicated there are some updates available or pending.
But it would be nice to know when it will be suitable to start with
substantial modifications of the input files. Maybe you could apply
your updates directly to that repository?

Best
Urs

> Phil.
> 
> 

Re: Arpeggio by Dieupart

[Urs Liska]

Am Sonntag, den 31.05.2020, 22:31 +0200 schrieb Franz-Rudolf Kuhnen:
> Hi,
> 
> in his "Six Suittes de Clavessin" Dieupart used a specific sign for
> an 
> arpeggio. -> Attachment 
> How can I  do that with Lilypond?

Here is an includable function for slashed beams:

https://github.com/openlilylib/oll-misc/blob/master/custom-elements/slashed-stem/module.ily

with a usage example here:

https://github.com/openlilylib/oll-misc/blob/master/custom-elements/usage/slashed-stem.ly

To get this to work you'd have to "install" openLilyLib along with the
oll-misc package. See https://github.com/openlilylib/oll-core/wiki for
an overview and installation instructions.

HTH
Urs

> 
> Thank You in advanced for Your help
> 
> Regards
> Franz-Rudolf  
> https://www.kuhnen-musik.de
> https://noten.kuhnen-musik.de

Re: GitLab access

[Urs Liska]

Am Mittwoch, den 27.05.2020, 10:02 +0200 schrieb Valentin Villenave:
> On 5/27/20, Aaron Hill  wrote:
> > Apologies for hijacking the thread.
> 
> No apology needed.
> 
> > The link you provided worked for me
> > without needing an account.  What level of access are you talking
> > about?
> >   Is it something a mere mortal like me (i.e. someone who is not
> > currently a collaborator nor contributor) would need?
> 
> Well, you most certainly *are* a contributor judging by the number of
> helpful replies, nifty tricks and brilliant snippets you post each
> week on the list :-)
> The GitLab pages are publicly accessible (and I strongly hope they’ll
> remain so); with a GitLab account I *think* there are a few things
> one
> can do (post comments? open issues? unsure), 

Yes, that's what you can do as a public visitor of a repository on
these platforms.

but being referenced as a
> project member gives you more access, to take part in patch
> reviewing,
> to be assigned some issues and to be more easily CC-ed in various
> discussions.

If as a public member (i.e. with "only" a Gitlab account) you open an
issue or comment on an issue/MR you will automatically be notified
about activity on that issue (if you don't disable this in your account
settings) too. It's also possible to @mention any username, regardless
of their status in a team.

Urs


> I’d be delighted to see you get involved in that sort of
> stuff, but that’s up to you of course!
> 
> Cheers,
> -- V.
> 

Re: Are Lilyponds beams thick enough?

[Urs Liska]

Am Dienstag, den 26.05.2020, 13:18 +0200 schrieb Valentin Petzel:
> Hello other Valentin, hello David, hello Torsten.
> 
> The 0.55ss is taken to mimick the 1958 Bärenreiter edition, although
> I would 
> rather take a slightly thinner Beam with slightly reduced height. And
> it 
> depends strongly on the type of note. Note that an 8th profits quite
> a bit from 
> the just slightly Beam, while the 16th notes look quite good with
> the 
> defaults, but with anything smaller the defaults have to much
> whitespace 
> within.
> 
> I’ve appended a slightly larger example with thickness from .48 to
> .55, and 
> also with .5 and beam length from 85% to 100%.
> 
> In my opinion, .5 looks quite good both for 16ths and for smaller
> values, but 
> for small note values it still has quite too much whitespace (while
> for 16th 
> notes it’s quite beautiful). The closest to the Bärenreiter edition
> would 
> probably be something at 0.5ss with a beam hight of slightly under
> 95%.
> 
> Anyway, no matter if Lilypond’s default is too thin or not, since
> this is one 
> thing that is very dependent on the type of score, we could try to
> find other 
> such things that are not well readable in some cases, and try to
> create 
> multiple sets of sensible defaults for different use cases.

This is something we (especially Kieren MacMillan and I) have long had
on our plate, to be realized as an openLilyLib package. 
https://github.com/openlilylib/stylesheets is what currently is there
in that package, but this doesn't have much to do with what you are
after here.

What we would like to do is to provide an infrastructure where you can
define stylesheets in a presumably hierarchical manner where you can
load styles for example with something like
  \loadStylesheet peters.piano.landscape
or so.

Another package that implements something very close to what we're
discussing here is https://github.com/openlilylib/notation-fonts which
lets you load default stylesheets for supported notation fonts.
See for example 
https://github.com/openlilylib/notation-fonts/blob/master/fonts/haydn-default.ily
which happens to include a setting for beams (0.7 because the Haydn
font really is a special case).

Urs

> 
> @David: I’m not really sure if that is a problem here. Rounding
> should only 
> matter in the sense of rounding to pixels on a device, but here 0.5
> is not 
> much different to 0.48.
> 
> Regards,
> Valentin

Re: bach chorales

[Urs Liska]

I would suggest doing so and making it somewhat more accessible in the
sense to not having each chorale live in a self-contained file. I would
love to see an interface where you can *select* which chorale(s) to
engrave, apply style sheets, choose voices to engrave/hide etc. That
would make a terrific resource for teachers too.

This would also make a very nice case study for an exemplary
Frescobaldi extension. I really can't do that but would surely be
around helping out and/or mentoring such an effort.

Urs

Am Sonntag, den 24.05.2020, 12:02 +0200 schrieb Marc via LilyPond user
discussion:
> I'm not the author (I had it in my archives) The license seems to
> show 
> that it can be placed in a git repository.
> 
> Marc
> 
> Le 24/05/2020 à 11:41, Matt Wallis a écrit :
> > On 24/05/2020 05:05, Andrew Bernard wrote:
> > > Hello Marc,
> > > 
> > > Who are we to thank for this wonderful and useful work? I see the
> > > name
> > > Ph. Hardy in the score with an email. Is he still active?
> > > 
> > > Andrew
> > > 
> > > On Sun, 24 May 2020 at 02:26, Marc via LilyPond user discussion
> > >  wrote:
> > > > Dropbox link
> > > > 
> > > > https://www.dropbox.com/s/slxstuqpxbqojnp/Bach-371-Chorals-sources-ly_midi-3.zip?dl=0
> > > >  
> > > > 
> > > > 
> > > > • Copyleft 2011/01: cette oeuvre est libre, vous pouvez la 
> > > > (photo)copier,
> > > > la diffuser ou la modifier, selon les termes de la Licence Art
> > > > Libre, 
> > > > voir:
> > > > http://www.artlibre.org/licence/lal/ [en, de, es, pt, it]
> > > > Créé avec GNU LilyPond 2.13.51 http://www.LilyPond.org
> > > > par Ph. Hardy. http://superbonus.project.free.fr
> > > > Free Art License
> > 
> > Marc,
> > Many thanks for the link.
> > Am I right to understand from the license that it would be ok to
> > make 
> > these files available on a public git repository (e.g. Gitlab.com)?
> > Matt
> > 
> > 

Re: Suggestion to make sharps and flats persistent

[Urs Liska]

Am 18. Mai 2020 18:33:09 MESZ schrieb Kieren MacMillan 
:
>Hi all,
>
>> This is just a feature request for laziness with resulting
>opaqueness. I think it has been requested several times over the years
>because of other program's bad habits.
>
>I agree with this 100%. That being said…
>
>Are not
>
>\relative f'
>
>and
>
>\fixed c'''
>
>just "feature requests for laziness with resulting opaqueness"?  ;)
>
>More productively: Why couldn’t we add some sugar for those who want
>it, e.g.
>
>\keyed d \major { d f e c d }
>
>would result in
>
>{ d f# e c# d }
>
>??

I think this would be consistent (so a vague +1). But different from the OP's 
request.

>
>We (well… modulo me LOL) don’t get this worked up about how \relative
>makes cut-and-paste a nightmare. Why start now?  ;)

Touché ;-)

Urs
>
>Cheers,
>Kieren.

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Re: Suggestion to make sharps and flats persistent

[Urs Liska]

Am 18. Mai 2020 18:48:04 MESZ schrieb David Kastrup :
>Urs Liska  writes:
>
>> Am Montag, den 18.05.2020, 18:11 +0200 schrieb David Kastrup:
>>> Gianmaria Lari  writes:
>>> 
>>> > I don't know "how much Frescobaldi knows" of the lilypond code the
>>> > user is editing. If it has a logical representation of the source
>>> > code it could be Frescobaldi (and not lilypond) to handle this
>>> > feature and offering to autocorrect, according the key signature
>>> > indicated in the source code, the note you write while you write
>>> > it.  You are in F, you write b and it propose bes.  Maybe with
>>> > different language (never used english for lilypond note input)
>>> > this would be more difficult.
>>> 
>>> As an editing feature, this makes a lot more sense in my book: you
>>> see the effects it has and have the means to correct them
>>> immediately, like with actual graphic input.  But for a batch
>>> processor, this kind of second-thinking is a recipe for trouble, and
>>> the more second-thinking there is, the harder it is to reliably get
>>> results without the corresponding visual feedback.
>>> 
>>
>> I think there are only two reliable (and therefore reasonable)
>> approaches. Either you encode a pitch at what it "is" (a f sharp is
>> always an f sharp) or you encode it at how it is printed (a note in
>> the first staff space of a treble clef is encoded as "f" and will be
>> rendered as an f in c major but as an f sharp in d major. I really
>> dislike this idea but it is done so for example in MEI, also Amadeus'
>> input language works that way, and a power user insisted to me it is
>> superior because it doesn't cause ambiguity but substantially less
>> keystrokes).
>
>It may be superior if you encode a particular graphical output.  But
>LilyPond rather encodes music.  Other outputs are, for example, Midi,
>and coding input in terms of the graphical representation rather than
>the actual music then becomes a problem.  What if the Midi
>interpretation corresponds to a different accidental convention than
>what you imagine your input to be?

Exactly.
Even worse, the argument "encode what you see" makes no sense. You don't see a 
f thst is contextually an f sharp. You see a note head contextualized by a key 
and a clef. And many other conventions if you'd be consequent.

Urs

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Re: Suggestion to make sharps and flats persistent

[Urs Liska]

Am Montag, den 18.05.2020, 18:11 +0200 schrieb David Kastrup:
> Gianmaria Lari  writes:
> 
> > Hello Paul,
> > 
> > 
> > > [...]If I'm writing music in F, then I suggest that I be able to
> > > use *bF*
> > > as a pitch instead of *bf*. The *F* would indicate that all
> > > subsequent *b*s
> > > would be flattened until one is encountered with a different
> > > accidental or
> > > until the end of the current music expression. It should have the
> > > same
> > > scope as \stemUp or similar. [...]
> > > 
> > 
> > I don't know "how much Frescobaldi knows" of the lilypond code the
> > user is
> > editing. If it has a logical representation of the source code it
> > could be
> > Frescobaldi (and not lilypond) to handle this feature and offering
> > to
> > autocorrect, according the key signature indicated in the source
> > code, the
> > note you write while you write it.
> > You are in F, you write b and it propose bes.
> > Maybe with different language (never used english for lilypond note
> > input)
> > this would be more difficult.
> 
> As an editing feature, this makes a lot more sense in my book: you
> see
> the effects it has and have the means to correct them immediately,
> like
> with actual graphic input.  But for a batch processor, this kind of
> second-thinking is a recipe for trouble, and the more second-thinking
> there is, the harder it is to reliably get results without the
> corresponding visual feedback.
> 

I think there are only two reliable (and therefore reasonable)
approaches. Either you encode a pitch at what it "is" (a f sharp is
always an f sharp) or you encode it at how it is printed (a note in the
first staff space of a treble clef is encoded as "f" and will be
rendered as an f in c major but as an f sharp in d major. I really
dislike this idea but it is done so for example in MEI, also Amadeus'
input language works that way, and a power user insisted to me it is
superior because it doesn't cause ambiguity but substantially less
keystrokes).

But having "f" behave depending on what has been encoded before is
begging for disaster. Copy has already been mentioned, but I
think it is already harder to *read* in the input file. This by far
outweighs the saved keystrokes IMHO.

My 2cts
Urs

Re: Identify included files

[Urs Liska]

Am Montag, den 18.05.2020, 10:35 -0500 schrieb David Wright:
> On Fri 15 May 2020 at 12:03:33 (-0400), Fr. Samuel Springuel wrote:
> > > On 5/15/20, Fr. Samuel Springuel  wrote:
> > > > Before I start writing a script to do this, is there an
> > > > existing tool which
> > > > will identify all the `\include` files that a LilyPond file
> > > > depends on?
> > > > Even better, one that will work in a recursive fashion?
> > 
> > I’m hoping for something that doesn’t require actually typesetting
> > the document.  My end goal is a script which will somewhat
> > intelligently determine which files in a project have changed and
> > re-typeset them as needed.  Having to typeset the document in order
> > to determine which files it depends on means I’ve already done the
> > typesetting.  Is there a way to pass that and \set
> > Score.skipTypesetting = ##t at the command line?
> 
> If you follow some simple rules in your source layout, constructing
> such a list might be most straightforward to do in the shell, using
> grep. For example,
> 
> $ grep -e '^[[:space:]]*\\include ' foo-top-level.ly
> 
> will find all the includes in the source, restricting it to the start
> of lines, so that you can avoid false hits from, say, internal
> documentation or test includes.
> 

The include files may live in totally different directories, which are
essentially knows to LilyPond only.

I'm pretty sure that the only two ways to reasonably go forward is to
either invoke LilyPond to produce this list or to use a library that
already knows how LilyPond works. As I mentioned somewhere at the top
of this thread, Frescobaldi knows pretty well how to recurse into the
include files.

I would write a tool in Python that calls python-ly (well, probably
quickly, it's designated successor (
https://github.com/frescobaldi/quickly)) to produce the list of
dependencies and feed that into Make.

Urs

> You would insert the resulting filenames into two lists, files
> visited
> and all files. Iterate on the files list, skipping those visited,
> until the files to visit reaches zero (lists are of equal length).
> 
> One complication is applying the search of libraries in the same
> manner as LP, particularly if you rely on the order of searching.
> Another is if you're using external libraries where you have no
> control over their include format.
> 
> If you're not comfortable with shell programming, obviously it would
> be preferable to use a language like Python or Perl for coding.
> 
> The resulting list could be used for, say, making a tarball of source
> files for distribution, or for driving make to produce PDFs that are
> assembled by, say, TeX programs into final documents.
> 
> Cheers,
> David.
> 

Re: Identify included files

[Urs Liska]

Am Montag, den 18.05.2020, 14:37 +0100 schrieb antlists:
> On 18/05/2020 13:44, David Kastrup wrote:
> > antlists  writes:
> > 
> > > On 15/05/2020 21:17, Fr. Samuel Springuel wrote:
> > > > Now I just need to turn this list into something that can be
> > > > used to
> > > > figure out if the target needs to be recompiled.
> > > 
> > > As Jacques said, "make".
> > > 
> > > At the top of your directory structure you can have a makefile,
> > > and it
> > > just contains a list of all your targets, and the files they
> > > depend
> > > on. Okay, every time you add a new include, you need to update
> > > it,
> > > but...
> > > 
> > > Then when you change something, you just go to your top
> > > directory,
> > > type "make", and watch everything affected by your recent changes
> > > recompile.
> > > 
> > > The really nice thing about it, is it will handle recursive
> > > includes
> > > by itself. Can't remember the syntax, but if an include file
> > > pulls in
> > > other includes, you can define that include file as a target,
> > > which
> > > then flags any other that targets that use it. So each target in
> > > your
> > > makefile only needs to include the includes that it depends
> > > *directly*
> > > upon.
> > 
> > That's not how Makefile dependencies work.  Dependencies track the
> > relation of _output_ files to their _input_.  They do not track the
> > hierarchy of different input files that only refer to each other by
> > name: for the purpose of Make, those are independent and
> > equivalent.
> > But the _output_ file(s) generated from them are dependent on all
> > of the
> > respective input files in use, and tracking those and generating
> > the
> > dependencies was what Fr. Samuel was asking about in the first
> > place.
> > 
> Yup. But he wanted to know "which files do I need to recompile".
> Which 
> is exactly what makefiles do.
> 
> so if trombone.pdf is compiled from trombone.ly, which includes 
> trombone-notes.ly, which includes dynamics.ly, then I know there is
> some 
> sort of syntax which will:
> 
> define trombone-notes.ly as a target, define it as changed if its 
> dependencies change, and say "it doesn't exist as a file that can be 
> created with a command".
> 
> So if dynamics.ly changes, it cascades up and causes trombone.pdf to
> be 
> re-compiled, but this is the important bit - you don't need to 
> *ex*plicitly define trombone.pdf as relying on dynamics.ly
> 
> 
> Just had a slight rethink - which affects things - namely what
> exactly 
> is Fr. Samuel trying to achieve. Does he want a list of dependencies
> as 
> a thing in its own right, or does he want to know which targets need
> to 
> be recompiled as a result of changing a file. Because "make" is all
> he 
> needs if the latter is what he's aiming for. If he really wants the 
> former, then yes he'll need all thse lily functions etc that people
> have 
> pointed him to.

Sounds nice, but how can you tell Make what include files a given .ly
file depends on? Without inside knowledge into the LilyPond way of
recursing into the input files?

Urs

> 
> 
> Cheers,
> Wol
> 

Re: Resources For Learning Scheme?

[Urs Liska]

Am Samstag, den 16.05.2020, 17:24 -0300 schrieb Caio Barros:
> Em sáb., 16 de mai. de 2020 às 03:08, Jacques Peron <
> catac...@hotmail.com> escreveu:
> > This one, by Urs Liska, is specifically about scheme with
> > LilyPond :
> > https://scheme-book.ursliska.de/scheme/expressions.html
> 
> I wasn't aware Urs wrote this book. This is very nice! 

Well, the use of grammatical time is misleading. Instead of "wrote"
this should read "has at one point started working on this WIP resource
but had to move on to other tasks before nearing anything like
completion" ;-)

Urs

Re: Identify included files

[Urs Liska]

Am 15. Mai 2020 03:21:55 MESZ schrieb "Fr. Samuel Springuel" 
:
>Before I start writing a script to do this, is there an existing tool
>which will identify all the `\include` files that a LilyPond file
>depends on?  Even better, one that will work in a recursive fashion?

I know of Frescobaldi and lyluatex that have implemented thus recursive search.

Urs 

>
>✝✝
>Fr. Samuel, OSB
>(R. Padraic Springuel)
>St. Anselm’s Abbey
>4501 South Dakota Ave, NE
>Washington, DC, 20017
>202-269-2300
>(c) 202-853-7036
>
>PAX ☧ ΧΡΙΣΤΟΣ

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Re: Frescobaldi Quick key for Lily button

[Urs Liska]

Am 13. Mai 2020 05:10:55 MESZ schrieb Freeman Gilmore 
:
>On Sun, Dec 29, 2019 at 6:22 PM Urs Liska 
>wrote:
>>
>> Am Sonntag, den 29.12.2019, 10:44 -0500 schrieb Freeman Gilmore:
>> > In Frescobaldi is there a quick key that can be used in place of
>> > the Lily button?
>>
>> There are a number of preset shortcuts to trigger LilyPond
>> compilations:
>>
>> * Ctrl+M
>>   Regular compilation *with* point-and-click
>> * Ctrl+P
>>   "Publish" compilation without point-and-click
>> * Ctrl+Shift+M
>>   Open the custom compilation dialog
>>
>> > And one that will also clear the Music View or better one that
>would
>> > do both?The problem is that the old view may not be updated
>when
>> > you compile something that doe not show an error message.
>>
>> This is intended behaviour since usually you'd want to still see the
>> score when compilation has failed.
>>
>> > I would like a quick way to clear the Music View.
>> >
>>
>> That sounds like a reasonable feature request.
>> Added as https://github.com/frescobaldi/frescobaldi/issues/1235
>
>Has this been added to the new version?
>
>Thank you, ƒg
>>

Unfortunately not. Otherwise the issue would have been closed by now.

Urs

>>
>>
>> Best
>> Urs
>>
>> > Thank you,
>> > ƒg
>>

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Re: GS problem with Lily 2.21.0

[Urs Liska]

Am 18. April 2020 09:01:22 MESZ schrieb Jonas Hahnfeld :
>Am Donnerstag, den 16.04.2020, 19:15 +0100 schrieb Timothy Lanfear:
>> These lines would seem to be relevant showing a mixture of gs
>versions 
>> 9.26 and 9.21,
>> 
>> On 16/04/2020 13:46, Simon Albrecht wrote:
>> > 
>> > warning: No such directory 
>> >
>'/home/simon/lilypond/2.21.0/lilypond/usr/share/ghostscript/9.21/fonts'
>
>> > for GS_FONTPATH
>> > 
>> > warning: No such directory 
>> > '/home/simon/lilypond/2.21.0/lilypond/usr/share/gs/fonts' for
>GS_FONTPATH
>> > 
>> > Prepending 
>> >
>'/home/simon/lilypond/2.21.0/lilypond/usr/share/ghostscript/9.21/Resource'
>
>> > to GS_LIB
>> > 
>> > Setting GS_LIB to 
>> >
>'/home/simon/lilypond/2.21.0/lilypond/usr/share/ghostscript/9.21/Resource'
>> > 
>> > Prepending 
>> >
>'/home/simon/lilypond/2.21.0/lilypond/usr/share/ghostscript/9.21/Resource/Init'
>
>> > to GS_LIB
>> > 
>> > Setting GS_LIB to 
>> >
>'/home/simon/lilypond/2.21.0/lilypond/usr/share/ghostscript/9.21/Resource/Init:/home/simon/lilypond/2.21.0/lilypond/usr/share/ghostscript/9.21/Resource'
>> > 
>> 
>> > Invoking `gs -dSAFER -dDEVICEWIDTHPOINTS=595.28 
>> > -dDEVICEHEIGHTPOINTS=841.89 -dCompatibilityLevel=1.4 -dNOPAUSE
>-dBATCH 
>> > -r1200 -sDEVICE=pdfwrite -dAutoRotatePages=/None -dPrinted=false 
>> > -sOutputFile=bug.pdf -c.setpdfwrite -f/tmp/lilypond-1LrrwN'...
>> > 
>> > gs: Interpreter revision (926) does not match gs_init.ps revision
>(921).
>> > 
>> > 
>> On my machine
>> 
>> /usr/local/lilypond-2.21.0/lilypond/usr/bin/gs --version returns
>9.26, 
>> conflicting with 
>> /usr/local/lilypond-2.21.0/lilypond/usr/share/ghostscript/9.21
>> 
>> I hadn't noticed because I run my distribution's gs not Lilypond's. A
>
>> packaging error somewhere?
>
>I just downloaded 2.20.0 and 2.21.0 and both contain GhostScript in
>version 9.21. You're seeing 9.26 probably because the gs executable is
>linked dynamically and will use the libgs.so.9 it finds first. By
>default this is in /usr/lib/ which comes from your distribution. When
>instead using the wrapper script provided by the installer and put into
>bin/, you will get the correct version because it sets some magic
>environment variables.
>
>So the "correct" way to determine the version is
>LD_LIBRARY_PATH=lilypond/usr/lib/ ./lilypond/usr/bin/gs --version
>which returns 9.21
>
>To address the original problem you should invoke lilypond via the
>wrapper script /usr/local/lilypond-2.21.0/bin/lilypond
>instead of using the the directly binary from
>/usr/local/lilypond-2.21.0/lilypond/usr/bin/lilypond.

Which gets back to my question: how did you invoke it, do you run LilyPond from 
Frescobaldi?

Urs
>
>Regards
>Jonas

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Re: GS problem with Lily 2.21.0

[Urs Liska]

Hi Simon,

Am Donnerstag, den 16.04.2020, 14:46 +0200 schrieb Simon Albrecht:
> Hello everyone,
> 
> I’m having a problem with my newly installed Lilypond versions
> 2.20.0 
> and 2.21.0: Any compilation I start aborts while GS tries writing a
> PDF.

This sure sounds like the familiar issue with an OS version of
Ghostscript not matching that expected by LilyPond.

What LilyPond version did you use, the download from lilypond.org?
Did you run LilyPond from the command line or from Frescobaldi? I have
the impression that Frescobaldi for some reason chokes again with this
problem (although I think I had fixed it in the past), but didn't have
the time to properly investigate.

Best
Urs

> 
> I installed both versions yesterday, and the first tests were 
> successful, before this problem came up. Inbetween I mounted and 
> unmounted an SD card.
> 
> Any clues for how to investigate/proceed? A complete, verbose log is 
> found below.
> 
> Best, Simon
> 
> %%
> 
> Starting lilypond 2.21.0 [bug.ly]...
> 
> Log level set to 287
> 
> Relocation
> 
> LilyPond binary has absolute file name:
> 
> /home/simon/lilypond/2.21.0/lilypond/usr/bin/lilypond
> 
> Setting INSTALLER_PREFIX to
> '/home/simon/lilypond/2.21.0/lilypond/usr'
> 
> Using run-time value for datadir,
> 
> setting it to 
> '/home/simon/lilypond/2.21.0/lilypond/usr/share/lilypond/current'
> 
> Using run-time value for localedir,
> 
> setting it to '/home/simon/lilypond/2.21.0/lilypond/usr/share/locale'
> 
> Using run-time value for relocdir,
> 
> setting it to '/home/simon/lilypond/2.21.0/lilypond/usr/etc/relocate'
> 
> Using relocation config directory 
> '/home/simon/lilypond/2.21.0/lilypond/usr/etc/relocate'
> 
> Relocation file 
> '/home/simon/lilypond/2.21.0/lilypond/usr/etc/relocate/fontconfig.rel
> oc'
> 
> Setting FONTCONFIG_FILE to 
> '/home/simon/lilypond/2.21.0/lilypond/usr/etc/fonts/fonts.conf'
> 
> Setting FONTCONFIG_PATH to 
> '/home/simon/lilypond/2.21.0/lilypond/usr/etc/fonts'
> 
> Relocation file 
> '/home/simon/lilypond/2.21.0/lilypond/usr/etc/relocate/gs.reloc'
> 
> warning: No such directory 
> '/home/simon/lilypond/2.21.0/lilypond/usr/share/ghostscript/9.21/font
> s' 
> for GS_FONTPATH
> 
> warning: No such directory 
> '/home/simon/lilypond/2.21.0/lilypond/usr/share/gs/fonts' for
> GS_FONTPATH
> 
> Prepending 
> '/home/simon/lilypond/2.21.0/lilypond/usr/share/ghostscript/9.21/Reso
> urce' 
> to GS_LIB
> 
> Setting GS_LIB to 
> '/home/simon/lilypond/2.21.0/lilypond/usr/share/ghostscript/9.21/Reso
> urce'
> 
> Prepending 
> '/home/simon/lilypond/2.21.0/lilypond/usr/share/ghostscript/9.21/Reso
> urce/Init' 
> to GS_LIB
> 
> Setting GS_LIB to 
> '/home/simon/lilypond/2.21.0/lilypond/usr/share/ghostscript/9.21/Reso
> urce/Init:/home/simon/lilypond/2.21.0/lilypond/usr/share/ghostscript/
> 9.21/Resource'
> 
> Relocation file 
> '/home/simon/lilypond/2.21.0/lilypond/usr/etc/relocate/guile.reloc'
> 
> Prepending '/home/simon/lilypond/2.21.0/lilypond/usr/share/guile/1.8'
> to 
> GUILE_LOAD_PATH
> 
> Setting GUILE_LOAD_PATH to 
> '/home/simon/lilypond/2.21.0/lilypond/usr/share/guile/1.8'
> 
> Prepending '/home/simon/lilypond/2.21.0/lilypond/usr/bin' to PATH
> 
> Setting PATH to 
> '/home/simon/lilypond/2.21.0/lilypond/usr/bin:/home/simon/bin:/home/s
> imon/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sb
> in:/bin:/usr/games:/usr/local/games:/snap/bin'
> 
> Setting GUILE_MIN_YIELD_1 to '65'
> 
> Setting GUILE_MIN_YIELD_2 to '65'
> 
> Setting GUILE_MIN_YIELD_MALLOC to '65'
> 
> Setting GUILE_INIT_SEGMENT_SIZE_1 to '10485760'
> 
> Setting GUILE_MAX_SEGMENT_SIZE to '104857600'
> 
> Effective prefix: 
> '/home/simon/lilypond/2.21.0/lilypond/usr/share/lilypond/current'
> 
> FONTCONFIG_FILE="/home/simon/lilypond/2.21.0/lilypond/usr/etc/fonts/f
> onts.conf"
> 
> FONTCONFIG_PATH="/home/simon/lilypond/2.21.0/lilypond/usr/etc/fonts"
> 
> GS_LIB="/home/simon/lilypond/2.21.0/lilypond/usr/share/ghostscript/9.
> 21/Resource/Init:/home/simon/lilypond/2.21.0/lilypond/usr/share/ghost
> script/9.21/Resource"
> 
> GUILE_LOAD_PATH="/home/simon/lilypond/2.21.0/lilypond/usr/share/guile
> /1.8"
> 
> PATH="/home/simon/lilypond/2.21.0/lilypond/usr/bin:/home/simon/bin:/h
> ome/simon/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bi
> n:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin"
> 
> []
> 
> Guile 1.8
> 
> [/home/simon/lilypond/2.21.0/lilypond/usr/share/lilypond/current/scm/
> lily-library.scm]
> 
> [/home/simon/lilypond/2.21.0/lilypond/usr/share/lilypond/current/scm/
> output-lib.scm]
> 
> [/home/simon/lilypond/2.21.0/lilypond/usr/share/lilypond/current/scm/
> markup-macros.scm]
> 
> [/home/simon/lilypond/2.21.0/lilypond/usr/share/lilypond/current/scm/
> parser-ly-from-scheme.scm]
> 
> [/home/simon/lilypond/2.21.0/lilypond/usr/share/lilypond/current/scm/
> file-cache.scm]
> 
> [/home/simon/lilypond/2.21.0/lilypond/usr/share/lilypond/current/scm/
> define-event-classes.scm]
> 
> 

Re: how to write music elements

[Urs Liska]

Am Sonntag, den 12.04.2020, 08:45 +0200 schrieb Dario Marrini:
> Sorry I'm still in trouble, because I can't figure out how to write a
> simple note (i.e., a half note) without the staff, just the note on a
> white background; I took a look at feta fonts, but I can't build the
> note attaching the head to the stem (where is the stem?)

You shouldn't be doing that, but you should let LilyPond do the job for
you (this is why you wrote to the LilyPond mailing list, isn't it?).
There are two basic steps to creating an image file for inclusion in
word processors:
1)Make LilyPond output the bare music with something like
\layout {  \context {\Staff\omit StaffSymbol\omit
Clef\omit TimeSignature\omit KeySignature  }}
(maybe I've forgotten stuff here...)
2)Make LilyPond output a cropped image. You can do that in various
ways:
add  \include "lilypond-book-preamble.ly"to your input file.Or use the
-dpreview option on the command line.
HTH
Urs
PS:All of this is assuming that you want to include symbols in a *word
processor*. If using LaTeX is an option you can use the packages
lilyglyphs and lyluatex for better results and workflows.
> any idea will be appreciated
> 
> thanks 
> 
> dario
> 
> Il giorno dom 12 apr 2020 alle ore 01:43 Dario Marrini <
> dario.marr...@gmail.com> ha scritto:
> > I found !
> > 
> > 
> > Il giorno dom 12 apr 2020 alle ore 01:40 Dario Marrini <
> > dario.marr...@gmail.com> ha scritto:
> > > Thank you guys, both links are very useful, mostly the second one
> > > to me, I'm a Linux User.
> > > But how can I write a very short staff 'blank' fragment? no clef,
> > > no time, no notes? just staff only?
> > > 
> > > thank you
> > > 
> > > Il giorno sab 11 apr 2020 alle ore 22:08 Kieren MacMillan <
> > > kie...@kierenmacmillan.info> ha scritto:
> > > > Hi Dario,
> > > > 
> > > > 
> > > > 
> > > > > I'm going to write a little paper with short music elements
> > > > terminology; I need to be able to write single music elements,
> > > > as notes (whole note, half note, quarter note and so on) on
> > > > white field, without staff, the same about clef, time, tempo,
> > > > staff, double staff and so on; I need each single music element
> > > > alone, how can I do that?
> > > > 
> > > > 
> > > > 
> > > > You can do this in Lilypond proper using markup:
> > > > 
> > > > 
> > > > 
> > > > \markup \musicglyph #"noteheads.s0"
> > > > 
> > > > 
> > > > 
> > > > See the full reference at <
> > > > https://lilypond.org/doc/v2.18/Documentation/notation/the-feta-font>
> > > > ;.
> > > > 
> > > > 
> > > > 
> > > > Hope that helps!
> > > > 
> > > > Kieren.

Re: Frescobaldi Sessions

[Urs Liska]

Hi
Am Samstag, den 11.04.2020, 20:42 +0200 schrieb 
sir.teddy.the.fi...@gmail.com:
> Hi all,
> I’m trying to synchronize my Frescobaldi-installation with a
> different device.
> Is there any faster way than exporting and importing every single
> session on its own, like copying a file where all the sessions are
> stored?
>  

Yes.
But it depends on the operating system you are using. Linux and Mac
store the settings in a file while Windows uses the registry.
Urs
> Thanks in advance

Re: Remote Ensemble Playing

[Urs Liska]

Am Mittwoch, den 01.04.2020, 13:27 +0100 schrieb Dr Nicholas Bailey:
> Off topic, so I've not bothered the list with it. But you might be 
> interested...
> 
> https://www.researchgate.net/publication/
> 200806144_Perception_of_onset_asynchronies_Acoustic_Piano_versus_Sync
> hronized_complex_versus_pure_tones
> http://musicstudies.org/wp-content/uploads/2017/01/Parncutt_JIMS_11050202.pdf

Without having read it (sorry, so little time ATM) I think the physical
boundaries of perception are pretty independent from the boundaries of
musical reality. There's very much real musicians can achieve that
sceptics (self-declared science people) would declare physically
impossible. Like some pianists being much better at playing "legato"
than others, or the possibility to differenciate between a 4 over 3
tuplet and the corresponding rhythmic notation.

> 
> I'd be very interested to hear more about your Jitsi project by the
> way! 
> github?

That would be extremely interesting for us too because our work will
very much rely on a jitsi instance (which we fortunately had running
for some time already).

Urs

> 

Re: Remote Ensemble Playing

[Urs Liska]

Am Mittwoch, den 01.04.2020, 11:33 +0200 schrieb Christian Masser:
> Hi!
> I think whether it's easier with only click or with click+MIDI purely
> depends on the player's own stability in terms of intonation and
> rhythm. (And in terms of MIDI accompaniment you have to pay special
> attention to the tuning of the MIDI instrument.)
> 
> Having done a few of this recordings myself I found that for chorales
> or hymn tunes it's easier having a MIDI track because of the many
> small corrections you have to make in tuning depending on the harmony
> you're in while on the other hand it's mostly easier for rhythmically
> difficult pieces to just play along the click.
> 
> But this is all probably very subjective to my own musical approach.

One issue is that in 99% of classical music (with the exception of many
contemporary music ensemble pieces and maybe the Bolero) musicians do
*not* go along with a strict click track. Therefore usually a video of
a conductor will musically be more adequate. Of course having many
musicians perform against that video without hearing others will
usually not result in really synchronized playing.
One possibility might be having one instrument play along with the
conductor video, then have the next musician play along that video
while listening to the first recording and so on. That might work out
to produce a decent recording (with unreasonable amounts of technical
trickery), but I have to second Ralf in saying this is not really
playing together. "Making music together" (but not at the same time)
might capture the idea better ...
Urs

> All the best
> Christian
> 
> PS: Sorry Gianmaria, I accidentally answered to you directly without
> posting to the list.
> 
> 
> Gianmaria Lari  schrieb am Mi., 1. Apr.
> 2020, 11:13:
> > Ciao Urs!
> > 
> > On Wed, 1 Apr 2020 at 09:05, Urs Liska 
> > wrote:
> > > Am Mittwoch, den 01.04.2020, 08:51 +0200 schrieb Gianmaria Lari:
> > > > Off topic but very interesting :)
> > > > Does anyone have any idea how these people is able to do things
> > > > like these?
> > > > > https://youtu.be/Sj4pE_bgRQI
> > > > > https://youtu.be/3eXT60rbBVk
> > > 
> > > I think the Rotterdam Philharmonic information says it all: Most
> > > of the solutions that pop up so far are not "playing together"
> > > but playing separately to a preproduced "click track", whether
> > > this is an actual click track or a video recording of the
> > > conductor. Then every musician plays their part and someone does
> > > the digital post production.
> > 
> > Could be a "click track" a "neutral" recording maybe a midi file
> > temporized according a conductor? So that each player can play
> > "with" the music?
> > 
> > I'm asking this because, of course the orchestral musician are
> > professional, but to play an instrument part without the other
> > instrumental parts and only following a metronome (or a video of
> > the conductor) doesn't look easy.  
> > 
> > Does anyone know if this (temporized midi file) is something that
> > people do? Or they really only watch a click track (a video with
> > the score and the beating metronome)?
> > 
> > Thanks, g.
> > P.S. Hope my english is understandable.

Re: Remote Ensemble Playing

[Urs Liska]

Am Mittwoch, den 01.04.2020, 08:51 +0200 schrieb Gianmaria Lari:
> Off topic but very interesting :)
> Does anyone have any idea how these people is able to do things like
> these?
> > https://youtu.be/Sj4pE_bgRQI
> > https://youtu.be/3eXT60rbBVk

I think the Rotterdam Philharmonic information says it all: Most of the
solutions that pop up so far are not "playing together" but playing
separately to a preproduced "click track", whether this is an actual
click track or a video recording of the conductor. Then every musician
plays their part and someone does the digital post production.
In the Rotterdam recording you hear that the instruments are really
recorded in their actual living rooms (although with professional
equipment and personell normal people wouldn't have at their disposal).
But I'd bet when the choir enters *that* is from an existing recording.
The Ravel is surely done the same way, and I have the impression that
what you actually hear is an existing recording (just listen to the
homogenity of the mix and the acoustics), so what they presumably are
doing is essentially a "music video".
In a way you could consider this as cheating, but OTOH, all the
classical music recording industry is built on similar cheats, and if
you look at the comments on YouTube it does serve a positive social
purpose.
BestUrs
PS: Listening to this and watching in preparation to a video meeting
discussing how the conductors in my music university may go forward in
an "online semester".
> The only information I found is this:
> 
> https://slippedisc.com/2020/03/exclusive-rotterdam-made-that-amazing-beethoven-9th-without-rehearsal/
>  
> =
> []
> SD What technology did you use for recording?
> RP: The video might look ‘easy’ but its not. We used really
> professional hard and software, since we also have to protect the
> level of recording that we put of there Rotterdam Philharmonic
> Orchestra. Besides that we believe that the quality is part of the
> impact a message like this has.
> 
> (We asked Mike for further specifications). Mike adds: In general,
> what we do is we pre-produce a click-track which the musicians play
> to. Keep in mind that you have to think about tuning and intonation.
> Then we put all those videos in sync and work on the sound with
> professional studio software and equipment. []
> =
> 
> What does they mean with "click-track" ?
> 
> Thank you, g.
> 
> 
> 

Re: historical treatises – various questions

[Urs Liska]

Hi Derek,
Am Sonntag, den 29.03.2020, 16:40 +0200 schrieb Derek Remeš:
> Greetings,
> I’m considering making a modern edition/translation of a very large
> historical treatise in lyluatex. 

Good idea :-)
> The first example is attached. As a newbie with Lilypond/Frescobaldi
> I have several questions for which I can’t seem to find answers. How
> can I...
> 
> (1) ...place a time signature in brackets to show that it is
> editorial?
> 

http://lilypond.org/doc/v2.20/Documentation/snippets/staff-notation#staff-notation-time-signature-in-parentheses-_002d-method-3
> (2) ...fix the incipit to omit the C and center the original clef?
> 
> (3) ...start the next example with a new tim sig, key sig, bar
> numbers, instrument names, and indent? Or should I make separate .ly
> files? There would be hundreds...

Definitely separate examples. Ideally you should have some sort of
infrastructure for managing that.I have just done that with the music
examples for Leopold Mozart's violin school (600-700 examples,
depending on the counting). Definitely you should have one file per
example, plus a common LilyPond infrastructure to include from each .ly
file.
Depending on the time frame of your project I might help you. For the
Mozart I created an extension to Frescobaldi managing the repertoire
(see attached screenshot), but I have the strong incentive to
generalize this approach; having a concrete project for that might help
pushing it forward and having a basis for investigating the
generalization.
> (4) …have lilypond label all examples consecutively? Or should
> lyluatex do this at the compilation stage?

I would *suggest* doing that in the LaTeX domain. Not lyluatex but
something else. Depending on what you want it will probably the best
idea to just use figure environments, which give you automatic
numbering and even an automatic list of figures (or my not-yet-finished 
lyluateXMP package that also handles missing or failed scores in a
straightforward fashion.
> (5) …show the page numbers of the original treatise at the top of the
> system: previous page# | next page# ?

Create a music function that you can use like
  \originalPageBreak 12 13
which then will insert *something* at that point in a consistent manner
(including an actual break if at one point you want to have it that
way, e.g. for proof-reading). See 
https://github.com/openlilylib/scholarly/blob/master/usage-examples/diplomatic-line-breaks.ly
and 
https://github.com/openlilylib/scholarly/blob/master/usage-examples/diplomatic-line-breaks.preview.png
for an example.
> Any other suggestions for incorporating large amounts of text and
> numerous complex musical examples (such as in textbooks)?

One very general suggestion: If you are going to use lyluatex you will
use LuaLaTeX, and that gives you pretty much power to use Lua for
purposes of building/composing documents from arbitrarily-formatted
input data.
HTH
Urs
> Many thanks,
> 
> Derek
> 
> 
> 
> 
> 
> Derek Remeš
> derekremes.com
> Dozent für Musiktheorie an der Hochschule Luzern - Musik
> (Lucerne University of Applied Sciences and Arts)
> Editor-in-chief of the journal Music Theory and Analysis
> Doktorand an der Hochschule für Musik Freiburg
> Telefon: +41(0)784223906
> 
> 

Re: Remote Ensemble Playing

[Urs Liska]

Am Sonntag, den 29.03.2020, 11:34 +0100 schrieb Peter Gentry:
> Thanks for the responses. My current conclusion is that there are
> inherent technical issues  that are insurmountable. If there was a
> good solution it would be visible on the web.
>  
> My way forward is to record and distribute various pieces using midi
> or YouTube downloads (if available) so that members can practice and
> be perfect when we can meet up again.

I think that's the proper way to go forward. I'm working on making a
music university "go online" for the spring semester, and of course we
have lots of settings where realtime coordination is/would be a crucial
factor.
My take on this is that it will definitely be possible to have students
learn important things, but it won't necessarily be the same as they
learn usually. It's fair to concentrate on specific topics, maybe
considering them from unusual perspectives.
Best
Urs
>  
>  Keep safe everyone.
>  
>  Regards Peter
>