Re: What is the difference between \paper and \layout blocks?

[Trevor Bača]

On Sat, Jan 14, 2023 at 4:10 PM David Kastrup  wrote:

>
> What should it be?
>
> The presence of a \layout block in a score makes for typeset output.
> \paper contains things like paper dimensions only necessary for typeset
> output.  Also base file names that are also relevant for MIDI.
>
> Global markup currently only gets to see the \paper block.  That also
> concerns things like \score markup that can get information for
> typesetting from \layout blocks.
>
> Layout blocks "inherit" from the paper block: when a variable in a
> layout block is not set, it is taken from the respective paper block.
>
> Currently a "paper-book" where the typesetting is done only stores the
> relevant paper block.  Consequently, any page-level/top-level markup
> currently gets only the paper block as its "layout" parameter.
>
> That is not accepted as layout block in a score markup.
>
> Suggestions?
>


In 18 years of working with LilyPond, I have never understood the
distinction between \paper and \layout.

Trevor.


-- 
Trevor Bača
www.trevorbaca.com
soundcloud.com/trevorbaca

Re: LilyPond 2.23.80

[Trevor Bača]

Hi,

All of my scores compile under 2.13.80, and with no errors.

Congratulations, and thanks for the chance to test the 2.24 release
candidates.

Trevor.

On Sun, Oct 23, 2022 at 10:22 PM Jonas Hahnfeld via LilyPond user
discussion  wrote:

> We are happy to announce the release of LilyPond 2.23.80. This is the
> first release candidate towards the next stable version 2.24.0 expected
> in December. Please test your scores with this version and report back
> the experience as well as any problems you encounter. Please refer to
> the Installing section in the Learning Manual for instructions how to
> set up the provided binaries:
> https://lilypond.org/doc/v2.23/Documentation/learning/installing
>


-- 
Trevor Bača
www.trevorbaca.com
soundcloud.com/trevorbaca

Re[2]: "Hymn template" snippet

[Trevor]

Dan, you wrote 09/08/2022 13:33:11


On Aug 9, 2022, at 08:26, Kieren MacMillan  wrote:


 The big difference, in my mind — as composer, arranger, conductor, and 
performer — is that a caesura is generally longer than a comma/breath, and 
intentionally interrupts the flow of the overall line, whereas the comma/breath 
usually doesn't (or at least doesn't in as dramatic a manner).

 In musical theatre scores, the caesura is used almost exclusively when the 
music completely stops and is restarted ‘from silence’ in the next phrase — 
indeed, the caesura is quite often coupled with a fermata — whereas the 
comma/breath is really only used in situations where the singer/performer 
literally needs a little time to phrase off (either for dramatic or 
technical/breathing purposes) but the music [in the accompaniment] basically 
continues unbroken.


Thanks.  Those are the intended semantics of the \breathe and \caesura commands 
in the code that is under development.
Given those intended semantics, \breathe is the correct command for 
taking a breath between lines in a verse of a hymn. This is quite a 
different situation from the use of a caesura in musical theatre, which 
usually indicates a quite significant pause in the music.



Also, what about the bar lines?
I don't know why the thin double line is used at the end of some phrases 
and the comma is used elsewhere; when there is a pick-up the thin double 
line is not even at the end of a bar, although it is always at the end 
of a line of the verse. In hymn books both the comma and the thin double 
line are more to do with helping the sight-reading singer to re-locate 
his/her place in the music after glancing at the next line of the 
current verse (verses are never printed within the music) rather than 
indicating where breaths are to be taken. So the purpose of both commas 
and thin double lines is more to do with showing how the lines of each 
verse fit the music. I can't find anything in Gould about this use of 
the thin double line, but it is the way hymn books are usually written.


In more modern hymn books there is a movement to use thin double lines 
throughout rather than commas to show how the lines of the verse map 
onto the music, although settings of traditional hymns usually retain 
the commas (see Common Praise).


Trevor

Re: "Hymn template" snippet

[Trevor]

-- Original Message --
From: "Dan Eble" 
To: "lilypond-devel" 
Sent: 08/08/2022 22:46:32
Subject: "Hymn template" snippet


"Hymn template"
https://lsr.di.unimi.it/LSR/Item?id=703

I don't see any way to find the author of a snippet.  I'd like to ask the author of this snippet 
about the reason for using \breathe and \bar "||".  Are they intended to communicate two 
different things, or was it merely a stylistic decision to use \bar "||" at the end of a 
system and \breathe in the middle?

I would like to revise it to use \caesura but stay faithful to the original 
intent.

Thanks,
Dan

Hi Dan
I'm pretty sure I was the author of this snippet. It is used in NR 2.1.7 
(without comment about the comma).


A comma is the standard way of writing a breathing point in vocal music. 
It is used extensively in Hymns Ancient and Modern, New Standard. Gould 
writes on page 436 in the Vocal Music chapter: "When a note should be 
sung for its full duration, with extra time for the breath, add a comma 
above the stave - this adds a short pause to the bar in which it 
occurs." No mention here of a caesura. She also says on page 187, "The 
comma rather than the caesura is now more commonly used" (for allotting 
extra time for a short break in sound.)


If you change this snippet to use a caesura and render it as a comma in 
this section of the NR ("Chants, Psalms and Hymns") that would be OK I 
suppose (although \breathe seems the appropriate LP command), but "//" 
is definitely a no-no. I've never seen that in a hymnal.


Trevor

Re: LilyPond 2.23.7 released

[Trevor Bača]

Hi,

2.23.7 appears to introduce a bug in SVG output under macOS:

%%% BEGIN %%%

\version "2.23.7"

\new Staff
{
  \time 3/4
  c'2.
}

%%% END %%%

macOS 12.3.1 produces the following:

$ lilypond --svg example.ly
GNU LilyPond 2.23.7 (running Guile 2.2)
Processing `example.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...;;; note: source file
/Users/trevor/lilypond-2.23.7/share/lilypond/2.23.7/scm/lily/output-svg.scm
;;;   newer than compiled
/Users/trevor/lilypond-2.23.7/lib/lilypond/2.23.7/ccache/lily/output-svg.go
ice-9/eval.scm:351:13: Wrong number of arguments to #

The resulting SVG (attached here) is headed by a bright red banner
announcing an error.

Strangely, the choice of time signature is important: the example above
renders correctly in 4/4, even though the system-draw warning still appears.

The error appears to come from line 423 of
.../share/lilypond/2.23.7/scm/lily/output-svg.scm, at which
embedded-glyph-string is defined.

Note that the example above renders correctly with 2.23.6.

Trevor.


On Sat, Mar 26, 2022 at 10:36 PM Jonas Hahnfeld via Discussions on LilyPond
development  wrote:

> We are happy to announce the release of LilyPond 2.23.7. This is termed
> a development release, but these are usually reliable. If you want to
> use the current stable version of LilyPond, we recommend using the
> 2.22.2 version.
>
> Starting with this release, LilyPond requires Guile 2.2 and the
> official binaries were created with the new infrastructure developed
> over the past months. Issues reported for the previous release have
> been addressed, in particular regarding performance (by integrating
> compiled bytecode) and on Windows, where it is now possible to extract
> the provided zip archive with the Windows Explorer and use special
> characters in filenames. Please test this release and let us know about
> problems that you encounter.
>


-- 
Trevor Bača
www.trevorbaca.com
soundcloud.com/trevorbaca

Re[2]: who needs script `update-patch-version`?

[Trevor]

Werner wrote 01/02/2021 11:11:21


 It would be great if you can structure the revision as incremental
 updates and not as a big dump. Those are quite tedious to review and
 usually take much longer to go through...


Unfortunately, this is next to impossible since there are so many
changes.  I will provide a PDF that holds the changed pages so that
you and others can simply read what's written there, comparing it with
the current version of the Contributor guide if necessary.


It was this condition (to provide small incremental changes) that made
me abandon editing the docs many years ago. At the time I was part-way
through a major reorganisation of 2.1 Vocal Music which I had to abandon
as it was simply impossible to do it incrementally. Since then the docs 
have

virtually stagnated. Hope you're able to work this out better than I was
able to do, Werner.

Trevor

Re: Very Simple question

[Trevor]

Forwarding to LilyPond development list as I am no longer actively 
involved in Lily's development


Trevor

-- Original Message --
From: "Leonid Hrabovsky" 
To: t.dani...@treda.co.uk
Sent: 30/01/2021 02:17:46
Subject: Very Simple question


Dear Mr.Daniels,
as a composer using the most advanced notation forms, and being 
disappointed by inability of both Sibelius and Finale to meet my needs, 
I turned recently to LilyPond and see that there is a real hope for me 
to typeset my old scores still waiting since 1960-s. I have downloaded 
all manuals and feel that there are some hidden smart tricks allowing 
most crazy notational phenomena. But when I look into 2.8 Contemporary 
music section of Notation, I see that most sub-chapters here are still 
empty. So my question to you - how soon I and other users may expect 
the appearance of exhaustive covering all kinds of notation like 
Stockhausen, early Penderecki, Lutoslawski e.a.? Some isolated moments 
of it I see in Snippets, but it is far from enough for me.

Thank you in advance for your answer.

Very truly yours,

Leonid Hrabovsky
Леонід - Leonid


		Virus-free. www.avast.com 
<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=link> 
		 	

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Re[2]: state of the ’Pond for earnest tadpoles

[Trevor]

James wrote 02/01/2021 13:41:06


On 02/01/2021 12:20, Thomas Morley wrote:

A full `make doc` takes hours for me, even if invoked with `make doc
-j5 CPU_COUNT=5`
Thus I hardly do so, but use the CG-documented methods:


Hours?
Really?

Perhaps 'an hour' if you were using some very, very old CPU - but even using a 
single CPU on an 'old' i5 Intel system a full make doc for me took less than 50 
mins. That last time it took longer than an hour was when I had an old (8+ 
years ago) iMac running make doc in a linux VM.
When I had an old laptop with compromised cooling many years ago, a full 
build used to take several hours, presumably because my cpu was 
automatically clocked down to keep it from overheating. That was what 
triggered me to write the original versions (later improved by I forget 
who) of scripts/auxiliar/doc-section.sh MANUAL SECTION, as I was writing 
a lot of text for the manuals at the time, and needed to validate my 
contributions before pushing.


Trevor

Re[2]: issue verification

[Trevor]

Jonas, you wrote 17/09/2020 20:32:31
Subject: Re: issue verification


The problem I'm seeing is that it would become harder to find the
issues to verify: Most of the time, there will be fixed issues for the
current version still in development, which cannot be verified. Making
everybody wanting to help with verification skip over the same set of
issues potentially wastes a lot of time...

Jonas

Maybe I'm misunderstanding the problem, but a list of issues to verify
for a particular release, say 2.21.4, can be found by

Issues -> Milestones -> Release LilyPond 2.21.4 -> Milestone 2.21.4
Page down to see a list of completed issues (closed).

These are the ones to verify for 2.21.4 I believe.

Trevor

Re[2]: [lilypond-book] @format environments

[Trevor]

Michael Käppler, you wrote 09/07/2020 12:45:28


What strikes me the most is that 'addversion' is used only three times
throughout the
whole documentation, and these three occurrences are all in the LM,
fundamental.itely

What is the reason that the version string is mentioned for these
particular snippets and nowhere else?

I'm guessing, but I think these are the only examples that purport to be
"complete" LP programs. Everything else are just snippets of code.

The other possibility is that these were written by Graham, I think,
whereas I wrote most of the others.

I don't think it would be a problem if the version strings were dropped,
though.

Trevor

Re[2]: [RFC] Use GitLab Milestones

[Trevor]

Jonas, you wrote 29/06/2020 12:49:08


I got the list down to five corner cases, all involving multiple
commits related to a single issue.

https://gitlab.com/lilypond/lilypond/-/issues/154
https://gitlab.com/lilypond/lilypond/-/issues/1861
These two issues saw additional fixes after several years.

https://gitlab.com/lilypond/lilypond/-/issues/3807
https://gitlab.com/lilypond/lilypond/-/issues/4062
https://gitlab.com/lilypond/lilypond/-/issues/5039
Similar, but just multiple patches spread over subsequent releases.

I think it would be sufficient to have the final release that included
all commits, but wanted to check back if everybody agrees on that.


SGTM, Trevor

Re[2]: LilyPond | Doc: expand NR 1.6.2.3 Hiding staves (!91)

[Trevor]

Valentin, you wrote 27/05/2020


By the way: Trevor, would you take a look when you have a minute?
I’m worried this might be a bit convoluted and/or too wordy. 
@tdanielsmusic <https://gitlab.com/tdanielsmusic>


I support documenting the use of Vertical-Axis-Group.remove-layer, but 
it's a difficult concept to get across.
Having never used it myself I'm still trying to understand all the 
details of the hara-kiri-group-spanner-interface.
The description in the Internal Reference is fairly clear, but I'm 
struggling to decide how best to present it

to a typical user. Let me think it over for another day or so.

Trevor

Re: Handling problems with patches after the patch is pushed

[Trevor]

Carl Sorensen wrote 17/05/2020 18:32:27


I've been verifying issues from 2.21.1.

This has raised a need for clarification about how we handle issues
once they have been pushed.

It seems to me that there are at least two possibilities for how this
should be handled.

1) Once an issue is accepted and pushed, if there are problems
resulting from the issue, a new issue should be created.  This lets
the original issue stand as fixed.

2) Once an issue is accepted and pushed, if there are problems
resulting from the issue, the patch should be reverted, the issue
should be reopened, and the comments should be added to the issue
discussion.
I definitely prefer (1). I think (2) would potentially run into a 
variety of

further problems, and would make for a confusing trail if it needed
to be followed later. Maybe a comment and pointer could be added
to the first issue to indicate the continuation of the fix.

Trevor

Re[2]: 2.21.0 Issues all verified!

[Trevor]

Jonas Hahnfeld wrote 17/05/2020 11:57:10


Am Sonntag, den 17.05.2020, 00:28 +0200 schrieb David Kastrup:

 Personally, so far my main issue is, well, the workflow bypassing
 issues.  Changes that are only presented as merge requests without any
 accompanying issue are just too intangible for my taste: those
 correspond more to what we previously said "things like that you can
 push directly to staging".  I find it awkward to find my way around
 them, and after pushing there does not seem an obvious reverse relation
 to a tangible report that one could easily derive from seeing the commit
 in the repository.

 I prefer having an actual issue number for the details for anything of
 non-trivial nature.


I agree on having an issue for every bug we fix, especially those
coming from the bug-lilypond list. It's easier to have those in one
place instead of searching if a merge request happens to fix a problem.
For cleanups, compiler warnings or performance work I think having only
a MR is fine. In my opinion creating an issue for about any code change
is somewhat overkill. But there are guidelines mandating this, so I'd
be open to discussing the merits if somebody thinks it's the better
approach. After all, we had this previously...


I agree we need an issue for every bug we uncover, but fixes that are
trivial (in the sense that they are most unlikely to break anything) are
fine to simply issue a MR. In this past we left this judgement to the
fixer and it seemed not to cause any problems. Such trivial fixes are
now more visible than they were, so are even less likely to cause
problems or be applied inappropriately.

It is important to be able to move easily from Issue to Fix and back
when investigating possible problems in the future, so we should
ensure all the tags and links are in place before a fix is pushed.

Trevor

Re[4]: labels on GitLab

[Trevor]

Jonas, you wrote 13/05/2020 07:19:54


Am Dienstag, den 12.05.2020, 17:08 + schrieb Trevor:

 Jonas, you wrote 12/05/2020 14:49:27

 > Actually I think we should use milestones for this. They can be closed
 > and don't clutter the labels.
 > This comes with the disadvantage that there can be at most one
 > milestone set (which you also get with the scoped labels). This is not
 > correct for some patches that have been backported. I'm still building
 > ideas for how to handle this.
 Why do we need labels indicating a patch has been applied to several
 releases when a patch has been back-ported? Indicating the earliest
 release to which the patch has been applied should be adequate, or
 am I missing something here?

This would be easiest solution for this. But some strategy is required
because we do have issues with multiple labels applied right now. As I
said, I think this needs some thought and discussion first.


 Scoping the Fixed labels sounds good to me.


This would still leave us with 329 labels even after merging duplicates
(if my script is to be trusted). All of these will be listed in the
dropdown for eternity, right next to things like "Regression" and such.
With milestones instead we can close all except the last three or so,
and they will not be selectable for new issues. This shrinks the list
considerably and makes the UI much easier to use.

Milestones seem to have the wanted characteristics. But would we have
a hiatus with Labels before and Milestones after some changeover
release, both indicating the same thing? Even if that is so, it doesn't 
seem too

problematic to me.

Trevor

Re[2]: labels on GitLab

[Trevor]

Jonas, you wrote 12/05/2020 14:49:27


Actually I think we should use milestones for this. They can be closed
and don't clutter the labels.
This comes with the disadvantage that there can be at most one
milestone set (which you also get with the scoped labels). This is not
correct for some patches that have been backported. I'm still building
ideas for how to handle this.

Why do we need labels indicating a patch has been applied to several
releases when a patch has been back-ported? Indicating the earliest
release to which the patch has been applied should be adequate, or
am I missing something here?

Scoping the Fixed labels sounds good to me.

Trevor

Re: labels on GitLab

[Trevor]

Jonas wrote 12/05/2020 13:42:46

> In my opinion, there are currently far too many labels on GitLab. To
> avoid the situation getting worse, please do not create new labels out
> of thin air for now. Instead we should first contemplate on what we
> really need and configure this appropriately. (Adding a label for 
every

> possible warning that could be fixed is not helpful.)

+1

Labels are most useful when they form a limited set. That way we all 
know
what they are and what they mean. Inventing new labels is not really 
helpful
as they can rarely be applied to anything else and after a short while 
no one

knows they exist or what they mean.

Is there any way of limiting the set of labels which may be applied? 
That
would also eliminate spelling mistakes as well as making selecting 
Issues

by label more reliable.

Trevor

Re[2]: Verifying issues on Gitlab

[Trevor]

Another question:

How do I remove labels no longer relevant (or entered incorrectly!) eg 
Patch:Push for verified issues?


Trevor

-- Original Message --
From: "Kevin Barry" 
To: "Federico Bruni" 
Cc: "lilypond-devel" 
Sent: 12/05/2020 08:15:02
Subject: Re: Verifying issues on Gitlab


Hi Federico,

Thank you for the instructions. I will try to help get them done as
well.

On Tue, May 12, 2020 at 12:28:24AM +0200, Federico Bruni wrote:

 In the last comment you should find a commit id (if it's missing you'll have
 to search it).
 The easiest and quickest way to verify that a certain id has been included
 in the release tag label used in the issue is using Github. Start from this
 URL:


Another handy way to do this is to run git tag --contains .
(For me this is faster than github.)

Kevin

Re: Verifying issues on Gitlab

[Trevor]

Federico, you wrote 11/05/2020 23:01:14


I've started verifying issues on Gitlab.
It's quite straightforward, but still boring :-)
I think that most of the times it's "useless", meaning that I can't find any 
error.. but sometimes you may find something useful to report: a new command to be 
documented, an unclear new feature, etc.

The problem is that the number of issues to be verified, only for 2.21.0, is 
still huge (552):
https://gitlab.com/lilypond/lilypond/-/issues?scope=all=%E2%9C%93=closed_name[]=Fixed_2_21_0_name[]=Status%3A%3AFixed

and only 21 issues have been verified so far:
https://gitlab.com/lilypond/lilypond/-/issues?scope=all=%E2%9C%93=closed_name[]=Fixed_2_21_0_name[]=Status%3A%3AVerified

If nobody else jumps in, I will probably give up soon.
I've verified a few this evening, and will keep plugging away slowly 
from time to time ... at least for a while.


Trevor

Re: SourceForge still open

[Trevor]

Jonas, you wrote 11/05/2020 10:21:21


Apparently I failed to disable write access to SourceForge. Please do
not use it, new issues and comments will not be mirrored to GitLab!

(If somebody is able to help: Yesterday I dropped all groups the
permission to "create" and "update". I've now also removed the
individual tool permissions for "Issues", but I'm still able to post
comments. Maybe that's because I have admin permissions, I don't know.)


AFAICS you did everything necessary and correctly. I can't see what
else might be needed. There is a comment that changes might take
a few minutes to propagate, but it's already been several hours. :(

Trevor

Re[2]: 2.21.0 released

[Trevor]

Valentin Villenave wrote 09/04/2020 19:42:39


On 4/9/20, Carl Sorensen  wrote:

 Thank you so much for your dedication!

Ditto; Phil, you and James may both have the most thankless and yet
crucial jobs in the LilyPond community, so praises to you both! (And
obviously to Jonas, David, Han-Wen & al.).

Hear, hear to that! Well done to you all!


Here’s to hoping we can get back on track with our once bi-monthly
development release cycle!

+1

Trevor

Re[2]: Patch on dynamics and \RemoveEmptyStaves

[Trevor]

Hi "Jean Abou Samra", you wrote


My SourceForge username is jean-abou-samra. Could someone please give me write 
access to the issue tracker?


Added as a Developer, with Update and Create permissions in addition to 
Read.


Welcome aboard!

Trevor

Re[7]: a new way to build LilyPond binary releases

[Trevor]

Jonas, you wrote 12/03/2020 20:57:00


Am Donnerstag, den 12.03.2020, 20:45 + schrieb Trevor:

 I couldn't get convert-ly to work in Frescobaldi - not sure why yet.


The mingw archive doesn't contain a Python interpreter, so you'd need
this separately on Windows. As far as I remember, GUB put it next to
lilypond.exe but there were no wrapper scripts or such. How exactly did
you try to run it?

I simply used the Frescobaldi "Tools/Update with convert-ly".
It produces no messages - as it normally does if there is nothing to
convert (I think - it's a long time since I last ran it).

Trevor

Re[5]: a new way to build LilyPond binary releases

[Trevor]

Mats wrote12/03/2020 19:35:09


On 3/12/20 6:02 PM, Jonas Hahnfeld wrote:

Am Donnerstag, den 12.03.2020, 16:57 + schrieb Trevor:


I've tried compiling several of my files running this version of yours inside
Frescobaldi on my Windows 10 system. All worked fine except one. Here's
a MWE which shows the fault I found:

\version "2.20.0"
%\version "2.21.0"
{ R1\fermataMarkup }

The error is

C:/Users/tdani/AppData/Local/Temp/frescobaldi-ac_xr8yj/tmpxnqoyxdi/document.ly:3:5:
error: unknown escaped string: `\fermataMarkup'
{ R1
 \fermataMarkup }


