Re: 2.21.0 and announcements

[pkx166h]

Hello

On 26/03/2020 18:54, Davide Liessi wrote:

Dear David,

Il giorno gio 26 mar 2020 alle ore 17:11 David Kastrup  ha 
scritto:

I think
we should point out on our download page that the GUB-provided
installers are _only_ for 32bit MacOSX, and that separate downloads may
be provided elsewhere (possibly linking to Marnen's page

I agree.
Patch attached (based on master), but I haven't tested it.


in the hope
that it does not get overloaded?).

Marnen's builds are hosted on Bintray, whose free plan allows
downloads for up to 1TB/month: how much traffic do we expect?

Best wishes.
Davide


I'll test the patch and create a tracker etc. So we don't lose it.

James

An exciting new release… of Sibelius!!!

[Valentin Villenave]

Hi everybody,
I know it’s off-topic but I wanted to share the news because, let’s be
honest, nobody in their right mind would want to miss it:
Yes!  It’s finally here!  The latest and brightest version of Sibelius
is out…  *And* it offers one particularly exciting, exclusive new
feature:
https://is.gd/x16C0B

… Oh wait, that’s the wrong link.  There you go:
https://is.gd/ussdKG

Seriously guys, how cool is that??

Cheers,
V.

Re: An exciting new release… of Sibelius!!!

[Malte Meyn]

Am 27.03.20 um 15:08 schrieb Valentin Villenave:

Hi everybody,
I know it’s off-topic but I wanted to share the news because, let’s be
honest, nobody in their right mind would want to miss it:
Yes!  It’s finally here!  The latest and brightest version of Sibelius
is out…  *And* it offers one particularly exciting, exclusive new
feature:
https://is.gd/x16C0B

… Oh wait, that’s the wrong link.  There you go:
https://is.gd/ussdKG

Seriously guys, how cool is that??

Cheers,
V.



Hi Valentin,

