Re: GSoC 2020 update: (hopefully) final commits made; testing time

[Urs Liska]

Am Montag, den 24.08.2020, 09:06 +0200 schrieb Werner LEMBERG:
> > I've reordered and rebased my code, and it is now up to date with
> > the current master.  I've just published the new branch to GitLab
> as
> > dev/lamb/GSoC-2020-final if you'd like to give it a look.  It's
> only
> > nine commits now, instead of over a hundred, and they're ordered in
> > a way that's hopefully easy to follow.
> 
> Thanks!
> 
> > At the same time, I'll write docs for my work.  I figure I'll make
> > nine documentation commits, one for each code change commit.  (Of
> > course, I may not need one for every commit, but we'll see.)  Does
> > that sound all right?  Would it be better to make yet another
> branch
> > with the documentation integrated into the main commits?
> 
> I don't see any reason to synchronize the documentation with commits;
> it looks like unnecessary work.  Maybe others disagree, but I think
> you should simply add all of the documentation in a single, separate
> commit.
> 

+1

But probably regtests should match the state of their commits. Except
if you can add all regtests at the end.

Urs
> 
> Werner
> 

Re: maintaining lilypond git repository on github

[Urs Liska]

Am Mittwoch, den 19.08.2020, 09:24 +0200 schrieb Werner LEMBERG:
> >>   git remote update
> >>   git push --mirror g...@github.com:lilypond/lilypond.git
> > 
> > Definitely add --prune to "git remote update" to remove branches
> > that ceased to exist on the remote.
> 
> OK, done.
> 
> > In general, I would not run the mirroring from a real working copy
> > of the repository because AFAICT git push --mirror will also push
> > local branches.
> 
> I don't do that.  I have a separate clone for that (created with `git
> clone --mirror`).
> 
> > But it doesn't really matter if everybody is ok with me removing
> > them once I get access.

What's your Github user name?
I can give you access but couldn't find your account.

Urs

> 
> This is fine with me.
> 
> 
>Werner
> 

Re: LilyPond 2.21.5 release

[Urs Liska]

Am Dienstag, den 18.08.2020, 02:44 +0200 schrieb Urs Liska:
> 
> Am 18. August 2020 01:01:20 MESZ schrieb Andrew Bernard <
> andrew.bern...@gmail.com>:
> > Please pardon me for asking this once again... but where does one
> > find 
> > the set of changes just for this release, not that long accumulated
> > list 
> > in the documentation? I have forgotten where this info is.
> 
> I don't know whether this is noted explicitly anywhere, but you can
> list the commits between the previous and the latest tag (can't try
> out the command on my mobile right now)

git log release/2.21.4-1..release/2.21.5-1

should give you a start, or more concisely:

git log --pretty=oneline release/2.21.4-1..release/2.21.5-1

HTH
Urs

> 
> Urs
> > 
> > Andrew
> > 
> > 
> > On 18/08/2020 2:30 am, Shane Brandes wrote:
> > > Looks like a lot of neat new stuff implemented!
> > > 

Re: LilyPond 2.21.5 release

[Urs Liska]

Am 18. August 2020 01:01:20 MESZ schrieb Andrew Bernard 
:
>Please pardon me for asking this once again... but where does one find 
>the set of changes just for this release, not that long accumulated
>list 
>in the documentation? I have forgotten where this info is.

I don't know whether this is noted explicitly anywhere, but you can list the 
commits between the previous and the latest tag (can't try out the command on 
my mobile right now)

Urs
>
>
>Andrew
>
>
>On 18/08/2020 2:30 am, Shane Brandes wrote:
>> Looks like a lot of neat new stuff implemented!
>>

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

Re: GSoC 2020 update: Aug 7

[Urs Liska]

Hi Owen,

it's always a pleasure seeing your project evolve and proceed. I'd like
to throw in a comment, although I'm rather sure it isn't actually
needed.

Am Freitag, den 07.08.2020, 21:49 -0700 schrieb Owen Lamb:
> Hi all!
> 
> ...
>
> --turned out to be a major point of difference between
> LilyPond's and SMuFL's treatment of flags.
> 
> I've slightly modified my general project approach, 
>
> ...
>
> The school year is almost upon us here in AZ, and, as I mentioned at
> the
> beginning of summer, there'll be some overlap with GSoC. I'll be out
> for
> the count for a couple weekdays next week, so I'll pick up Saturday
> to make
> up for it. After that, I expect to be doing more night/weekend hours
> as
> classes start up the following week on the 20th.
> 
> My plan is largely the same as it was last week. If you have any
> questions/concerns, as always, feel free to ask away!

I don't recall reading anything about it but probably you have thought
about it right from the start, so please take this as just a friendly
reminder.

Now that the deadline of the project starts coming into view you should
keep in mind that the priority is to have your work properly tested,
cleaned-up and merged. This is much more important than getting one or
more further features implemented - even if they should be your pet
features or seem crucial.
As far as I can see your work so far has been extremely useful, and it
will remain so even if at the end of GSoC it's not in a state that
every user can use it out-of-the-box.
OTOH if I understood the recent discussion about merging and rebasing
correctly your code itself has not been reviewed at all so far? In that
case you should definitely expect the review process to take longer
than you initially expect... Even without serious issues the review
process for getting anything into LilyPond is somewhat time-consuming.

So I encourage you to plan from the end backwards and don't push the
possibly tedious and boring tasks of finalizing your work too much away
.

Best
Urs

> 
> Thanks,
> Owen

Re: GSoC-2020 update: Jul 31

[Urs Liska]

Am 1. August 2020 23:31:32 MESZ schrieb Jean Abou Samra :
>Hi everyone,
>
>Le 01/08/2020 à 18:19, Urs Liska a écrit :
>> Am 1. August 2020 16:12:24 MESZ schrieb Werner LEMBERG :
>>>>> Another issue: Maybe it makes sense if you try to rebase your 
>>>>> branch from time to time. 
>>>> Really rebase? 
>>> Yes, I favour rebasing over merging since the former causes a 
>>> `prettier' git commit tree.
>>>> This would be a case where "general wisdom" argues against
>modifying 
>>>> pushed commits. Typically you'd rather merge master into your 
>>>> working branch here. 
>>> Well, there's a good reason that gitlab has a big, fat 'rebase' 
>>> button... 
>
>Not sure about the meaning of your message: this button shows up
>because 
>we enabled it as a project-wide setting. To my knowledge, the default 
>and most common strategy is merging.
>
>> Yes, but that is meant to deal with integrating the final result into
>
>> master. Rebasing during work means that Owen's commits don't match 
>> those pulled by others. I don't have a strong opinion here but it 
>> should be an agreed-upon procefure for all.
>
>While I generally prefer merging over rebasing, since we enforce an 
>all-fast-forward policy for merging to master, I think we should rebase
>
>here. My reasoning is that you put in more information when resolving 
>conflicts during a rebase: merging means you unify two diverging 
>histories, thus you get prompted once and for all, but rebasing forces 
>you to resolve conflicts for each intermediary commit. As far as my 
>understanding extends, if Owen merges now, there will still be work
>left 
>for rebasing at the end of the project, part of which will be 
>duplicated. By contrast, rebasing now means less error-prone work in
>the 
>future.

That sounds reasonable.

However, it means everybody should expect commits to change after having looked 
at rhem. So: always pull again (well, that's clear) and never add commits to 
Owen's branch wirhout clarifying the state directly with him.

Urs
>
>Best,
>Jean

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

Re: GSoC-2020 update: Jul 31

[Urs Liska]

Am 1. August 2020 16:12:24 MESZ schrieb Werner LEMBERG :
>>> Another issue: Maybe it makes sense if you try to rebase your
>>> branch from time to time.
>> 
>> Really rebase?
>
>Yes, I favour rebasing over merging since the former causes a
>`prettier' git commit tree.
>
>> This would be a case where "general wisdom" argues against modifying
>> pushed commits.  Typically you'd rather merge master into your
>> working branch here.
>
>Well, there's a good reason that gitlab has a big, fat 'rebase'
>button...

Yes, but that is meant to deal with integrating the final result into master.
Rebasing during work means that Owen's commits don't match those pulled by 
others.

I don't have a strong opinion here but it should be an agreed-upon procefure 
for all.

Urs

>
>
>Werner

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

Re: GSoC-2020 update: Jul 31

[Urs Liska]

Am 1. August 2020 06:59:16 MESZ schrieb Werner LEMBERG :
>
>> In the meantime, I've gotten Bravura glyphs to appear on the page!
>
>Congrats!
>
>A question to commit d092b23276059c77e33cab9428b9a9753b5cd27a: Why do
>you change from the (IMHO preferable) `-` to `_` in the file name?  I
>consider `_` an abomination that is only necessary because `-` is not
>a valid character in identifiers of many programming languages.
>
>Another issue: Maybe it makes sense if you try to rebase your branch
>from time to time.

Really rebase?
This would be a case where "general wisdom" argues against modifying pushed 
commits.
Typically you'd rather merge master into your working branch here.

I can see use in both ways, but I strongly suggest making an explicit decision 
with feedback from those who might occasuonally want to look at your code.

But trying not to let master get too far from your branch is surely a good 
suggestion.

Urs

>
>
>Werner

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

Re: Accidentals' font

[Urs Liska]

Am Freitag, den 10.07.2020, 10:34 +0200 schrieb Jean-Julien Fleck:
> Hello Urs,
> 
> Le ven. 10 juil. 2020 à 09:03, Urs Liska  a
> écrit :
> > 
> > But I'd like to repeat that the fonts created by Abraham (including
> > 
> > Gonville) are at least partially available as free fonts, and they
> > 
> > already *can* be used in a regular LilyPond installation without
> > any
> > 
> > hassles.
> > 
> > 
> > 
> > All you need to do is copy (or better link) the font files in the
> > fonts
> > 
> > directory (Frescobaldi even offers a nice interface for handling
> > that
> > 
> > for arbitrary new LilyPond installations) and add some code to the
> > 
> > paper block of your document. 
> > 
> > If you use openLilyLib this is as easy as \useNotationFont
> > Gonville.
> > 
> > The notation-fonts package even provides (optional) default
> > stylesheets
> > 
> > for all supported fonts (to provide a good starting point regarding
> > 
> > e.g. line thicknesses).
> 
> Could you please give us a link that explains how to do that
> installation ?
> 
> 
> I've been searching (a bit) ever since the page 
> https://github.com/OpenLilyPondFonts appeared in this thread but
> couldn't find a tutorial to explain step by step what to do. I would
> have expected that such an explanation to be placed in the README.md
> file at the top of each font repository, at least pointing to a place
> explaining the generic way to do it but I couldn't find any.
> 
> Is there such a step-by-step tutorial and where can I find it ?

Unfortunately not comprehensively.
There's  https://github.com/openlilylib/oll-core/wikiwhich explains how
to obtain openLilyLib
  https://github.com/openlilylib/notation-fonts/gives a short overview
on how the notation-fonts package is used.
  
https://github.com/openlilylib/notation-fonts/tree/master/usage-examples/fontsincludes
several usage examples (along with compiled PDF files).
I'm not sure where installing additional fonts in LilyPond is
explained, but in a nutshell: you have to identify
the  /usr/share/lilypond/current/fonts/directory within a given
LilyPond installation, and drop the OTF and SVG font files in the
corresponding subdirectory (.woff files go into SVG).Best practice for
this is storing all your fonts in one central location and place links
into the LilyPond directory.
If you use a current Frescobaldi the tool Tools=>Document fonts
provides a convenient interface for manging fonts (installation and
creating the input code).
HTH
Urs
> Thanks,
> 
> --
> JJ Fleck
> Physique et Informatique
> PCSI1 Lycée Kléber

Re: Accidentals' font

[Urs Liska]

Am Donnerstag, den 09.07.2020, 21:40 +0200 schrieb Paolo Prete:
> On Thu, Jul 9, 2020 at 8:35 PM Jean Abou Samra 
> wrote:
> 
> > Le 08/07/2020 à 15:31, Paolo Prete a écrit :
> > 
> > 
> > 
> > On Wed, Jul 8, 2020 at 12:13 PM Jean Abou Samra  > >
> > wrote:
> > 
> > > I would like to emphasize that this is not at all simple. I agree
> > > that
> > > the technical part is reachable. Yet, this has consequences on
> > > the
> > > organization of the LilyPond ecosystem that have to be considered
> > > with care.
> > > 
> > > Fonts external to LilyPond also have development cycles that are
> > > different from LilyPond’s. If Gonville or other fonts were
> > > integrated as
> > > built-in options, we would end up receiving bug reports or
> > > feature requests
> > > from fellow users about fonts which we are incompetent about. It
> > > would
> > > force the authors of these fonts to follow LilyPond issues and
> > > make changes
> > > in parallel with Feta, for example, make it SMuFL-compliant by
> > > the end of
> > > the summer, which is very demanding. When the original author
> > > will not be
> > > available or no longer willing to support it, users will complain
> > > about the
> > > font not working and other LilyPond developers will need to fix
> > > it, and
> > > first learn its generation system, which is a custom one entirely
> > > different
> > > from Feta’s.
> > > 
> > 
> > Hello Jean,
> > 
> > I think the problem you emphasize is automatically solved with the
> > ./configure flag. Let me show a practical example.
> > ffMPEG has a native aac codec and a configure flag (--enable-
> > libfdk-aac)
> > which adds a third-party aac encoder (Fraunhofer FDK AAC).
> > 
> > Hi Paolo,
> > 
> > If I'm not mistaken, the use case for configure flags like
> > --enable-guilev2 is to influence compilation. By contrast, fonts
> > are loaded
> > dynamically at runtime. Hence, a configure flag would essentially
> > do
> > nothing but move a few files (except if it changed the default, but
> > we
> > don't want that).
> > 
> 
> Hi Jean,
> 
> I intended it exactly in the way you described. That flag would not
> influence compilation but only *linking*, preventing compatibility
> issues
> (mismatch of versions)
> 
> 
> > In fact, it's already possible and very simple to build LilyPond
> > with
> > Gonville support: just follow the usual build procedure, then copy
> > the
> > Gonville OTF files into
> > build/out/share/lilypond/current/fonts/otf/. That's
> > simple enough that I don't believe it deserves a special flag.
> > 
> 
> Yes, but this would make a *patched* build, and not a clean build.
> Note too
> that the flag should be more general than --with-gonville-font (for
> example, just an extemporary idea: --with-font=gonville,foobarfont
> etc.)
> 
> 
> 
> > Doing that, every maintainer of a *distro* (I highlight the word
> > *distro*,
> > and not the src one) can choose to create the binary with or
> > without third
> > party pieces.
> > Note that, for example, ffMPEG. There are some distros of ffMPEG
> > with
> > x264, and some distros without.
> > 
> > This nuance is not possible with LilyPond since, to my knowledge,
> > the vast
> > majority of users downloads binaries from lilypond.org.
> > 
> 
> This is true. But what if, in the future, someone wants to create,
> for
> example, a Linux Distro called LilyBuntu ? ;-)
> 
> 
> 
> > That said, I really think we ought to pause this discussion until
> > the
> > details of SMuFL support get clear.
> > 
> > 
> I agree. I pause it as well.
> 

But I'd like to repeat that the fonts created by Abraham (including
Gonville) are at least partially available as free fonts, and they
already *can* be used in a regular LilyPond installation without any
hassles.

All you need to do is copy (or better link) the font files in the fonts
directory (Frescobaldi even offers a nice interface for handling that
for arbitrary new LilyPond installations) and add some code to the
paper block of your document. 
If you use openLilyLib this is as easy as \useNotationFont Gonville.
The notation-fonts package even provides (optional) default stylesheets
for all supported fonts (to provide a good starting point regarding
e.g. line thicknesses).

So I really don't see the need for a patched compilation of LilyPond.
Urs

>  Best,
> P

Re: Accidentals' font

[Urs Liska]

Am Samstag, den 04.07.2020, 10:06 -0500 schrieb Karlin High:
> On 7/4/2020 5:55 AM, Paolo Prete wrote:
> > Just leave Feta as a native font and insert a dummy
> > wrapper for Gonville in the ./configure. This does not require any
> > development, nor uniformity in the coding standard and can be
> > easily added
> > to the source tree.
> 
> This discussion is reminding me of the Google Summer of Code project 
> proposal, "Support for Style Sheets."
> 
> "
> LilyPond’s engraving output can be tweaked to the least detail, and
> one 
> important addition in recent years was the ability to use
> alternative 
> notation fonts. It is possible to create reusable modules for “house 
> styles”, but this project aims at bringing this to a new level by 
> creating a convenient extension package with support for creating, 
> applying, and sharing modular style sheets.
> "
> 
> 
> That looks to me like there IS community support for having ways to 
> change the look-and-feel of LilyPond's output, depending how the 
> development goals are defined and presented.

I just want to point out that there's an openLilyLib package 
https://github.com/openlilylib/notation-fonts which allows you to use
any installed (i.e. compatible) notation font as easily as

\include "oll-core/package.ily"
\loadPackage notation-fonts
\useNotationFont lilyjazz

This loads a default stylesheet provided for lilyjazz, but you can also
specify custom styles with

\useNotationFont \with {
  stylesheet = #'my-custom-style.ily
} haydn

The repository with the old OFL versions of Abraham Lee's work (which
includes Gonville BTW) has been mentioned, and Frescobaldi provides a
easy-to-use dialog to install and choose notation fonts with built-in
preview function.

Urs

Re: GSoC 2020 update, June 15

[Urs Liska]

Am Dienstag, den 16.06.2020, 09:16 +0200 schrieb Han-Wen Nienhuys:
> Isn't Smufl a standard proposed by the Dorico folks? 

Yes and no. Daniel Spreadbury spearheaded the effort while Dorico was
developed. But it was originally conceived as an open standard.

> We could try to
> 
> agree on a mechanism with them?

If it fits into what they (this is also the www music notation
community group (https://www.w3.org/community/music-notation/)) see fit
for the way forward it is certainly possible to talk with them.

Urs

Re: Remove lily-git?

[Urs Liska]

Am Donnerstag, den 04.06.2020, 13:36 +0200 schrieb Jean Abou Samra:
> Hi,
> Le 04/06/2020 à 08:31, James Lowe a écrit :
> > On 03/06/2020 21:25, Karlin High wrote:
> > > On 6/3/2020 3:14 PM, Jean Abou Samra wrote:
> > > > There is a discussion at 
> > > > https://gitlab.com/lilypond/lilypond/-/issues/1012
> > > > about the future of lily-git.Basically, I think that it no
> > > > longer 
> > > > makes sense to keep it now that we switched to GitLab.
> > > 
> > > I remember seeing this thing bring in over 500MB of dependencies
> > > on a 
> > > Debian Linux system. And I was thinking, "If that's the only
> > > piece of 
> > > TCL in the whole LilyPond ecosystem, there has GOT to be a way
> > > to 
> > > avoid having this."
> > 
> > I am not sure that is correct, lily-git is just a set of python 
> > commands with a Front End GUI (for the likes of me) that made sure 
> > that you had set your git repo correctly and could easily download 
> > $LILYPOND_GIT. It also forced you to set your git user and email.
> > 
> > Lily-git in and of itself was tiny and needed hardly anything to
> > run 
> > (wish lily-git.tcl).
> > 
> > The 500MB of dependencies was, I expect, for dblatex et al. That
> > we 
> > needed for doc building at the time but lily-git only cloned the
> > repo 
> > (and allowed a button to hard reset - again for idiots like me).
> > 
> > I am a bit older and wiser now, but even so git is still a
> > terrible 
> > 'ecosystem' not made much better by the gitlabs and githubs of the 
> > world (I have the joy of having to interface with both as a 
> > non-developer). That said, yes we don't 'need' lily-git, however
> > I'd 
> > like to give a hat-tip to the few devs that kept it going so I
> > could 
> > do my work. If it weren't for lily-git (and at the start 'lily-dev' 
> > - 
> > still less faff than containers and jails BTW for non-devs) I'd
> > have 
> > not been able to easily contribute to this project and may have
> > simply 
> > given up having to learn the terrible interface that is git cli
> > with 
> > all the breakages of master we had at the start of when I joined.
> > 
> > James
> I do agree with you that Git can be a bit of a trick to learn (at
> least,
> there is a long path before you fully master it). What if right now
> we
> just added a link to some Git graphical client like 
> https://www.syntevo.com/smartgit/?

SmartGit is a great Git client, but it is proprietary, so we can't link
to it (even provided they have a free (lowercase 'f') license for non-
commercial work).
Unfortunately I haven't yet found a Free GUI tool that made me feel
comfortable, so I've always got back to it.

> It doesn't remove the complexity of Git (obviously that's quite more
> involved than lily-git, the target not being the same), but at the
> very
> least, you don't need to bother with a command-line interface.
> 
> lily-git is not going to be usable in an immediate future.
> Anyway, if I had to write something, I would do it in Python as per
> the abovementioned issue (now that recent versions of Python ship
> with tkinter). And as we're still trying to figure out how exactly
> we are going to work with GitLab, starting a new tool right now
> doesn't look like a good idea. So, what I would propose at this point
> is
> to drop lily-git.tcl, as it doesn't provide a value neither for a
> user
> these days, nor for the people that could develop a new tool in
> Python
> in the future; then, depending on how things go on, and if we feel
> the
> need for it, write lily-git.py or whatever. Maybe we could open an
> issue
> to track that. Makes sense?

To me, yes. But I don't think that is too relevant here.

Best
Urs

> 
> Best,
> Jean Abou Samra
> 
> 

Re: GSoC 2020 update

[Urs Liska]

Hi Owen!

Am 27. Mai 2020 22:58:19 MESZ schrieb Owen Lamb :
>Hi all!
>
>I pushed the new dev/lamb/GSoC-2020 branch to origin yesterday, and it
>appears to be visible on GitLab. I haven't committed anything new yet,
>but
>I will soon. I'll push any commits I make at the end of each work day.
>
>I plan to give updates regularly every Friday. So far I have been
>investigating open-type-font.cc as an entrypoint for changing the
>encoding,
>but I'll have a more detailed report then.
>
>I have a couple questions in the meantime:
>
>I plan to temporarily add the Bravura font to my lilypond branch for
>testing SMuFL throughout the summer. Is there any legal reason not to

No. Bravura has very avöctively been developed and promoted to be an open font.

It may be shared along with the usual license stuff, but ...

>(or
>at least to .gitignore it so it only appears on my machine)? 

... as long as we don't intend to ship Bravura along with LilyPond I'd say it 
shouldn't be added to the repository. Except if it's necessary to get your work 
tested (maybe one day you'll habe a merge request that won't work without a 
real SMuFL font ...).

To keep something local to your computer it's better not to use the .gitignore 
file but .git/info/exclude - which does the same but without itself being 
committed.

Best
Urs

It appears
>to
>be licensed under OFL 1.1, just like Feta, but I'd just like to make
>sure
>I'm not accidentally breaking any laws as I work publicly.
>
>This next one is a minor annoyance and probably a C++ newbie question,
>but
>my IDE (VS Code, chosen for comfort) is reporting "a
>dynamically-initialized local static variable is not allowed inside of
>a
>statement expression" about a million times throughout the .cc files,
>whenever particular #define'd macros, e.g. ly_symbol2scm or
>get_property,
>are referenced. From what I know, macros aren't dynamically
>initialized,
>are they? Does anyone know why this might be happening? This doesn't
>seem
>to affect compilation, so I can easily ignore the red squiggly lines,
>but
>if there's a way to get rid of them, I'm all ears.
>
>And, of course, if you have any comments or suggestions about anything
>else, please let me know!
>
>Thanks,
>Owen

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

Re: Access to push new branch to origin

[Urs Liska]

Am Montag, den 25.05.2020, 20:30 +0200 schrieb Jonas Hahnfeld:
> Am Samstag, den 23.05.2020, 16:38 +0200 schrieb Urs Liska:
> > Am 23. Mai 2020 15:01:11 MESZ schrieb Werner LEMBERG :
> > > > I can grant you access to the repository later today if needed.
> > > > However I'd first like to understand (probably from Werner)
> > > > what
> > > > makes a branch in the upstream repository more "preserving"
> > > > than a
> > > > public clone.  Being distributed it really doesn't make much
> > > > difference from the git perspective.
> > > 
> > > IMO, code for a LilyPond GSoC project should become an integral
> > > part
> > > of the master git repository.  I think it should be freezed in
> > > its
> > > final form (this is, right after GSoC ends) for documentation
> > > purposes.  If the stuff gets merged, the branch should still stay
> > > and
> > > not be deleted.
> > > 
> > > Note that this is my personal point of view, and I don't insist
> > > on it.
> > > On the other hand: if you see problems with that approach please
> > > elaborate.
> > 
> > I would second that a student who has been accepted to GSoC should
> > be considered part of the team and grantwd push access, as long as
> > there are regulations preventing them from accidentally pushing to
> > master.
> 
> Invited @WolfGangsta to the lilypond group.

While we're at it, I'd be happy to be part of the group too.

Urs

Re: Access to push new branch to origin

[Urs Liska]

Am 23. Mai 2020 15:01:11 MESZ schrieb Werner LEMBERG :
>
>> I can grant you access to the repository later today if needed.
>> However I'd first like to understand (probably from Werner) what
>> makes a branch in the upstream repository more "preserving" than a
>> public clone.  Being distributed it really doesn't make much
>> difference from the git perspective.
>
>IMO, code for a LilyPond GSoC project should become an integral part
>of the master git repository.  I think it should be freezed in its
>final form (this is, right after GSoC ends) for documentation
>purposes.  If the stuff gets merged, the branch should still stay and
>not be deleted.
>
>Note that this is my personal point of view, and I don't insist on it.
>On the other hand: if you see problems with that approach please
>elaborate.

I would second that a student who has been accepted to GSoC should be 
considered part of the team and grantwd push access, as long as there are 
regulations preventing them from accidentally pushing to master.

Urs

>
>
>Werner

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

Re: LilyPond GSoC logistics

[Urs Liska]

Am 21. Mai 2020 19:21:27 MESZ schrieb Owen Lamb :
>>
>> To preserve your code within LilyPond it probably makes sense if you
>put
>> your code into a private (but public) branch of the upstream lilypond
>> repository (i.e., not a gitlab clone of it), for example
>> 'dev/lamb/GSoC-2020'.
>>
>
>I'm a bit confused here, so let me just make sure I understand what
>you're
>saying
>
>I'll be making a new branch titled "dev/lamb/GSoC-2020" in the GitLab
>repository, based off the current master. It will be "private" in the
>sense
>that it's my personal workspace (hence the "lamb" namespace), but it
>will
>be "public" in the sense that it will be visible to the public. It will
>not
>be merely "a gitlab clone" of the master branch, since it is a new
>branch
>entirely. Did I interpret that correctly?

Yes, that should be how it is.

I think the message should read "not a fork". A fork is a personal copy that 
you need when you don't have push access to a repository.

A "clone" in Git-speak is the local copy you are actually working in. Of course 
you will have such a clone. 

HTH 
Urs


>
>I'm pretty new to git, so please excuse my lack of expertise!

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

Re: [RFC] Enabling GitLab CI

[Urs Liska]

Am Montag, den 18.05.2020, 11:15 +0100 schrieb Kevin Barry:
> On Mon, May 18, 2020 at 10:48:55AM +0100, James Lowe wrote:
> > but how do I know? That is the nub of what I am asking. If a patch
> > is 'new'
> > how do I know that an automated make doc is 'in progress, has
> > completed with
> > errors, has completed without errors' as I am not going to bother
> > to do any
> > work on it if it is the first two cases. What is the point?
> 
> The merge request list has an icon next to every merge request
> showing
> the current pipline status. There are different icons for passed,
> failed and in-progress. Is that what you want? See the merge request
> page for inkscape:
> https://gitlab.com/groups/inkscape/-/merge_requests
> 
> Is the information you would like to be able to see visible there?

No, at least not at the time I looked.
What James needs is additionally an icon that states that MR is
*currently* being tested.

But that will also be visible in the interface (which Jonas addressed
with his comment that in this case you can simply skip the MR and have
a look later when it can be assumed finished.

HTH
Urs

> 
> It will only show a pass if all stages pass, as far as I know.
> 
> Kevin
> 

Re: README.md (was: migrating to GitLab)

[Urs Liska]

Am Sonntag, den 17.05.2020, 10:01 +0200 schrieb Han-Wen Nienhuys:
> On Sun, May 17, 2020 at 9:55 AM Urs Liska 
> wrote:
> > Hello all,
> > 
> > although I have admittedly been pretty much silent about all this I
> > would like to ask about getting access to the LilyPond repository
> > in
> > the new place as well. My user name there is urs.liska.
> > 
> > One thing I noted while setting up my account is that we don't have
> > a
> > README.md in the root directory. Is this by any conscious decision
> > or
> > simply because nobody has done it or started a discussion yet?
> 
> We have README.txt (generated from a .texi in Documentation/topdocs),
> and ROADMAP. I think it would be a great idea if someone would
> reformat the contents into a README.md file in the root of the tree.

My offer was to write a README.md after some discussions, but of course
reworking an existing resource is an even better approach.

Do I understand you correctly that README.txt is generated upon
compiling LilyPond? So where does it end up, I couldn't find a
README.txt neither in the source repository nor in the installation
directory. Does it only end up in the documentation (which I haven't
built locally)?

Urs

> 

README.md (was: migrating to GitLab)

[Urs Liska]

Hello all,

although I have admittedly been pretty much silent about all this I
would like to ask about getting access to the LilyPond repository in
the new place as well. My user name there is urs.liska.

One thing I noted while setting up my account is that we don't have a
README.md in the root directory. Is this by any conscious decision or
simply because nobody has done it or started a discussion yet?

I think having such a file as a first - auto-formatted - introduction
on a repository's entry page is a common expectation for any visitor of
this kind of platform. Not finding general information on the front
page would be irritating for most visitors (and potential
contributors).

This is to start a discussion of what should be on that page before
writing one and starting a Merge Request.

I think a README.md should include:

 * A general description of what LilyPond is, with a reference to the
   website and a direct link to the manuals
 * An initial overview of how to become a contributor with
* a description of the used programming languages
* a list of included support tools with their programming languages
  (e.g. musicxml2ly)
* a link to the CG
* maybe a quick reference about what we expect Merge Requests to
  look like

Best
Urs

Am Freitag, den 08.05.2020, 08:57 +0200 schrieb Jonas Hahnfeld:
> I haven't heard further objections which, for me, means we are going
> with GitLab. If you don't agree, now's your final time to speak up.
> Otherwise I would like to tackle the migration rather soon to take
> advantage of the new opportunities :-)
> 
> This leads me to some final considerations:
> 1) I'm going to disable write access to SourceForge when starting the
> migration. Otherwise the two copies will diverge over time, leading
> to
> confusion for everyone. As all old issues are retained, including
> their
> ticket numbers, this shouldn't be a problem: We can just continue
> working on them and preferably close the issues over time ;-)
> 
> 2) I'm not attempting to migrate outstanding patches from Rietveld.
> As
> we'll most probably have some during the switch, they need to be
> resubmitted. This shouldn't be a major deal as everybody should be
> working with branches already. Right?
> 
> 3) The idea is to have the "main" repository at GitLab, next to the
> issues and merge requests. This leads to the question what to do with
> Savannah because git is distributed anyway. I first thought about
> only
> pushing "important" branches and tags to GitLab (master, stable/*,
> release/*). Switching platforms would actually be one of the few
> opportunities to do so - in particular tags are hard to get rid of.
> However most of us are probably going to reuse their local
> repository,
> just updating the URL. While GitLab has options to prevent pushing
> certain refs, that's probably not a great idea. So I guess I'll just
> push an identical copy to GitLab unless somebody has a better
> proposal.
> 
> Ultimately we can talk about cleaning up the Savannah repo and only
> keeping the "important" branches there. This could for example be
> coupled with automated mirroring, which GitLab supports out-of-the-
> box. 
> I won't look into this for the initial switch though, so just make
> sure
> you're not pushing conflicting commits there...
> 
> 4) I expect the script to take 9-10 hours for the issue migration
> which
> I plan to run over night (European time). This is primarily for post-
> processing tasks at the end which are better done when fully awake.
> So
> no issue tracker during this time, but that's probably justifiable.
> 
> ---
> 
> And now to the most important task: picking a date when I'm
> available.
> I could do: Sunday evening & Monday; Tuesday & Wednesday; or
> Wednesday
> & Thursday.
> 
> Cheers
> Jonas

Re: Obstacles for using GitLab CI

[Urs Liska]

Am Mittwoch, den 13.05.2020, 22:33 -0400 schrieb Dan Eble:
> On May 13, 2020, at 17:13, David Kastrup  wrote:
> > > > At the current point of time, our pipeline does not tend to be
> > > > all that
> > > > full I think.  We are not at Linux kernel levels of
> > > > participation...
> > > 
> > > No, you're probably right. It's only a bit more bothersome if you
> > > have
> > > multiple changes to submit from the same countdown.
> > 
> > The real problem starts when people don't manage to get their patch
> > in
> > because the pipeline is always busy.  But if we are there, the free
> > CI
> > plan will most certainly not do the trick anymore.
> 
> One thing is clear: we need to make sure we don't abuse James'
> generosity, so I'm willing to try whatever system you think will be
> the fairest all around, even if it might be a bit "bothersome" as an
> individual submitter from time to time.
> 

That's true.
But I'd like to disencourage (can you say that?) using our small
contribution frequency as an argument here. Making it easier to
contribute and as a consequence have more contribution was a major
motivation behind all this. So while we'll surely never get to a Linux
kernel situation having a solution that scales to some activity
substantially increased from what we have now should be a requirement.

Urs

> — 
> Dan
> 
> 

Re: repository at GitLab

[Urs Liska]

Am Montag, den 11.05.2020, 11:52 +0200 schrieb Jonas Hahnfeld:
> Am Montag, den 11.05.2020, 11:39 +0200 schrieb Werner LEMBERG:
> > > I granted everybody access to the group 
> > > https://gitlab.com/lilypond who
> > > sent requests so far.
> > 
> > Please give me access too; my username on GitLab is 'lemzwerg'.
> 
> Done.
> 
> > Another question is what to do with the lilypond git mirror on
> > github...
> 
> If we want to keep the mirror, we can make GitLab push updates
> automatically as potentially discussed for Savannah.

Sorry if I'm asking things I might have read if I had been able to pay
closer attention recently.

With the repository on Gitlab.com anybody who has an account can freely
fork the repository and interact with that fork. (And from there then
create Pull Requests to interact with the official repository.)

If that's the case I don't think there's an actual need for a mirror on
Github anymore. The original intention to set this up has been to
enable people to work with the code without having to ask for
permissions on the Savannah repository.

My suggestion would be to disable that mirror by updating the README.md
and archiving it (i.e. making it read-only).

Urs

> 
> Jonas

Re: stale git branches

[Urs Liska]

Am 11. April 2020 15:33:06 MESZ schrieb David Kastrup :
>Jonas Hahnfeld  writes:
>
>> Hi all,
>>
>> following removal of dev/translation-* branches, I took a closer look
>> at stale branches. I think it would make sense to keep unscoped
>> branches (outside of dev/user/) to a minimum. This should also avoid
>> overlooking old changes that have not been merged yet.
>> The following list is by no means complete, but maybe a good start:
>>
>> dev/pango contains commits:
>> 53ed2b55e2 Add a RAII wrapper for extracting FT_Face from PangoFcFont
>> c93c477180 Make Pango >= 1.36 mandatory.
>> in master:
>> 9cf8d35e8c Add a RAII wrapper for extracting FT_Face from PangoFcFont
>> 15b7118410 Make Pango >= 1.36 mandatory.
>> I'm fairly certain the branch can be removed.
>
>git rebase origin origin/dev/pango
>
>ends up with no commit on top.  So yes.
>
>> Branches dev/issue3300,
>
>Mine, but actually issue 3330.  Removed.
>
>> dev/issue3330, dev/issue3648 are likely related
>> to the named issues which have status 'Verified'. AFAICS there are
>some
>> additional commits in the branches, could be due to review comments?
>> David, you are probably the best to judge if they are fully merged or
>> some changes could still be relevant, could you take a look?
>>
>> As far as I understand, master now also has the relevant commits from
>> dev/guile-v2-work, dev/guilev2, and dev/guilev21? Can those branches
>be
>> dropped to avoid possible confusion about the current status?
>
>Will followup on all those later.
>
>> Then there are some dev/user/ branches. I consider these relatively
>> "private" to that person and would not propose to delete them on a
>> global basis. Still maybe everyone can take a look and delete unused
>> personal branches on their own?
>
>origin/dev/rune may be considered an epitaph.  I don't think anybody
>ever attempted merging what this was about: maybe it's in the interest
>area of Hans Aberg.  Whether or not somebody does an assessment of it
>at
>one point of time, I think it appropriate to leave it as-is, including
>not rebasing/rewriting any of it in-place.
>
>I'll readily agree that there is a disconcerting large set of other
>apparently semi-dead branches by living people, most of them likely
>unaware of what they left lying there.  There may be some point in
>going
>through and mailing them about what they think best to do here.

I will look into what I have lying around.

Urs

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

GSoC applications

[Urs Liska]

Hi all,

an hour ago this year's GSoC student application deadline has been
completed, and it seems I'm currently the only registered mentor having
access to that.

Of course we can't discuss application(s) on public lists. So please
reply to me privately so I can share the application(s) with you and
discuss further process. This involves evaluation of proposal(s) and
considering mentorship.

Best
Urs

Re: 2.21.0 and announcements

[Urs Liska]

Am 26. März 2020 17:46:07 MEZ schrieb Carl Sorensen :
>
>
>On 3/26/20, 10:12 AM, "lilypond-devel on behalf of David Kastrup"
>d...@gnu.org> wrote:
>
>
> So it's time to roll out 2.21.0 and I think the build instructions are
>   ok-ish for that.  We don't clarify the relations/recommendations for
>Guile-1.8/2.x but that relation/recommendation is currently in flux and
>this is an unstable release.
>
>We still haven't made the "big" 2.20 announcement, and 2.21.0 being out
>  would make the web page consistent with regard to stable/unstable, so
>that would seem like a good opportunity.
>
>Except that the web page currently is broken with some Python2/3
>problems, and that people are hitting a roadblock with MacOSX.  I think
>we should point out on our download page that the GUB-provided
>installers are _only_ for 32bit MacOSX, and that separate downloads may
>   be provided elsewhere (possibly linking to Marnen's page in the hope
>that it does not get overloaded?).
>
>I can provide a pretty robust mirror of Marnen's page if need be.  It
>would be on my university server with lots of bandwidth.

Could we do that too, Ralf, Moritz?
>
>Thanks,
>
>Carl
>

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

Re: 2.21.0 and announcements

[Urs Liska]

Am 26. März 2020 17:11:36 MEZ schrieb David Kastrup :
>
>So it's time to roll out 2.21.0 and I think the build instructions are
>ok-ish for that.  We don't clarify the relations/recommendations for
>Guile-1.8/2.x but that relation/recommendation is currently in flux and
>this is an unstable release.
>
>We still haven't made the "big" 2.20 announcement, and 2.21.0 being out
>would make the web page consistent with regard to stable/unstable, so
>that would seem like a good opportunity.
>
>Except that the web page currently is broken with some Python2/3
>problems, and that people are hitting a roadblock with MacOSX.  I think
>we should point out on our download page that the GUB-provided
>installers are _only_ for 32bit MacOSX, and that separate downloads may
>be provided elsewhere (possibly linking to Marnen's page in the hope
>that it does not get overloaded?).
>
>Because once the big announcements are made, we want people to actually
>be able to work with what they find on the web page.
>
>We can release 2.21.0 prior to that, of course, since the web page
>updates are (I think) independent from releases.
>
>Thoughts?

Sounds all reasonable to me.
Just wanted to state that I'm sorry I can't be involved more these days but 
that I'm happy to see that consistently high level of activity.

Urs

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

Re: Lilypond API

[Urs Liska]

Hello Brahim,

Am Montag, den 16.03.2020, 10:31 + schrieb brahim.pro via
Discussions on LilyPond development:
> Hello,
> 
> I would like to use lilypond parser in my own application.
> I can't find any API or external library to do that.

There is no such thing.

> What is the correct approach you would advice me to follow?

That very much depends on what you are actually trying to achieve. The
typical way to use LilyPond from the outside is generate some input for
it (or have users write that) and than pass it to LilyPond for
compilation. This can be either by writing a file and give that to
LilyPond or by directly passing it the content in a string through the
shell.

For some applications it may also be a way to use the python-ly library
that powers the Frescobaldi (text) editor (
https://python-ly.readthedocs.io/en/latest/).

But you should really clarify what you're after.

Urs

> 
> Thanks
> Brahim
> 
> Sent with [ProtonMail](https://protonmail.com) Secure Email.

Re: [GSOC 2020] Discussing GNU Lilypond project ideas?

[Urs Liska]

Am Donnerstag, den 27.02.2020, 08:57 -0300 schrieb Leandro Doctors:
> On Wed, 26 Feb 2020 at 18:56, Urs Liska 
> wrote:
> > I'd like to stress that the GSoC page lists
> > project *ideas*, and if you're specifically interested in Scheme
> > stuff
> > you may as well suggest other topics than listed there.
> 
> Sure, Urs :-)
> 
> As I said before, I have only started reading the Ideas page.
> All I know right now is that I would like to work on a Scheme-related
> project :-)
> 
> I will clone Lilypond's repo, read the code and try building it, and
> get
> back with more specific details, if that's OK with you.

Of course.

You may also be interested in openLilyLib (https://openlilylib.org for
a very-WIP introdcution and https://github.com/openlilylib for the
development space. There is much room for Scheme work in there, if it
looks interesting to start with I suggest you clone and look into the
oll-core repository (first) edition-engraver  and/or scholarly (order
irrelevant).

Urs

> 
> Best,
> Leandro
> 

Re: [GSOC 2020] Discussing GNU Lilypond project ideas?

[Urs Liska]

Am Mittwoch, den 26.02.2020, 15:46 -0600 schrieb Karlin High:
> On 2/26/2020 3:28 PM, Leandro Doctors wrote:
> > Could you please point me in the right direction?
> 
> Thanks for your interest! In the past, Urs Liska has been leading
> GSOC 
> efforts. He's indicated that this list is his preferred way to begin 
> GSOC discussions, so I think you're at the right place.

That's correct, although I'd claim that this is a "natural" solution
and not my preference ;-)

But more importantly I'd like to stress that the GSoC page lists
project *ideas*, and if you're specifically interested in Scheme stuff
you may as well suggest other topics than listed there.

Urs

Re: lilypond.org now serving HTTPS

[Urs Liska]

Am Donnerstag, den 13.02.2020, 18:48 +0100 schrieb Jean-Charles
Malahieude:
> Le 13/02/2020 à 15:10, Han-Wen Nienhuys a écrit :
> > FYI, lilypond.org is now serving on HTTPS
> > 
> > See here https://codereview.appspot.com/559470043/ for background.
> > 
> 
> This should be applied on stable/2.20 as well.
> 
> Cheers,
> --
> Jean-Charles
> 

My browser complains about mixed content, i.e. http-linked media on the
page.

Urs

GSoC

[Urs Liska]

Just to let you know: GNU has been accepted as a GSoC mentoring
organization.

a)
This means that now people may visit 
https://lilypond.org/google-summer-of-code.html and look at our GSoC
project ideas. So if anythingg could be added (or fixed or removed)
there now would be the (latest) time to do so.

b)
If you know of any distribution channels for this information please
share https://summerofcode.withgoogle.com/ 
https://www.gnu.org/software/soc-projects/ideas-2020.html and the link
from a)

Urs

Re: music-cause

[Urs Liska]

Am Donnerstag, den 20.02.2020, 17:12 +0100 schrieb David Kastrup:
> David Kastrup  writes:
> 
> > Graham Percival  writes:
> > 
> > > On Sun, Jan 22, 2012 at 11:49:06AM +0100, David Kastrup wrote:
> > > > Anybody actually using the "music-cause"?  Inside of LilyPond,
> > > > the only
> > > > appearance (apart from its declaration) would be
> > > > 
> > > >   /*
> > > > ES TODO: This is a temporary fix. Stream_events should not
> > > > be
> > > > aware of music.
> > > >   */
> > > >   e->set_property ("music-cause", self_scm ());
> > > 
> > > If it's used anywhere, it would be here:
> > > http://lilypond.org/website/pdf/thesis-erik-sandberg
> > > 
> > > It may have been added just so he could produce some graphs or
> > > tables or something?  I know that I have a ton of "graph-
> > > producing
> > > code" in Artifastring and Vivi like that.
> > 
> > Seems somewhat pointless since events take the whole mutable
> > property
> > list of their originating music event anyway.  If you need more for
> > tracking, you could just do
> > 
> > maketrackable =
> > #(define-music-function (parser location m)
> >   (music-map
> > (lambda (m)
> >(set! ly:music-property 'music-cause m)
> >m)
> > m))
> > 
> > and call that on your music before processing.
> 
> I lean towards going through with my threat here and removing
> music-cause which seems like a weird punch-through kind of property.
> Any objections here?  Anybody actually using it anywhere?
> 

It is used in openLilyLib a few times, I assume by Jan-Peter:

$ grep -rnw . -e 'music-cause'
./snippets/editorial-tools/auto-
transpose/module.ily:79:   ;  (ly:make-stream-event 'key-
change-event `((music-cause . ,key-sig)) ))
./snippets/editorial-tools/auto-transpose/module.ily:92:(cond-
transp engraver (ly:event-property event 'music-cause)))
./snippets/editorial-tools/auto-transpose/module.ily:95:(cond-
transp engraver (ly:event-property event 'music-cause)))
./edition-
engraver/engine.scm:944:  (music-
cause . mod)
./lilypond-export/api.scm:147:  ; search for music-cause of grob
./lilypond-export/api.scm:152: ((ly:stream-event? grob) (grob-
cause (ly:event-property grob 'music-cause)))
./lilypond-export/api.scm:205:(music (ly:event-property 
event 'music-cause))
./lilypond-export/api.scm:468:   (music (ly:event-property
event 'music-cause))
./oll-misc/pitch/auto-
transpose/module.ily:79:   ;  (ly:make-stream-event 'key-
change-event `((music-cause . ,key-sig)) ))
./oll-misc/pitch/auto-transpose/module.ily:92:(cond-transp
engraver (ly:event-property event 'music-cause)))
./oll-misc/pitch/auto-transpose/module.ily:95:(cond-transp
engraver (ly:event-property event 'music-cause)))

Re: 2.20 and 2.21 release plans

[Urs Liska]

Am Montag, den 17.02.2020, 13:25 +0100 schrieb David Kastrup:
> Ok, I think 2.20 is basically done and we should push it out by the
> end
> of this week.  

This is really great news!
I'm somewhat undecided whether it is a cause for celebration or not to
finally release a "stable" version after six years. But at the end of
the day I think we should praise those who have actually worked so hard
to make it happen. And all of us who benefit from that work might think
about what we can do to help bringing the *next* stable release over
the goal line in less than six years.

I have one side remark to that, although I'm not sure if it's
appropriate to inject it into this thread.

I haven't commented on the issue of a package loading mechanism
recently, for two reasons: I don't have any time right now, and I
thought it would be a distraction from the more pressing issues around
the build system, contribution workflow/tooling and finalizing a
release.
While it has been clear from the start that integrating a package
loading mechanism was not in question for 2.20.0, I would like to ask
if it can be considered making this go into a 2.20.x release and not
keep it on the 2.21 track as would be the natural itinerary. Doing so
(the latter) would force openLilyLib and - more importantly -
interfaces like Frescobaldi to support two alternative syntaxes of
loading packages until a 2.22 release.
So I would be glad if we could spend sufficient effort after 2.20.0 and
2.21.0 releases to discussing, implementing, and testing a package
loading mechansim sufficiently that we can integrate it not only in the
2.21.x but also a 2.20.x release.

Urs

> This leaves a few days for the translation team to catch
> up with the current state.
> 
> In particular HINT HINT HINT it gives the opportunity to native
> speakers
> of languages not as meticulously maintained as the currently most
> active
> translations to at least tackle the Changes document and maybe check
> a
> few other points of the web presence.  This is more addressed to
> people
> reading this announcement on the lilypond-devel list than to lurkers
> on
> the translations list, though of course the latter would be equally
> welcome.
> 
> What does this mean for 2.21.0?  I think we should aim to push it out
> fast afterwards, basically a few days later at most, just to get
> kinks
> with webpage/versioning from 2.20 ironed out.
> 
> I am not sure it is realistic to expect to get the translations
> merged
> into 2.21.0 already: because of the significant divergence
> experienced
> so far, I expect this to be a significant merging headache.  It would
> be
> nice to have, but not essential: this is the unstable branch after
> all.
> 
> For more extensive changes of internals and/or syntax, I would
> recommend
> to let them sit till 2.21.1 before committing, assuming that we _do_
> manage to get 2.21.0 out fast.  Why?  2.21.0 has by now quite
> significantly diverged from 2.20.0.  If something does not quite
> work,
> it would be nice to have a _released_ version to compare to, and
> nothing
> but 2.21.0 would really serve that role satisfactorily.  Particularly
> where problems are detected a long time after getting introduced,
> having
> an installable version as a reference is nice, and "it stopped
> working
> in 2.21.0" is enough of a quagmire already that we do not really want
> to
> add a lot more here.
> 
> The size of the headache basically is commensurate with how long the
> stable branch has diverged.  Hopefully we manage to find some
> combination of process and responsible persons next time around that
> delivers faster.
> 
> Nevertheless, I am glad we are getting there.
> 

Re: [Jose E. Marchesi] [gnu-prog-discuss] [VERY URGENT] GNU ideas for GSOC 2020

[Urs Liska]

I just told them to copy last year's proposal, which basically links to *our* 
GSoC page.

Urs

Am 12. Februar 2020 20:03:49 MEZ schrieb David Kastrup :
>
>Someone with a good idea?
>
> Start of forwarded message 
>From: jema...@gnu.org (Jose E. Marchesi)
>To: gnu-prog-disc...@gnu.org
>Date: Wed, 12 Feb 2020 19:50:06 +0100
>Subject: [gnu-prog-discuss] [VERY URGENT] GNU ideas for GSOC 2020
>
>
>Hi people!
>
>Once again, we are applying as a mentoring organization for GSOC 2020.
>At this point, we need to populate our ideas page with projects [1].
>
>This should be done before this Thursday (yes tomorrow).  So, if you
>want your GNU package to participate in GSOC, please send us your ideas
>to summer-of-c...@gnu.org ASAP!
>
>For each project idea, we need:
>
>- Name of the GNU program.
>  Example: GNU poke.
>
>- Summary of the project/idea.
>  Example: DWARF to Poke translator
>
>- Little paragraph explaining the project/idea.
>
>- Skills required.
>  Example: Good knowledge of DWARF, C programming.
>
>- Contact address for interested students.
>  Example: poke-de...@gnu.org
>
>If you have an external page where you are documenting your ideas, then
>please send us the URL so we can list it in the main page.
>
>Sorry for the late notice!
>And thanks! :)
>
>[1] https://www.gnu.org/software/soc-projects/ideas.html
>
>
>
> End of forwarded message 
>
>-- 
>David Kastrup

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

Re: Add Code of Conduct [Another RFC or not now?]

[Urs Liska]

Am 8. Februar 2020 19:23:34 MEZ schrieb Karlin High :
>On 2/8/2020 11:24 AM, Phil Holmes wrote:
>> I remain strongly opposed to a CoC.
>
>Clearly noted; thanks for responding. I have nothing further to say on 
>this topic just now; it's pretty much all been covered in prior
>messages.
>
>I'm sorry if I got your name wrong. I know "Phil Holmes" and "James 
>Lowe" are names associated with great service to the project in
>managing 
>patches and builds, but I have trouble remembering who's who for them.

No, you remembered right, James voiced his opposition in even stronger, 
borderline inappropriate ä, words.

Urs

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

Re: Add Code of Conduct

[Urs Liska]

Am Samstag, den 08.02.2020, 17:52 +0100 schrieb David Kastrup:
> Urs Liska  writes:
> 
> > Am Samstag, den 08.02.2020, 17:31 +0100 schrieb David Kastrup:
> > > Thomas Morley  writes:
> > > 
> > > > P.S. that 'make test-baseline' failed, I'll need to investigate
> > > > after
> > > > sending this.
> > > > 
> > > > 
> > > 
> > > input/regression/display-lily-tests.ly:230:1: fatal error: Test
> > > unequal: BUG.
> > > in  = \applyOutput Foo #(lambda (arg) (list))
> > > out = \applyOutput Foo ##f
> > > 
> > > 
> > > \test ##[ \applyOutput Foo #(lambda (arg) (list)) #]
> > > 
> > > 
> > > Not much of a surprise here: Guile-2 does not keep the source of
> > > functions around in general.  And Urs 
> > 
> > ? (is there another one around here?)
> 
> Dan.  Knowing my luck, now both will be offended.  Sorry.

No, I'm not offended ;-)

Urs
> 
> > > turned warnings in that file into
> > > errors so that they would not get overlooked.  Which certainly is
> > > sensible, but it means we need to think about what to do here.

Re: Add Code of Conduct

[Urs Liska]

Am Samstag, den 08.02.2020, 17:31 +0100 schrieb David Kastrup:
> Thomas Morley  writes:
> 
> > P.S. that 'make test-baseline' failed, I'll need to investigate
> > after
> > sending this.
> > 
> > 
> 
> input/regression/display-lily-tests.ly:230:1: fatal error: Test
> unequal: BUG.
> in  = \applyOutput Foo #(lambda (arg) (list))
> out = \applyOutput Foo ##f
> 
> 
> \test ##[ \applyOutput Foo #(lambda (arg) (list)) #]
> 
> 
> Not much of a surprise here: Guile-2 does not keep the source of
> functions around in general.  And Urs 

? (is there another one around here?)

> turned warnings in that file into
> errors so that they would not get overlooked.  Which certainly is
> sensible, but it means we need to think about what to do here.
> 

Re: [RFC] switch to GitLab / gitlab.com

[Urs Liska]

Am 7. Februar 2020 09:48:30 MEZ schrieb Kevin Barry :
>> (CC to Kevin Barry, who mentioned GitLab experience in a separate
>> thread. My info here is more based on research than experience, so
>> please call out any misunderstandings I have.)
>
>Thank you for the CC. I have read through the messages, and the
>previous
>discussion from 2018.
>
>My two cents are:
>- I think if we want to integrate issue tracking, code review, and
>source code
>  hosting in one place, then Gitlab is the best option
>- I do not have the experience of working with SF/Allura, Rietveld, and
> Savannah to get code into LilyPond, but, judging from appearances, the
>flow for contributions will be smoother for existing developers and
>less
>off-putting for new or occasional developers (I think, outside projects
>like
>the Linux kernel, drive-by pull/merge requests are more common than
>drive-
>  by patches)
>- I agree that using gitlab.com is better than self-hosting, but
>depending on the
>technical challenges involved it may be necessary to host a dedicated
>Gitlab
>  runner (i.e. a server for doing CI/CD builds/tests).
>- I think it's possible James Lowe's workflow might be be different
>under Gitlab.
>Re the concerns he raised in the old thread, I believe he would be able
>to
>mostly replicate what he does now with labels (and sorting by priority
>label).
>(I can see that this flow, including the "countdown" is under
>discussion
>  elsewhere.)
>- I don't know who tests that every patch successfully builds and
>passes basic
>tests, but in my experience, having Gitlab do that for me every time
>someone
>  opens a merge request (on one of my own projects at work) has been a
>  godsend (before that, I had to do it myself every time).

To add: tests are also triggered when additional commits are pushed to an open 
MT.


>
>> Additionally I'm not (yet) proposing to use MRs to actually
>> merge the change, that still happens via staging -> master. I only
>> propose that we use the UI to review the patches, instead of
>Rietveld.
>I think this is a good approach. Gitlab allows, for example, to have a
>number of
>protected branches (master + staging), and to default merge requests to
>any one.
>You can also set it to do different CI/CD on a branch by branch basis
>(for example
>you may want to run more stringent or longer tests on the staging
>branch than on
>others).

I think this is an extremely good point. Being able to squash upon merge, with 
or without merge commit, in combination with being able to automate that as a 
staging branch with final test, seems a very good idea to me.

This integration of tools can be handled completely independently from any 
policies about the review process or countdown etc.

To recap at this point: the worry about gitlab.com is similar to that wrt 
guthub: their TOS won't give us a substantial amount of trust in continuity of 
service.

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

Re: ’Pond Jobs & Their Descriptions

[Urs Liska]

Am Mittwoch, den 05.02.2020, 22:26 -0500 schrieb Kieren MacMillan:
> Hi Graham,
> 
> > Oh, that would definitely be a good idea!
> 
> Okay, then! I’ll start with your suggestion to [paraphrasing:]
> "summarize the jobs described in the CG", and prepare a skeleton
> document where each entry is like that one.
> 
> > (I'm not quite certain about the "Receives From" and "Passes To"
> > lines, as I think that implies a more formalized process than
> > LilyPond has
> 
> Those would be more for understanding the flow of the process, and
> figuring out where combinations/elisions can happen (e.g., someone
> might have sufficient skill and interest to be both Patch Submitter
> and Patch Formatter), and where automation can help (e.g., code
> formatting LOL).

If I'm not mistaken such a list wouldn't/shouldn't imply that
separating jobs relies on assigning one job per person (wow, why do my
fingers insist typing "mob" instead of "job" this morning???)

It *might* be misleading someone to think your effort would go in that
direction of a strictly formalized working environment, but a) we don't
have so many people for so many jobs and b) of course many people can
do much more than one task of such a list.
But such a detailed "job description" would probably be very helpful
when thinking about a possible improvement/solution/patch: What do I
want, what is needed to achieve it, which parts can I do myself, for
what exactly do I need assistance?

Urs

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

Re: Add Code of Conduct (issue 575620043 by janek.lilyp...@gmail.com)

[Urs Liska]

Am Mittwoch, den 05.02.2020, 21:21 +0100 schrieb David Kastrup:
> Urs Liska  writes:
> 
> > Am 5. Februar 2020 20:08:28 MEZ schrieb 
> > nine.fierce.ball...@gmail.com:
> > > On 2020/02/05 18:17:25, c_sorensen wrote:
> > > > I recognize that Mike Solomon has a different opinion.  I mean
> > > > no
> > > disrespect to
> > > > Mike, Janek, Han-Wen, or any other member of the LilyPond
> > > > team.  I
> > > highly value
> > > > the team spirit of the LilyPond team.
> > > 
> > > Well said.  Here's the current tally as I understand it:
> > > For: Han-Wen, Janek, Mike, Urs, Werner
> > > Against: Carl, Dan, David K., Trevor
> > > Mixed: David N.
> > 
> > I must say that I haven't actually expressed an opinion about it so
> > far, and I don't know which I have.
> > 
> > I don't feel uncomfortable without and wouldn't mind adding it.
> > 
> > OTOH openLilyLib owes its existence to a nonzero part to the fact
> > that
> > I found it easier to do that than getting my ideas into LilyPond
> > itself. (Although this isn't actually a comment on the CoC issue).
> 
> That would be relevant regarding the Code of Conduct if fear of
> getting
> harrassed kept you from contributing the code to LilyPond.

Now that you say it I recall what triggered my comment in the first
place (I got distracted while writing and was somewhat confused
afterwards).

Indeed it was the kind of unpleasant discussion about proposed changes
(I don't recall whether it was lilypond-devel threads or actual
patches, probably the former) that was the driving force. In a nutshell
my requests or suggestions were furiously fenced off as simply enabling
"single-person use cases". It was offending because the rejection was
pretty personal, especially since the argument was explicitly and
unfoundedly questioning (or rather denying) the usefulness of my
suggestions, and I think by now I do have some credentials with regard
to consequential usability or use case enhancements.

I think it would count as a case falling under a CoC, but even in
hindsight I have no idea whether having one would have helped the
situation.

> 
> It would be marginally relevant if the use of development platforms
> was
> under consideration where accepting/providing a particular Code of
> Conduct was mandatory, and use of such a particular platform would
> have
> made working directly in the LilyPond repository more feasible.
> 
> For what it's worth, I do think that the bulk of OpenLilyLib likely
> just
> is a better fit for keeping in a separate repository/project since
> changes in there do not need tight coordination with changes in
> LilyPond.

That's correct, and in a way this has been a lucky coincidence. But
noone could have expected that this system would take off enabling the
development of even pretty massive extension package like the edition-
engraver or scholarLY. And it is all but a certainty to expect a would-
be contributor like me ending up doing that kind of stuff rather than
just leaving ship.

Urs

> 

Re: Add Code of Conduct (issue 575620043 by janek.lilyp...@gmail.com)

[Urs Liska]

Am 5. Februar 2020 20:08:28 MEZ schrieb nine.fierce.ball...@gmail.com:
>On 2020/02/05 18:17:25, c_sorensen wrote:
>> I recognize that Mike Solomon has a different opinion.  I mean no
>disrespect to
>> Mike, Janek, Han-Wen, or any other member of the LilyPond team.  I
>highly value
>> the team spirit of the LilyPond team.
>
>Well said.  Here's the current tally as I understand it:
>For: Han-Wen, Janek, Mike, Urs, Werner
>Against: Carl, Dan, David K., Trevor
>Mixed: David N.

I must say that I haven't actually expressed an opinion about it so far, and I 
don't know which I have.

I don't feel uncomfortable without and wouldn't mind adding it.

OTOH openLilyLib owes its existence to a nonzero part to the fact that I found 
it easier to do that than getting my ideas into LilyPond itself. (Although this 
isn't actually a comment on the CoC issue).

Urs

Urs


>
>Mike, you asked,
>> What are the blockers to making a decision about this patch?
>> Does it need more discussion or more buy in?
>
>5-4 halfway through the first day doesn't look like buy-in to me.
>
>
>https://codereview.appspot.com/575620043/

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

Motivational statistics

[Urs Liska]

Hi all,

I wanted to get a better understanding from my impression of the
significant increase in traffic on lilypond-devel.

For this I did some statistics on James' "PATCHES - Countdown"
messages. Since patches are counted multiple times while flowing
through the process I think the only relevant metric is the "New"
section, and this should not be calculated by the countdown message but
averaged by day. And the results are convincing:

Four weeks leading to the Salzburg conference:
0,32 new patches per day

Since Salzburg:
1,46 patches per day

Of course these are no scientifically hardened results - but they match
the feeling of excited frenzy visible on this list. However sustainable
the effect may be, the short term impact of the developer meeting and
the conference seems to have been remarkable.

Urs

Re: Move Guile-style modules from scm to scm-modules (issue 567140045 by m...@ursliska.de)

[Urs Liska]

Am Freitag, den 31.01.2020, 18:38 +0100 schrieb David Kastrup:
> Urs Liska  writes:
> 
> > Am Mittwoch, den 29.01.2020, 07:01 -0800 schrieb d...@gnu.org:
> > > On 2020/01/29 12:20:10, mail5 wrote:
> > > > Unfortunately I haven't set up a build system on my new
> > > > computer
> > > > yet,
> > > so this
> > > > patch is not tested locally at all, so I'm humbly waiting for
> > > > the
> > > automated
> > > > tests to succeed or fail ...
> > > 
> > > I don't like the "use-modules clauses adjusted accordingly".  I
> > > don't
> > > think it makes sense readjusting use-modules clauses all the time
> > > while
> > > we are deciding on the final module organisation, so I'd strongly
> > > suggest first biting the bullet and deciding on a syntax for a
> > > user-level command able to load Scheme modules without further
> > > options,
> > > and then introduce that command.  In that manner, future
> > > directory
> > > organisations (which are almost certain to come) will not affect
> > > the
> > > source of user-level documents any more.
> > > 
> > > https://codereview.appspot.com/567140045/
> > 
> > Maybe I'm missing something, but AFAICS there will always be the
> > need
> > for a module path like (ice-9 regex), or (scm display-lily). We
> > will
> > have that with *any* user-facing load syntax.
> 
> \loadScmPackage display-lily
> 
> or even
> 
> \loadPackage display-lily.scm
> 
> with the last .scm getting interpreted specially.
> 
> #(use-modules ...) is not a user-facing load syntax.  We don't want
> people to have to change their input when an optional package
> migrates
> to the system or a local package changes hierarchy.  Specific path
> components may make sense for disambiguation, but if I take a look at
> what LaTeX does, a flat hierarchy as first user-level approximation
> does
> not appear to have significant scaling problems.

I'm not so sure about that. In the LaTeX world this means that you have
to come up with file names that are unique to the whole ecosystem
because otherwise you're relying on luck that "your" file is found
first in case of conflicts.
I had this several times, mostly in the form of requests of TeX Live
maintainers to rename files which were considered dangerously generic.

The other thing to consider is that path components are (currently) not
only used for disambiguation but also for the lookup. LilyPond starts
searching for files at each include path, and it relies on relative
paths starting from a (any) include path. LaTeX, however, recursively
searches for files starting from the include paths. I think going that
route would have several negative impacts (disadvantage/risk):

 * The recursive search is potentially expensive
 * There are actual risks of loops in the search path
 * Targets are not really specified, using relative paths is
   more expressive and explicit.
 * kpathsea is pretty complex and has corner cases that don't work well
   (e.g. it doesn't always follow symlinks when a directory does not
   contain at least one "real" file), and we would knowingly have to
   decide creating and maintaining a comparable tool

So, requiring explicit paths gives clearer interfaces (although more
typing is required) and reduces searching complexity.

In the case of display-lily and all other built-in modules we can
reduce this by adding the scm directory to the include path. But for
external packages I am pretty sure that using explicit paths from the
include paths (like we already have it with \include) makes sense.

###

However, I'd like to stress that we are (or at least should be) talking
about several different things when saying "package" and "loading":

1)
Loading a package/module *file*, parsing its code and making elements
available to clients

1a)
One question is how to address these includable files
1b)
The other question is where the elements and which elements of the
loaded files are visible.

2)
Loading/using a package in a more conceptual sense, like "edition-
engraver" or "scholarLY". Here all the stuff about option handling
becomes (more) relevant, and the questions of 1) are prerequisites.

###

So when talking about new commands to "load packages" we are actually
talking about two different things that *both* have to be done.

Urs

Re: Data structure for (package) options

[Urs Liska]

Am Donnerstag, den 30.01.2020, 09:50 +0100 schrieb Han-Wen Nienhuys:
> On Tue, Jan 28, 2020 at 2:48 PM David Kastrup  wrote:
> 
> > > I think we should aim to avoid textual inclusion as a mechanism
> > > that
> > > powers packaging.
> > 
> > At the implementation side, "textual inclusion" will be what has to
> > power systems where one can "plug in" packages and have them work
> > by
> > being present.  Even Guile's use-modules mechanism works at that
> > level.
> > But of course that doesn't mean that we want \include as a user-
> > level
> > access method in the long haul.
> 
> By textual inclusion, I mean a mechanism that must insert all its
> data
> in the global namespace. Library systems usually must have means to
> be
> explicit about external APIs and internal implementation details. I
> am
> advocating that there is an easy to use mechanism such that OLL
> packages can shield some of the implementation from other packages.
> 

My idea for packages is:

 * packages *always* have .ly files as entry points (even if their
   "real" work is exclusively Scheme). That makes it easier to handle
   (no need to load packages in two different forms) and gives regular
   users a lower threshold of moving library code to packages.
 * they explicitly define their public interface. See below for my
   ideas about that.
 * A new command \usepackage will either load the whole package or only
   a subset of its interface (like the "from X load Y" syntax in
   Python).

Maybe a clean way of making an interface explicit would be not to do

  myFunction = #(define-music-function ...

but having a new (set of?) command(s) that allow

  \export myFunction #(define-music-function

When parsing the package (i.e. loading it for the first time
`myFunction` is stored as the package's interface (in an internal
structure storing the interfaces of all loaded packages, along with
their defined options). [This is something *I* can do with the current
Scheme possibilities]

When using a package that has already been loaded (\usepackage checks
that first) the stored Scheme values (which may equally be variables or
procedures) are made visible in the caller's scope.

The question I have is:
If \usepackage makes the names available to everything else later (like
a regular \include of a LilyPond file) I can do this with what we
already have in Scheme.
If \usepackage should make the names available only within the current
input file (like (use-modules) does) I think \usepackage would have to
be  implemented at the parser level.

Urs

Re: Move Guile-style modules from scm to scm-modules (issue 567140045 by m...@ursliska.de)

[Urs Liska]

Am Mittwoch, den 29.01.2020, 07:01 -0800 schrieb d...@gnu.org:
> On 2020/01/29 12:20:10, mail5 wrote:
> > Unfortunately I haven't set up a build system on my new computer
> > yet,
> so this
> > patch is not tested locally at all, so I'm humbly waiting for the
> automated
> > tests to succeed or fail ...
> 
> I don't like the "use-modules clauses adjusted accordingly".  I don't
> think it makes sense readjusting use-modules clauses all the time
> while
> we are deciding on the final module organisation, so I'd strongly
> suggest first biting the bullet and deciding on a syntax for a
> user-level command able to load Scheme modules without further
> options,
> and then introduce that command.  In that manner, future directory
> organisations (which are almost certain to come) will not affect the
> source of user-level documents any more.
> 
> https://codereview.appspot.com/567140045/

Maybe I'm missing something, but AFAICS there will always be the need
for a module path like (ice-9 regex), or (scm display-lily). We will
have that with *any* user-facing load syntax.

My thought was to separate the two different types of .scm files in
that directory, and that could of course also be achieved by moving the
*other* files, those that are loaded with ly:load from lily.scm to a
different directory.

Or - of course - I can simply drop this and add new modules to that
same directory for now.

> 

Visibility of files loaded with ly:load, location of "local" guile modules

[Urs Liska]

One final question before I start working on some package code
proposal:

All the basic Scheme files are loaded in lily.scm with

  (for-each ly:load init-scheme-files)

What does this do internally? I.e. how is the visibility handled of
definitions/bindings from names in files loaded with ly:load ?

When I manually ly:load a .scm file I can see both variables created
with define and define-public. I have the impression that everything
loaded with ly:load is visible to any .ly file afterwards, is that
correct?

So my approach would be to create a file packages.scm, add it to the
list of auto-loaded files in lily.scm and define in this only what is
to become the public interface of the package mechanism. All internal
code would be loaded from there with (use-modules), or am I missing
something here?

Where would I store Scheme modules which are *not* to be loaded through
ly:load in lily.scm but through (use-modules)? 
We *do* have a number of such modules in the scm directory.

  (git grep "(scm "

indicates this for the following modules:

 * accreg
 * clip-region
 * coverage
 * display-lily
 * editor
 * framework-eps
 * framework-null
 * framework-ps
 * framework-scm
 * framework-svg
 * graphviz
 * guile-debugger
 * lily
 * ly-syntax-constructors
 * memory-trace
 * output-ps
 * output-socket
 * output-svg
 * page
 * paper-system
 * ps-to-png
 * safe-utility-defs
 * song
 * song-util
 * to-xml

So I could simply store my guile modules there too, but wouldn't it
make sense to move them to a new directory to disentangle ly:load from
use-modules files? That would seem in line with moving the .ly files
like bagpipe.ly which are not loaded automatically but only upon
request to packages.

Urs

Re: Data structure for (package) options

[Urs Liska]

Am 28. Januar 2020 14:48:54 MEZ schrieb David Kastrup :
>Han-Wen Nienhuys  writes:
>
>> On Mon, Jan 27, 2020 at 11:39 PM Urs Liska 
>wrote:
>>>
>>> I didn't have time to really think about much (about LilyPond) the
>past
>>> week, just enjoyed seeing so much constructive discussion.
>>> [..]
>>
>> I haven't read your messages in detail, but I'd like to throw out one
>> thought to consider: we use GUILE modules as a mechanism for
>> identifier namespacing (\paper, \header all create modules). I think
>> it might be useful if we could provide a LilyPond native mechanism
>for
>> packaging that declares a namespace implicitly, eg.
>>
>>   \module "edition" {
>>   internal = ...
>>   addTweak  = ...
>>   }
>>
>>   \import edition.addTweak
>>
>> that would let you define constructs in a package that doesn't
>pollute
>> the global namespace, and let .ly packages control explicitly what
>> symbols they want to use.
>>
>> I think we should aim to avoid textual inclusion as a mechanism that
>> powers packaging.
>
>At the implementation side, "textual inclusion" will be what has to
>power systems where one can "plug in" packages and have them work by
>being present.  Even Guile's use-modules mechanism works at that level.
>But of course that doesn't mean that we want \include as a user-level
>access method in the long haul.
>
>It's likely that a typical more complex package may consist of both .ly
>and/or .scm components and that is an implementation detail that a
>package user should not need to bother about, and that hopefully should
>not significantly complicate things for people wanting to provide
>packages with either or both .ly and/or .scm components.

From my experience with OLL it would sesm reasonable to have all packages use 
.ly files as entry point. From there they can use Scheme modules if they need 
to. OLL does some work to add its root to the guile path, so there's the way to 
use modules relstive to the package.

Urs


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

Re: Data structure for (package) options

[Urs Liska]

Am Dienstag, den 28.01.2020, 09:26 +0100 schrieb Han-Wen Nienhuys:
> On Mon, Jan 27, 2020 at 11:39 PM Urs Liska 
> wrote:
> > I didn't have time to really think about much (about LilyPond) the
> > past
> > week, just enjoyed seeing so much constructive discussion.
> > [..]
> 
> I haven't read your messages in detail, but I'd like to throw out one
> thought to consider: we use GUILE modules as a mechanism for
> identifier namespacing (\paper, \header all create modules). I think
> it might be useful if we could provide a LilyPond native mechanism
> for
> packaging that declares a namespace implicitly, 


That sound similar to what David suggested in 
https://lists.gnu.org/archive/html/lilypond-devel/2020-01/msg00349.html

> > Ok.  One thing to think about is that we want package files to be
> > contributed by "ordinary" users.  But something like
> >
> > \exportSymbols transposeSequence,instrumentGroup,scratchMyBack
> >
> > would be perfectly feasible syntactical sugar.

and following conversation on that thread.

I'm all for such an encapsulation strategy for packages.

> eg.
> 
>   \module "edition" {
>   internal = ...
>   addTweak  = ...
>   }

I think this concrete suggestion *looks* nice but would be awkward to
handle and impose restriction on how package authors can express
themselves.

I'd prefer (IISC more to David's suggestion) being able to write a
package as a regular .ly or .scm file with commands to explicitly
export/expose selected functions and variables.

> 
>   \import edition.addTweak

In analogy to Python one could have a choice between

  \import edition

for making all exported names visible or

  \import \with {
addTweak.foo.bar
  } edition

for selectively importing three names.
(the \with being my current abuse of ly:context-mod?)

I have no strong opinion, and \import seems like a natural choice with
a programmer's eye, but \usepackage might be more expressive from a
document author's perspective.

> 
> that would let you define constructs in a package that doesn't
> pollute
> the global namespace, and let .ly packages control explicitly what
> symbols they want to use.
> 
> I think we should aim to avoid textual inclusion as a mechanism that
> powers packaging.
> 

That's a good point but will definitely be beyond what *I* can do.

Urs

Re: Data structure for (package) options

[Urs Liska]

Am Dienstag, den 28.01.2020, 00:34 +0100 schrieb David Kastrup:
> Urs Liska  writes:
> 
> > I didn't have time to really think about much (about LilyPond) the
> > past
> > week, just enjoyed seeing so much constructive discussion.
> > 
> > I think the first thing I'd like to go for with the
> > package/extension
> > mechanism is storing and handling (package) options.
> > 
> > There are three use cases which are differently closely related to
> > the
> > actual package mechanism but should be dealt with together:
> > 
> >  * package options
> > * specified, typed and preset with default values by a package
> > * handled by getter and setter functions
> >  * custom options
> > * behave like package options
> > * not associated with a package but explicitly called for in
> > user
> >   code
> >  * custom data
> > * use the option syntax/infrastructure to store arbitrary data
> > * for example a music tree as described in Jan-Peter's
> > templating
> > 
> > I think package options should be handled in one association list,
> > hidden in a Scheme module and only accessed by specific accessor
> > code.
> > The list elements should have the package name as car and an option
> > *object* as cdr:
> > 
> >   (define package-options
> >'((edition-engraver . ee-options)
> >  (scholarly . scholarly-options)
> >  ...
> > ))
> > 
> > I expect the number of packages loaded in a document ranging from
> > "a
> > few" to "a few dozens", so probably a simple alist should be the
> > right
> > data structure?
> 
> Before we devolve into an efficiency discussion here, let me sketch
> one
> of my "should make sense" projects": our access of alists mostly is
> through our own accessor function ly:assoc-get .  If the elements on
> an
> alist could not just be a key-value pair but a hashtable (for looking
> up
> key-value, of course) or a vector (I think I'd prefer it being 1-
> based
> in spite of making the Scheme indexing less obvious), our lookup
> routines should be able to deal with that.  Some alists could be
> compressed on use, making things like drumtables and note alists
> efficient behind the scenes.
> 
> Such a replacement would work transparently for things like
> 
> package-options.edition-engraver = #'ee-options
> 
> or similar.  So basically there is long-term potential for efficiency
> to
> mostly become a non-issue.

I'm sorry, but I don't fully understand what you are trying to tell me
here. Are you saying that you already had some internal changes in mind
and that storing the package options in an alist is something I
shouldn't really worry about?

BTW: I mistook my own example (shouldn't have started writing late in
the evening ...). What I meant is storing the options in objects, not
assigning symbols:

  (define package-options
   `((edition-engraver . ,ee-options)
 (scholarly . ,scholarly-options)
 ...
))

with ee-options and scholarly-options having been bound to tree objects
before.

> 
> > It seems reasonable to not store a package's options as a nested
> > alist,
> > though. I'd rather consider using a tree implementation in a class,
> > which would for example make it cleaner to encapsulate the
> > behaviour
> > and e.g. implement type checking in that class rather than in the
> > accessor functions, or enable alternative tree implementations if
> > that
> > should become interesting for custom data storage.
> > We have a tree implementation in oll-core at 
> > https://github.com/openlilylib/oll-core/blob/master/scheme/oll-core/tree.scm
> > Would that be something to use here?
> 
> Whatever we do, it should be an implementation detail the user _and_
> the
> package programmers do not really need to know about.  There should
> be
> accessors hiding the organisation.
> 

Yes, that's what I intended. It should be a tree implementation with a
given characteristic that basically noone should bother about. There
should be the *possibility* to drop-in a different tree implementation
(with the same interface) if for whatever reason a package might want
to do so (I could imagine that for some algorithmic use of the data it
might be reasonable to consider some sort of self-organizing tree to
optimize access times - but definitely not for the bread-and-butter use
case of package options).

Urs

Data structure for (package) options

[Urs Liska]

I didn't have time to really think about much (about LilyPond) the past
week, just enjoyed seeing so much constructive discussion.

I think the first thing I'd like to go for with the package/extension
mechanism is storing and handling (package) options.

There are three use cases which are differently closely related to the
actual package mechanism but should be dealt with together:

 * package options
* specified, typed and preset with default values by a package
* handled by getter and setter functions
 * custom options
* behave like package options
* not associated with a package but explicitly called for in user
  code
 * custom data
* use the option syntax/infrastructure to store arbitrary data
* for example a music tree as described in Jan-Peter's templating

I think package options should be handled in one association list,
hidden in a Scheme module and only accessed by specific accessor code.
The list elements should have the package name as car and an option
*object* as cdr:

  (define package-options
   '((edition-engraver . ee-options)
 (scholarly . scholarly-options)
 ...
))

I expect the number of packages loaded in a document ranging from "a
few" to "a few dozens", so probably a simple alist should be the right
data structure?

Package and custom config options are organized as a tree. From my
experience so far the nodes in that tree have 1-10 children each, while
I can imagine this to be 20 to 30 or even 50 in rare cases, but surely
not more.

It seems reasonable to not store a package's options as a nested alist,
though. I'd rather consider using a tree implementation in a class,
which would for example make it cleaner to encapsulate the behaviour
and e.g. implement type checking in that class rather than in the
accessor functions, or enable alternative tree implementations if that
should become interesting for custom data storage.
We have a tree implementation in oll-core at 
https://github.com/openlilylib/oll-core/blob/master/scheme/oll-core/tree.scm
Would that be something to use here?

My idea is to put that in an .scm file, say, scm/options.scm, and the
accessor code in a file ly/options.ly.

Additionally there's a file ly/packages.ly that will define a
\usepackage command. \usepackage will check if there's already an
element in the options alist for the given package name, and if not it
will create one with a new tree object. The package file is then free
to register options which will implicitly be stored in the tree object.

Does that look like a viable approach?

Urs

Re: french beaming incorrectly makes stems longer

[Urs Liska]

Am 25. Januar 2020 08:56:44 MEZ schrieb Werner LEMBERG :
>
>> What is "french beaming" supposed to do/be?
>
>No stems within the beam.

Ah, yes. Sorry for forgetting that...
>
>
>Werner

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

Re: french beaming incorrectly makes stems longer

[Urs Liska]

Am 25. Januar 2020 08:36:08 MEZ schrieb Han-Wen Nienhuys :
>Looks like a bug.

What is "french beaming" supposed to do/be?

>
>On Sat, Jan 25, 2020 at 8:12 AM Werner LEMBERG  wrote:
>>
>>
>> Before adding it to the bug tracker I want to check this group's
>> knowledge whether there is a reason that French beams are longer than
>> normal:
>>
>>   \relative c'' {
>> r16 f d f
>> \override Stem.french-beaming = ##t
>> r16 f d f
>>   }
>>
>> Looking into scores from French publishers this behaviour seems to be
>> incorrect.
>>
>>
>> Werner

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

Re: PATCHES - Countdown for January 23rd

[Urs Liska]

Am Freitag, den 24.01.2020, 11:41 +0100 schrieb Han-Wen Nienhuys:
> On Fri, Jan 24, 2020 at 11:28 AM David Kastrup  wrote:
> 
> > Han-Wen Nienhuys  writes:
> > 
> > > Thanks for keeping track of this.
> > > 
> > > Can you confirm my countdown patches will get pushed without any
> > > of my
> > > involvement (assuming nobody else objects)?
> > 
> > For developers with repository access, the procedure is for them to
> > do
> > the pushing themselves once "patch push" is reached, so if you have
> > doubts about how to do that (only push to staging branch, ever,
> > never to
> > master) or want someone else to do it, holler.
> > 
> 
> I guess I am a developer with repository access, but in Salzburg,
> Werner
> offered to me to do the mechanics of shepherding the patches through,
> and
> I'd like to take that offer. My time is probably better spent
> navigating
> the arcana of the GUILE 2 / 3 transition.
> 

OK, that looks reasonable. That means patches will *not* get pushed
"without any of your involvement" but you have to ask someone, i.e.
Werner to do so. Probably he's monitoring this anyway, but you might
ping him again privately, just in case.

Urs

Re: Packages/modules

[Urs Liska]

Am Mittwoch, den 22.01.2020, 11:43 +0100 schrieb Urs Liska:
> Am Mittwoch, den 22.01.2020, 11:06 +0100 schrieb David Kastrup:
> > Urs Liska  writes:
> > 
> > > Am Dienstag, den 21.01.2020, 11:19 +0100 schrieb Urs Liska:
> > > > > Ok.  One thing to think about is that we want package files
> > > > > to
> > > > > be
> > > > > contributed by "ordinary" users.  But something like
> > > > > 
> > > > > \exportSymbols
> > > > > transposeSequence,instrumentGroup,scratchMyBack
> > > > > 
> > > > > would be perfectly feasible syntactical sugar.
> > > > > 
> > > > 
> > > > I'll be more verbose than probably necessary, just to make sure
> > > > we're
> > > > talking about the same thing.
> > > > 
> > > > ...
> > > > 
> > > > If I got you right then from my experience with openLilyLib and
> > > > creating project environments (which basically are the same as
> > > > packages), I would say:
> > > > 
> > > >  * I'm all for hiding names in packages by default and having
> > > > to
> > > >explicitly expose/export the package's interface
> > > >  
> > > 
> > > One more implication: If variables and functions have to be
> > > explicitly
> > > exported it will be easier for external tools (like Frescobaldi)
> > > to
> > > add
> > > proper support for extensions.
> > > 
> > > I assume that at one point Frescobaldi will
> > > 
> > >  * know about available (core and external) extensions
> > >  * provide ways to "use" an extension (as part of the Score
> > > wizard
> > > and
> > >locally)
> > >  * at that point know about the options that can be passed to
> > > that
> > >package
> > >  * provide autocompletion and highlighting for available symbols
> > >exported from extensions
> > >  * provide actions to generate the code for getting and setting
> > > package
> > >options
> > > 
> > > So when planning the syntax of that export it would be good to
> > > take
> > > the
> > > needs/interest of IDEs into account that will not work with the
> > > result
> > > as LilyPond does but that parse the package files themselves.
> > 
> > Maybe we should have single-command exports after all
> 
> You mean that a package has to export every function or variable
> separately? I think that would be good wrt self-documentation.
> 

This gave me another idea: How would it be if elements (functions,
variables, whatever) exported by packages would have to be addressed
through a package namespace:

* scholarly.annotate exports \criticalRemark
* this can't be used with \criticalRemark but (syntax of course up to
the parser maintainer ;-) ) \scholarly.annotate.criticalRemark

That way the global namespace would be less pollutable, and identical
names in different packages wouldn't be an issue.

A user can still do something like

  criticalRemark = scholarly.annotate.criticalRemark

as a local shorthand.

Urs

Re: GUILE 2/3 and string encoding cost

[Urs Liska]

Am Mittwoch, den 22.01.2020, 20:28 + schrieb Carl Sorensen:
> 
> On 1/22/20, 1:21 PM, "lilypond-devel on behalf of David Kastrup" <
> lilypond-devel-bounces+c_sorensen=byu@gnu.org on behalf of 
> d...@gnu.org> wrote:
> 
> Han-Wen Nienhuys  writes:
> 
> > On Wed, Jan 22, 2020 at 12:01 PM David Kastrup 
> wrote:
> >
> >> Han-Wen Nienhuys  writes:
> >>
> >> > I looked a bit through the GUILE source code to see what is
> going on.
> >> >
> >> > I believe our current hypothesis (LilyPond's slowdown is
> caused by
> >> > expensive unicode transcoding into 32-bit strings) is
> incorrect.
> >> >
> >> > If you look into the source code, you can see that the UTF-8 
> -> SCM
> >> > conversion checks if there are any code points over 255
> >> >
> >> >
> >> >
> >> 
> https://git.savannah.nongnu.org/cgit/guile.git//tree/libguile/strings.c/?id=1b8e9ca0e37fab366435436995248abdfc780a10#n1620
> >> >
> >> > if there aren't, it uses Latin1 encoding ("narrow == 1") to
> encode the
> >> > string as a normal byte array. This code walks the string
> twice, but that
> >> > is very cheap due to CPU cache locality, so it should be
> >> > essentially equivalent to whatever GUILE 1.8 was doing.
> >>
> >> GUILE 1.8 did not walk the string even once
> >>
> >
> > GUILE 1.8 walks it once when you do memcpy.
> 
> Ok, but that's sort of a cheap walk.
> 
> >> > Even so, if the input flie does use UTF-8, there should be
> little
> >> > overhead, because the number of texts that we process is
> always
> >> > small. LilyPond is not a text processor.
> >> >
> >> > So, what hard data do we have on GUILE 2/3 slowness, and
> what does
> >> > that data say?
> >>
> >> That data says "humongous slowdown".  There is not much more
> than
> >> speculation what this is caused by as far as I know.
> >>
> >>
> > Do we have a standardized test file for benchmarking
> performance?
> 
> input/regression/mozart-hrn-3.ly possibly, but it's not
> particularly
> large.
> 
> We don't have a standardized test file, but we do have some
> representative results from a couple of (unknown but described)
> files:
> 
> https://lists.gnu.org/archive/html/lilypond-devel/2018-10/msg00054.html
> 
> Perhaps we could get those files to become standards (along with some
> other, shorter-compiling files).
> 

Not right now but in the not-so-distant future I'd be able¹ to provide
the 650 examples from the Mozart violin school as a set of many small
scores, which might be a nice complement to one large score.

Urs

¹ It's not about copyright (the edition is released under a CC) but
about being ready for that purpose. 

> Carl
>  
> 

Re: Packages/modules

[Urs Liska]

Am Mittwoch, den 22.01.2020, 11:06 +0100 schrieb David Kastrup:
> Urs Liska  writes:
> 
> > Am Dienstag, den 21.01.2020, 11:19 +0100 schrieb Urs Liska:
> > > > Ok.  One thing to think about is that we want package files to
> > > > be
> > > > contributed by "ordinary" users.  But something like
> > > > 
> > > > \exportSymbols transposeSequence,instrumentGroup,scratchMyBack
> > > > 
> > > > would be perfectly feasible syntactical sugar.
> > > > 
> > > 
> > > I'll be more verbose than probably necessary, just to make sure
> > > we're
> > > talking about the same thing.
> > > 
> > > ...
> > > 
> > > If I got you right then from my experience with openLilyLib and
> > > creating project environments (which basically are the same as
> > > packages), I would say:
> > > 
> > >  * I'm all for hiding names in packages by default and having to
> > >explicitly expose/export the package's interface
> > >  
> > 
> > One more implication: If variables and functions have to be
> > explicitly
> > exported it will be easier for external tools (like Frescobaldi) to
> > add
> > proper support for extensions.
> > 
> > I assume that at one point Frescobaldi will
> > 
> >  * know about available (core and external) extensions
> >  * provide ways to "use" an extension (as part of the Score wizard
> > and
> >locally)
> >  * at that point know about the options that can be passed to that
> >package
> >  * provide autocompletion and highlighting for available symbols
> >exported from extensions
> >  * provide actions to generate the code for getting and setting
> > package
> >options
> > 
> > So when planning the syntax of that export it would be good to take
> > the
> > needs/interest of IDEs into account that will not work with the
> > result
> > as LilyPond does but that parse the package files themselves.
> 
> Maybe we should have single-command exports after all

You mean that a package has to export every function or variable
separately? I think that would be good wrt self-documentation.

Would it be possible to export some meta information too? e.g. the type
of a variable, the signature (including if it is a music-function etc.)
of a function? That would be good.
The options do something like that already in their current
implementation. The \registerOption is used as a guard against trying
\setOption with an unregistered option, but the concept can directly be
used for package documentation.

>  and have a
> (non-optional ?) documentation string to be used as mouse-over?  I
> think
> a unified approach to documentation might go a long way towards basic
> usability.

A non-optional docstring sounds nice. This itself doesn't guarantee
that the docstrings are actually *helpful*, but if e.g. Frescobaldi
provides direct access to them pressure would certainly mount to
improve them one by one.

Wilbert plans (I don't recall if he said so in a presentation or just
while chatting) to use his current rewriting of Frescobaldi's LilyPond
parser to provide such "introspection", through a mouse-over effect or
by extending the interface of the autocompletion dropdown. This will
*certainly* make it more straightforward to get used to LilyPond's
internals.

Urs

> 

Re: Packages/modules

[Urs Liska]

Am Dienstag, den 21.01.2020, 11:19 +0100 schrieb Urs Liska:
> > Ok.  One thing to think about is that we want package files to be
> > contributed by "ordinary" users.  But something like
> > 
> > \exportSymbols transposeSequence,instrumentGroup,scratchMyBack
> > 
> > would be perfectly feasible syntactical sugar.
> > 
> 
> I'll be more verbose than probably necessary, just to make sure we're
> talking about the same thing.
> 
> ...
>
> If I got you right then from my experience with openLilyLib and
> creating project environments (which basically are the same as
> packages), I would say:
> 
>  * I'm all for hiding names in packages by default and having to
>explicitly expose/export the package's interface
>  

One more implication: If variables and functions have to be explicitly
exported it will be easier for external tools (like Frescobaldi) to add
proper support for extensions.

I assume that at one point Frescobaldi will

 * know about available (core and external) extensions
 * provide ways to "use" an extension (as part of the Score wizard and
   locally)
 * at that point know about the options that can be passed to that
   package
 * provide autocompletion and highlighting for available symbols
   exported from extensions
 * provide actions to generate the code for getting and setting package
   options

So when planning the syntax of that export it would be good to take the
needs/interest of IDEs into account that will not work with the result
as LilyPond does but that parse the package files themselves.

Urs

Option handling

[Urs Liska]

We have discussed options already on a conceptual level as "package
options", but technically it should be dealt with separately.

Options are not functionally required for the package loading to work,
but they are an integral part of the functionality, and I have found
that their availability has increased my ability to create
infrastructures and "user interfaces" fundamentally/exponentially.
Options are also useful as a low level building block, and I often load
oll-core just for having them available. So I suggest implementing the
option handling as the first step of the extension mechanism so it's in
place when starting on the packages.

The current implementation in oll-core is pretty powerful but it also
has fundamental flaws. Therefore you *can* look up the implementation
at 
https://github.com/openlilylib/oll-core/blob/master/internal/options.ily
but I suggest not to do so and keep the conversation on the conceptual
level like we have so far done with the package mechanism itself.
Eventually it should be coded newly from scratch.


## Interface

The basic interface is to specify an option with

  \registerOption package.component.some.path 

then retrieve the value with

  \getOption package.component.some.path

or change it with

  \setOption package.component.some.path 

Today I'm missing one feature: specifying (and enforcing) an optional
type to the value. This is not something I considered undoable, I just
haven't got around giving it a serious shot. An issue with that is that
I'm pretty sure that the underlying data structure is not ideal and
should be redesigned from scratch (see below), which made me less eager
to patch around with the typing.

There are convenience functions to set and get child options, useful
for iterating over a list of (generated) properties (e.g a list of
provided colors or all files in a directory).

There are also variants of the getter functions ...WithFallback in case
an option is "empty". But I think now this would better be handled with
an optional "default" argument to the normal function.

In the current implementation a package has to make sure itself that
the \registerOption is done before possibly given options are
evaluated. There should be a mechanism/interface to make that
straightforward for package authors.


## Command line options

Option should also be settable through the command line invocation so
it is possible to make use of them from outside (i.e. in invocation
scripts or the Frescobaldi/Emacs).

What I have done so far in projects is simply use a -d option, ignore
the warning about the unknown option and look for that option within,
and look for the option when needed. Actually we do this with
Frescobaldi's Layout Control Options as well, and I'm surprised that
noone has complained about the "warning: no such internal option: ..."
yet.

Of course when reading the command line there is no notion of loaded
packages, so what I think would be necessary is a new command line
option that takes a key=value argument and stores it in an independent
flat alist. That might then look like

  #'((scholarly.annotate.use-colors . #t)
 (stylesheets.base . "my-house-style"))

\usepackage (or whatever) will then check whether options for the given
package are present in the command line *and* registered in the
package.

I'm not sure if there are security issues to be considered beyond
executing LilyPond in the first place.


## Option definition

oll-core abuses the ly:context-mod? implementation for its option
interface. For example critical remarks can be entered with
scholarly.annotate like this:

  \criticalRemark "e' in manuscript" es'

or

  \criticalRemark \with {
message = "e' in manuscript"
item = Accidental
  } es'

I like this very much as a user interface because it is both powerful
and expressive. However it is clearly an abuse:

 * the predicate ly:context-mod? clearly refers to something
   fundamentally different
 * message = "e' in manuscript" is not represented as a pair but rather
   as '(assign item Accidental)

I have written convenience functions to create an alist from the
expression, and Stefano Troncaro has done an amazing job making the
configuration flexible and robust, for example with enforcing types and
providing defaults. However, when included in LilyPond itself it would
clearly be good to have a native implementation.

>From what I can see this should be a new predicate, say ly:options? and
a parser item that works like the above but with a different keyword.
If this suggestion is agreed upon we should discuss the details
separately.


## Data Structure

Currently oll-core maintains one single nested alist for storing
options which is accessed by the getter and setter functions. The
rationale was to pollute the namespace with only one single variable
oll-options that could be considered "pretty" safe by the prefix. Now I
think the data structure(s) holding the options would better be hidden
inside a Scheme module  

Re: Document C++ structs for slur scoring (issue 571380043 by hanw...@gmail.com)

[Urs Liska]

Am Dienstag, den 21.01.2020, 03:56 -0800 schrieb lemzwerg--- via
Discussions on LilyPond development:
> Very nice, thanks!
> 
> https://codereview.appspot.com/571380043/
> 

I've only looked at it cursorily, but I think this is really a step in
the right direction (even if it may feel like the drop in the desert).
Also, renaming cryptic variables to still-short-but-digestible names is
a valuable help when looking at these files.

Urs

Re: Packages/modules

[Urs Liska]

Am Montag, den 20.01.2020, 23:45 +0100 schrieb David Kastrup:
> Urs Liska  writes:
> 
> > OK. The *current* behaviour of oll-core is:
> > 
> > * loaded packages and modules (let's for now keep the existing
> > names)
> >   are accounted for in an alist.
> > * if the requested package/module is already loaded:
> >   * if options are passed, try setting them (overriding defaults
> > and/or values set by an earlier loading)
> > => This behaviour has to be discussed
> 
> Sounds to me like overriding defaults is perfectly reasonable (else
> specifying options wouldn't work at all) 

Yes, of course that's the idea behind it.

> and overriding values set by an
> earlier loading should flag an error.

That's probably right. Sometimes giving users too much controls and to
many alternatives makes the interface convoluted and as a result
confusing.

> 
> Maybe packages should have two ways of overriding a default: set a
> default and require a value.
> 
> A request in a user document is always treated as a requirement, two
> packages setting defaults leads to an error (or a warning and a
> revert
> to the original default?) unless some package (or the user) requires
> a
> particular setting which takes priority.  And of course different
> requirements cause an error.
> 
> Or is this too contrived, and only requirements should be allowed?

I don't find this too contrived in general, but there's one thing where
you may be too generic in the description.

There are two basic use cases for overriding default values: Loading a
package with options and setting an option explicitly after loading the
package. The other complication is in packages implicitly loading other
packages.

The simple case is when a user explicitly sets an option with (current
syntax) \setOption package.module.some.option-leaf value. This can
happen to change the global behaviour or to change something at some
point in the score/music expression (depending on how the value is
used). This is what you called a requirement and should always be
respected. If *that* triggers an error or produces unwanted results
it's clearly the user's responsibility.

The other case is when a package depends on another one and loads it,
which may result in the depended-on package being loaded more than
once, possibly with conflicting options.

Say you have a helper package [A] providing a data structure for some
use case (for example there is the `breaks` package that provides some
alists and accessor functionality to maintain sets of line/page
breaks).
Such a package may expose an option with a default value (currently the
syntax is \registerOption package.option.path default-value (specifying
types is on my wish-list)).
A client package [B] may just load that while a client package [C]
might load it overriding the value, for example because it wants [A] to
work in a specific mode. Another client package [D] may override the
option with a different value or pass the choice along to the user.
This is where conflicts may occur, and where it is not in our reach to
know at design time (designing the system, i.e. now) whether these
conflicts will be harmless or not. So erroring may be the safest
choice. Actually that would be the situation in LaTeX when you have to
know that two packages "don't work well" together.

After having written this I have the impression that the spot to
address your distinction between "setting" defaults and "requiring"
values would be:

 * A package "knows" whether a current value is at its default value or
   not (either with a "changed" flag or by on-the-fly comparison)
 * When to the *loading* of a package an option is passed that has
   already been changed it is considered illegal, and a warning or
   error is raised (to be decided, probably an error).
 * When an option is modified explicitly from user code it is simply
   done.

I will raise the issue of how options are handled and stored in a
separate thread, we should keep that out of the current discussion.

> >>> ...
> 
> > > And of course Guile has modules.  Do we already have a thought
> > > about
> > > how
> > > to relate to the module system?  
> > 
> > Yes, that's right! \loadModule is definitely a bad name.
> 
> I was not as much worrying about the name, actually, 

OK, but still that name should be discarded.

> but about the
> semantics.  Seems to me like defaulting to a separate module might be
> a
> reasonable thing.  It would require exporting whatever you want to
> use
> from outside the module.

OK, I *think* I see. I'll comment on that together with the other stuff
at the end below.

> 
> > In LilyPond there's a fundamental difference between \include and 
> > #(use-modules, which is not the case 

Packages/modules (was: Extension management, first sketch)

[Urs Liska]

Am Montag, den 20.01.2020, 14:14 +0100 schrieb David Kastrup:
> Urs Liska  writes:
> 
> > Am Montag, den 20.01.2020, 10:27 +0100 schrieb Urs Liska:
> > > * A core extension library shipping with LilyPond will be
> > > initiated. 
> > >   Extensions that are considered core functionality (prime
> > > candidates:
> > >   edition-engraver, stylesheets) will eventually be moved here
> > > from
> > >   openLilyLib, additionally special functionality (e.g.
> > > gregorian.ly,
> > >   arabic.ly) may over time be moved there to expose the
> > > difference
> > >   between core functionality and use-case specific modules more 
> > >   clearly. These tools will then be called through `\loadModule`
> > >   instead of `\include`, which will be easy to handle with
> > >   convert-ly rules. Probably it would be a good idea to
> > > eventually 
> > >   expose *all* non-standard notation through explicit packages
> > >   and have that nicely describe in the LM. This too will not be
> > >   called openLilyLib.
> > 
> > Thinking about it I would go one step further:
> > 
> > Currently we have a /ly folder in the installation which contains
> > core
> > files like music-functions-init.ly on the one hand, and on the
> > other
> > hand optional files that users can \include for specific
> > functionality,
> > such as the ones I have given as examples above.
> > 
> > I think now that *all* the files that are not included
> > unconditionally
> > but only upon user request should be treated as packages. This will
> > make the code structure clearer, since there is a clear distinction
> > between the files LilyPond needs/uses for its startup (then *all*
> > files
> > in /ly) and optional files at the user's disposition.
> 
> Seconded.
> 
> Regarding \loadModule :  LaTeX has \documentclass for defining a
> document layout.  LilyPond does not have files dedicated to that
> purpose
> yet so that's something for later.

Yes, I think we can ignore that for now.
Everything a documentclass does I do with an initial include of the
infrastructure, and I think everybody else would do so as well. 

Conceptually I can see what a document class might be in notation, but
I don't see for what a separate construct would be necessary.

> 
> With regard to packages, LaTeX has \usepackage from user documents
> and
> the sort-of equivalent \RequirePackage from package code (not sure
> what
> the rationale for the difference is, there may be something related
> to
> when loading is allowed) and a counterpiece \ProvidePackage.

My impression is that - like with \newcommand, \renewcommand and
\providecommand they want to give control over the handling of
conflicts from already loaded packages.

> 
> Emacs has
> require is a built-in function in ‘C source code’.
> 
> (require FEATURE  FILENAME NOERROR)
> 
>   Probably introduced at or before Emacs version 15.
> 
> If feature FEATURE is not loaded, load it from FILENAME.
> If FEATURE is not a member of the list ‘features’, then the
> feature is
> not loaded; so load the file FILENAME.
> 
> If FILENAME is omitted, the printname of FEATURE is used as the
> file
> name, and ‘load’ will try to load this name appended with the
> suffix
> ‘.elc’, ‘.el’, or the system-dependent suffix for dynamic module
> files, in that order.  The name without appended suffix will not
> be
> used.  See ‘get-load-suffixes’ for the complete list of suffixes.
> 
> The directories in ‘load-path’ are searched when trying to find
> the
> file name.
> 
> If the optional third argument NOERROR is non-nil, then return
> nil if
> the file is not found instead of signaling an error.  Normally
> the
> return value is FEATURE.
> 
> The normal messages at start and end of loading FILENAME are
> suppressed.
> 
> [back]
> 
> and a matching
> 
> provide is a built-in function in ‘C source code’.
> 
> (provide FEATURE  SUBFEATURES)
> 
>   Probably introduced at or before Emacs version 15.
> 
> Announce that FEATURE is a feature of the current Emacs.
> The optional argument SUBFEATURES should be a list of symbols
> listing
> particular subfeatures supported in this version of FEATURE.
> 

OK. The *current* behaviour of oll-core is:

* loaded packages and modules (let's for now keep the existing names)
  are accounted for in an alist.
* if the requested package/module is already loaded:
  * if options are passed, try setting them (overriding defaults
and/or values set by an ear

Re: github mirror of lilypond?

[Urs Liska]

Am Montag, den 20.01.2020, 16:53 +0100 schrieb David Kastrup:
> David Kastrup  writes:
> 
> > Werner LEMBERG  writes:
> > 
> > > > > Han-Wen has recently pushed a bunch of changes directly to
> > > > > Rietveld, most of them quite uncontroversial.  I assume that
> > > > > this
> > > > > is as good as an e-mail :-)
> > > > > 
> > > > > I thus suggest that after his patches have been reviewed,
> > > > 
> > > > How are they going to get reviewed when there is nothing
> > > > pointing to
> > > > them?  How would anyone including Han-Wen know when the review
> > > > phase
> > > > ends?
> > > 
> > > Well, as has been pointed out, pull requests at github don't have
> > > 'review phases', and what we have here is comparable IMHO.
> > > 
> > > One developer (or maybe two, just to be sure) acknowledges the
> > > patch,
> > > and that's it.  Kind of a highway solution for trivial things.
> > 
> > Trivial things from a developer with push access can be just
> > pushed.
> > Complex or otherwise contential things warrant a chance for
> > developers
> > to take a look at it.  "Half a chance" seems an unnecessary
> > complication.
> 
> At any rate: we haven't had a protocol for patches not going through
> the
> regular process.  Maybe we should use the Signed-off-by: convention
> for
> such patches, including the original submitter and the LGTM
> votes?  It's
> probably mostly psychological, but it suggests a bit of
> accountability/responsibility.
> 

I would like to add to that. With my few contributions to the actual
LilyPond codebase I was several times hit hard by last-moment
objections in the countdown stage.

This is totally annoying and also frustrating - but what would be the
alternative? Obviously there was something that should not go into the
code base, and the fact that we're so few that not everyone has the
opportunity to look at all patches immediately should not be a
"justification" for letting stuff slip through.

Re: Extension management, first sketch

[Urs Liska]

Am Montag, den 20.01.2020, 10:27 +0100 schrieb Urs Liska:
> * A core extension library shipping with LilyPond will be initiated. 
>   Extensions that are considered core functionality (prime
> candidates:
>   edition-engraver, stylesheets) will eventually be moved here from
>   openLilyLib, additionally special functionality (e.g. gregorian.ly,
>   arabic.ly) may over time be moved there to expose the difference
>   between core functionality and use-case specific modules more 
>   clearly. These tools will then be called through `\loadModule`
>   instead of `\include`, which will be easy to handle with
>   convert-ly rules. Probably it would be a good idea to eventually 
>   expose *all* non-standard notation through explicit packages
>   and have that nicely describe in the LM. This too will not be
>   called openLilyLib.

Thinking about it I would go one step further:

Currently we have a /ly folder in the installation which contains core
files like music-functions-init.ly on the one hand, and on the other
hand optional files that users can \include for specific functionality,
such as the ones I have given as examples above.

I think now that *all* the files that are not included unconditionally
but only upon user request should be treated as packages. This will
make the code structure clearer, since there is a clear distinction
between the files LilyPond needs/uses for its startup (then *all* files
in /ly) and optional files at the user's disposition.

Urs

Re: Finding files in include paths

[Urs Liska]

Am Montag, den 20.01.2020, 10:34 +0100 schrieb Han-Wen Nienhuys:
> I documented it in https://codereview.appspot.com/573400043/
> 
> you could add a scheme callback similar to ly:source-file, eg.
> ly:source-find to do the equivalent of kpsewhich

Thanks. I have to go to work now, but I'll have a look ASAP:

Urs

> 
> On Mon, Jan 20, 2020 at 9:22 AM Urs Liska 
> wrote:
> > Hi all,
> > 
> > how/where is the file searchign with LilyPond's search path is
> > implemented?
> > 
> > If I write 
> >   \include "a/relative/path"
> > the given path is searched for relative to all search paths known
> > to
> > LilyPond.
> > 
> > Is there a way to do the same in Scheme, say
> >   (file-visible-to-lilypond "a/relative/path")
> > to determine whether a target can be found within any LilyPond
> > search
> > path? Probably the function should return the absolut path, similar
> > to
> > what kpsewhich does.
> > 
> > I need that to check whether a certain file is present (and then
> > open
> > it) without knowing the absolute location.
> > 
> > Urs
> > 
> > 
> 
> 

Extension management, first sketch

[Urs Liska]

Hi,

one of the results of yesterday's developer meeting in Salzburg
[someone™ should provide a more concise summary than the notes in the
GoogleDoc] was that I should go forward "integrating openLilyLib" as
LilyPond's official extension mechanism.

I spent my travel back home reading through the code and writing a few
summaries and drafts etc., and while doing so I came to the conclusion
that the actual task, i.e. what has to be done "now" is surprisingly
(not to say, disappointingly) small.

I think it is best to start a discussion without looking at the current
implementation at all, so any issues (architecture considerations or
coding critique) with the existing oll-core code base won't distract us
from the conceptual perspective. So I wrote up a very short summary of
how I think an extension system should look like and what initial steps
there are to be taken. If anything is unclear or needs more factual or
conceptual detail I'll of course happily expand on it.

For reading convenience I attach a PDF version, but for inline
commenting the text below should be better.

Best
Urs


## Current State

* openLilyLib is a set of extension packages, providing high-level
  functionality
* `oll-core` provides the basic interface and implements required and
  additional functionality.

## Overall Outline

* Relevant functionality will be moved from `oll-core`
  to LilyPond proper, providing the main extension mechanism
  as well as some of the additional functionality (option
  handling, logging ["oll:" function to report status and errors]).
* The extension mechanism provides the commands `\loadPackage` and
  `\loadModule`, and it allows configuration options to be passed to
  either. It also handles package dependencies and implicit loading.
  (one example for using options (just for getting an idea) would be
  \loadPackage \with { modules = annotate.choice } scholarly. )
* This will *not* be called openLilyLib anymore (but "is" LilyPond's
  unnamed extension mechanism).
* A core extension library shipping with LilyPond will be initiated. 
  Extensions that are considered core functionality (prime candidates:
  edition-engraver, stylesheets) will eventually be moved here from
  openLilyLib, additionally special functionality (e.g. gregorian.ly,
  arabic.ly) may over time be moved there to expose the difference
  between core functionality and use-case specific modules more 
  clearly. These tools will then be called through `\loadModule`
  instead of `\include`, which will be easy to handle with
  convert-ly rules. Probably it would be a good idea to eventually 
  expose *all* non-standard notation through explicit packages
  and have that nicely describe in the LM. This too will not be
  called openLilyLib.
* openLilyLib will remain similar to what it is now, a curated
  collection of standard packages that are not mature enough or too
  specific to be included in LilyPond itself. The extension mechanism
  will find openLilyLib packages through LilyPond's search path.
* Packages can be stored anywhere on disk (=> LilyPond search path),
  so on the long term it may be interesting to set up an uncurated 
  package manager like npm or CTAN/TeX Live.
* Frescobaldi will provide a user interface to manage extensions but
  also for using them in documents (e.g. it will know about available
  configuration options and provide an action (context menu/dialog)
  to use a given package).


roadmap.pdf
Description: Adobe PDF document

Finding files in include paths

[Urs Liska]

Hi all,

how/where is the file searchign with LilyPond's search path is
implemented?

If I write 
  \include "a/relative/path"
the given path is searched for relative to all search paths known to
LilyPond.

Is there a way to do the same in Scheme, say
  (file-visible-to-lilypond "a/relative/path")
to determine whether a target can be found within any LilyPond search
path? Probably the function should return the absolut path, similar to
what kpsewhich does.

I need that to check whether a certain file is present (and then open
it) without knowing the absolute location.

Urs

Re: mirroring lilypond on github

[Urs Liska]

.
>
>contributions in GitHub are usually stored on a branch + fork owned by
>the contributor, e.g.
>
>  https://github.com/mikesol/lilypond/
>
>branch code_of_conduct.

I think that needs clarification.
Forks are "usually" used by people without push access to a repository. People 
*with* push access have their PRs on branches *in* the repo. So these would be 
overwritten.

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

Re: github mirror of lilypond?

[Urs Liska]

Am Sonntag, den 19.01.2020, 20:31 + schrieb Erlend Aasland:
> True. But, there are GitHub alternatives that are free, for example
> Gitea.

Yes, but self-hosting a Git repository software (well, I have a Gitea
instance on my server) is an involved thing, and I don't think it's
reasonable to expect putting that burden and responsibility on
someone's personal shoulders.
I don't think that's an option for us either, although it would be the
way to go on a conceptual level. We'd have some money to pay for the
server and the maintenance...

Urs

Re: github mirror of lilypond?

[Urs Liska]

Am Sonntag, den 19.01.2020, 07:20 +0100 schrieb Werner LEMBERG:
> > While that may be true, there are already GNU projects using GitHub
> > as their host, for example gnucash and gnuradio.
> 
> Gnucash uses github as a mirror only, see
> 
>   https://wiki.gnucash.org/wiki/Git#code.gnucash.org
> 
> But gnuradio admittedly uses github.  I'm 100% sure that if RMS knew
> that he would ask them immediately to move the source to a host that
> is more GNU-compliant.
> 
> However, there is nothing bad with mirroring at github, so it's OK if
> LilyPond does the same.

Considering the start of this thread I think there should be some
automatic way of keeping such a mirror up-to-date. It has happened more
than once that people came to think this *is* the code base and try to
patch it.

> 
> > As it stands, GitLab would probably be a more viable candidate to
> > look at than GitHub.
> 
> I agree.  IMHO, the main repository should stay at Savannah, though.

One consideration that hasn't been mentioned this time is that GitHub's
terms of service allow them to discontinue support for a given project
for any reason without notice.

However, I also count to the group of people who would strongly prefer
a more convenient and more welcoming way of contributing. Not in terms
of the review process. While having run into that wall more than once I
agree that it's important to have that tedious kind of process. 
The main advantage of Github and its clones (Gitlab, Gitea) I see over
the current process is a) that the code review is done on the actual
code, if you will, and integrated with the comments, and b) that when a
patch is accepted it can be simply merged (or squashed with/without
merge commit). I'm always feeling insecure when basically redoing my
patch before pushing to staging.

Urs

> 
> 
> Werner
> 

Re: [Notensatz im 21. Jahrhundert] Lily+Scheme bootcamp?

[Urs Liska]

Am Montag, den 13.01.2020, 15:42 -0500 schrieb Kieren MacMillan:
> Hello future Salzburg-ers!
> 
> Knowing the way my life works, and the fact that I’ll be in Salzburg
> for four days without the normal distractions (family, etc.), and at
> hand will be a rather wonderful collection of brains and facilities…
> Is there any way that someone (Urs? Harm? David N?) could run a
> relatively short (90'?) "Intro to Scheme-ing In Lilypond" bootcamp? 

Hm, and when? Right now I can't see a slot for something like that. The
problem *I* see with these four days is basically the programme forcing
too many decisions what to attend and what to miss already ...

Best
Urs

> Nothing too formal: just a stream-of-consciousness “Hello World”
> tutoring for those of us who want to get into Scheme-ing, but real
> life seems to always get in the way?
> 
> I’d be happy to pay a little something — in currency hard (€) or soft
> (suds/grapes) — for the time & expertise.
> 
> Thanks,
> Kieren.
> 
> 
> Kieren MacMillan, composer (he/him/his)
> ‣ website: www.kierenmacmillan.info
> ‣ email: i...@kierenmacmillan.info
> 
> 

Re: [Notensatz im 21. Jahrhundert] edition-engraver session, Sunday Jan 19 @ 15:30

[Urs Liska]

Hi Kieren,

Am Samstag, den 11.01.2020, 11:03 -0500 schrieb Kieren MacMillan:
> Hello colleagues!
> 
> I just had a wonderful video-chat with Jan-Peter, as part of the
> preparations for my session “The Edition-Engraver: The benefits and
> limitations of tweaking LilyPond scores” at next week’s
> [un]conference.
> 
> Rather than simply talk for thirty minutes about how I use the
> edition-engraver, I feel the very best use of this historic
> opportunity — having so many important Lilypond developers together
> in one place at one time — is to dedicate some portion of my session
> time to a discussion/brainstorm regarding the current roadblocks
> facing the edition-engraver, both technically and (to a much lesser
> extent) from the perspective of wider adoption and use.

This is a very good idea, and it is good you brought it up for
discussion. I had a very similar plan with regard to the openLilyLib
presentation on Sunday.

I think the main target audience for the Sunday topics is people who
are very much into LilyPond and its development anyway. Probably there
are random participants, but anybody who stays for another night will
very much have a quite specific reason to do so. Nobody will need to
learn at that point what the edition-engraver or openLilyLib are
generally.

> 
> I’m proposing I spend the first 10-15 minutes giving a more-or-less
> traditional presentation: an introduction to the extension/framework,
> examples of usage, best practices when coding with the EE, and so
> forth. 

Given what I wrote above I can imagine you could even reduce that to
not more than 10 minutes by sending example files before.

> Then, in the second "half" of the time slot, I facilitate/mediate a
> discussion — primarily between Jan-Peter and the main Lilypond and
> Frescobaldi development teams — in which we brainstorm how to bring
> the EE to its greatest potential, solve low-level technical issues,
> deeply integrate it in Frescobaldi, etc. The goal of this second
> section would not be to have solved the problems in 15-20 minutes, of
> course, but would just provide a chance for everyone to end up on the
> same page about this powerful tool and how it might move forward.

I would put “solving low-level technical issues” to the bottom of that
list. This is something that may not be too suitable for discussion in
the larger group since (I suspect) nobody except Jan-Peter will be able
to discuss such issues spontaneously.

What I think would be most helpful and making most of the “historic
situation“ would be discussing ways how to get the edition-engraver
integrated in LilyPond. This is raised every now and then, everybody (I
think) agrees to that, but it doesn't really have any substantial
progress. Which is - just like the deplorable state of openLilyLib's
documentation - due to the fact that Jan-Peter won't be able to achieve
that on his own and that never any community effort has gained any
traction.

Integration of the edition-engraver in Frescobaldi is another issue
with additional implications. We won't directly support it until it is
integrated in LilyPond. The only way to hard-code edition-engraver
support into Frescobaldi would be to include the code directly in the
Frescobaldi code, as we did with the code for the Layout Control Mode.
But I think everybody will agree that such a fork (which it would
effecitvely be) is a terrible idea.
However, there is one road that can be pursued, and that is
Frescobaldi's new extension API. I plan (have already old code that
could be adapted) to create an openLilyLib extension. This will allow
the Frescobaldi user to directly download, install and manage
openLilyLib and its packages and should also provide tools (shortcuts,
context menu items and maybe something like the Quick Insert Panel) to
simplify the inclusion of openLilyLib (a GUI for selecting and creating
the package loading code).
On top of that (but I haven't thought this through) that basic
extension will provide an infrastructure/API for *other* extensions
that may be added for specific packages. The prime use case *I* am
thinking of will be the scholarLY package, i.e. an annotation
editor/viewer. But such a package for the edition-engraver will also be
extremely helpful.

> 
> Jan-Peter is on board for this approach. How does it sound to
> everyone else? Please let us know if you plan to attend, and if so
> whether you’d be an interested/willing participant in a
> brainstorm/discussion.
> 

I think the above makes clear that I'm very much in favor of your
suggestion. However, I suggest we reorder the program for Sunday, and I
think it's not an issue to do that at this point. Regardless of the
actual points in time the three slots should be in the order
Frescobaldi => openLilyLib => edition-engraver. The Frescobaldi part
will introduce the extension concept, and openLilyLib is the framework
in which the edition-engraver operates (and any discussion about its
future should build upon the discussion of 

Re: move some OLL functions to vanilla LilyPond? [was: A suggestion: add \rf to built-in dynamics]

[Urs Liska]

Am 7. Januar 2020 23:53:42 MEZ schrieb Andrew Bernard 
:
>Hi Malte,
>
>\shapeII is a function I use heavily - heavily - in all my work. It's
>indispensable for me at least. I'm very familiar with OpenLilyLib, and
>contribute a bit to it, so it's not an issue for me, but that's a
>function that really ought to go into lilypond core in my view.
>
>As for newbies not using OpenLilyLib, you can't make such as assertion
>because you cannot say what their level of experience with computers
>and software is, so I don't think that's a pertinent point.
>
>Perhaps ois the NR had instructions for how to install and use
>OpenLilyLib as a powerful addon, then it make have more 'street cred'
>and become more widely used in the way it is intended, not just copy
>and paste of bits. I do think people see it as far outside Lilypond
>and don't want to get involved, somehow.

I agree that openLilyLib could be introduced in the documentation or at least 
on the website.
However, I don't think OLL is ready for that. I I wouldn't want it to be 
officially endorsed as long as it is not at least basically documented.

Urs
>
>Andrew
>
>
>On Sat, 4 Jan 2020 at 22:34, Malte Meyn  wrote:
>
>> Am 04.01.20 um 12:29 schrieb Malte Meyn:
>
>> One could argue that openlilylib can be installed easily but users
>might
>> not want to install “addons” for basic tasks like this. (In fact, I
>have
>> never used openlilylib apart from copying definitions from the
>> definitions.ily files and I see myself as a advanced user; I don’t
>think
>> that many newbies will use oll …)
>>
>> Same argument for \shapeII.
>>

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

Re: move some OLL functions to vanilla LilyPond? [was: A suggestion: add \rf to built-in dynamics]

[Urs Liska]

4. Januar 2020 12:34, "Malte Meyn"  schrieb:

> Am 04.01.20 um 12:29 schrieb Malte Meyn:
> 
>> But that brings me to another question: Shouldn’t we add the \dynamic > 
>> command from openlilylib to
>> vanilla LilyPond? This would allow users to > have “p dolce”, “più f” and 
>> ‘exotic’ dynamics like
>> “mfz” whithout having > to define extra commands using make-dynamic-script.
> 
> One could argue that openlilylib can be installed easily but users might not 
> want to install
> “addons” for basic tasks like this. (In fact, I have never used openlilylib 
> apart from copying
> definitions from the definitions.ily files and I see myself as a advanced 
> user; I don’t think that
> many newbies will use oll …)


There are good arguments to make openLilyLib more accessible to the general 
user (at the conference in Salzburg next week discussing the state of this will 
be part of my agenda). There are significant packages available that can be 
extremely useful but seem not really suitable to be merged into vanilla 
LilyPond.

OTOH from the many smaller functions scattered over the "snippets" and oll-misc 
repository many might really be added to the main program. The dynamic 
functions might be prime candidates for that.
That means someone should prepare a documented patch with regtest (if 
appropriate) and submit it for review.
If nobody is willing to invest that amount of time the functions may well stay 
available in openLilyLib ...


> 
> Same argument for \shapeII.


This is definitely something I'd want to see in LilyPond. Maybe it has to be 
significantly updated by now, and it should *not* have that indexed name. If 
*replacing* \shape with \shapeII is not an option I'd suggest finding a 
completely new name.

Urs

Re: A snippet for editing curves using the mouse and reporting changes to the .ly file

[Urs Liska]

Am 16.12.19 um 10:18 schrieb Urs Liska:

 * For integration in LilyPond the functionality should be wrapped into
   a single file that can be included. Including the file should
   automatically activate the functionality.
   Maybe there should be a second includable file that does *not*
   automatically activate the functionality but provides a command to
   selectively switch it on and off or apply it to only one curve.
   There may be people who don't want the whole score to be polluted
   with the control points but only see the slur they want to edit.



Forgot one thing here: In addition to have an includable file in the 
LilyPond directory I'd suggest making it also available through a 
command line option. This will make it easier to use the functionality 
from external scripts or editors.

Perception of LilyPond development status

[Urs Liska]

Any LilyPond dev who does have a Facebook account might have a look at 
this interesting, although somewhat sad, discussion. I think it gives a 
clear picture of how our current state of development is perceived by users:


https://www.facebook.com/groups/gnulilypond/permalink/10157762793383529/

Urs

Re: Poster for music engraving conference

[Urs Liska]

Hi Jan-Peter,

that sounds like a very nice idea.

However, I'm so involved in the conference already (along with my other 
duties which are quite overwhelming right now) that I can't commit to 
that beyond maybe occasional commenting or helping out with some 
lyluatex syntax/options.


From what I see in this thread I have the impression that it's 
necessary that *someone* steps out, creates a repository and a basic 
file, having some confidence not to stay alone with the task.


Best
Urs

Am 05.12.19 um 15:43 schrieb Jan-Peter Voigt:

Hi Werner, hi Bernhard, and especially Urs ;-),

what about using a LaTeX a0poster-template together with lyluatex? That
would make collaboration with GIT straightforward.
A quick search brought up these templates:
https://www.cfd.tu-berlin.de/~panek/tex/poster/poster.html
http://www.latextemplates.com/cat/conference-posters

Though, the template(s) need some adaption to work with lualatex.

Even though my schedule is quite tight I would like to contribute.
I have obtained the permission from two publishers to use single
excerpts/pictures from the St.Mark passion (Ortus Berlin, I will talk
about it) and a contemporary score composed by Hermann Keller (Edition
Juliane Klein Berlin).

Jan-Peter


Am 04.12.19 um 12:05 schrieb Werner LEMBERG:

Folks,


the music engraving conference in Salzburg (January 17.-19.) aims to
present as much note engraving programs as possible.  While some
companies send representatives (e.g., Dorico, Capella, Finale) – some
even with talks – we don't have something similar for LilyPond in the
main part of the conference.

Instead, we would like to have a poster (in A0 format) that shows how
LilyPond works, together with some showcase results.

Now my question: Are there people who are willing to produce such a
poster?  Has anyone already done something similar for other
conferences?


 Werner

Re: shepherd a patch?

[Urs Liska]

Am 15. November 2019 14:35:26 MEZ schrieb David Nalesnik 
:
>On Fri, Nov 15, 2019 at 12:33 AM Urs Liska 
>wrote:
>>
>> Hi David,
>>
>> I feel responsible for this because I know where this is coming from 
>;-)
>
>Hah! :)  (Seriously, though, this is something that I've wanted and
>Kieren has clamored for...)

Ah yes, you said so back then.

Coincidentally, you can see lots if examples in the project that was released 
this week.

Urs
>

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

Re: shepherd a patch?

[Urs Liska]

Hi David,

I feel responsible for this because I know where this is coming from  ;-)

You can send me the patch. However, it's a long time since I uploaded 
anything, so I'm not sure my set-up still works. But I'll try.


Best
Urs

Am 15.11.19 um 04:10 schrieb David Nalesnik:

Hi all,

I have a patch which implements measure-attached spanners.  I am
having a devil of a time getting the patch up for review.  I simply
can't get git-cl to upload it.  (I suspect this has something to do
with the number of files it touches--my system times out before
everything can be uploaded.)

Would someone be willing to shepherd the patch for me?

Attached is a PNG which shows the output of one of the regtests.

This would _really_ be appreciated.  Thanks!

David

Re: lilyglyphs: Python 2 deprecation

[Urs Liska]

Am 12. November 2019 10:50:45 MEZ schrieb David Kastrup :
>Werner LEMBERG  writes:
>
>>>> This package is written by Urs Liska , who is
>>>> quite busy these days.  In case you have experience with Python 2
>>>> to 3 conversion, please help produce a new version!
>>> 
>>> Should it still be backwards compatible with Python 2.7 if possible
>or
>>> is it ok to drop Python2 backwards compatibility completely? Option
>>> one is possible, option two gives cleaner code, and is easier to
>>> maintain in future.
>>
>> I favour option one.  Inspite of the announced `death' of Python 2
>I'm
>> quite sure that this version series will stay for many years.
>

I wouldn't see the need for backwatd compatibility, but I must admit I haven't 
thought about the issue too much.

>With regard to GUB, 2.7 compatibility makes for a much nicer transition
>period.  But GUB is not likely involved in uses of that package

Correct, lilyglyphs doesn't play any role in creating or building LilyPond. 

Urs

> which
>seems to be mainly used in a TeXlive context.  I haven't checked, but I
>think that TeXlive is pretty much prepared to use Python3.

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

Re: updated Granados example

[Urs Liska]

27. September 2019 08:55, "Urs Liska"  schrieb:

> Hi Werner,
> 
> thanks for working on this.
> 
> I have the impression it would be nice to add at least one example with an 
> alternative notation
> font to the example page. Here is the list of freely available fonts:
> https://github.com/openlilylib-resources/lilypond-notation-fonts/tree/master/fonts
>  (note that while
> it is *legal* to use Abraham's other fonts for which he revoked the free 
> license we shouldn't use
> them on our website (which is unfortunate since Haydn or Gutenberg1939 would 
> make really nice
> examples.
> 
> Considering the existing content of the examples page we should probably 
> limit this to one example,
> and for that it would probably make sense to use LilyJAZZ since that might be 
> the most-wanted
> feature. Maybe reuse this "piece"?
> https://github.com/frescobaldi/frescobaldi/pull/1075#issuecomment-529471468
> 

PS: the source for this can be found here: 
https://github.com/frescobaldi/frescobaldi/blob/master/frescobaldi_app/fonts/templates/musicfont-realbook.ly

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

Re: updated Granados example

[Urs Liska]

Hi Werner,

thanks for working on this.

I have the impression it would be nice to add at least one example with an 
alternative notation font to the example page. Here is the list of freely 
available fonts: 
https://github.com/openlilylib-resources/lilypond-notation-fonts/tree/master/fonts
 (note that while it is *legal* to use Abraham's other fonts for which he 
revoked the free license we shouldn't use them on our website (which is 
unfortunate since Haydn or Gutenberg1939 would make really nice examples.

Considering the existing content of the examples page we should probably limit 
this to one example, and for that it would probably make sense to use LilyJAZZ 
since that might be the most-wanted feature. Maybe reuse this "piece"? 
https://github.com/frescobaldi/frescobaldi/pull/1075#issuecomment-529471468

Also, I think section 3.4.4 of the NR should be updated to be much more 
explicit and suggestive. If I can find the time I'd volunteer to do this.
http://lilypond.org/doc/v2.19/Documentation/notation/replacing-the-notation-font.html

Urs

26. September 2019 22:35, "Werner LEMBERG"  schrieb:

> Attached you can find my revised version of the three bars from the
> Granados piece. The staff size is still smaller than the original
> since it is not possible currently to typeset that dense with LilyPond
> (while getting an optically pleasing result) – but it is larger than
> previously :-)
> 
> Note that for testing purposes I've applied Dave Nalesnik's patch for
> tuplet slurs
> (http://lilypond.1069038.n5.nabble.com/tuplet-slurs-td199904.html).
> Interestingly, this was never added to the tracker; I've asked David
> to do that now.[*]
> 
> Werner
> 
> [*] What's available in the link is not his latest patch, according to
> the e-mail thread.
> 
> %
> % This is a brief passage from Enrique Granados %
> % Goyescas, "Coloquio en la Reja." %
> %
> 
> \version "2.19.83"
> 
> \include "example-header.ily"
> 
> #(set-global-staff-size 14)
> 
> \paper {
> paper-height = 70\mm
> }
> 
> csh = \change Staff = "high"
> csm = \change Staff = "middle"
> csl = \change Staff = "low"
> 
> crmolto = \markup { \italic "cresc. molto" }
> appassmolto = \markup { \whiteout \italic "appassionato molto" }
> 
> #(ly:set-option 'point-and-click #f)
> 
> global = { \time 3/4 }
> 
> upperVoiceOne = \relative {
> \override TupletBracket.bracket-visibility = ##t
> \override TupletBracket.tuplet-slur = ##t
> \override TupletNumber.padding = #0
> 
> % 1
> \voiceOne
> 8\tweak height-limit #4 ([ \tuplet 5/4 { g'32 aes g f g] }
> 8[ \tuplet 5/4 { 32 c' bes aes bes] }
> 8 ) |
> 
> % 2
> 4( \voiceTwo
> 4)\arpeggio
> 16^(  8) |
> 
> % 3
> \voiceOne
> 8\tweak height-limit #4 ([ \tuplet 5/4 { 32 aes' g f g] }
> 16
> \set stemRightBeamCount = #1
> 
> \set stemLeftBeamCount = #1
> \tuplet 5/4 { bes'32 c bes aes bes] }
> \ottava #1 16   \slashedGrace f8 16) |
> }
> 
> upperVoiceTwo = \relative {
> % 1
> \voiceTwo s8 c''8\<
> [ 
> c' \!] |
> 
> % 2
> s4_\tweak X-offset #1 -\appassmolto
> \voiceOne a'''8\rest ->
> s4 |
> 
> % 3
> s8 \voiceTwo \crossStaff { g,8
> aes4 }
> }
> 
> middleVoiceOne = \relative {
> % 1
> \crossStaff { d'!8 } s8
> s8 s8\offset Y-offset #-2 _\crmolto
> s4 |
> 
> % 2
> s4
> 8[ ]
> \voiceOne e,8( dis16 e) |
> 
> % 3
> \once \override VoiceFollower.bound-details.left.Y = #-10
> \showStaffSwitch \csh \stemUp f4
> }
> 
> middleVoiceTwo = \relative {
> % 1
> s2. |
> 
> % 2
> s4
> \hideNotes \stemUp bes'\arpeggio \unHideNotes
> \voiceTwo \crossStaff { e,!4 } |
> 
> % 3
> s4
> 8 16 d'
> 8  |
> }
> 
> lowerVoiceOne = \relative {
> \mergeDifferentlyHeadedOn
> \mergeDifferentlyDottedOn
> 
> % 1
> \once \override Beam.damping = #5
> bes,,8 \csm \stemDown 8
> s2 |
> 
> % 2
> \csl \stemUp s8
> \hideNotes \stemDown es,,64^( s64 s \unHideNotes \stemUp
> g'64\offset positions #'(-0.7 . -0.7)
> \tweak damping #3 [
> \set stemLeftBeamCount = #1
> bes c d c])
> s2 |
> 
> % 3
> \once \override Beam.damping = #3
> bes,,8 \csm \stemDown 8 s2 |
> }
> 
> lowerVoiceTwo = \relative {
> % 1
> \voiceTwo bes,,2. |
> 
> % 2
> \csh
> \once \override Beam.damping = #+inf.0
> % XXX Currently, cross-staff beaming support is partially broken. This
> % means we have to adjust the vertical beam position manually.
> \once \override Beam.positions = #'(-30 . -30)
> 8 \csl es,,64 bes' es g s32. c64
> s4
> 4
> 
> % 3
> bes,,2.
> }
> 
> \score {
> \new PianoStaff <<
> \set PianoStaff.connectArpeggios = ##t
> \override PianoStaff.Arpeggio.stencil = #ly:arpeggio::brew-chord-bracket
> \override PianoStaff.Arpeggio.padding = #-0.5
> 
> \new Staff = "high" <<
> \global
> \context Voice = "upperVoiceOne" { \upperVoiceOne }
> \context Voice = "upperVoiceTwo" { \upperVoiceTwo }
>>> 
> \new Staff = "middle" <<
> \global
> \context Voice = "middleVoiceOne" { \middleVoiceOne }
> \context Voice = "middleVoiceTwo" { \middleVoiceTwo }
>>> 
> \new Staff = "low" <<
> \clef bass
> 

Re: end of Python2

[Urs Liska]

Hi Martin,

23. September 2019 11:17, "Martin Tarenskeen"  schrieb:

> Hi,
> 
> This has been discussed here before but https://pythonclock.org made me 
> wonder in which direction LilyPond and Frescobaldi are currently going. 

Well, if you're wondering about the direction then you might just read up the 
corresponding threads from the last days.

> 
> Unlike Lilypond, Frescobaldi3 is already more prepared for Python3.

Frescobaldi is not "more prepared" for Python3. Frescobaldi is fully ported to 
Python3 and hasn't even worked with Python2 anymore  for some years now.

Urs

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

Re: updated Stockhausen example

[Urs Liska]

Am 21. September 2019 19:09:55 MESZ schrieb David Kastrup :
>Werner LEMBERG  writes:
>
>> Here's an updated version of the Stockhausen example, with a lot of
>> added comments to the source code.
>>
>> I've also attached an image of rendering the old code (as present in
>> the git) with a lilypond binary from current git.
>
>[...]
>
>Looking at the image, this appears more to the credit of LilyPond than
>Stockhausen.  I have a hard time imagining a performer bringing this to
>life in a manner justifying the complexity written into the score.

Why?

It seems you haven"t heard enough of today"s highly qualified and dedicated 
performers ...

Urs

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

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

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

Re: 2.20 where are we?

[Urs Liska]

Am 21. September 2019 04:09:36 MESZ schrieb Andrew Bernard 
:
>So let me get this straight.
>
>It's not the case that GUB is completely broken. We can still build 
>releases.
>
>DK is working steadily to cherry pick items for 2.20.
>
>Python 2 to Python 3 is a major issue.
>
>So, I offered to do the 2->3 port a long time ago but circumstances 
>prevented me from doing so. Would it be constructive if I launched into
>
>that aspect? I cant understand the lilypond internals code but I have 
>extensive Python experience.
>
>Would this be helpful to moving forward?
>

This may be an even more important way to help than with the teo Frescobaldi 
topics I suggested to you.

>But have people already started on this, I thought?
>

IIRC there were some things done or st least planned but surely nothing that 
should prevent you from joining ...

Best
Urs

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

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

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

Re: 2.20 release roadmap

[Urs Liska]

Am 20. September 2019 02:23:58 MESZ schrieb Carl Sorensen :
>We are stuck for release because GUB is not working properly.  Until we
>get GUB to work properly, we cannot make a release.
>
>As far as I know now, the answer is in fact indefinite.

But is that the actual roadblock for the *2.20* release, not just *any*? I 
mean: once that's solved, there was discussion about another 2.19 release, but 
would that also mean 2.20 can be immediately released?

Of course it's futile since I can't help much, but it would becreally great to 
have a "stable" release by January . We'll have the music engraving conference 
in Salzburg (that Werner announced  a few days ago), where we expect other 
software to be presented too. It would be awkward - to put it mildly - to talk 
about our program that hasn't seen  a stabke release in six years bx then ...

Urs

>
>Thanks,
>
>Carl
>
>
>On 9/19/19, 6:14 PM, "Andrew Bernard" 
>wrote:
>
> I do hope this is not seen as impertinent, because it is not intended 
>that way. It's curious that I have asked the question about 2.20
>release 
>more than once and each time received no reply (unless lost in my
>mailers).
>
>Most projects will give some sort of indication about future releases. 
> If the indication for lilypond is simply 'indefinite' that's alright, 
>but I would be keen to know.
>
>
>Andrew
>
>
>On 18/9/19 1:44 pm, Andrew Bernard wrote:
>> Hello All,
>>
>> I asked the same on the user list, but no response. Is there any 
>> roadmap as to when 2.20 may be released? Are there any plans to do
>so?
>>
> > I KNOW we are very under-resourced. I'd very much like to help with 
>> the development but I regret to say I have never been able to wrap my
>
>> mind around the lilypond source code and how it all works, so I can't
>
>> contribute, although I would very much like to. For some reason, 
>> despite experience in software, I personally find it very opaque. But
>
>> that's just me.
>>
>> As always, sincere thanks to those who do work on this amazing
>software.
>>
>> Andrew
>>
>>
>
>___
>lilypond-devel mailing list
>lilypond-devel@gnu.org
>https://lists.gnu.org/mailman/listinfo/lilypond-devel
>
>
>___
>lilypond-devel mailing list
>lilypond-devel@gnu.org
>https://lists.gnu.org/mailman/listinfo/lilypond-devel

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

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

Re: Improved Schenker diagram

[Urs Liska]

Hi Werner,

thank you for that!

I can't comment on it because I don't know much about Schenker graphs. But I 
could right away use it ;-)
https://github.com/frescobaldi/frescobaldi/pull/1173#issuecomment-531884243 
(actually this was something I had been hoping for).

Best
Urs

16. September 2019 14:55, "Werner LEMBERG"  schrieb:

> I've invested some time to revise the Schenker diagram, which
> deteriorated over time.
> 
> Here is the original version
> 
> https://www.linuxjournal.com/article/8364
> 
> Here is what we currently have (not the bad spacing and bad vertical
> alignment).
> 
> http://lilypond.org/doc/v2.19/Documentation/ly-examples/bach-schenker.png
> 
> And attached you can find my new version.
> 
> Please comment so that I can add this to the git repository.
> 
> Werner
> 
> % -*-coding: utf-8 -*-
> 
> \version "2.19.21"
> 
> \header{
> composer = "J.S. Bach"
> title = "Wenn wir in höchsten Nöten sein (BWV 641)"
> subtitle = "Analysis from Gene Biringer's Schenker Text, Ex. 5-27"
> enteredby = "Kris Shaffer, Werner Lemberg"
> }
> 
> setup = { \oneVoice
> \override NoteColumn.ignore-collision = ##t }
> 
> % Some remarks.
> %
> % - Number `i' in the comments below gives the `i'th column in the graph.
> % Rhythmically, every column is (arbitrarily) represented as an eighth.
> % In total, the graph has 15 columns.
> %
> % - Using `\stemUp' and `\stemDown' influences the positioning of slurs even
> % if `\omit Stem' disables printing of stems.
> %
> % - Since each layer of the Schenker graph uses `\\' to create a new voice
> % it is not necessary to undo `\omit' or `\hide' commands. The same holds
> % for overridden properties.
> %
> % The `price' for using `\\' is to call the above-defined macro `\setup'
> % at the beginning of each voice to undo horizontal voice shifts and to
> % make LilyPond ignore collisions.
> %
> % - Trailing (musical) skips in voices are omitted.
> 
> rightHand = {
> \clef treble
> \key g \major
> 
> <<
> {
> \setup
> % This produces half notes as note heads of eighths.
> \override NoteHead.duration-log = #1
> 
> % 1
> s2
> % 5
> b'8\tweak positions #'(8 . 8) ^[
> ^\markup { \override #'(baseline-skip . 0.8)
> \column { \with-color #red \small { ^ 3 } } }
> s4.
> % 9
> s4 a'8
> ^\markup { \override #'(baseline-skip . 0.8)
> \column { \with-color #red \small { ^ 2 } } }
> s8
> % 13
> s4 g'8]
> ^\markup { \override #'(baseline-skip . 0.8)
> \column { \with-color #red \small { ^ 1 } } }
> }
> \\
> {
> \setup
> \override Slur.color = #(x11-color "purple")
> \stemUp
> \omit Stem
> \hide NoteHead
> \slurDashed
> 
> % 1
> s2
> % 5
> b'2\tweak height-limit #6 _(
> % 9
> b'4)
> a'4\tweak height-limit #3.25 _(
> % 13
> s8
> a'4)
> }
> \\
> {
> \setup
> 
> % 1
> \stemUp
> g'8\tweak positions #'(4.5 . -3.25) -[ s4.
> % 5
> \stemDown
> \once \hide NoteHead
> b'8]
> \stemUp
> a'8\tweak positions #'(3 . -3) -[ s
> \stemDown
> c''8]
> }
> \\
> {
> \setup
> \override Slur.color = #(x11-color "violet")
> 
> % 1
> \stemDown
> \omit Stem
> \omit Flag
> s8 fis'^(_\markup { \with-color #blue \tiny N } g')
> a'8^(^\markup { \with-color #blue \tiny P }
> % 5
> \hideNotes
> b'4)
> \unHideNotes
> \once \override TextScript.outside-staff-priority = ##f
> b'8^(^\markup { \with-color #blue \tiny P }
> \undo \omit Stem
> \undo \omit Flag
> \stemUp
> \override Stem.length = #10
> c''8)^(
> % 9
> \override Stem.length = #14
> b'4) s8
> \stemDown
> \omit Stem
> \omit Flag
> c''8^(
> % 13
> b'8_\markup { \with-color #blue \tiny P } a')
> }
> \\
> {
> \setup
> \override Slur.color = #(x11-color "violet")
> 
> % 1
> \stemUp
> \omit Stem
> \omit Flag
> g'8_( fis' g'4)
> % 5
> s2
> % 9
> s2
> % 13
> b'8_( a')
> }
> \\
> {
> \setup
> \omit Stem
> \hide NoteHead
> 
> % 1
> s2
> % 5
> s8 d'4
> \change Staff = "LH"
> b4
> }
> \\
> {
> \setup
> \omit Stem
> \hide NoteHead
> 
> % 1
> s2
> % 5
> s2
> % 9
> s4
> d'4
> \change Staff = "LH"
> % 13
> b4
> }
>>> 
> 
> \bar "|."
> }
> 
> leftHand = {
> \clef bass
> \key g \major
> 
> <<
> {
> \setup
> % This produces half notes as note heads of eighths.
> \override NoteHead.duration-log = #1
> 
> % 1
> g8\tweak positions #'(-8 . -8) _[
> _\markup { \with-color #(x11-color 'LawnGreen) \bold I }
> s4.
> % 5
> s2
> % 9
> s2
> % 13
> d8_\markup { \with-color #(x11-color 'LawnGreen) \bold V }
> s8
> g,8]_\markup { \with-color #(x11-color 'LawnGreen) \bold I }
> }
> \\
> {
> \setup
> \override Slur.color = #(x11-color "violet")
> \stemUp
> \hide Stem
> \hide Flag
> 
> % 1
> s8
> \once \override TextScript.outside-staff-priority = ##f
> \once \override TextScript.padding = #1
> a8_(^\markup { \with-color #blue \tiny P } b)
> \stemDown
> fis8^(^\markup { \with-color #blue \tiny P }
> % 5
> e8)
> c8\tweak height-limit #1.5 ^(
> d8)^\markup { \with-color #blue \tiny N }
> \stemUp
> fis,8_(
> % 9
> \undo \hide Stem
> \undo \hide Flag
> \override Stem.length = #10
> \stemDown
> g,4)
> c8_(
> \hide Stem
> \hide Flag
> a,8)
> % 13
> \once \hide NoteHead
> d8^( d,)
> }
> \\
> {
> 

Re: Idea for subdivide beams

[Urs Liska]

Hi Kim,

thank you for the suggestion.

4. August 2019 16:14, "hs kim"  schrieb:

> Hi.
> I was making "la campanella". There was many subdivide beams but it was so
> confused that I can't make it anymore. That's why I decided to change the
> way subdivide beams are written.
> 
> In the stable branch, subdivide beams are too complicated to know. But my
> idea is (subdividing of four 32 note and four 16 note with 1/8)
> 
> \set subdividieBeams = #"8"
> a32[[ b c b] f16[ g a g]]

As I understand it this is a suggestion for an input syntax for manual beam 
subdivisions.
As such it would not be an approach to handle the beam subdivision problems on 
a fundamental level (https://sourceforge.net/p/testlilyissues/issues/5547/), 
but I think it would indeed be a good idea to have such a manual syntax - just 
as manual beaming is often necessary over automatic beaming.

However, the proposed syntax has two issues as far as I can tell:

* It changes the meaning of the single bracket, a well-established syntax,
  requiring really involved modifications for existing scores
* It would be somewhat inconsistent - as single brackets would mean something 
different
  in different contexts.
* I'm not sure about the issues for the actual parser.

Instead I would suggest to keep the meaning of the single [ ] as it is (=> 
manually beam the given group of notes), and add a new syntactic element for 
"beam subdivision" instead. A few suggestions (note that the following 
characters are already in use and should not be repurposed: . | - [ ] { } ( ) =

a32[ b c b ; f16 g a g]
a32[ b c b / f16 g a g]
a32[ b c b "]" f16 g a g]
a32[ b c b T f16 g a g]

To be clear: What this thread can achieve is a discussion about an *intent* for 
some new development. There would still have to be someone to actually take a 
look at it and implement it. And I think it's not totally trivial.

Urs

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

Re: lilypond-book-preamble and cropping

[Urs Liska]

30. Juli 2019 11:16, "David Kastrup"  schrieb:

> "Urs Liska"  writes:
> 
>> I'm not sure if this is actually a *development* request or if it
>> could also be solved at the "user" level.
>> 
>> As Werner showed in https://github.com/jperon/lyluatex/issues/268
>> (https://github.com/jperon/lyluatex/issues/268) there is an issue with
>> the output of scores compiled with `lilypond-book-preamble.ly`. AFAICT
>> this is something inherent in the lilypond-book handling which should
>> also be visible in any lilypond-book scores.
>> 
>> When compiling with lilypond-book-preamble the score gets sliced in
>> systems, and each system is *additionally cropped*. I have never
>> understood the commands in that file so I don't know in what order
>> these things happen, I don't even know if that lack of the concept of
>> a "page" (we only have a sequence of systems now) affects the actual
>> layout process.
>> 
>> Of course you will often want to have the cropped systems, essentially
>> when including single systems in a text document, or at the top or the
>> bottom of pages. However, when stacking the resulting systems this
>> means that the space between systems is inconsistent and generally too
>> narrow. This can sometimes be alleviated by adding space between the
>> systems, but sometimes this doesn't help. As Werner's example images
>> in the issue report linked above show: when a system has much
>> additional stuff above or below (e.g. marks, text or just legder
>> lines) this significantly disturbes the vertical spacing.
>> 
>> What I would need to achieve - either by providing some modification
>> of lilypond-book-preamble or as a feature request to be added to
>> LilyPond - is a compilation mode that behaves like
>> lilypond-book-preamble *without the vertical cropping* (but with
>> horizontal cropping). Alternatively (maybe even better) would be
>> writing an additional aux file stating the amount of space cropped, at
>> least at the top and bottom but maybe for all four sides. Or the
>> original image size before cropping. Anything that can be used to
>> infer the space one should add before and after the system to rebuild
>> LilyPond's original page layout.
>> 
>> Any ideas?
> 
> For employing something like TeX, one needs to know the baseline, the
> top extent, the bottom extent, and the skyline spacing to be used
> between one system and the next. Then one can pad as necessary when
> systems are separated by pagebreaks or other material and use the
> skyline spacing then they aren't. Yes, glue like that can be
> constructed in TeX while still leaving the page break decisions to TeX.
> 
> The main problem we are having with cropping is the implementation of
> cross staff material which does not count towards skylines and extents.
> Instead it would need to count towards the upper skyline and extent in
> its top staff, and towards the bottom skyline and extent in its bottom
> staff. That way it would not push apart the systems it crosses while
> still making an impact letting it survive in the bounding boxes.

I see that an issue is that *of course* a PDF including one system *has* to 
cause a problem when two adjacent systems overlap. 
https://github.com/jperon/lyluatex/issues/268#issuecomment-516358134 and 
https://github.com/jperon/lyluatex/issues/268#issuecomment-516360973 show 
contrived examples compiled with and without lilypond-book-preamble to 
demonstrate the problem.

Would there be any way to get LilyPond to produce a number from which one can 
infer the extent by which two adjacent systems should overlap or have been 
drawn apart through the page layout?

Urs

> 
> --
> David Kastrup

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

lilypond-book-preamble and cropping

[Urs Liska]

I'm not sure if this is actually a *development* request or if it could also be 
solved at the "user" level.

As Werner showed in https://github.com/jperon/lyluatex/issues/268 
(https://github.com/jperon/lyluatex/issues/268) there is an issue with the 
output of scores compiled with `lilypond-book-preamble.ly`. AFAICT this is 
something inherent in the lilypond-book handling which should also be visible 
in any lilypond-book scores.

When compiling with lilypond-book-preamble the score gets sliced in systems, 
and each system is *additionally cropped*. I have never understood the commands 
in that file so I don't know in what order these things happen, I don't even 
know if that lack of the concept of a "page" (we only have a sequence of 
systems now) affects the actual layout process.

Of course you will often want to have the cropped systems, essentially when 
including single systems in a text document, or at the top or the bottom of 
pages. However, when stacking the resulting systems this means that the space 
between systems is inconsistent and generally too narrow. This can sometimes be 
alleviated by adding space between the systems, but sometimes this doesn't 
help. As Werner's example images in the issue report linked above show: when a 
system has much additional stuff above or below (e.g. marks, text or just 
legder lines) this significantly disturbes the vertical spacing.

What I would need to achieve - either by providing some modification of 
lilypond-book-preamble or as a feature request to be added to LilyPond - is a 
compilation mode that behaves like lilypond-book-preamble *without the vertical 
cropping* (but with horizontal cropping). Alternatively (maybe even better) 
would be writing an additional aux file stating the amount of space cropped, at 
least at the top and bottom but maybe for all four sides. Or the original image 
size before cropping. Anything that can be used to infer the space one should 
add before and after the system to rebuild LilyPond's original page layout.

Any ideas?
Thanks
Urs
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: New function css-color (issue 580780043 by g...@ursliska.de)

[Urs Liska]

Thank you for doing so. 

The thing is (as buried in a comment somewhere), these regular reminders served 
as an incentive for me not to forget that I wanted to push this only after 
documenting the new feature...
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: New function css-color (accompanying x11-color) (issue 570690043 by g...@ursliska.de)

[Urs Liska]

Am 04.06.19 um 10:53 schrieb Urs Liska:

Am 04.06.19 um 00:13 schrieb thomasmorle...@gmail.com:


https://codereview.appspot.com/570690043/diff/564820043/scm/color.scm
File scm/color.scm (right):

https://codereview.appspot.com/570690043/diff/564820043/scm/color.scm#newcode678 


scm/color.scm:678: (define css-color-list
Is there anything new in this list or are all entries always alias?


I checked and saw that the following CSS colors are *not* in the X11 
list:


CSS Color names not defined in X11 colors:

...

*Most* of the others are basically defined identical, with the 
differences being rounding errors. However, there are a number of real 
differences, AFAICS it's the discrepancies described in 
https://en.wikipedia.org/wiki/X11_color_names#Clashes_between_web_and_X11_colors_in_the_CSS_color_scheme 



The proper list of differenlty defined colors is:

CSS Color names not defined in X11 colors:

aqua

crimson

fuchsia

indigo

lime

olive

rebeccapurple

silver

teal

CSS Color defined differently than X11:

gray

green

grey

maroon

purple

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

Re: New function css-color (accompanying x11-color) (issue 570690043 by g...@ursliska.de)

[Urs Liska]

Am 04.06.19 um 00:13 schrieb thomasmorle...@gmail.com:


https://codereview.appspot.com/570690043/diff/564820043/scm/color.scm
File scm/color.scm (right):

https://codereview.appspot.com/570690043/diff/564820043/scm/color.scm#newcode678 


scm/color.scm:678: (define css-color-list
Is there anything new in this list or are all entries always alias?


I checked and saw that the following CSS colors are *not* in the X11 list:

CSS Color names not defined in X11 colors:

aqua

crimson

fuchsia

indigo

lime

olive

rebeccapurple

silver

teal

*Most* of the others are basically defined identical, with the 
differences being rounding errors. However, there are a number of real 
differences, AFAICS it's the discrepancies described in 
https://en.wikipedia.org/wiki/X11_color_names#Clashes_between_web_and_X11_colors_in_the_CSS_color_scheme 




...
Ofcourse this leads to identical definitions for css-color and x11-color
and x11-color would return a color even for p.e. Darkblue (wrongly
cased).
I can't imagine a problem, though


I'm not totally sure about the best way to proceed here. I agree that 
it's not a terrific idea to duplicate all those color definitions.


However, especially given the number of differences there should be 
explicit access methods for both color models. What might be a 
reasonable approach is:


 * Have one long list of shared color definitions, basically the
   existing one plus entries for the list above (I assume we can ignore
   the rounding errors issue)
 * For each color model have a list of *names* and a list (doesn't have
   to be a *separate* list) of definitions for colors that don't match
   the shared-colors list. For X11 this would *only* be the names list.
   (The determination of colors that need special definitions should be
   done once during development, not at runtime.)
 * When asking for a color it is first checked if it is in the color
   model's extension list, then in the shared list (and then fall back
   to black)
 * Given that the X11 colors Wikipedia entry states that the
   capitalization of X11 color names isn't handled consistently I
   suggest that we totally ignore casing (keep the CamelCase names in
   the manual but state that colors can be requested case insensitively)

What do you think?
Urs
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: What version of guile to build 2.21.0

[Urs Liska]

Am 18.05.19 um 05:53 schrieb Carl Sorensen:

1.8



It's actually 1.8.8 IIRC

Urs

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

Re: Google Season of Docs

[Urs Liska]

Am 06.04.19 um 01:49 schrieb Kieren MacMillan:

Hi Werner,


Would this be of interest for LilyPond?
https://developers.google.com/season-of-docs/docs/project-ideas

It would be *very* valuable for OpenLilyLib…  =)



Indeed, but I don't think this program is suitable for that ...
If I've understood the program correctly it is targeted at "technical 
writers"  who should be able to write about an arbitrary subject. The 
first thing is that "we" would need writers with very specific prior 
knowledge (LilyPond and Scheme), and the major issue is that openLilyLib 
would rather need a fundamental *infrastructure* for *generating* 
documentation. Which is a programming challenge, not one about writing, 
and consequentially we have it listed on the GSoC project ideas page.


I think the general LilyPond documentation would be much more suitable. 
Here we have an abundance of existing texts, and it would be very useful 
to review much of that from the perspective of technical writing, i.e. 
improving the understandability by thinking more about the target reader 
than the underlying technical foundation.


Urs




Cheers,
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


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


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

Re: GSoC in contemporary notations

[Urs Liska]

Hi Tsz Kiu,

Am 03.04.19 um 13:48 schrieb Tsz Kiu Pang:

Hi Urs,

Whether or not I'll be suitable to participate in GSoC, I am keen to 
dive into openlilylib.



That would be great!




On Thu, 21 Mar 2019 at 17:58, Urs Liska <mailto:li...@openlilylib.org>> wrote:



What you should do now is:

  * [of course dive more into Scheme]
  * get an understanding of openLilyLib with
    a) https://github.com/openlilylib/oll-core/wiki
    b) the code in that repository
    c) looking at how other openLilyLib packages are built within that
    infrastructure
  * Form an idea how a contemporary notation package could be
approached
    and discuss that with us
  * Find some small things you could do to openLilyLib package(s)
to a)
    practice and b) give us an opportunity to assess your work. If we
    have some idea about your current familiarity with the matter
we can
    find some suggestions for that.

I was looking at the issues page on oll-core and there were a couple 
that you opened two weeks ago.
Also, it seems like there is quite a number of TODOs in the codes (in 
oll-core/scheme, oll-core/util, and oll-core/internal).
I am just wondering would these be "some small things" that I can do 
to the oll package?



Most of the items on the issue tracker don't look like suitable 
first-time tasks. But there are actually two issues you could have a 
look at, both having to do with module loading. This may not be as 
attractive as adding shiny new features, but I think it is a good way to 
get a better understanding of how things are working in there.


https://github.com/openlilylib/oll-core/issues/43
https://github.com/openlilylib/oll-core/issues/39

43 is actually a "current" idea, but 39 is a limitation that really 
should be removed - especially since just last week someone else 
stumbled over the problem.


Both issues could be tackled by looking at the module handling code.

Handling metadata (issue 43) is done within \loadPackage, so you can 
follow the procedure calls to see how that package.cnf file is processed 
and metadata registered. \loadModule would then have to check not only 
(as it currently does) whether the entry file is found on disk but also 
(and before) whether the requested module is registered in the package's 
metadata.


Preloading package/module options would basically work by integrating a 
workaround. Currently options are set after a package or module has been 
successfully loaded. This means that *while loading* the package or 
module the user option is not available yet. Essentially using the \with 
{} clause to set options is currently only a nice way to do the 
package/module configuration for a user file, but user-provided options 
can't be used to control the way the package/module is *loaded*. I see 
two appraoches on how to solve the problem, and both are described in 
the issue on Github. [Edit: Actually I think the approach I just thought 
of and added as a comment there is the way to go]


Having thought of all this and doing some investigation *while* writing 
this email I came to the conclusion that looking into issue 39 with the 
approach described in 
https://github.com/openlilylib/oll-core/issues/39#issuecomment-479813636 
should be a good idea to start with, both getting a good idea how things 
work in oll-core and providing some very valuable improvement.


Best
Urs



Kind regards,
Tsz Kiu


HTH
Urs

>
> Kind regards,
> Tsz-Kiu
> ___
> lilypond-devel mailing list
> lilypond-devel@gnu.org <mailto:lilypond-devel@gnu.org>
> https://lists.gnu.org/mailman/listinfo/lilypond-devel
___
lilypond-devel mailing list
lilypond-devel@gnu.org <mailto:lilypond-devel@gnu.org>
https://lists.gnu.org/mailman/listinfo/lilypond-devel


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

Re: GSoC in contemporary notations

[Urs Liska]

This is directed at the other devs, to (please) join the conversation

Am 01.04.19 um 08:30 schrieb Tsz Kiu Pang:



I just have some concerns.
Sorry I might have overestimated myself in the past week, but I
realised I might not be able to commit for 30+ hours per week
during May since I am in Australia, the exams are usually in
May-early June.



In general "full time" commitment is expected throughout the
official coding period, and we can't make substantial exceptions.
However, a) the coding period only begins May 27, the "bonding
period" is explicitly not included in the full-time commitment. b)
it is possible to circumvent the issue by starting earlier. I have
no idea about your workload during and before exams, but if you
should be accepted (which is announced May 6) and are able to do
*some* work in May (not full-time) that would otherwise be part of
your work in June that should be OK. When exactly would your exams
be over? What would be your estimate for being able to do
*something* in May?

Although it is hard to predict exactly what would be my workload in 
the next couple of months, I can say I would be able to commit 8-10 
hours per week once I've got accepted.
Though I have just realised I was mistaken before, that my exams is 
from 11th to 28th June. I can still commit 8 hours per week during 
that time.
However, considering that it is way into June, I am not sure whether 
that will fit into the GSoC timeline.
Worst scenario is that, I might just try to apply for GSoC next year 
when I have less study load.




To make things clear for those who have not been following closely: What 
Tsk Kiu is saying is that he expects being able to


 * commit 8-10 hours per week during the bonding period when he isn't
   officially required to spend specific working time yet. So these
   would be "additional"
 * commit only 8-10 hours during a three week period within the
   official project time
 * [and of course the actual situation during exams is not fully
   predictable]

What do you make of this?

Best
Urs

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

Re: GSoC in contemporary notations

[Urs Liska]

Hi Tzk Kiu,

Am 21.03.19 um 13:06 schrieb Tsz Kiu Pang:

Hi Urs,

Thank you for your reply, and thank you so much for asking about my name.


On Thu, 21 Mar 2019 at 17:58, Urs Liska <mailto:li...@openlilylib.org>> wrote:


Hi Tsz Kiu Pang (which of these names would you like to be called, or
should I use all of them like I did?)


Tsz Kiu Pang is fine, though people usually call me Tsz Kiu, which is 
my first name.



> I was just looking at the project suggestions, and am interested
in working
> on contemporary notations.

This would be great. While all of our GSoC suggestions would be very
welcome additions this one would maybe provide the most "visible" and
spectacular addition, opening up LilyPond for a whole range of
applications and therefore potential users.


I am glad to hear that my interests align with you guys.

A specific composer's package would be a secondary package built
on top
of a general package, and I think it would be great to aim at
starting
one for one specific composer (the one I had always thought of as a
basis was Lachenmann, but Xenakis or Carter are equally valid
choices),
although it is not a requirement to achieve /comprehensive/
coverage of
a composer.


Yes, I agree that the secondary package would have to be build on top 
of a general package, and this is great since I hope this project can 
make contemporary notation accessible to LilyPond users in a general 
sense, but not just focusing on one or two composers.



The idea (as far as I have thought about it in the past) is to provide 
"building blocks" like functions that help create custom elements that 
behave like slurs ("lines" connecting two notes), elements that use 
paths to draw custom notation elements and more such basics. On top of 
that concrete commands should be built and organized maybe by repertoire 
or composer or whatever. But the building blocks should enable the 
creation of packages supporting something specific or the creation of a 
personal library of one's own notation repertoire.






The Scheme/Guile part has three steps for you to consider:

  * "Counting parentheses" (i.e. the language basics)
    Depending on how far you've got https://scheme-book.ursliska.de
    might be a useful resource for you. It goes only that far but it
    specifically addresses a) the Scheme language from a dedicated
    LilyPond perspective and b) users counting parentheses (i.e.
giving
    a pretty slow-paced introduction)
  * Understanding how Scheme is hooked into LilyPond (on a general
level)
  * (Learning how openLilyLib ist structured)
  * Learning how to retrieve the relevant information about score
    elements and how to modify them in appropriate places.

The last one is probably the hardest one since it is pretty opaque
and
terribly documented. But it's the crucial one for a contemporary
notation package - and it's the one where such a package will make it
hugely easier for people to work with non-standard notation.


They all sound pretty hard, but your website seems like a great 
resource. I will definitely have a look at it.
Regarding learning how Scheme is hooked into LilyPond, what is some 
other good resource for it, apart from your website?



The "official" reference is at 
http://lilypond.org/doc/v2.19/Documentation/extending/index. However, 
one may find it somewhat hard to digest since obviously it is not always 
written with readers in mind who do not already know a lot about it ...




Just last week I've decided to start with a new openLilyLib package:
https://github.com/openlilylib/grob-tools. The repository on
Github is
empty, and right now I only have one single uncommited function
locally,
but the idea is to create building blocks for recurring tasks like
getting the exact position of objects relative to the staff or to
another object, enumerating all NoteColumns included in a slur or
similar things. This will be very much relevant for a contemporary
notation package. One could either say that you should put much of
your
results in that package, or we can try to make development of that
package a community effort so that would take work from you,
giving you
the freedom to go further with the specific challenges.

Making the development as a community effort sounds great, though I 
cannot say for sure until I have a solid proposal.



What I mean is that to some extent that package could be developed by 
others ("the community"), relieving you from some of the work. However, 
I absolutely can't make any promise that this would work out with regard 
to the community dynamic.





What you should do now is:

  * [of course dive more into Scheme]
  * get an understanding of openLilyLib with

Re: GSoC in contemporary notations

[Urs Liska]

Hi Tsz Kiu Pang (which of these names would you like to be called, or 
should I use all of them like I did?)


Am 21.03.19 um 06:58 schrieb Tsz Kiu Pang:

Hi all,

I am writing to express my interest in working on LilyPond as part of GNU
in the Google Summer of Code.

I was just looking at the project suggestions, and am interested in working
on contemporary notations.



This would be great. While all of our GSoC suggestions would be very 
welcome additions this one would maybe provide the most "visible" and 
spectacular addition, opening up LilyPond for a whole range of 
applications and therefore potential users.




As a composer myself, I do find using Lilypond a
very steep learning curve, especially for contemporary music, where a lot
of workarounds are needed.



That's true, and one major issue with that (which a package would 
address) is that so many things have to be done from scratch over and 
over again, for each new project, or at least by each new user dealing 
with them.




I hope I can use this opportunity to create an
infrastructure for contemporary notations that will make composers' life
easier. I am also interested in creating a package that covers the style of
composers such as Iannis Xenakis or Elliott Carter.



A specific composer's package would be a secondary package built on top 
of a general package, and I think it would be great to aim at starting 
one for one specific composer (the one I had always thought of as a 
basis was Lachenmann, but Xenakis or Carter are equally valid choices), 
although it is not a requirement to achieve /comprehensive/ coverage of 
a composer.





I am just wondering if there are any suggestions in applying for GSoC and
writing a project proposal?



Basically you'd have to discuss a proposal on this list or in a somewhat 
more private circle (although generally as much as possible 
communication should be in public space) and find a way to show us your 
qualification, potential and way of communication until April 9.  A bit 
more on that below.





As for qualifications, I did my undergraduate in Music, majored in
Composition during my honours year, so I have good knowledge in
contemporary notation techniques and the capacity to research further if
required. I am currently a Master student in electrical engineering at the
University of Melbourne. I have only started programming last year but now
I am a tutor in programming/computing in C at the University. Though
scheme/guile is not my strong suit yet (I know the basic syntax and list
operations, but still struggling to count the parentheses), I am willing to
learn more and I believe I will have a good command in scheme/guile in a
few weeks.



The Scheme/Guile part has three steps for you to consider:

 * "Counting parentheses" (i.e. the language basics)
   Depending on how far you've got https://scheme-book.ursliska.de
   might be a useful resource for you. It goes only that far but it
   specifically addresses a) the Scheme language from a dedicated
   LilyPond perspective and b) users counting parentheses (i.e. giving
   a pretty slow-paced introduction)
 * Understanding how Scheme is hooked into LilyPond (on a general level)
 * (Learning how openLilyLib ist structured)
 * Learning how to retrieve the relevant information about score
   elements and how to modify them in appropriate places.

The last one is probably the hardest one since it is pretty opaque and 
terribly documented. But it's the crucial one for a contemporary 
notation package - and it's the one where such a package will make it 
hugely easier for people to work with non-standard notation.


Just last week I've decided to start with a new openLilyLib package: 
https://github.com/openlilylib/grob-tools. The repository on Github is 
empty, and right now I only have one single uncommited function locally, 
but the idea is to create building blocks for recurring tasks like 
getting the exact position of objects relative to the staff or to 
another object, enumerating all NoteColumns included in a slur or 
similar things. This will be very much relevant for a contemporary 
notation package. One could either say that you should put much of your 
results in that package, or we can try to make development of that 
package a community effort so that would take work from you, giving you 
the freedom to go further with the specific challenges.


###

What you should do now is:

 * [of course dive more into Scheme]
 * get an understanding of openLilyLib with
   a) https://github.com/openlilylib/oll-core/wiki
   b) the code in that repository
   c) looking at how other openLilyLib packages are built within that
   infrastructure
 * Form an idea how a contemporary notation package could be approached
   and discuss that with us
 * Find some small things you could do to openLilyLib package(s) to a)
   practice and b) give us an opportunity to assess your work. If we
   have some idea about your current familiarity with the matter we can
  

Re: Anchor points of Slurs / Phrasing slurs

[Urs Liska]

Am 16. März 2019 20:20:15 MEZ schrieb Valentin Villenave 
:
>On 3/16/19, Valentin Petzel  wrote:
>> Currently the anchor points are set both over or both under the
>starting /
>> ending note, depending on the slur’s direction. For the S-shape we
>would
>> need
>> the control points to differ in directions, so one point above and
>one point
>> beneath the respective notes.
>
>Another possibility would be to use polar coordinates, as Janek and
>David N. tried to do a while back:
>https://lists.gnu.org/archive/html/lilypond-user/2013-11/msg00832.html
>(That code compiles very well with 2.18, but some tweaks are needed
>for 2.19 and 2.21. It may also have some duplicate functions wrt
>polar->rectangular.)
>
>I can’t remember that part of their code having ever been merged
>upstream, 

correct.

> but this could provide you with an interesting starting
>point to actually get it included in LilyPond.

https://github.com/openlilylib/snippets/blob/master/notation-snippets/shaping-bezier-curves/shapeII/module.ily

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

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

Re: GSOC and stylesheet work

[Urs Liska]

Hi Daniel,

Am 27.02.19 um 15:00 schrieb Daniel Benjamin Miller:

Hi all:

I'm an undergraduate student at McGill University. As I've personally 
wanted to tweak LilyPond to improve the stylistic output of my scores, 
I was hoping to do some work on LilyPond this summer, perhaps through 
GNU's involvement in GSOC. I have some background in font design 
(although mostly with outline fonts, not METAFONT, as I've only messed 
around with that), and would be interested in improving either the 
font or stylesheet support (so, sort of touching on two suggestions in 
the project list from last year). 



Great. Be assured that the project suggestions listed on 
http://lilypond.org/google-summer-of-code.html are strictly that: 
suggestions. There's absolutely nothing speaking against tailoring an 
alternative project.



My main caveat is that I'm not especially experienced in Scheme 
(mostly having just messed around with it for LilyPond purposes), 
though I'm eager to learn more and interested in working on these 
issues, esp. if a mentor is available.


Are there any comments/suggestions on the current status of these 
components and what I might be best advised to look at/work on?



This is a bit difficult to assess since you give us a pretty sparse idea 
of your skillset. "Not especially experienced in Scheme" is a bit vague, 
especially as we have no idea what "eager to learn more" would turn out 
in practice.


If you're interested in font design there would be no way around dealing 
with METAFONT, the other options will require dealing with Scheme and/or 
C++, to various extents. Do you have any experience with C++?


If you should be heading toward a project that requires dealing with 
Scheme you should maybe try to familiarize yourself with it and show 
yourself and us how that would be going.


AFAICS with any projects in the realm of fonts/stylesheets there would 
be mentors available, so you can go ahead and try to figure out somewhat 
more concretely what you might be interested in.


Best
Urs




Thanks!

DBM


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


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