It works fine in Fresco with 2.20.0 and earlier releases.

Correct, because \fermataMarkup is no more in master / what will become
2.21.0 since the following commit:
commit 4424b153c016632e69a7cd7cae6425024cee49fb
Author: Malte Meyn 
Date:   Fri Apr 19 12:15:57 2019 +0200

 Issue 5511/2: deprecate \fermataMarkup
  This removes \fermataMarkup and adds a convert-ly rule.

The bad thing is that we don't have documentation on this yet without
an unstable release 


The good thing is that if you run convert-ly on the file, it will automatically 
update to the new syntax! :-)

Thanks Jonas and Mats.

I couldn't get convert-ly to work in Frescobaldi - not sure why yet.
I had tried that first and it (mis-)lead me to believe there was no 
syntax change.


But at least I can see in the relevant documentation how to fix it.
(I still keep my LilyPond source repository more or less up to date, 
even though
my days of hacking the docs are over. And having read the docs I do 
remember

seeing the change now!)

Trevor

Re[2]: a new way to build LilyPond binary releases

[Trevor]

Jonas, you wrote

I've just finished building anew, please give
https://github.com/hahnjo/lilypond-binaries/releases/tag/2020-03-12 a
try. Or rebuild with the updated scripts 
I've tried compiling several of my files running this version of yours 
inside

Frescobaldi on my Windows 10 system. All worked fine except one. Here's
a MWE which shows the fault I found:

\version "2.20.0"
%\version "2.21.0"
{ R1\fermataMarkup }

The error is


C:/Users/tdani/AppData/Local/Temp/frescobaldi-ac_xr8yj/tmpxnqoyxdi/document.ly:3:5 
<0>:


error: unknown escaped string: `\fermataMarkup'

{ R1

\fermataMarkup }



It works fine in Fresco with 2.20.0 and earlier releases.



Trevor

Missing link

[Trevor]

Congratulations to all involved in getting 2.20 out the door!
This is a big step forward.

One minor glitch I noticed: in http://lilypond.org/website/all.html
the link to the 2.18 documentation in the list of previous stable 
versions

has gone AWOL, although the documentation itself is still in the correct
place  in http://lilypond.org/doc/v2.18/Documentation/web/manuals

Current users of 2.18 will still need this until they get around to 
migrating.


Trevor

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

[Trevor]

Phil Holmes wrote 08/02/2020 17:24:56
Subject: Re: Add Code of Conduct [Another RFC or not now?]


- Original Message - From: "Karlin High" 
However, I'd like to hear from David Kastrup and James Lowe first. To me, their 
opposition registered as the strongest.

I remain strongly opposed to a CoC.

As do I. I'm quite sure we on this list are all perfectly capable of 
civil and caring behaviour without having it spelled out in nanny-ish 
terms.


Trevor

Re: My availability

[Trevor]

Dan Eble wrote 07/02/2020 18:33:10
Subject: My availability


I'm facing the bittersweet experience of becoming an employee again on Monday.  
I'm not sure what the ramp-up will require or what the new cadence of my life 
will be, but I will certainly have less time to devote to LilyPond.  Hopefully, 
it will be a reversion to the mean and not more!  I thought I should let you 
know so that when my engagement diminishes subito you don't think there's 
something wrong.

Congratulations, Dan. Your new employers have found a gem!

Trevor

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

[Trevor]

David Kastrup wrote  07/02/2020 12:21:30
Subject: Re: [RFC] switch to GitLab / gitlab.com


The seminal difference being that a workable free version of their
software is available for the purpose of self-hosting.  That gives an
escape hatch that either users or competing services can pick up in the
case of contingency.

This may seem academical, but even the academical possibility reins in
corporate decision makers from performing wholesale changes on a whim.

The Allura software that we use at SourceForge is also Open Source, I 
believe.


See https://allura.apache.org/

I don't know to what extent the SourceForge team have modified this, but
if self-hosting is a possibility this should at least be seriously 
investigated.
(Not by me, I should add - at 79 my days of technical involvement are 
over.)


We'd always intended to migrate Allura to a self-hosted platform, but
no-one seemed willing to put in the effort 5 years ago.

Trevor

Fw: Assessment of Allura at SourceForge

[Trevor]

Hi Federico

I've fished the mail below out of my archive. It shows the assessment I 
made of Allura before starting the migration. You might find this useful 
as a set of points to consider.


I was amazed to find I carried out this migration as a temporary 
stop-gap to avoid losing all our database in the summer of 2015 - almost 
5 years ago - when Google dropped their !


In spite of the good match it still took me almost three months of quite 
hard work to bring the migration to a successful conclusion. The main 
problem was getting a reliable and complete migration of all the data - 
including correct numbering, full text of comments, contributor names, 
and images (particularly tricky). Because the data transfer took many 
hours it frequently broke before completing. I needed the help of the 
Allura devs several times to overcome various problems. They were 
particularly responsive and helpful.


Let me know if you'd like any more info.

Trevor

-- Forwarded Message --
From: "Trevor Daniels" 
To: "Lily-Devel List" 
Sent: 17/05/2015 09:33:32
Subject: Assessment of Allura at SourceForge

Hi

I've now completed my assessment of Allura at SourceForge against the list of 
requirements supplied by Phil.  A point-by-point comparison is shown below.  My 
conclusion is that Allura at SourceForge is suitable for hosting our Issues DB.

There are some differences from GoogleCode, but these are relatively minor and 
can be accommodated by small changes in our procedures.  In particular the 
Blocking and Duplicate facilities will be different, and the various posts in 
the discussion are fully threaded and so are not numbered, meaning 
cross-referencing is by link rather than number.  The emails sent out following 
additions and amendments are not formatted as nicely as those from GoogleCode, 
but contain all the information.  Support is by +ve and -ve voting rather than 
starring.  Finally, the Owner field in the transferred tickets is not 
populated.  The owner is identified in the text of the ticket,  so the field 
can be manually amended after the event in the few tickets where this matters.

Other than that the facilities are remarkably similar, and apart from 
congestion the transfer of the DB is fairly trouble-free.

I'm in the process of tailoring a test facility for developers and admin to 
play with, and as a vehicle for re-engineering git-cl and patchy.  I'll post 
again when this is ready.

Here's the point-by-point comparison:


 1. Allow creation of a new sequentially numbered issue, with
 text describing the issue's title and details


Available as standard.


 2. Allow tagging the issue with a range of types
 (e.g. Type-Critical = Defect which blocks a stable release,
 Type-Maintainability = Hinders future development)


Available by creating a new custom field Type, with a list of permitted
values.


 3. Allow tagging the issue with life-cycle stages
 (e.g. Accepted, started, fixed)


This is the Status field.  Available as standard.


 4. Allow tagging issues with patch status


Available by creating a new custom field: Patch, with list of permitted
values.  Note that existing values are not capitalised, unlike
values of the Type field, so need to continue with this as searches
are case-sensitive.  Search name is "_patch".  (All field names in
searches are lower-case only, and custom field names start with an
underscore.)


 5. Allow display of issues at different lifecycle stages
 (issues open, issues to be verified, all issues)


Comprehensive searching possible, eg "labels:2_19_19 AND status:Fixed"
also custom buttons can be created for commonly required searches.


 6. Allow display of issues of different types
 (e.g. Critical, Documentation, .)


Possible after creating new field called Type.  Search name is "_type".
eg "_type:Documentation AND !status:Fixed"


 7. Allow image attachment and display


Available as standard.


 8. Allow non-image attachments


Available as standard.


 9. Prevent non-registered users from adding issues


Available as standard.  Separate permissions may be set for:

  Admin
  Configure
  Create tickets
  Delete tickets
  Moderate comments
  Post comments (subject to moderation)
  Post comments (without moderation)
  View Tickets
  Edit Tickets

Permissions are set per group:

  Admin
  Developer
  Member
  Authenticated
  Anonymous

Additional groups can be created.

so Create tickets (etc) could be restricted to Admin and Developers

It would be possible to have a second set of tickets which could be
available to anyone.  Tickets can be selected and moved between
trackers or even projects.


 10. Allow registered admins to add users


Available as standard.  Users must have a SourceForge account.


 11. Allow users to add comments to existing issues


Controlled by permissions.  See 9. above.
Might be best restricted to Authenticated users (any logged-in user).


 12. Provide an API

Re[2]: Code of Conduct

[Trevor]

Dan Eble wrote 05/02/2020 14:25:26
Subject: Re: Code of Conduct


On Feb 5, 2020, at 05:45, Han-Wen Nienhuys  wrote:


 Having a CoC gives us a set of guidelines, a process and a set of
 corrective actions to take to help keep things nice.


I prefer the implicit good-neighbour agreement we have now.

So do I! Definitely!

It's remarkable how well it has worked and how free of animosity it has 
been.


Trevor

Re: Janek is coming back to LilyPond! :-)

[Trevor]

Janek, you wrote 20/01/2020 16:34:15


I just came back from music engraving conference organized by Werner and
Urs (kudos to them!!), and - inspired by the people present there (most
importantly Han-Wen, Mike Solomon and Kieren MacMillan) - I decided to get
involved in the project again :-) I should be able to spend about 5-10
hours a week on LilyPond.

Wow! Han-Wen and now Janek! Welcome back to both of you!


One of the topics discussed in Salzburg was making it easier to contribute
to LilyPond. I have proposed to lead that effort, and the people present
agreed to it. I would like to ask the full developer community for your
trust*,* too. I will share my plans in a separate thread.

Good luck!

Trevor

Re: sf issue tracker access

[Trevor]

Hi Han-Wen

Great to have you back!

You've now got Create and Update permissions along with Read in the 
SourceForge Issue Tracker.


Trevor

-- Original Message --
From: "Han-Wen Nienhuys" 
To: "lilypond-devel" 
Sent: 17/01/2020 23:02:18
Subject: sf issue tracker access


Hi,

i'm "hanwen" for the sourceforge bug tracker. Could someone give me
write access?

--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen

Re: Issue tracker write access?

[Trevor]

David, you wrote 12/01/2020 09:46:47


Hello,

I have written some documentation I would like to submit for
consideration/review (following this thread on lilypond-user:
https://lists.gnu.org/archive/html/lilypond-user/2020-01/msg00081.html) -
how should I proceed? May I request write access to the issue tracker and
upload to Rietveld, or submit some other way?

My SourceForge user name is davidsg
Added to the SourceForge Issue Tracker with Create and Update 
permissions as well as Read.


Welcome aboard!

Trevor

Re: Issue tracker access

[Trevor]

"Michael Käppler"  wrote 10/01/2020 07:02:42


Hi all,
I would like to participate in LilyPond development (again, after many
years - my last contributions date from 2009).
Thus I'm asking for access to the Sourceforge issue tracker.
My username is xmichael-k.

Hi Michael, welcome back! You should now have access to the issue 
tracker

with Create and Update permissions as well as Read.

Trevor

Re[2]: MacOS 64bit support

[Trevor]

Yassine Chbani, you wrote 15/12/2019 20:49:32


Sure! IIUC, I need to upload the patch to the code review tool and update
the issue tracker? If so, could you (or someone else) give my account
yassinec write access to the issue tracker? Otherwise I can send the patch
by email
I've added yassinec to the issue tracker with Create and Update 
permissions

as well as Read. Welcome aboard!
Trevor

Re: shepherd a patch?

[Trevor Bača]

Hi David,

On Mon, Dec 2, 2019 at 7:57 AM David Nalesnik 
wrote:

> Hi Trevor,
>
> On Sun, Dec 1, 2019 at 9:24 PM Trevor Bača  wrote:
> >
> > Hi David (and Kieren and Urs),
> >
> > Awesome. I'll look forward to using measure-attached spanners, too.
> >
> > Trevor.
> >
>
> If you build from current master, you can use them now.  Patch has been
> pushed!
>

Fantastic. Thanks for yet another contribution to my workflow.

Trevor.


-- 
Trevor Bača
www.trevorbaca.com
soundcloud.com/trevorbaca

Re: shepherd a patch?

[Trevor Bača]

Hi David (and Kieren and Urs),

Awesome. I'll look forward to using measure-attached spanners, too.

Trevor.

On Fri, Nov 15, 2019 at 10:02 AM Kieren MacMillan <
kie...@kierenmacmillan.info> wrote:

> Hi David,
>
> > this is something that I've wanted and Kieren has clamored for...
>
> Yes! I’m so excited to see this progress.
>
> Thanks!
> Kieren.
>
>

-- 
Trevor Bača
www.trevorbaca.com
soundcloud.com/trevorbaca

Re: Lilypond Issue Tracker Access

[Trevor]

Hi Austin


I'm trying to make a (small) contribution to Lilypond. The instructions
I found at
http://lilypond.org/doc/v2.19/Documentation/contributor/git_002dcl tell
me to email this address and ask for write access to the Lilypond issue
tracker.

Sourceforge username: austinglaser
Added as a Developer on SourceForge, with permissions to Create and 
Update Issues as well as Read them.


Welcome aboard!

Trevor

Re[2]: Working on issue 665, how to proceed?

[Trevor]

Hi Jaap

I've added de-wolff to Sourceforge with Developer permissions. You may 
now update and create Issues as well as reading them.


Next step is to initiate discussion about your patch under Issue 665 at 
Sourceforge, and upload a patch as a proposal to Rietveld for a code 
review. Instructions for doing this are in the Contributor's Guide 
http://lilypond.org/doc/v2.19/Documentation/contributor/quick-start .


I see the patch would be quite large, so a code review will be 
difficult. I'll leave it to the experienced code developers to take it 
from here.


Thanks for working on this - hope it all goes well!

Trevor

-- Original Message --
From: lilyp...@de-wolff.org
To: "'Trevor'" 
Sent: 16/11/2019 16:53:36
Subject: RE: Working on issue 665, how to proceed?


I already have an sourceforge account: my username is de-wolff

Jaap


 -Original Message-----
 From: Trevor 
 Sent: Saturday, November 16, 2019 3:44 PM
 To: lilyp...@de-wolff.org; lilypond-devel@gnu.org
 Subject: Re: Working on issue 665, how to proceed?

 lilyp...@de-wolff.org wrote 15/11/2019 23:31:33
 Subject: Working on issue 665, how to proceed?

 Hi Jaap

 You wrote

 >In the last weeks I did write a start of a lilypond -> musicxml solution.
 >
 >As this is an (old) issue, there is need to put this in lilypond, but how?
 >What level of quality is needed? Who can help me to join the lilypond
 >developer group?
 The first step is to obtain a username at sourceforge.net and post it to the -
 devel list so we can add you as a Developer. Then you'll be able to add your
 comments and code to Issue 665.

 Trevor

Re[2]: Implement MeasureAttachedSpanner (issue 571180043 by david.nales...@gmail.com)

[Trevor]

-- Original Message --
From: thomasmorle...@gmail.com
To: david.nales...@gmail.com; lemzw...@googlemail.com; 
carl.d.soren...@gmail.com; nine.fierce.ball...@gmail.com

Cc: re...@codereview-hr.appspotmail.com; lilypond-devel@gnu.org
Sent: 16/11/2019 14:30:43
Subject: Re: Implement MeasureAttachedSpanner (issue 571180043 by 
david.nales...@gmail.com)



On 2019/11/16 14:27:25, Dan Eble wrote:

On 2019/11/15 19:21:09, Carl wrote:
> I think the name should be changed from MeasureAttachedSpanner to
> BarAttachedSpanner.



Calling it just MeasureSpanner would also address the specific problem you
raised.  Is it more important for the name to state where it is attached or what
it spans?


I'd vote for MeasureSpanner.

+1

Trevor

https://codereview.appspot.com/571180043

Re: Working on issue 665, how to proceed?

[Trevor]

lilyp...@de-wolff.org wrote 15/11/2019 23:31:33
Subject: Working on issue 665, how to proceed?

Hi Jaap

You wrote


In the last weeks I did write a start of a lilypond -> musicxml solution.

As this is an (old) issue, there is need to put this in lilypond, but how?
What level of quality is needed? Who can help me to join the lilypond
developer group?
The first step is to obtain a username at sourceforge.net and post it to 
the

-devel list so we can add you as a Developer. Then you'll be able to add
your comments and code to Issue 665.

Trevor

Core dump: page-breaking.cc (line 1180) with \autoPageBreaksOff [2.19.83]

[Trevor Bača]

Hi,

The page-breaker core dumps in the following example:

%%% BEGIN BUG %%%

\version "2.19.83"

notes = {

c'4 c'4 c'4 c'4 c'4
c'4 c'4 c'4 c'4 c'4
c'4 c'4 c'4

}

\layout {

\context {
\name TimeSignatureContext
\type Engraver_group
\consists Axis_group_engraver
\consists Time_signature_engraver
\override TimeSignature.font-size = 3
}

\context {
\Score
\accepts TimeSignatureContext
}
}

\context Score = "Score"
<<

\context TimeSignatureContext = "Time_Signature_Context"
{

\autoPageBreaksOff
\time 5/4
s1 * 5/4
\time 5/4
s1 * 5/4
\time 1/4
s1 * 3/4

}

\context Staff = "Staff_I"
\context Voice \notes

\context Staff = "Staff_II"
\context Voice \notes

\context Staff = "Staff_III"
\context Voice \notes

\context Staff = "Staff_IV"
\context Voice \notes

>>

%%% END BUG %%%


Output:

GNU LilyPond 2.19.83
Processing `illustration.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1
page.../home/gub/NewGub/gub/target/darwin-x86/src/lilypond-git.sv.gnu.org--lilypond.git-stable-test/lily/page-breaking.cc:1180:
failed assertion `ret <= cached_line_details_.size ()'


Note, oddly, that almost every line in the MWE above needs to be present to
trigger the core. That is: commenting out \autoPageBreaksOff prevents the
core; reducing the example from four staves to three staves prevents the
core; selecting a different series of time signatures for the example
prevents the core (?!); even commenting out the TimeSignature.font-size
override prevents the core (?!).


Thanks,

Trevor.


-- 
Trevor Bača
www.trevorbaca.com
soundcloud.com/trevorbaca
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Write permissions for lilypond sourceforge

[Trevor]

Hi Matt


Could I please given write access to sourceforge as I'd ideally like to
contribute a few small python changes upstream from the py2to3 work
continues broader discussion.

My profile is https://sourceforge.net/u/masterodin/profile and the email is
same as this one (matt.peve...@gmail.com).

Added masterodin to the Developer list at SourceForge. You should now be
able to comment on issues and add new ones.

Welcome!

Trevor


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

Fw: [testlilyissues:issues] #4975 [Windows] Grace notes cause staff to protrude into the margin

[Trevor]

Found the original message ...

Trevor

-- Forwarded Message --
From: "Jean Abou Samra" 
To: "[testlilyissues:issues] " 
<4...@issues.testlilyissues.p.re.sourceforge.net>

Sent: 14/07/2019 21:07:26
Subject: [testlilyissues:issues] #4975 [Windows] Grace notes cause staff 
to protrude into the margin


Also reported on Mac OS (at least 10.12.6 Sierra [me] and 10.13.6 High Sierra 
[Michael Hendry]) with LilyPond 2.21.0, but _not_  LilyPond 2.19.83, quite 
surprisingly as the bug appeared with 2.19.19 on Windows. Both above examples 
are reproduced, and I can add a third one:
```
\version "2.21.0"
\relative {
c'1
\acciaccatura { bes8 } c1
}
```
Full outputs and logs on the three examples using 2.21.0, 2.19.83 and 2.18.2 
are available in the attached archive.
Two additional remarks:
* On the first example, "mis-predicted force" programming errors show up, and 
yet the output is perfectly normal, the staff doesn't protrude.
* On the last example, the bug is triggered as soon as the grace note is 
altered, no matter the alteration and no matter wether \acciaccatura or \grace 
is used.
Hope that helps!



---

** [issues:#4975] [Windows] Grace notes cause staff to protrude into the 
margin**

**Status:** Started
**Created:** Sun Sep 18, 2016 11:07 PM UTC by Simon Albrecht
**Last Updated:** Sun Jul 14, 2019 07:23 PM UTC
**Owner:** Phil Holmes


http://lilypond.1069038.n5.nabble.com/Grace-notes-and-staff-miss-alignment-tp181529p188186.html
As reported by Karol and confirmed by Pierre, this code


:::TeX
\version "2.19.48"

\transpose c c' {
  \repeat unfold 16 { e'8 a }
  R1*8
}

\transpose c c' {
  \repeat unfold 16 { \grace dis'8 e' \grace gis8 a }
  R1*8
}


under Windows (at least 7 and 8) causes lots of `programming error: 
mis-predicted force` and has the last staff flow into the margin.
Output at <http://lilypond.1069038.n5.nabble.com/file/n188186/ttt.pdf>

The first bad version is 2.19.19.


---

Sent from sourceforge.net because you indicated interest in 
<https://sourceforge.net/p/testlilyissues/issues/4975/>



To unsubscribe from further messages, please visit 
<https://sourceforge.net/auth/subscriptions/>


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

Fw: [testlilyissues:issues] Moderation action required

[Trevor]

Forwarding on behalf of Jean Abou Samra as I deleted the message in 
SourceForge by mistake :( I don't know what the original subject line 
was, and the attachment is lost. Sorry! Perhaps Jean could resubmit.


Trevor

-- Forwarded Message --
From: "Jean Abou Samra" 
To: nore...@sourceforge.net
Sent: 14/07/2019 20:23:46
Subject: [testlilyissues:issues] Moderation action required

The following submission requires approval at 
https://sourceforge.net/p/testlilyissues/issues/_discuss/moderate before it can 
be approved for posting:'t

Also reported on Mac OS (at least 10.12.6 Sierra [me] and 10.13.6 High Sierra 
[Michael Hendry]) with LilyPond 2.21.0, but _not_  LilyPond 2.19.83, quite 
surprisingly as the bug appeared with 2.19.19 on Windows. Both above examples 
are reproduced, and I can add a third one:
```
\version "2.21.0"
\relative {
c'1
\acciaccatura { bes8 } c1
}
```
Full outputs and logs on the three examples using 2.21.0, 2.19.83 and 2.18.2 
are available in the attached archive.
Two additional remarks:
* On the first example, "mis-predicted force" programming errors show up, and 
yet the output is perfectly normal, the staff doesn't protrude.
* On the last example, the bug is triggered as soon as the grace note is 
altered, no matter the alteration and no matter wether \acciaccatura or \grace 
is used.
Hope that helps!



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

Re: Syntax: numbers prefixed with # or not

[Trevor Bača]

On Thu, Feb 21, 2019 at 7:44 AM Kieren MacMillan <
kieren_macmil...@sympatico.ca> wrote:

> Hi Valentin,
>
> > Or, we just don’t bother and keep using (and recommending) # everywhere.
> > Thoughts?
>
> I use # everywhere I can, even where it’s not strictly necessary, in part
> because it visibly sets arguments apart for easy parsing [by me].
>
> Not sure if that’s useful input for you?
>

Hi Kieren, Valentin,

I've shifted my practice the opposite direction of Kieren's, I suppose: I
omit # before numbers everywhere that it's possible to do so.

No real Lily rationale here, other than a personal coding practice to
employ the (lexically) shortest version of equivalent statements. I think
the original impulse came years ago when I was trying to rid myself of
redundant precedence indicators, eg, to use "a + b * c" everywhere in place
of "a + (b * c)"; because the two forms are equivalent (in most languages),
I wanted a canonical version for myself that I could spot at a glance. That
practice leaked into my Lily code, with the slight preference now for "99"
to "#99" where the forms are equivalent.

Trevor.

-- 
Trevor Bača
www.trevorbaca.com
soundcloud.com/trevorbaca
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re[2]: Please test gub

[Trevor]

John, you wrote 21/02/2019 17:19:23


Could somebody please add me (login john-mandereau) on SourceForge so I can
upload a patch using the expected workflow?


Added with Developer privileges. Welcome!

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

Re: Can alternateTextSpannerEngraver now completely replace Text_spanner_engraver in a public release?

[Trevor Bača]

On Wed, Feb 13, 2019 at 8:35 AM David Kastrup  wrote:

> David Nalesnik  writes:
>
> > On Wed, Feb 13, 2019 at 7:49 AM Trevor Bača 
> wrote:
> >>
> >> Could somebody else possibly provide James a patch of David N.'s
> >> alternateTextSpannerEngraver?
> >>
> >> Trevor.
> >
> > The issue which would come up is that it is written in Scheme, rather
> > than C++.  This has implications for documentation.
>
> It does?  What kind of documentation cannot be achieved in Scheme that
> would be possible in C++?
>
> Here is some page from the Internals reference:
>
> File: lilypond-internals.info,  Node: Merge_rests_engraver,  Next:
> Metronome_mark_engraver,  Prev: Mensural_ligature_engraver,  Up: Engravers
> and Performers
>
> 2.2.71 Merge_rests_engraver
> ---
>
> Engraver to merge rests in multiple voices on the same staff.  This
> works by gathering all rests at a time step.  If they are all of the
> same length and there are at least two they are moved to the correct
> location as if there were one voice.
>
>Properties (read)
>
>  ‘suspendRestMerging’ (boolean)
>   When using the Merge_rest_engraver do not merge rests when
>   this is set to true.
>
>‘Merge_rests_engraver’ is not part of any context.
>
>
> This is an engraver written in Scheme.
>
> --
> David Kastrup
>

Thank you both (David and David) so much for engaging on this last step!
Truly wonderful; and if I can just chime in one last time while you are
thinking through the problem: I *think* (not 100% certain, but close to it)
that the ideal final implementation path would be not just to add
alternateTextSpannerEngraver as, say, Alternate_text_spanner_engraver, but
rather to *replace* the existing Text_spanner_engraver with (the
implementation of) alternateTextSpannerEngraver. I think this was clear in
my previous mail, but I just wanted to insert one last time here as the
question of Scheme-vs-C++ final resting spot gets considered.


Trevor.


-- 
Trevor Bača
www.trevorbaca.com
soundcloud.com/trevorbaca
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Can alternateTextSpannerEngraver now completely replace Text_spanner_engraver in a public release?

[Trevor Bača]

On Wed, Feb 13, 2019 at 4:58 AM James Lowe  wrote:

> Hello Trevor,
>
> On Tue, 12 Feb 2019 16:45:35 -0600, Trevor Bača 
> wrote:
>
>
> >
> > Question: is it now possible to replace Text_spanner_engraver with David
> > N.'s extended implementation, in a coming public release of LilyPond?
> >
> >
> > Trevor.
> >
>
>
> If you have a patch based on current master I can at least test that for
> you.]
>
> James
>

Hi James,

I have no patch.

Could somebody else possibly provide James a patch of David N.'s
alternateTextSpannerEngraver?

Trevor.


-- 
Trevor Bača
www.trevorbaca.com
soundcloud.com/trevorbaca
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Can alternateTextSpannerEngraver now completely replace Text_spanner_engraver in a public release?

[Trevor Bača]

Hi,

For many years, one of the clearest functional gaps in LilyPond was the
limitation that voices allow only a single text spanner at a time. Very
many scores of recent decades notate two musical parameters changing at the
same time: a passage of string music moving ponticello -> tasto while at
the same time decreasing from vibrato molto -> non vibrato, for example.
Arrowed lines are the nearly universal way of notating such things,
available in LilyPond as text spanners; but to allow for what now counts as
newly emerged common practice, an arbitrary number of text spanners need to
be allowed per voice.

Lily users have asked for the feature for a long time. Here's an example
from 2009:

http://lists.gnu.org/archive/html/lilypond-user/2009-11/msg00031.html

By 2015, the idea of spanner-id had been added to LilyPond to allow for
this type of functionality. But despite the name of the property ("will
spanner-id allow for ALL types of spanner to overlap?"), integration first
centered on slurs and phrasing slurs. Here's a thread from 2015 with David
K. working to allow an input syntax for those first two types of spanner:

http://lists.gnu.org/archive/html/lilypond-user/2015-10/msg00157.html

At that same time in 2015, however, David N. had in fact rewritten Lily's
Text_spanner_engraver to integrate spanner-id, and hence supply the missing
functionality. David N.'s attachment (given later in the same thread listed
above) gives the necessary code:

http://lists.gnu.org/archive/html/lilypond-user/2015-10/msg00545.html

Last year, in May 2018, I finally integrated David N.'s
alternateTextSpannerEngraver into my own work, using it to replace Lily's
default Text_spanner_engraver completely. The results have been extremely
good: *David N.'s alternateTextSpannerEngraver performs exactly the same as
the current Text_spanner_engraver but with the additional flexibility of
being able to define (and use) arbitrarily many types of text spanner in a
single voice.*

So, it looks like David N.'s alternateTextSpannerEngraver supplies a piece
of functionality that's been missing in LilyPond since inception, which is
fantastic.

Question: is it now possible to replace Text_spanner_engraver with David
N.'s extended implementation, in a coming public release of LilyPond?


Trevor.

-- 
Trevor Bača
www.trevorbaca.com
soundcloud.com/trevorbaca
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Please test new lilypond installers

[Trevor]

Knut Petersen wrote 29/01/2019 09:19:33

Urs Liska provides installers for branch master of lilypond, generated by an 
updated version of our build system GUB:

   https://cloud.ursliska.de/s/QPINwLqJNeVslCu

There you'll find

   lilypond-2.21.0-1.darwin-ppc.tar.bz2
   lilypond-2.21.0-1.darwin-x86.tar.bz2
   lilypond-2.21.0-1.freebsd-64.sh
   lilypond-2.21.0-1.freebsd-x86.sh
   lilypond-2.21.0-1.linux-64.sh
   lilypond-2.21.0-1.linux-ppc.sh
   lilypond-2.21.0-1.linux-x86.sh
   lilypond-2.21.0-1.mingw.exe
   lilypond-2.21.0.tar.gz

Please test if those files provide valid lilypond installations and report 
success / failure by replying to this thread if no identical test results 
already have been posted.
The mingw.exe download appears to work fine in Frescobaldi running under 
Windows 10 Home on Intel Core i7-7500U cpu. I'll continue to use it for 
all future typesetting.


Looking good! Many thanks to David, Knut, Urs and all those involved in 
generating this release!


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

Re: Request for write access to Sourceforge issue tracker

[Trevor]

Hi Bobo


I'd like to request write access to the Sourceforge issue tracker.
I've written a small patch to fix the issue described here:
https://lists.gnu.org/archive/html/lilypond-user/2015-02/msg00035.html
Following the contributor's guide I'm currently setting up `git-cl` and
therefore require access to the issue tracker. My username is 
"bobo1239".

Thanks in advance.


Added with Developer status.

Trevor


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

Re: Write access to the issue tracker.

[Trevor]

Hi Pedro

Welcome!

I've added you as a Developer to the Issue Tracker.

Trevor

-- Original Message --
From: "Pedro Pereira" 
To: "lilypond-devel@gnu.org" 
Sent: 25/07/2018 14:17:11
Subject: Write access to the issue tracker.


Hello,

I really want to contribute to the Lilypond project ( or at least to 
give it a try ) !
So, I'm writing this email to ask for write access to the issue 
tracker, as specified in the CG.


Sourceforce username : augmented-chord
Best regards,
Pedro Pereira
___
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[2]: Sourceforge is playing up - is anyone else having the same problems

[Trevor]

Phil, you wrote 17/05/2018 09:59:38


- Original Message - From: "James Lowe" <james.l...@runbox.com>


For the last 2 days I have been struggling to login to sourceforge.

This morning I managed to get a login session for about 10 mins before 
I got the irritating 'Oops..' message and then have not been able to 
login since. I can get to the main site and list the issues and Phils' 
URL is still scraping OK.


Is anyone else having the same problem *logging in* and not just 
listing issues (I am also using 2FA)?


James


I'm currently getting:

"503 No Backend Servers Available
No backend servers were available to answer your request. Please notify 
the site admins."


I haven't logged in for a few days, but tried it just now and all seems 
fine.

Searches seem to work as normal.

What exactly generated the problem re Backend Servers?

Trevor


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

Re[2]: [testlilyissues:issues] Moderation action required

[Trevor]

David Kastrup wrote 12/05/2018 11:27:40


James, they try to fix lilypond 2.18, not 2.20 or master.

2.18 is still insecure.


At this point of time we probably really need to decide to release 
2.20,

come hell and high water, including its current faults.

Or pitch out 2.18.3.  At the very least it might make sense to add
purely compilation fixes (for keeping up with more current versions of
compilers etc) to the current stable branch in future even if one does
no proper release.  Possibly even security fixes.  That way there is
some semi-official way of dealing with bit rot.  Also makes it easier 
to

do regression testing 5 years later.


"decide to release 2.20"? Yes. Better still: "And" rather than "Or".

If details of the regressions in 2.20.0 are provided alongside the 
improvements

folk can decide which of 2.18.3 and 2.20.0 suits them best.

Trevor


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

Re[2]: Clarify notation for slurs and beams (issue 343060043 by carl.d.soren...@gmail.com)

[Trevor]

Carl, you wrote 30/04/2018 18:16:05


On 4/30/18, 11:04 AM, "lilypond-devel on behalf of 
tdanielsmu...@googlemail.com" 
<lilypond-devel-bounces+c_sorensen=byu@gnu.org on behalf of 
tdanielsmu...@googlemail.com> wrote:


   @ref definitely should work.  It may be that the heading for one
   of them is "Articulation and dynamics", not "Articulations and
   dynamics" - no "s".  Using @ruser bypasses the check, I think.

OK, that's clearly the issue.

Now, how should it be fixed?  Should we stick with "Articulation and 
dynamics", even though the next menu down is "Articulations"?  Or 
should we change to "Articulations and dynamics"?  I can do either one.
Well, I'd prefer adding the "s" to the title, as long as it doesn't 
break other references (I don't know if there are any, but if there are 
any in the LM they should show up as errors in a make doc.)  
Documentation/scripts/auxiliar/ref_check.py should check all refs for 
you, if it still works - it's a while since I used it.


Trevor


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

Re: testlilyissues access

[Trevor]

 "Bernhard M. Wiedemann" wrote 12/03/2018 12:36:50


http://lilypond.org/doc/v2.19/Documentation/contributor/git_002dcl

says, I need to ask here for write-access to the SF issue tracker
for my username:
greenbird


Can someone please set this up for me,
so that I can contribute some patches from
https://codereview.appspot.com/337650043
and
https://savannah.gnu.org/patch/index.php?9370

and maybe even some more (hopefully with the help of one of you)

I'm doing this as part of
https://en.opensuse.org/openSUSE:Reproducible_Builds

but OTOH I already used lilypond for some music, too.


Hi Bernhard

Added to SF Issue Tracker as requested

Trevor


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

Re: Web/Easier editing update

[Trevor]

Simon, you wrote 28/02/2018 18:00:14


I noticed slight glitches when having a look at the ‘Easier editing’ 
page on the website. This is the text about Frescobaldi:


> Frescobaldi is a lightweight, yet powerful, music and text editor 
with many features added and enhanced particularly for LilyPond. Major 
features include point-and-click links between the code and music 
views, detailed score wizards, built in LilyPond documentation browser, 
syntax highlighting and automatic completion. Frescobaldi is written in 
Python, with PyQt4 for its user interface, and will run on all major 
operating systems (GNU/Linux, Mac OS X and Windows).


I’m not a native speaker, so help me out here: the two commas 
encompassing ‘yet powerful’ seem German to me. Is that idiomatic 
English? Also: built in or built-in?
The effect of encompassing "yet powerful" in commas adds emphasis to 
that phrase by introducing pauses.  Imagine holding up a finger at that 
point if you were reading it aloud - same effect.   It should be 
built-in.


Trevor


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

Re[2]: Issue 5272: Add \depart (issue 337520043 by nine.fierce.ball...@gmail.com)

[Trevor]

Hi Carl

I can't resist adding my tuppence-worth :)

You wrote 07/02/2018 15:18:55

If we want to capture semantics properly, I believe we need to 
recognize that there are three different kinds of marks:


1) "jump-from" marks (D.S. al ..., D.C. al ..., To Coda)
2) "jump-to" marks (Segno, beginning of piece, coda)
3) "stop playing" marks (Fine, end of piece)

Agreed

But if we try to capture all three semantics in a single mark, our 
prospective MIDI performer would need to analyze the mark to decide 
which kind it was.  And since we can do whatever we want with the mark 
by changing the markup, it seems like we need three *different* marks.  
My initial proposal if we want to go the functional route would be to 
use


\depart
\join
\fine
I really don't like \depart, and as all three are marks as well as 
potential semantic elements I would suggest


\gotoMark ID sign or \flowMark  ID sign
\locationMark  ID sign or \placeMark ID sign
\endMark  sign

Trevor


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

Re: Request for LilyPond Issue Tracker Project Authorization

[Trevor]

Hi Torsten, you wrote 12/01/2018 09:56:44

Could anybody please be so kind as to add me to the LilyIssues project 
in sourceforge?
Without this authorization the automatic tag update etc using git 
didn't work when trying to upload a patch regarding issue #3653.

Thomas Morley/Harm edited the tags for me this time (thanks!)

My sourceforge user is: be-3
Added as a Developer, with permissions to Create, Read, and Update 
tickets at SourceForge.


Welcome!

Trevor


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

Re[2]: OLL-core and Win10 [was Re: edition-editor usage]

[Trevor]

Hi Urs

As I was the first to report this I apologise for not responding sooner 
- I had other commitments these last two days.  However, I have made a 
quick test this morning using example-1.ly in the Usage Examples of 
Edition Engraver and I confirm the changes in the "windows" branch fix 
the problem for me, at least as far as that example goes.  I'm on 
Windows 10, using Frescobaldi 3.0.1.  So that's great!  Many thanks.  I 
can now to get to grips with the Edition Engraver properly, maybe later 
today :)


Trevor


-- Original Message --
From: "Urs Liska" <li...@openlilylib.org>
To: "Karlin High" <karlinh...@gmail.com>; lilypond-devel@gnu.org
Sent: 08/01/2018 17:14:59
Subject: Re: OLL-core and Win10 [was Re: edition-editor usage]




Am 08.01.2018 um 18:11 schrieb Karlin High:

Urs, was there supposed to be a "Windows" branch?


Oops, obviously I only pushed the master branch again.
Now the windows branch is on Github, sorry.

Urs

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



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

Re[2]: OLL-core and Win10 [was Re: edition-editor usage]

[Trevor]

Hi Urs



OK, at least now I know where (in the code) the problem is and recall 
that I fixed that once. Just to be sure: are you sure you you use the 
latest state of oll-core? OTOH, from the type of issue it may well be a 
Windows question.


I can't look into it right now (and don't know if I can for the next 
few days).
There's no particular urgency to this - I appreciate your time whenever 
you can spare it.


For debugging could you please locate the file 
oll-core/internal/os-path.ily and insert a ly:message after line 193 so 
that the "this-parent" function looks like this:


% Return the parent of (this-dir)
#(define-public (this-parent)
   (let ((file (this-file)))
 (ly:message "this file: ~a" file)
 (list-head file (- (length file) 2

The problem is in the list-head command. The thing is that "file" seems 
to be a list of length 1 (instead of anything above 2), which leads to 
the value-out-of-range error.


Additionally insert a message in line 184 so "this-file" looks like

% Return the normalized absolute path and file name of "this" file
#(define-public (this-file)
   (ly:message "location: ~a" (*location*))
   (ly:message "initial path: ~a" (car (ly:input-file-line-char-column 
(*location*

   (location->normalized-path (*location*)))

And send me the log output.

Done; here's the log output:

Starting lilypond-windows.exe 2.19.80 [Untitled]...
Processing 
`C:/Users/tdani/AppData/Local/Temp/frescobaldi-u9vnw1qc/tmp4_jxjpvb/document.ly'