mocking Finale/Sibelius for what they cannot (could not) do is fun but 
we have to admit that LilyPond’s LV ties aren’t exactly perfect. No one 
should have to use the hacky snippet 715 
(http://lsr.di.unimi.it/LSR/Item?id=715) for setting the tie length. 
Sibelius—now that it has LV ties—seems to do the better job.


Cheers,
Malte

Re: Trim unused toplevel targets. (issue 547810069 by hanw...@gmail.com)

[Han-Wen Nienhuys]

On Thu, Mar 26, 2020 at 12:26 PM David Kastrup  wrote:
> >> > Many GNU packages haven't been with the times. Git is now 14 years old.
> >> > I people want to know what changed, they can read the man page to
> >> > git-log.
> >>
> >> That assumes that they don't have an official and versioned distribution
> >> of LilyPond (or of some fork of it) but rather a clone of the repository
> >> corresponding to their version of Git.  The GPL does not guarantee that
> >> modified source comes with full repository access to back it.  Merely
> >> the _current_ corresponding source.
> >>
> >> That's the reason "many GNU packages auto-generate a ChangeLog file from
> >> the git commit messages".  The decision to do that has been made after
> >> considerable discussion and the respective tools have been developed.
> >
> >
> > This is all nice and dandy, but
> >
> > $ tar tfz ~/Downloads/lilypond-2.20.0.tar.gz lilypond-2.20.0/|grep -i 
> > changelog
> > lilypond-2.20.0/out/ChangeLog
> > lilypond-2.20.0/Documentation/misc/ChangeLog-2.10
> > lilypond-2.20.0/Documentation/misc/ChangeLog-1.5
> > lilypond-2.20.0/Documentation/misc/ChangeLog-2.3
> > lilypond-2.20.0/Documentation/misc/ChangeLog-2.1
> >
> > ie. the ChangeLog is in a place where nobody can find it, and
>
> That would be reason to fix it?

The deeper reason is that I'm trying to improve the build system. This
will take the form of a rewrite.  In that context, it's useful to
remove as much unnecessary cruft from the current build system as
possible, so it is clear what is needs to be redone. The
almost-useless ChangeLog in a non-discoverable place is an example of
such cruft.

> > $ cat lilypond-2.20.0/out/ChangeLog
> > See 
> > http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=log;h=refs/tags/release/2.20.0-1
> >
> > it just contains a link, to a paged  version of our log. Good luck
> > making sense of that.
>
> This is the (intended) consequence of
> commit 525fcaecb829de8c680ad36151d8532da8e35219
> Author: Jan Nieuwenhuizen 
> Date:   Wed Jan 14 12:24:47 2009 +0100
>
> Add missing ChangeLog file with web marker only.
>
> I agree that this does not make a whole lot of sense since it cannot
> provide any useful information for anything not released from the
> central repository.
>
> Autogenerating the ChangeLog, in contrast, would decouple the tarball
> from the Git repository.

This only true in theory. In practice, the ChangeLog doesn't provide
enough information to reconstruct what happened to a file. If a
distribution packager encounters a problem, they are much more likely
to use git-blame and git-log to find out what changed, for what
reason.

> > Given that nobody has complained about this undiscoverable and useless
> > ChangeLog for over 9 years, I think it is safe to remove it.
>
> It's not useless as such (the link is useful) but it is useless for the
> purpose of providing a change history if anybody desires to work with
> it.  It is worth noting that the explicit requirement to mark/list all
> changes prominently is part of GPLv2 but no longer of GPLv3.
>
> GNU Coding standards
> 
> state:
>
> Instead of using a file named ChangeLog, you can record the change
> log information as log entries in a version control system such as
> RCS or CVS. This can be converted automatically to a ChangeLog file
> using rcs2log; in Emacs, the command C-x v a (vc-update-change-log)
> does the job.
>
> The choice of listed version control systems makes clear that this text
> likely comes from a time before distributed version control systems.
>
> I know that Emacs autogenerates its (GNU standard format) ChangeLog
> files from the Git commit messages, but I think that this requires
> generally adhering to the kind of formatting you want to end up seeing
> in the ChangeLog.

I think you are saying here, that it's OK for us to remove the
ChangeLog from the perspective of GNU standards and our license.

> >> It's not like decision and implementation of such a policy would
> >> happen in a vacuum and be unprecedented, so the cost of implementing
> >> such a policy would be considerably more moderate than if we had to
> >> do it from scratch.
> >
> > I think you are overestimating the amount of careful thought that went
> > into this.
>
> The Emacs developer community is large enough that one can with some
> confidence assume that not all of them are idiots.  And if they managed
> to converge on a solution that they consider reasonably painless for
> that purpose, at least taking a look does not seem outlandish.

It involves a 300 line perl program,

https://github.com/emacs-mirror/emacs/blob/ac242ed3843e127c1e2e506ecfd1a4552a2a8c44/build-aux/gitlog-to-changelog

The output looks like

2020-03-01  Werner Lemberg  

Issue 5795: NR: Improve color table layout

2020-02-29  Dan Eble  

Issue 5790/8: Rational: to_int () becomes trunc_int ()
... and returns I64 li

Re: An exciting new release… of Sibelius!!!

[Shane Brandes]

They are really on the ball on that one.

-Shane

On Fri, Mar 27, 2020 at 10:09 AM Valentin Villenave 
wrote:

> Hi everybody,
> I know it’s off-topic but I wanted to share the news because, let’s be
> honest, nobody in their right mind would want to miss it:
> Yes!  It’s finally here!  The latest and brightest version of Sibelius
> is out…  *And* it offers one particularly exciting, exclusive new
> feature:
> https://is.gd/x16C0B
>
> … Oh wait, that’s the wrong link.  There you go:
> https://is.gd/ussdKG
>
> Seriously guys, how cool is that??
>
> Cheers,
> V.
>
>

Re: Remove trailing whitespace {python,scm,lily,scripts}. (issue 547810043 by hanw...@gmail.com)

[hanwenn]

commit 2ddc627c3c3e0299c4dc0ba109340cff54c49710
Author: Han-Wen Nienhuys 
Date:   Sat Mar 21 13:13:32 2020 +0100

Remove trailing whitespace in {python,scripts,*make*}.



https://codereview.appspot.com/547810043/

Re: Add dynamic-interface to keepAliveInterfaces (issue 553760043 by j...@abou-samra.fr)

[jean]

This is a relevant point, but I think Werner is right.

You can put your dynamics in a Dynamics context. Currently, they would
be
removed completely, while with this patch, they would be kept entirely.
Whatever the value of keepAliveInterfaces, this is no good solution for
the
kind of partitura that you describe (althought I tend to think that the
latter
would be less cryptic to the user). But with this change, the default
behavior will
be correct with a usual Dynamics, that is, if you just write spacer
rests when
you want no dynamics.

What we're debating here is the case where you put the dynamics together
with
the music in the same Staff context.

Without this change, staves with rests only are removed whatever their
dynamics.
You could think this is useful, but what if the winds start tacet in the
middle
of a system? You will then have rests with dynamics on them. With this
patch, all the
staves will be kept as soon as they contain dynamics, and you will also
have rests with
dynamics on them. I don't think there is much better to do. Whatever the
state of
keepAliveInterfaces, there is no 'easy' solution: it's up to the user to
split their
dynamics variable, or use \quoteDuring, or write a very tricky function.
As a result,
I can see no situation where the current value of keepAliveInterfaces
does a better
job than the one with dynamic-interface.

If someone does and can provide a concrete example, I'll gladly create a
different
value for Dynamics contexts, but if there is no real reason to do this,
let's keep it simple.

https://codereview.appspot.com/553760043/

Re: Proposal: Changing tremolo beam gap implementation

[Thomas Morley]

Am Fr., 27. März 2020 um 20:45 Uhr schrieb Thomas Morley
:
>
> Am Fr., 27. März 2020 um 18:35 Uhr schrieb Torsten Hämmerle
> :
> >
> > Hello all,
> >
> > Looking more deeply into Harm's strange whole-note tremolo beam gap
> > behaviour, I've stumbled over the current gap implementation:
> >
> > It's probably rather academic, but my understanding of "gap size" is the
> > actual gap size (white space) between two objects.
> >
> > Looking at the current implementation and playing around with stem
> > thickness, however, it becomes obvious that the gap is, other than expected,
> > not the free space between stem and beam:  It it is measured from the outer
> > side of the stems and not from the inner side of the stems.
> >
> > The following illustration will compare the current behaviour to what I
> > would expect, varying the beam thicknesses from 0 via standard up to
> > exaggerated values in order to make the effect clearly visible:
> >
> > 
> >
> > *What do you think?*
> > Wouldn't it be better to have "gap" actually mean "free space"?
> > Before opening an issue and uploading a patch, I'd rather ask for opinions.
> >
> > Thanks in advance,
> > Torsten
> >
> > tremolo-gap-comp.png
> > 
>
> Hi Torsten,
>
> for whole-note-tremolo there is taken care for not colliding with
> left/right NoteHeads, even for 'gap = 0
> If 'gap <= 2 then there is white space added, exactly as specified
> (half of gap-size to left/right), measured from NoteHeads to Beam.
>
> (1) Why should it be different if 'gap is greater than 2.0?
> (2) Why should it be different for other note-durations?
>
> Thus I think 'gap should always specify the _white_ space.
>
>
> Btw, I stumbled across it while trying to code a custom-function
> attempting to make whole-note-tremolo-beams avoid possible Dots to the
> left and possible Accidentals to the right.
>
> Any chance for a fix, while you're on it?
>
>
> Many thanks,
>   Harm
>
> P.S. I crossposted to devel, not all are subscribed to the user-list

Re: Added transition lines for lyrics (issue 565750043 by davidgrant...@gmail.com)

[hanwenn]

On 2020/03/25 08:45:31, davidsg wrote:
> Patch description in the issue tracker has been updated.
> 
>
https://codereview.appspot.com/565750043/diff/569570043/lily/vowel-transition.cc
> File lily/vowel-transition.cc (right):
> 
>
https://codereview.appspot.com/565750043/diff/569570043/lily/vowel-transition.cc#newcode37
> lily/vowel-transition.cc:37: SCM num_length = me->get_property
> ("minimum-length");
> On 2020/03/24 21:46:30, hanwenn wrote:
> > num suggests a number.
> > 
> > minimum_length ?
> 
> Done.
> 
>
https://codereview.appspot.com/565750043/diff/569570043/lily/vowel-transition.cc#newcode137
> lily/vowel-transition.cc:137: w += -d * r->item_drul_[d]->extent
> (r->item_drul_[d], X_AXIS)[-d];
> On 2020/03/24 21:46:29, hanwenn wrote:
> > this still looks strange, but if it's problem, it'll be contained
within the
> > vowel-transition code, which is acceptable.
> 
> Acknowledged, thanks.

this went into master. Can you close the review?

https://codereview.appspot.com/565750043/

Re: mf: use python scripting for generating Emmentaler fonts (issue 553580043 by hanw...@gmail.com)

[lemzwerg--- via Discussions on LilyPond development]

https://codereview.appspot.com/553580043/diff/571810043/mf/gen-emmentaler-brace.fontforge.py
File mf/gen-emmentaler-brace.fontforge.py (right):

https://codereview.appspot.com/553580043/diff/571810043/mf/gen-emmentaler-brace.fontforge.py#newcode40
mf/gen-emmentaler-brace.fontforge.py:40: # mergeFonts takes a font, but
this is a recent innovation fo
s/fo/of/

https://codereview.appspot.com/553580043/

Re: Add dynamic-interface to keepAliveInterfaces (issue 553760043 by j...@abou-samra.fr)

[v . villenave]

On 2020/03/27 19:00:08, jean wrote:
> I can see no situation where the current value of keepAliveInterfaces
does a
> better
> job than the one with dynamic-interface.

OK, you both make a valid point.  Then it LGTM as well.

V.

https://codereview.appspot.com/553760043/

Re: Proposal: Changing tremolo beam gap implementation

[Torsten Hämmerle]

Thomas Morley-2 wrote
> P.S. I crossposted to devel, not all are subscribed to the user-list

I first wanted to ask what users in general think about the gap size.


Thomas Morley-2 wrote
> Thus I think 'gap should always specify the _white_ space.

That's exactly what I had in mind, but the current implementation behaves
differently.


Thomas Morley-2 wrote
> If 'gap <= 2 then there is white space added, exactly as specified
> (half of gap-size to left/right), measured from NoteHeads to Beam.

Yes, exactly.  But this "half of gap-size" is the answer to the following
question of yours:


Thomas Morley-2 wrote
> (1) Why should it be different if 'gap is greater than 2.0?

Let's consider the right side, it's less confusing direction-wise.
In case of semibreves (whole notes), i.e. when we have "invisible stems",
LilyPond considers the following two beam starting point alternatives:
(1) Stem x-position - gap + stem-thickness/2  (currently)
(2) Left edge of notehead - gap/2
The stem x-position for invisible stems is in the centre of the notehead
(!), that makes things a bit weird.

LilyPond will pick the alternative that's closer inside.
For small gaps, alternative (2) will be chosen, but, as gap increases,
alternative (1) is proportional to gap, but alternative (2) is only
proportional to gap/2 and for bigger gaps, alternative (1) will be picked.

The workaround with large stem widths just has the effect that LilyPond will
always pick alternative (2) and thus behave as expected.


Elaine Gould says: /"For semibreves, position the tremolo beams as if the
semibreves were stemmed […]"/ (Behind Bars, p. 226)
That would be kind of alternative (1), except that for an unknown reason
LilyPond's calculation is based on a stem starting in the centre of the
notehead (???).


Gould continues with "/It's acceptable to move semibreve beams closer to the
noteheads […]/"
That's basically alternative (2) and LilyPond's (intended) standard
behaviour. 


But first, we'll have to agree that a gap is generally supposed to be free
space. This change will also influence the whole-note beaming mechanism.
And I'd like to change the centre-stem calculation that does not make any
sense to me. Or am I missing something?

Cheers,
Torsten




--
Sent from: http://lilypond.1069038.n5.nabble.com/Dev-f88644.html

Re: Add dynamic-interface to keepAliveInterfaces (issue 553760043 by j...@abou-samra.fr)

[nine . fierce . ballads]

Is the impact (if any) on existing scores important?  (cases that we
might not have in regression tests but that might irk users?)

https://codereview.appspot.com/553760043/

Re: Add dynamic-interface to keepAliveInterfaces (issue 553760043 by j...@abou-samra.fr)

[nine . fierce . ballads]

On 2020/03/27 23:16:40, Dan Eble wrote:
> Is the impact (if any) on existing scores important?  (cases that we
might not
> have in regression tests but that might irk users?)

... and speaking of regression tests, if you don't want someone to break
your work later, it would be a good idea to add one.

https://codereview.appspot.com/553760043/

Re: An exciting new release… of Sibelius!!!

[Andrew Bernard]

Very amusing. I use LV ties a lot and exactly need lengthy ones all the 
time, not the short ones (despite the Bars book). One of our kind 
colleagues on the list gave me code to extend LV ties, just excellent. 
Not likely to be getting Sib. for that hot new feature.



Andrew