Parsing...
location: #C:/Users/tdani/openlilylib/oll-core/package.ily:57:2>

initial path: C:/Users/tdani/openlilylib/oll-core/package.ily
this file: (C:/Users/tdani/openlilylib/oll-core/package.ily)
C:/Users/tdani/openlilylib/oll-core/package.ily:57:2: error: GUILE 
signaled an error for the expression beginning here

#
 (if (not (defined? 'openlilylib-root))

Value out of range 0 to 4294967295: -1
fatal error: failed files: 
"C:\\Users\\tdani\\AppData\\Local\\Temp\\frescobaldi-u9vnw1qc\\tmp4_jxjpvb\\document.ly"

Exited with return code 1.


Trevor


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

Re[4]: OLL-core and Win10 [was Re: edition-editor usage]

[Trevor]

Hi Urs

OK, but I'm not at home right now, so it is somewhat hard to digest. 
Could you please send the log for a document that contains only

 \include "oll-core/package.ily"
?


Sure; it's quite bit shorter, so here it is inline:

Starting lilypond-windows.exe 2.19.80 [Untitled]...
Processing 
`C:/Users/tdani/AppData/Local/Temp/frescobaldi-u9vnw1qc/tmp4_jxjpvb/document.ly'

Parsing...
C:/Users/tdani/openlilylib/oll-core/package.ily:57:2: error: GUILE 
signaled an error for the expression beginning here

#
 (if (not (defined? 'openlilylib-root))

Value out of range 0 to 4294967295: -1
fatal error: failed files: 
"C:\\Users\\tdani\\AppData\\Local\\Temp\\frescobaldi-u9vnw1qc\\tmp4_jxjpvb\\document.ly"

Exited with return code 1.

Trevor






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

Re[2]: OLL-core and Win10 [was Re: edition-editor usage]

[Trevor]

Hi Urs


Could you please post the *full* log and the input file?
Then I can look into it. I recall having seen this error before but not 
what it was about.
Thanks for looking!  Source and log attached.  The source is 
example-1.ly from edition-engraver/usage-examples.


Trevor

Starting lilypond-windows.exe 2.19.80 [example-1.ly]...
Processing 
`C:/Users/tdani/AppData/Local/Temp/frescobaldi-u9vnw1qc/tmpuqjcysah/example-1.ly'
Parsing...
C:/Users/tdani/openlilylib/oll-core/package.ily:57:2: error: GUILE signaled an 
error for the expression beginning here
#
 (if (not (defined? 'openlilylib-root))

C:/Users/tdani/AppData/Local/Temp/frescobaldi-u9vnw1qc/tmpuqjcysah/example-1.ly:35:1:
 error: unknown escaped string: `\loadPackage'

\loadPackage edition-engraver

C:/Users/tdani/AppData/Local/Temp/frescobaldi-u9vnw1qc/tmpuqjcysah/example-1.ly:35:14:
 error: syntax error, unexpected SYMBOL, expecting '.' or '=' or ','
\loadPackage 
 edition-engraver

C:/Users/tdani/AppData/Local/Temp/frescobaldi-u9vnw1qc/tmpuqjcysah/example-1.ly:37:1:
 error: unknown escaped string: `\addEdition'

\addEdition test

C:/Users/tdani/AppData/Local/Temp/frescobaldi-u9vnw1qc/tmpuqjcysah/example-1.ly:39:1:
 error: unknown escaped string: `\editionMod'

\editionMod test 2 0/4 sing.with.bach.along.Voice.B \once \override 
NoteHead.color = #red

C:/Users/tdani/AppData/Local/Temp/frescobaldi-u9vnw1qc/tmpuqjcysah/example-1.ly:39:53:
 error: syntax error, unexpected MUSIC_FUNCTION, expecting '='
\editionMod test 2 0/4 sing.with.bach.along.Voice.B 
\once \override 
NoteHead.color = #red

C:/Users/tdani/AppData/Local/Temp/frescobaldi-u9vnw1qc/tmpuqjcysah/example-1.ly:41:1:
 error: unknown escaped string: `\editionMod'

\editionMod test 2 2/4 sing.with.bach.along.Voice.B \override NoteHead.color = 
#green

C:/Users/tdani/AppData/Local/Temp/frescobaldi-u9vnw1qc/tmpuqjcysah/example-1.ly:41:13:
 error: syntax error, unexpected SYMBOL, expecting '.' or '=' or ','
\editionMod 
test 2 2/4 sing.with.bach.along.Voice.B \override NoteHead.color = 
#green

C:/Users/tdani/AppData/Local/Temp/frescobaldi-u9vnw1qc/tmpuqjcysah/example-1.ly:41:53:
 error: syntax error, unexpected \override, expecting '='
\editionMod test 2 2/4 sing.with.bach.along.Voice.B 
\override NoteHead.color = 
#green

C:/Users/tdani/AppData/Local/Temp/frescobaldi-u9vnw1qc/tmpuqjcysah/example-1.ly:42:1:
 error: unknown escaped string: `\editionMod'

\editionMod test 2 3/4 sing.with.bach.along.Voice.B \override NoteHead.color = 
#blue

C:/Users/tdani/AppData/Local/Temp/frescobaldi-u9vnw1qc/tmpuqjcysah/example-1.ly:42:13:
 error: syntax error, unexpected SYMBOL, expecting '.' or '=' or ','
\editionMod 
test 2 3/4 sing.with.bach.along.Voice.B \override NoteHead.color = 
#blue

C:/Users/tdani/AppData/Local/Temp/frescobaldi-u9vnw1qc/tmpuqjcysah/example-1.ly:42:53:
 error: syntax error, unexpected \override, expecting '='
\editionMod test 2 3/4 sing.with.bach.along.Voice.B 
\override NoteHead.color = 
#blue

C:/Users/tdani/AppData/Local/Temp/frescobaldi-u9vnw1qc/tmpuqjcysah/example-1.ly:43:1:
 error: unknown escaped string: `\editionMod'

\editionMod test 3 1/4 sing.with.bach.along.Voice.B \revert NoteHead.color

C:/Users/tdani/AppData/Local/Temp/frescobaldi-u9vnw1qc/tmpuqjcysah/example-1.ly:43:13:
 error: syntax error, unexpected SYMBOL, expecting '.' or '=' or ','
\editionMod 
test 3 1/4 sing.with.bach.along.Voice.B \revert NoteHead.color

C:/Users/tdani/AppData/Local/Temp/frescobaldi-u9vnw1qc/tmpuqjcysah/example-1.ly:43:53:
 error: syntax error, unexpected \revert, expecting '='
\editionMod test 3 1/4 sing.with.bach.along.Voice.B 
\revert NoteHead.color

C:/Users/tdani/AppData/Local/Temp/frescobaldi-u9vnw1qc/tmpuqjcysah/example-1.ly:45:1:
 error: unknown escaped string: `\editionMod'

\editionMod test 5 0/4 sing.with.bach.along.Voice.#(string->symbol "1") \revert 
NoteHead.color

C:/Users/tdani/AppData/Local/Temp/frescobaldi-u9vnw1qc/tmpuqjcysah/example-1.ly:45:1:
 error: syntax error, unexpected STRING, expecting '='

\editionMod test 5 0/4 sing.with.bach.along.Voice.#(string->symbol "1") \revert 
NoteHead.color

C:/Users/tdani/AppData/Local/Temp/frescobaldi-u9vnw1qc/tmpuqjcysah/example-1.ly:45:73:
 error: syntax error, unexpected \revert, expecting '='
\editionMod test 5 0/4 sing.with.bach.along.Voice.#(string->symbol "1") 
\revert 
NoteHead.color

C:/Users/tdani/AppData/Local/Temp/frescobaldi-u9vnw1qc/tmpuqjcysah/example-1.ly:47:1:
 error: unknown escaped string: `\editionMod'

\editionMod test 13 3/8 sing.with.bach.along.Voice.C \once \override 
NoteHead.color = #red

C:/Users/tdani/AppData/Local/Temp/frescobaldi-u9vnw1q

Re[2]: edition-editor usage

[Trevor]

Hi EE-Users

I thought I'd try to bring the edition engraver into use over the 
holiday period, so I cloned edition-engraver and oll-core from git-hub 
into a local repository, placed that in Frescobaldi's include path and 
tried to compile the first example in edition-engraver.  It fails with 
the message:


C:/Users/tdani/openlilylib/oll-core/package.ily:57:2 <0>: error: GUILE 
signaled an error for the expression beginning here

#

(if (not (defined? 'openlilylib-root))



C:/Users/tdani/AppData/Local/Temp/frescobaldi-u9vnw1qc/tmpuqjcysah/example-1.ly:35:1 
<1>: error: unknown escaped string: `\loadPackage'




\loadPackage edition-engraver

Before I spend time investigating this further, I'm wondering if the 
edition-engraver is known to work within Frescobaldi on Windows 10 with 
LilyPond 2.19.80.  Are there any such users?


Alternatively, any ideas what I might be doing wrong?

Trevor


-- Original Message --
From: "Jan-Peter Voigt" <jp.vo...@gmx.de>
To: lilypond-u...@gnu.org; "Mason Hock" <masonh...@gmail.com>
Sent: 24/12/2017 10:19:48
Subject: Re: edition-editor usage


Hello Mason,

it is possible to use \shapeII with the edition-engraver :-)
And it sounds like this is the use case the EE is originally meant for.

Yes, the wording is a bit inconsistent and/or irritating. I will try to 
sum it up:
In the recent versions I used the terms target and context to divide 
two dimensions. The target names the requested output like for example 
'fullscore' or 'violinI-part'. If you "activate" an edition-target with 
\addEdition violinI-part it uses all modifications that look like
\editionMod violinI-part{ 
\shapeII ... }


This is a real example I used inside the piano reduction:
\editionMod klavier 38 0/8 chor.ten.TenorStaff \once \shapeII #'(()(0 . 
1)()()) Slur

It means:
with edition-target 'klavier' (the piano reduction) in measure 38 the 
first eighth apply the shapeII-command inside the context identified by 
'chor.ten.TenorStaff'.
Moments are counted zero-based, so the first moment is zero. This might 
irritating on first sight, but it is meaningful as the distance from 
the beginning of the measure. The context in the example above is the 
tenor staff inside the choir-staff.


I think the main point is understanding the three dimensions:
1. the edition-target - that is the condition if to apply the 
modification ... apply this modification for the score of type T(arget)
2. the edition-context - that is where to apply the modification ... 
the LilyPond context like Voice, Staff, Score etc.
3. the time - that is the musical timestamp when to apply the 
modification ... moment X inside measure Y


HTH

I will send more details and information soon!
But for today and tomorrow I wish you a merry Christmas and all the 
best for 2018!


Jan-Peter


Am 23. Dezember 2017 20:09:29 MEZ schrieb Mason Hock 
<masonh...@gmail.com> <mailto:masonh...@gmail.com>:

I have a piece in which each performer reads from a version of the score
with their staff full-sized with the other parts on small staves. This
pieces also requires a lot of manual tweaking of slurs.

I've been using \shapeII for the slurs, which works great, except that
if I shape the slur correctly for the full-sized version of the part it
is shaped incorrectly for the small version of the part and vice versa.
In order for the slurs to look good in both situations I need two sets
of \shapeII tweaks.

edition-editor looks like a promising solution, but I'm having trouble
learning how to use it. The only documentation I can find is the usage
examples here.

https://github.com/openlilylib/edition-engraver/tree/master/usage-examples

Each example is very specific, which makes it difficult to decode how
edition-engraver works in general. I guess my questions are

(1) Will edition-engraver work for tweaking slurs with \shapeII?

(2) If so, what should be my approach in terms of organization? My guess
would be to have 8 editions, a full-size version and small version for
each of the 4 staves, where each pdf uses 1 full-size edition and 3
small editions.

(3) How do I make certain 'editions' (at this point I'm questioning
whether I'm using that term correctly) apply to certain staves in each pdf?

(4) What is the basic syntax for using edition-editor? It's difficult to
tell from the examples in the repo what is the basic syntax and what is
extending it.

Thanks to anyone who can clarify.

Mason





lilypond-user mailing list
lilypond-user@gnu.orghttps://lists.gnu.org/mailman/listinfo/lilypond-user

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

Re[2]: New Status "Shelved" in LilyPond Bug Tracker

[Trevor]

James Lowe wrote 13/12/2017 12:14:59


On Mon, 11 Dec 2017 16:50:01 +, Trevor <t.dani...@treda.co.uk> 
wrote:



Devs and Bug Trackers

I have implemented a new Status field in the Issues Tracker at
SourceForge: Status:Shelved, with the meaning:

"Probably desirable, but impractical to implement at present due to 
lack

of resources".

There is also a new Search: Open (Shelved) to list them.

ATM only one Issue has this Status,
https://sourceforge.net/p/testlilyissues/issues/5244/ but there are 
lots
of other existing issues that could be assigned to it, when someone 
has

a few spare moments to go through the Issues to find them.


Without getting into unnecessary semantics with dictionary definitions 
etc. how does this 'status' differ, so to speak, from an issue that is 
simply marked as an 'enhancement' and has the 'Status' field either 
blank or set to 'accepted'.
You raise a valid point and maybe there is no clear distinction; but 
there could be one of degree.


An Issue marked Accepted/Enhancement sounds to me very positive, 
suggesting that there might be hope this could be implemented relatively 
quickly: implying it has been assessed ("Accepted") and considered to be 
a practical and desirable enhancement.


Whereas giving an Issue the status of Shelved makes it plain there are 
absolutely no plans to implement this in the foreseeable future: it has 
not yet been assessed and is not yet Accepted; it is just a marker 
meaning it might be considered at some unspecified time in the future.


Does that accord with your understanding, David?



After all, I suspect that 'many' enhancements (if not all) on our 
tracker list could be classed as "... impractical to implement at 
present due to lack of resources"


Yes; as I suggested earlier (above): there may be many Issues that could 
be so reclassified.


Trevor

ps Apologies if the nesting of original email and my replies is not 
right - I'm struggling with a new mail client ATM and I noticed an 
earlier reply of mine was not nested correctly.



---
This email has been checked for viruses by AVG.
http://www.avg.com


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

New Status "Shelved" in LilyPond Bug Tracker

[Trevor]

Devs and Bug Trackers

I have implemented a new Status field in the Issues Tracker at 
SourceForge: Status:Shelved, with the meaning:


"Probably desirable, but impractical to implement at present due to lack 
of resources".


There is also a new Search: Open (Shelved) to list them.

ATM only one Issue has this Status, 
https://sourceforge.net/p/testlilyissues/issues/5244/ but there are lots 
of other existing issues that could be assigned to it, when someone has 
a few spare moments to go through the Issues to find them.


Trevor



---
This email has been checked for viruses by AVG.
http://www.avg.com


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

Re: [testlilyissues:issues] Ticket 3960 discussion

[Trevor Daniels]

James wrote: Wednesday, October 18, 2017 11:54 AM

>- **status**: Started --> Invalid
> - **Patch**: needs_work -->  
> - **Comment**:
> 
> Revisiting this, the example given at the start of this issue
> 
> http://lilypond.org/doc/v2.18/Documentation/notation/explicit-breaks
> 
> has no corresponding entry at all in the 2.19 documentation. In fact the 
> entire NR 4.x section is completely different.
> 
> The example in the 2.18 is for overriding when LilyPond doesn't honour a 
> manual `\break` or `\pagebreak` command by using 
> `NonMusicalPaperColumn.line-break-permission` overrides. The 2.19 doc doesn't 
> mention any example or even snippet. It does have one mention about 
> `line-break-permission` but only in the context of what the setting does and 
> what its defaults are.

This section was changed significantly in Oct 2014when the various 
\auto..breaks.. commands were installed.  See

https://sourceforge.net/p/testlilyissues/issues/4169/
 
> So I wonder now if this tracker is still needed.

so marking this invalid is correct.
 
Trevor


---
This email has been checked for viruses by AVG.
http://www.avg.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Introduction + how/what to contribute?

[Trevor Daniels]

"Koen Samyn" wrote Thursday, September 28, 2017 9:02 AM

Hi and Welcome!

> I am trying to get started with the lilypond source code and see where I
> can contribute, but the documentation links seem out of order, for example
> the following link:
> 
> /doc/v2.21/Documentation/contributor/summary-for-experienced-developers.htm

2.21 has not yet been released.  Try this one:

http://lilypond.org/doc/v2.19/Documentation/contributor/summary-for-experienced-developers
 
> Any pointers you can give me where extra programming help might be required?

You could browse the Issues DB:

https://sourceforge.net/p/testlilyissues/issues/
 
Trevor


---
This email has been checked for viruses by AVG.
http://www.avg.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: How to locate all layout-property values for a particularLayoutObject in the source files?

[Trevor Daniels]

Simon Albrecht wrote Sunday, September 24, 2017 4:34 PM


> On 24.09.2017 14:30, James wrote:
>> Where would I go to see the 'complete list' of all possible NoteHead.style 
>> values
> 
> <http://lilypond.org/doc/v2.19/Documentation/internals/note_002dhead_002dinterface>
>  
> – the description of the style property isn’t helpful (since it 
> summarises the use of that property in any grob), but at the top of the 
> page there is a link to all the styles.
> 

This links to Appendix A.9 which seems to be incomplete.
For example, it doesn't contain semipetrucci or blackpetrucci,
which differ from petrucci in the longer note values.  Kievan is
missing too.

So part of James' work might be to extend this table too.

Trevor


---
This email has been checked for viruses by AVG.
http://www.avg.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: PATCHES - Countdown for September 10th

[Trevor Daniels]

James wrote Tuesday, September 12, 2017 9:05 AM


> On Mon, 11 Sep 2017 23:24:31 +0200
> Thomas Morley <thomasmorle...@gmail.com> wrote:
> 
>> for about a month I'm often surprised about new issues/patches etc.
>> I _am_ subscribed to the lilypond-auto mailing-list which should
>> notify me about stuff from the tracker.
>> 
>> Did I miss a recent change?
>> 
>> Thanks,
>>   Harm
>> 
> 
> If you look here:
> 
> http://lists.gnu.org/archive/html/lilypond-auto/
> 
> It seems that the emails stopped 2nd August.
> 
> I wonder if there is some 'spam' setting that has been triggered on the 
> lilypond-auto list?

I'm pleased to say the lilypond-auto mailing list is operational again, thanks 
to excellent help from the SourceForge team.

The problem stemmed from a privacy change around 2 Aug 2017 which required all 
members of the parent list at SourceForge to resubscribe.  This requirement was 
communicated to all members of all SourceForge lists, but for some reason this 
either was not propagated to our lilypond-auto list at gnu.org or we all missed 
it.  As a result mailings from the SF list to the gnu list stopped.

Getting them working again was tricky.  If you're interested you can see the 
story here:
https://sourceforge.net/p/forge/site-support/15567/

You can, of course, subscribe to the SF list directly, cutting out the (now 
dubious) hop via gnu.org, here:
https://sourceforge.net/p/testlilyissues/mailman/

Trevor


---
This email has been checked for viruses by AVG.
http://www.avg.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Issue 5187 Add command for Thin Aiken noteheads (issue 326510043by karlinh...@gmail.com)

[Trevor Daniels]

Karlin High Wednesday, September 20, 2017 6:46 PM

> On Wed, Sep 20, 2017 at 12:37 PM,  <karlinh...@gmail.com> wrote:
>> This is my first effort at making a patch, so I could be doing things wrong.
> 
> I gather I am supposed to request write access to the issue tracker on
> Sourceforge? Username: karlinhigh

Thanks.  You should be good to go now.

Trevor


---
This email has been checked for viruses by AVG.
http://www.avg.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: PATCHES - Countdown for September 10th

[Trevor Daniels]

James wrote Tuesday, September 12, 2017 9:05 AM

> If you look here:
> 
> http://lists.gnu.org/archive/html/lilypond-auto/
> 
> It seems that the emails stopped 2nd August.
> 
> I wonder if there is some 'spam' setting that has been triggered on the 
> lilypond-auto list?

I can't see anything wrong, but the list admin can't see who's subscribed (!), 
only that there are two subscriptions.  Not sure if this secrecy is a recent 
change.

I've resubscribed lilypond-a...@gnu.org to the SF testlilyissues-auto mailing 
list to see if this fixes it.

I see I'm the only administrator for this SF list, which doesn't seem healthy.  
Phil, should I add you?

Trevor



---
This email has been checked for viruses by AVG.
http://www.avg.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Propose Commit access for Étienne Beaulé

[Trevor Daniels]

James wrote Thursday, September 07, 2017 4:19 PM

> Étienne has pushed couple of patches now and I wondered if we could
> perhaps give him full commit access to git?

Who now has the authority to do this?  I don't, and I've lost track of who does
now that Han-Wen, Jan and Graham are rarely seen on the lists.

Trevor


---
This email has been checked for viruses by AVG.
http://www.avg.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Issues write access

[Trevor Daniels]

Étienne Beaulé wrote Thursday, August 10, 2017 2:51 AM


> Hello. May I be granted write access on our issue tracker? My username is
> ebe123. Thank you!

Added.  Welcome!

Trevor


---
This email has been checked for viruses by AVG.
http://www.avg.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Any objections to branching off a stable branch for 2.20?

[Trevor Daniels]

Phil Holmes wrote Tuesday, July 18, 2017 11:07 AM

> Subject: Any objections to branching off a stable branch for 2.20?

> No objections from me towards aiming for a 2.20 stable release.

None from me either.

Trevor


---
This email has been checked for viruses by AVG.
http://www.avg.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: I'm to teach LilyPond officially again

[Trevor]

As the maintainer of LilyBin, I'll be interested in knowing if you
encounter any issues, especially with reliability of the service! Last
year, I and another developer did some work to get LilyBin running on AWS
Lambda especially to handle the load of classroom situations where many
people use are compiling concurrently. Let me know how it goes!

On Sun, Jun 18, 2017 at 6:05 PM Francisco Vila 
wrote:

> Hello all,
>
> Some time ago I was teaching LilyPond in a Conservatoire, then stopped
> doing so, now I'm doing it again! The course is October to June and it's
> optional and open to all four levels of High Music Education.
>
> I'm delighted because I was already missing giving lectures to groups. I
> plan to keep all as practice-oriented as possible with a minimum of
> theoretical issues beyond what's strictly necessary to understand some
> issues.
>
> I have plenty of teaching material, including my 30 weekly lessons plus
> lesson zero.
>
> "Lesson Zero" is {}{}~~~  in a Spanish keyboard, I think
> once achieved that, all else is easy :-)
>
> I'll use Frescobaldi, lilybin, OLy for OOo, and more. Students will also
> learn to enter LP music in wikipedia.
>
> Any suggestions are welcome.
>
> Regards,
>
> --
> Francisco Vila. Badajoz (Spain)
> paconet.org , csmbadajoz.com
>
>
> ___
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-devel
>
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Releasing 2.20

[Trevor Daniels]

David Kastrup wrote Wednesday, June 07, 2017 9:34 PM

> tomorrow I am leaving for physical therapy.

Hope it all goes well for you.

> So I should be able to do some reasonably straightforward work.

Good, but that should not be your priority ATM.
 
> So how is it going to end up?  Barring objections, I'll probably branch
> off a stable release branch early next week.  I'll have to see what to
> cherry-pick into this branch as fixes proceed, and possibly what to
> revert when it is not clear that functionality provided by recent
> patches/changes can be considered stable in use and interface.

Again, good, but ...
 
> I don't think that we should need much more than the 3-week maturing
> period corresponding to the expected physical therapy duration.

Agreed, there seem to be very few reasons to delay.  Presumably it will
be a .0 release anyway, meaning "use cautiously and look out for bugs."
 
> The alternative of releasing 2.18.3 since 2.18.2 does not even compile
> using gcc-7 anymore is something I want to avoid.

Definitely.  There are so many improvements since 2.18 that a major
release is the sensible choice.

> So I'd rather pitch for a timely release of 2.20.  There have been a few
> critical bugs flagged, however.  I'll take a look at them eventually but
> if someone else has a good idea...

We might need to revisit these to see if they really are critical.

Trevor


---
This email has been checked for viruses by AVG.
http://www.avg.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Back in the Pond

[Trevor Daniels]

Hi David

Thanks for the update.

You wrote Monday, May 29, 2017 9:56 PM

> Gianmaria Lari <gianmarial...@gmail.com> writes:
>>
>> what's the better way to give a financial contribution?
> 
> In Europe's EURO zone (guessing from your name, that would likely be the
> case) SEPA transfers are usually easiest (account number on request) as
> the fees must not exceed in-country EUR transfers.  U.S. and U.K. and a
> number of other countries get fewer fees via Paypal (this mail address
> works fine).

I recently made my usual (small) monthly contribution.  Hope it helps
a little.

> But even with some distractions being off-limits now, at the rate I am
> being able to focus on complex tasks, I expect to be able to only
> contribute lightly to LilyPond's progress in the next month or so.  Not
> a whole lot of bang for the buck I am afraid.

No problem.  It is more important ATM to concentrate on regaining
as much control over your body as possible.
 
> At least apart from the head/neck ache and from the necessity for
> physical exercise and keeping my blood pressure at tiresome levels, my
> intelligence has not taken a hit: it's really mostly damaged wiring to
> various body parts that I have to work with here.  But of course I need
> to get the body back into a shape where I get along with moderate effort
> in order not to take further hits to my bodily health.

It's excellent news that your intelligence is still intact.

> In a nutshell: I'd appreciate support but it will be a bit of time
> before I deliver good value for it again.

We can wait.  We're all rooting for your full recovery!

Trevor


---
This email has been checked for viruses by AVG.
http://www.avg.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Merge Rests Engraver

[Trevor Daniels]

Jay Anderson wrote Wednesday, May 17, 2017 7:31 AM

> Thanks. When I ran `git cl upload origin/master` it wasn't able to associate 
> the patch with an issue:

> We were not able to associate this patch with a tracker issue.
> Please enter a valid tracker issue number
> (or enter nothing to create a new issue): 1228
> Problem setting patch status for Allura issue

Did you register git-cl in your account at SourceForge and obtain a bearer 
token?
See "Authorizing git-cl for the LilyPond issue tracker" as the next step in 
configuring git-cl 
in http://lilypond.org/doc/v2.19/Documentation/contributor/git_002dcl

If this is not the problem we'll need Phil to take a look.

Trevor


---
This email has been checked for viruses by AVG.
http://www.avg.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Calling in for sickness

[Trevor Daniels]

David, you wrote Monday, May 15, 2017 5:42 PM

> had a sort of apoplexy and will not be able to do anything while
> recovering.  I am hospitalized at the moment, CRT and MRT did not show
> any specific anomalies but my right side is hampered and I cannot yet
> swallow or cough which is sort of inconvenient.

Please take things easy for a while and make sure you are fully better
before starting work on LP again.  Your health is more important!

But do keep us informed about your progress back to health.

With my best wishes for a speedy recovery,

Trevor


---
This email has been checked for viruses by AVG.
http://www.avg.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Merge Rests Engraver

[Trevor Daniels]

Hi Jay, you wrote Sunday, May 14, 2017 5:15 AM

> When running git-cl it failed to create a new ticket number to track the
> issue (the instructions say I need to request access:
> http://lilypond.org/doc/v2.19/Documentation/contributor/git_002dcl#configuring-git_002dcl).
> There is an existing issue (
> https://sourceforge.net/p/testlilyissues/issues/1228/). Let me know what
> more I need to do there. Thanks.

You need to create an account at SourceForge
https://sourceforge.net/user/registration
if you don't already have one, and post your username 
to this list.  We'll then register you as a developer
on the Lily Issues DB, which will permit you to modify
existing and create new Issues.

Trevor


---
This email has been checked for viruses by AVG.
http://www.avg.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: 2.19.59: Bad horizontal spacing when \override LyricText #'X-offset

[Trevor Daniels]

Dmytro O. Redchuk wrote Friday, April 28, 2017 9:10 AM

> please take a look at this MWE:
>
% --- 8< 
\version "2.19.59"

{ r4 a a2 a4 a2 }
\addlyrics {
  \override LyricText #'X-offset = #0
  "Блаженні голодні й спрагнені правди, бо вони на" -- си -- тять -- ся.
}
% --- 8< 
>
> I've attached images for 2.18.2, 2.19.59 and 2.19.59 with no \override.
>
> If I missed something and that spacing should be treated in some
> special way for such rather extreme cases in 2.19?
>
> Or is there any issue/regression?

This seems to be a bug so copying to the bug list.  I don't think this has
been reported before.

The output is correct in 2.18.2 and up to 2.19.9, but wrong from 2.19.10.

The changes in 2.19.10 include Janek's:

   Issue 2462  ab6842155a003ba7d9243507594e3e973ebbb3e4

which directly affects lyrics, but there are several other commits which 
affect horizontal alignment generally.

Trevor


---
This email has been checked for viruses by AVG.
http://www.avg.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Add a \voicify command (issue 320820043 by d...@gnu.org)

[Trevor Daniels]

David Kastrup wrote Sunday, April 09, 2017 5:14 PM
> 
> Harm brought a few points, one concerning different warning/error
> behavior (and with regard to the _text_ of the existing warning, I will
> cede the point thought there isn't yet a proposal for \voices as far as
> I can see).  He also pointed out that this calls for changing more of
> the preexisting documentation.  Again, I'll cede that this would make
> sense but I consider it separate work where I'd be glad that someone
> else would tackle it.

I'm sure someone will pick this up.
 
> So how to proceed?  Formally this patch went through countdown, but for
> one thing I stated that I was going to do a rename anyway, and for
> another, there were several points raised.  I'm just very ambiguous on
> addressing them.  For most of the bike-shedding I lean towards just
> canning it for now since I prefer the current proposal.  For some
> improvement suggestions I'd appreciate more concrete proposals fitting
> with \voices.
> 
> I think I'll upload the current, renamed patch and then wait to see what
> other feedback I feel I can sensibly incorporate.

Sounds good to me.

Trevor


---
This email has been checked for viruses by AVG.
http://www.avg.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Add a \voicify command (issue 320820043 by d...@gnu.org)

[Trevor Daniels]

David Kastrup wrote Friday, April 07, 2017 9:07 PM


> "Trevor Daniels" <t.dani...@treda.co.uk> writes:
> 
>> David, you wrote Thursday, April 06, 2017 4:54 PM
>>
>>> You could try separate commands \voicifyUp and \voicifyDown .  I am not
>>> sure whether or not \voicify should not be \voices or \voicing or
>>> \voicings instead, possibly making for nicer compounds like that.
>>> 
>>> I mean, something like
>>> 
>>> \voices 1,3,4 ...
>>
>> Although you later argued cogently against compounds like \voicesUp I
>> think \voices is a better choice than \voicify anyway, simply because
>> it expresses its operation more clearly (not sure what meaning the word
>> "voicify" would trigger in the mind - in Google it enables voice dictation;
>> in Twitter it applies a filter, for example).  
>>
>> In other words \voices stands better than \voicify on its own merits.
> 
> I'll not stop the countdown for now but am going to commit with this
> change unless we get a conflicting view in which case it would make
> sense to stop the countdown and gather more opinions, possibly from the
> user list.

OK.  Happy to wait to see what others think, or, if there's no further
input, to defer to your preference.
 
> Not sure what to name input/regression/voicify.ly instead, though.
> "voicify.ly" is clearly referring to the command, "voices.ly" is much
> more ambiguous.  But at least it is not taken yet.

Well, lots of the regression tests have compound names.
"reordering-voices-in-parallel-construct.ly or something
similarly descriptive would be fine.

Trevor


---
This email has been checked for viruses by AVG.
http://www.avg.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Add a \voicify command (issue 320820043 by d...@gnu.org)

[Trevor Daniels]

David, you wrote Thursday, April 06, 2017 4:54 PM

> You could try separate commands \voicifyUp and \voicifyDown .  I am not
> sure whether or not \voicify should not be \voices or \voicing or
> \voicings instead, possibly making for nicer compounds like that.
> 
> I mean, something like
> 
> \voices 1,3,4 ...

Although you later argued cogently against compounds like \voicesUp I
think \voices is a better choice than \voicify anyway, simply because
it expresses its operation more clearly (not sure what meaning the word
"voicify" would trigger in the mind - in Google it enables voice dictation;
in Twitter it applies a filter, for example).  

In other words \voices stands better than \voicify on its own merits.

Trevor


---
This email has been checked for viruses by AVG.
http://www.avg.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Degenerate file access patterns

[Trevor]

Downloaded binary.

On Thu, Mar 23, 2017 at 2:38 PM Han-Wen Nienhuys <hanw...@gmail.com> wrote:

> Trevor, did you compile it from scratch or are you using the packaged
> binary?
>
>
> On Thu, Mar 23, 2017 at 11:42 AM, Trevor <trevordi...@gmail.com> wrote:
> > I don't know enough to be very helpful, but I can report that on Ubuntu,
> I
> > also see  "9925953   90234" from strace.
> >
> > On Tue, Mar 21, 2017 at 10:33 AM Han-Wen Nienhuys <hanw...@gmail.com>
> wrote:
> >>
> >> the repeating syscall is the read, on the same file descriptor. If
> >> fontconfig failed a cache, you'd more likely see
> >>
> >>  open() = 6
> >>  read(6, .. )
> >>  close(6)
> >>  open() = 6
> >>  read(6, .. )
> >>  close(6)
> >>
> >> I think.
> >>
> >> I'll have a look again tonight. Maybe I can attach a debugger (my
> >> machine has long lost the ability to compile lilypond. Sigh.)
> >>
> >> On Tue, Mar 21, 2017 at 5:00 AM, Werner LEMBERG <w...@gnu.org> wrote:
> >> >
> >> >>> "The culprit is that the lilypond binary has a bit sub-optimal file
> >> >>> access pattern (opening the same file thousands of times and
> >> >>> reading it byte by byte, causing a syscall flood - nearly 500K
> >> >>> lseek and read operations).  On a local machine, because of this
> >> >>> issue, it will spend about 1s in I/O syscalls, which is half of the
> >> >>> total execution time. This currently does not play nice with our
> >> >>> systems, getting it from 1s to over half a minute."
> >> >
> >> > Interesting, I don't get this behaviour on my openSuSE GNU/Linux box.
> >> >
> >> >> The font support is reading the same section of some font file over
> >> >> and over again.
> >> >>
> >> >> $ cat f.ly
> >> >> { c }
> >> >> $ strace -e trace=open,read lilypond f.ly  >& log ; grep OTTO log|wc
> >> >> 9925953   90234
> >> >
> >> > On my box this is
> >> >
> >> >   1   6  88
> >> >
> >> >> $ grep OTTO log|head -10
> >> >> read(6, "OTTO\0\r\0\200\0\3\0PCFF
> >> >> \364\24\241\262\0\0\t\334\0\0\373PFFTM"..., 4096) = 4096
> >> >> read(6, "OTTO\0\r\0\200\0\3\0PCFF
> >> >> \364\24\241\262\0\0\t\334\0\0\373PFFTM"..., 4096) = 4096
> >> >> read(6, "OTTO\0\r\0\200\0\3\0PCFF
> >> >> \364\24\241\262\0\0\t\334\0\0\373PFFTM"..., 4096) = 4096
> >> >>
> >> >> the number of calls is apparently proportional to the number of
> glyphs
> >> >> in the file:
> >> >>
> >> >> $ cat f.ly
> >> >> \repeat unfold 100 { c }
> >> >>
> >> >> $ strace -e trace=open,read lilypond f.ly  >& log ; grep OTTO log|wc
> >> >> 40929  245575 3724501
> >> >
> >> > For me, it is again
> >> >
> >> >   1   6  88
> >> >
> >> >> Werner may have better hunches than I which code is really
> >> >> responsible for this.
> >> >
> >> > Maybe a problem with fontconfig?  Where is the location of
> >> > fontconfig's database of available fonts on your system?  This must be
> >> > created in advance so that lilypond can access it.  If it is missing,
> >> > fontconfig tries to build it (which makes e.g. the first invocation of
> >> > lilypond very slow on a Windows box since there is no global
> >> > fontconfig database).
> >> >
> >> > Is it possible that fontconfig always fails so that it tries again and
> >> > again?
> >> >
> >> >
> >> > Werner
> >>
> >>
> >>
> >> --
> >> Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
>
>
>
> --
> Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
>
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Degenerate file access patterns

[Trevor]

I don't know enough to be very helpful, but I can report that on Ubuntu, I
also see  "9925953   90234" from strace.

On Tue, Mar 21, 2017 at 10:33 AM Han-Wen Nienhuys  wrote:

> the repeating syscall is the read, on the same file descriptor. If
> fontconfig failed a cache, you'd more likely see
>
>  open() = 6
>  read(6, .. )
>  close(6)
>  open() = 6
>  read(6, .. )
>  close(6)
>
> I think.
>
> I'll have a look again tonight. Maybe I can attach a debugger (my
> machine has long lost the ability to compile lilypond. Sigh.)
>
> On Tue, Mar 21, 2017 at 5:00 AM, Werner LEMBERG  wrote:
> >
> >>> "The culprit is that the lilypond binary has a bit sub-optimal file
> >>> access pattern (opening the same file thousands of times and
> >>> reading it byte by byte, causing a syscall flood - nearly 500K
> >>> lseek and read operations).  On a local machine, because of this
> >>> issue, it will spend about 1s in I/O syscalls, which is half of the
> >>> total execution time. This currently does not play nice with our
> >>> systems, getting it from 1s to over half a minute."
> >
> > Interesting, I don't get this behaviour on my openSuSE GNU/Linux box.
> >
> >> The font support is reading the same section of some font file over
> >> and over again.
> >>
> >> $ cat f.ly
> >> { c }
> >> $ strace -e trace=open,read lilypond f.ly  >& log ; grep OTTO log|wc
> >> 9925953   90234
> >
> > On my box this is
> >
> >   1   6  88
> >
> >> $ grep OTTO log|head -10
> >> read(6, "OTTO\0\r\0\200\0\3\0PCFF
> >> \364\24\241\262\0\0\t\334\0\0\373PFFTM"..., 4096) = 4096
> >> read(6, "OTTO\0\r\0\200\0\3\0PCFF
> >> \364\24\241\262\0\0\t\334\0\0\373PFFTM"..., 4096) = 4096
> >> read(6, "OTTO\0\r\0\200\0\3\0PCFF
> >> \364\24\241\262\0\0\t\334\0\0\373PFFTM"..., 4096) = 4096
> >>
> >> the number of calls is apparently proportional to the number of glyphs
> >> in the file:
> >>
> >> $ cat f.ly
> >> \repeat unfold 100 { c }
> >>
> >> $ strace -e trace=open,read lilypond f.ly  >& log ; grep OTTO log|wc
> >> 40929  245575 3724501
> >
> > For me, it is again
> >
> >   1   6  88
> >
> >> Werner may have better hunches than I which code is really
> >> responsible for this.
> >
> > Maybe a problem with fontconfig?  Where is the location of
> > fontconfig's database of available fonts on your system?  This must be
> > created in advance so that lilypond can access it.  If it is missing,
> > fontconfig tries to build it (which makes e.g. the first invocation of
> > lilypond very slow on a Windows box since there is no global
> > fontconfig database).
> >
> > Is it possible that fontconfig always fails so that it tries again and
> > again?
> >
> >
> > Werner
>
>
>
> --
> Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
>
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Degenerate file access patterns

[Trevor]

I'm trying to run LilyPond in Google Cloud Functions
, and execution is ridiculously slow
(like 40 seconds compilation vs. 2 seconds on my laptop). A Google Cloud
engineer tested it and reported the following:

"The culprit is that the lilypond binary has a bit sub-optimal file access
pattern (opening the same file thousands of times and reading it byte by
byte, causing a syscall flood - nearly 500K lseek and read operations). On
a local machine, because of this issue, it will spend about 1s in I/O
syscalls, which is half of the total execution time. This currently does
not play nice with our systems, getting it from 1s to over half a minute."

Anybody know why this behavior is exhibited? Is this something that might
be within the power of a programmer new to LilyPond development to fix?
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Lily version operators documentation

[Trevor Daniels]

Urs Liska wrote Wednesday, February 15, 2017 8:04 AM

> Am 14.02.2017 um 18:27 schrieb Trevor Daniels:
>
>> As these functions are not intended for the usual LilyPond user I
>> don't think the NR is suitable, other than to have them listed in A22.
>> Similarly, they will also be listed in the IR under Scheme functions.
> 
> Are they listed there really?
> I was of the impression that the ly:something functions defined in
> Scheme are *not* documented anywhere.

You're right.  I was misled by the title of A.22 - "Scheme functions".
Having explored how this is generated it seems these are actually
scheme-callable functions written in C++, if I understand it correctly.

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

Re: Lily version operators documentation

[Trevor Daniels]

Urs Liska wrote Tuesday, February 14, 2017 9:23 AM

> my patch https://sourceforge.net/p/testlilyissues/issues/5067/
> http://codereview.appspot.com/317270043 is currently on countdown. It
> introduces the procedures
> 
> - lilypond>?
> - lilypond>=?
> - lilypond - lilypond<=?
> - lilypond=?
> 
> comparing a given version to the one currently compiling the document.
> This makes it possible to write library code supporting multiple
> LilyPond versions across syntax changes.
> 
> My question is: Where can I add documentation for this? Browsing through
> Extending and IR doesn't seem to indicate a suitable place. It *might*
> be fitting somewhere in the "General input and output" of the NR, but
> I'm way from being sure about that either.

As these functions are not intended for the usual LilyPond user I
don't think the NR is suitable, other than to have them listed in A22.
Similarly, they will also be listed in the IR under Scheme functions.

Perhaps the best place to add a description is in Section 2 of the
Usage Manual where convert-ly is discussed?  A new subsection 
2.2 Testing the version (displacing the existing sections down 1)
could be added.  But I concede mixing with convert-ly is hardly ideal.

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

Re: request for LilyPond issue tracker user account

[Trevor Daniels]

Flaming Hakama by Elaine wrote Wednesday, February 08, 2017 9:12 PM


>I endeavored to start contributing to lilypond development.

Great!

> I've been following the steps in the contributor docs, and on the git-cl
> page instructs me:
> 
> http://lilypond.org/doc/v2.19/Documentation/contributor/git_002dcl
> For the LilyPond issue tracker, please request a user account by sending an
> email to the LilyPond Developer’s mailing list (lilypond-devel@gnu.org),
> preferably using the same email address that you want to use for your user
> login.
> 
> So, I'd like to get a LilyPond issue tracker user account for my email
> ela...@flaminghakama.com

Certainly possible, but that particular instruction is wrong, or at least
incomplete.  What you actually need to do is go to SourceForge:

https://sourceforge.net/p/testlilyissues/issues/

and obtain a user account (unless you already have one) and send me
or post on the Dev list your Username there.  It's the Username I need,
not your email address.

Note: need to correct that para in the CG.

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

Re: Issue 3830: Document \offset command (issue 319150043 bydavid.nales...@gmail.com)

[Trevor Daniels]

david.nales...@gmail.com wrote Tuesday, January 24, 2017 10:57 PM

> Question:
> 
> How do I get a backslash in @subsubsubheading{} ?
> 
> The literal symbol doesn't show up, and @backslashchar{} displays
> @backslashchar{}

>From memory it's @bs{}.

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

Re: Back in the Pond

[Trevor Daniels]

David, you wrote Thursday, January 19, 2017 10:18 AM

> it would appear that my excursion into a regular workplace ended up
somewhat shortlived.

Really sorry to hear that, but it's great to have you back!

> So for the short time range, I am again dependent 
> on support by other LilyPond lovers.

I'll definitely turn on my financial contribution again.

> So what's next on my agenda?  
>
> One somewhat long-standing goal was to remove LilyPond's own
> implementation of a Rational data type and replace it by one based on
> Guile's arbitrary-precision arithmetic.

Worthwhile, but best left for 2.21 I think.
 
> I am glad that I'll be able to provide technical support and expertise
> at least for a while and thus hopefully help Graham pick up the reins of
> the overall project governance a bit better.

Excellent!

> And, of course, this is an opportunity to try putting out the 2.20
> release finally.  

Definitely the top priority, IMO.

> But at any rate, I hope to be on board at least for making LilyPond 2.20
> a thing.

:)

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

Re: How to adjust space between ChordNames and Staff?

[Trevor Daniels]

Thomas Morley wrote Friday, January 13, 2017 9:05 PM


> 2017-01-13 17:05 GMT+01:00 Trevor Daniels <t.dani...@treda.co.uk>:
>>
>> Risto Vääräniemi wrote Friday, January 13, 2017 3:15 PM
>>
>>> On 13 January 2017 at 01:20, Trevor Daniels <t.dani...@treda.co.uk> wrote:
>>>
>>>> Interesting.  Does that mean the ChordNames and Lyrics contexts behave
>>>> differently wrt the vertical spacing controls when these are placed within 
>>>> a
>>>> \with { } block, since Lyrics can be spaced out that way?
>>>>
>>>> If so, is this intended for some reason ... or a bug?
>>>
>>> Thanks Harm. That did the trick. However, I concur with Trevor about the
>>> confusing difference compared to Lyrics. I assumed that they'd work the
>>> same way so I did not occur to me to try the \layout block. If it /is/ an
>>> intended behaviour, there should probably be a note that the settings
>>> won't work with \with { }.
>>
>> Exactly, but I think we need to understand exactly what the problem is before
>> we can decide (a) whether this _is_ a bug and if so (b) whether it is a 
>> coding or
>> a documentation problem.
>>
>> Copying to bug list so this doesn't get forgotten.
>
> No bug.
> It's \chords vs \chordmode.
>
> \chords (as a shortcut) already created a ChordNames-context, see:
>
> chordStuff = \chords { c1 d:m }
> \void \displayLilyMusic \chordStuff
>
> So if you really want to use \chords you need to put overrides, etc
> into \layout or use
> \chords \with { ... }
> at least with newer devel-versions.
>
> If you use \chordmode you can do
> \new ChordNames \with { ... } \chordmode

Excellent explanation!  Many thanks!

So no bug, but we should add a paragraph somewhere in the NR to make this
clear.  I'll start on that in a day or two.

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

Re: How to adjust space between ChordNames and Staff?

[Trevor Daniels]

Risto Vääräniemi wrote Friday, January 13, 2017 3:15 PM

> On 13 January 2017 at 01:20, Trevor Daniels <t.dani...@treda.co.uk> wrote:
>
>> Thomas Morley wrote Thursday, January 12, 2017 10:26 PM
>>
>>> 2017-01-12 21:13 GMT+01:00 Risto Vääräniemi <risva...@gmail.com>:
>>>
>>>> The spacing between ChordNames and Staff seems a bit tight by default. I've
>>>> been trying to adjust it but I haven't figured out the right magic words
>>>
>>> Do it in \layout
>>>
>>> chordStuff = \chords { c1 d:m }
>>> melody = \relative c'' { c4 c c c | d d d d }
>>> \score {
>>>  <<
>>>\new ChordNames  { \chordStuff }
>>>\new Staff { \melody }
>>>  >>
>>>  \layout {
>>>  \context {
>>>\ChordNames
>>>\override VerticalAxisGroup.nonstaff-relatedstaff-spacing.padding = 
>>> #10
>>>  }
>>>  }
>>> }
>>
>> Interesting.  Does that mean the ChordNames and Lyrics contexts behave
>> differently wrt the vertical spacing controls when these are placed within a
>> \with { } block, since Lyrics can be spaced out that way?
>>
>> If so, is this intended for some reason ... or a bug?
>
> Thanks Harm. That did the trick. However, I concur with Trevor about the 
> confusing difference compared to Lyrics. I assumed that they'd work the 
> same way so I did not occur to me to try the \layout block. If it /is/ an 
> intended behaviour, there should probably be a note that the settings 
> won't work with \with { }.

Exactly, but I think we need to understand exactly what the problem is before
we can decide (a) whether this _is_ a bug and if so (b) whether it is a coding 
or
a documentation problem.

Copying to bug list so this doesn't get forgotten.

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

Re: How to adjust space between ChordNames and Staff?

[Trevor Daniels]

Thomas Morley wrote Thursday, January 12, 2017 10:26 PM


> 2017-01-12 21:13 GMT+01:00 Risto Vääräniemi <risva...@gmail.com>:
>
>> The spacing between ChordNames and Staff seems a bit tight by default. I've
>> been trying to adjust it but I haven't figured out the right magic words
>
> Do it in \layout
> 
> chordStuff = \chords { c1 d:m }
> 
> melody = \relative c'' { c4 c c c | d d d d }
> 
> \score {
>  <<
>\new ChordNames  { \chordStuff }
>\new Staff { \melody }
>  >>
>  \layout {
>  \context {
>\ChordNames
>\override VerticalAxisGroup.nonstaff-relatedstaff-spacing.padding = #10
>  }
>  }
> }

Interesting.  Does that mean the ChordNames and Lyrics contexts behave 
differently wrt the vertical spacing controls when these are placed within a 
\with { } block, since Lyrics can be spaced out that way? 
 
If so, is this intended for some reason ... or a bug? 

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

Re: Staging Broken with last makelsr - incorrect TexInfo commandformat

[Trevor Daniels]

David Nalesnik wrote Wednesday, January 11, 2017 3:22 PM


> Ok, so I will probably do
> 
> git revert HEAD
> 
> in my staging branch
> 
> and push it to origin/staging.
> 
> ---
> 
> I won't attempt to clear the LSR queue in preparation for my patch
> update (as I did) by running makelsr.py again.
> 
> When I update my issue, I'll simply add my snippet to snippets/new,
> and leave updating the LSR to the future (when the frenched-score
> snippet and my proposed snippet and whatever else appears will be
> integrated)

Sorry my recipe caused a problem in this case.  Normally clearing
the old LSR queue first with makelsr.py would be fine.  But what
you suggest is also OK, as long as someone fixes the problem and
runs makelsr.py reasonably soon - before the next new snippet is
added (I can't run it myself - on my Windows Vista it always tries 
to change all the \ to / or vice versa.)

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

Re: adding a snippet to a patch

[Trevor Daniels]

David Nalesnik wrote Monday, January 09, 2017 9:51 PM


> On Mon, Jan 9, 2017 at 2:00 PM, David Nalesnik <david.nales...@gmail.com> 
> wrote:
>
>> I'm adding a snippet to a patch dealing with hairpins, and I'm not
>> sure what I need to do.
>>
>> I've added the snippet to Documentation/snippets/new.
>>
>> Do I then need to run scripts/auxiliar/makelsr.py and add the
>> resulting files to my patch for upload to Rietveld?
>>
>> The reason I ask is that there is a snippet not my own which is
>> getting written to Documentation/snippets/ when I run the script:
>> using-marklines-in-a-frenched-score.ly.  This leads to changes in
>> Documentation/snippets/staff-notation.snippet-list as well.
>>
>> I don't want these changes jumbled in with my patch.
> 
> Looking over several older patches affecting snippets, I see that I
> should run the makelsr script and add the resulting files.
> 
> This, however, was not done in the last patch adding a snippet:
> 
> commit 5944d20489bb5b8e4c4907fa3b3bcae9ec275ccb
> Author: Mark Knoop <m...@opus11.net>
> Date:   Thu Sep 8 18:56:16 2016 +0100
> 
> I'm at a loss what to do.   Should I just add the files relevant to my
> patch, and ignore those produced by Mark's?

The normal practice is to include the makelsr.py changes with
your patch on Reitveld, but as two separate commits, so the
makelsr.py changes are in a commit on their own.

In this case, as there are some other changes involved, I
suggest running makelsr.py first, before applying your patch,
and push to staging.  No need for a prior review.  Then your 
patch, including a second makelsr.py in a separate commit,
can be uploaded to Reitveld cleanly.

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