Re: Issue 1990 in lilypond: Patch: Uses convert-ly to update changes stemming from the creation of a Flag grob.

[lilypond]

Updates:
Status: Fixed

Comment #3 on issue 1990 by mts...@gmail.com: Patch: Uses convert-ly to  
update changes stemming from the creation of a Flag grob.

http://code.google.com/p/lilypond/issues/detail?id=1990

Fixed in dev/staging with 25dc2c605448eaa2d5bdd6f937d9690b0373ad5d.


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

Re: Issue 1992 in lilypond: Patch: Fixes all duplicate declarations of Flag #'transparent

[lilypond]

Updates:
Status: Fixed

Comment #3 on issue 1992 by mts...@gmail.com: Patch: Fixes all duplicate  
declarations of Flag #'transparent

http://code.google.com/p/lilypond/issues/detail?id=1992

Fixed in dev/staging with 25dc2c605448eaa2d5bdd6f937d9690b0373ad5d.


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

Re: Issue 1127 in lilypond: Piano staff centred dynamics

[lilypond]

Comment #9 on issue 1127 by lemzw...@gmail.com: Piano staff centred dynamics
http://code.google.com/p/lilypond/issues/detail?id=1127

Thanks for the example!  I prefer the bottom staff to the top one, except  
that it would be desirable that the dynamics in the second and third bar  
stay slightly more aligned vertically. No idea whether this is possible.


Could you show us how it looks if you add two or three extra staff-space  
between the staves?  Maybe I have to withdraw issue 5 of my proposed  
algorithm in favour of centering between the skylines...




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

Re: Issue 1127 in lilypond: Piano staff centred dynamics

[lilypond]

Comment #8 on issue 1127 by k-ohara5...@oco.net: Piano staff centred  
dynamics

http://code.google.com/p/lilypond/issues/detail?id=1127

So it seems the desire is to move individual dynamics (or groups linked as  
per issue 1362).  When the music is tight the dynamics are forced midway  
between the skylines of the staves; when spacing gets loose they go midway  
between the staves.


To show the transition between loose- and tight-limits, I made a picture  
with tight spacing in the middle, and one extra staff-space between staves  
at top and bottom.  The top system has dynamics return to the center line  
between staves as quickly as possible; the bottom system has dynamics  
follow the mid-line between skylines.  Anything between these two would  
look pretty good to me.


The examples just use tweaks.  Having Lilypond do it automatically takes  
some careful work, because Lilypond places everything relative to its home  
Staff or Lyrics context before working on the relative placement of Staves.


Attachments:
1127.png  139 KB


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

Re: Issue 1988 in lilypond: Patch: Rename \markuplines to \markuplist (before running convert-ly)

[lilypond]

Updates:
Labels: -Patch-review Patch-countdown

Comment #9 on issue 1988 by colinpkc...@gmail.com: Patch: Rename  
\markuplines to \markuplist (before running convert-ly)

http://code.google.com/p/lilypond/issues/detail?id=1988

(No comment was entered for this change.)


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

Re: Issue 1567 in lilypond: Add documentation for footnotes

[lilypond]

Updates:
Labels: -Patch-review Patch-needs_work

Comment #15 on issue 1567 by colinpkc...@gmail.com: Add documentation for  
footnotes

http://code.google.com/p/lilypond/issues/detail?id=1567

Mike has comments on Rietveld.


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

Re: Issue 1972 in lilypond: Seg fault and 100% CPU when using \override Staff.StaffSymbol #'ledger-positions

[lilypond]

Updates:
Labels: -Patch-countdown Patch-push

Comment #15 on issue 1972 by colinpkc...@gmail.com: Seg fault and 100% CPU  
when using \override Staff.StaffSymbol #'ledger-positions

http://code.google.com/p/lilypond/issues/detail?id=1972

Counteddown to 20111025


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

Re: Issue 1992 in lilypond: Patch: Fixes all duplicate declarations of Flag #'transparent

[lilypond]

Updates:
Labels: Patch-review

Comment #1 on issue 1992 by percival.music...@gmail.com: Patch: Fixes all  
duplicate declarations of Flag #'transparent

http://code.google.com/p/lilypond/issues/detail?id=1992#c1

Patchy the autobot says: LGTM.


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

Re: Issue 1988 in lilypond: Patch: Rename \markuplines to \markuplist (before running convert-ly)

[lilypond]

Updates:
Labels: Patch-review

Comment #8 on issue 1988 by percival.music...@gmail.com: Patch: Rename  
\markuplines to \markuplist (before running convert-ly)

http://code.google.com/p/lilypond/issues/detail?id=1988#c8

Patchy the autobot says: LGTM.


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

Re: Issue 1943 in lilypond: lilypond after 2.15.8 fails on x86 Macs

[lilypond]

Comment #12 on issue 1943 by stans...@gmail.com: lilypond after 2.15.8  
fails on x86 Macs

http://code.google.com/p/lilypond/issues/detail?id=1943

On PPC OS 10.5.8, by moving missing files from 2.15.14-1 (official  
download) into Resources, both of the above bundles appear to work.


On x86 iMac OS 10.5.8, using Resource files from 2.15.8 (the last working  
version), both of the bundles appear to work.


By working, the "Welcome to LilyPond" file was saved and processed  
successfully. I'm sorry that I don't have time to do further checking at  
the moment. Thanks for your efforts!



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

Re: Issue 1943 in lilypond: lilypond after 2.15.8 fails on x86 Macs

[lilypond]

Comment #11 on issue 1943 by chh...@gmail.com: lilypond after 2.15.8 fails  
on x86 Macs

http://code.google.com/p/lilypond/issues/detail?id=1943

The official PPC binary still uses the previous LilyPond.app. For the x86  
version this was changed to support 10.7.


Do any, or both of the following work on PPC and x86 < 10.6 ? (only bundle,  
no lilypond included)


http://klarinett.li/lilypond/lilypond-app-bundle-10.3.tar.bz2 (does _not_  
work on 10.7)

http://klarinett.li/lilypond/lilypond-app-bundle-10.6.tar.bz2



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

Re: Issue 1943 in lilypond: lilypond after 2.15.8 fails on x86 Macs

[lilypond]

Comment #10 on issue 1943 by stans...@gmail.com: lilypond after 2.15.8  
fails on x86 Macs

http://code.google.com/p/lilypond/issues/detail?id=1943

Please note that the "official" ppc version 2.15.15-1 for PPC (downloaded  
from the LilyPond.org site)  appears to be working normally. I converted  
and compiled a source file without apparent error.



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

Re: Issue 1943 in lilypond: lilypond after 2.15.8 fails on x86 Macs

[lilypond]

Comment #9 on issue 1943 by stans...@gmail.com: lilypond after 2.15.8 fails  
on x86 Macs

http://code.google.com/p/lilypond/issues/detail?id=1943

Re: ppc version. On PowerBook G4, OS 10.5.8, the  
http://klarinett.li/lilypond/lilypond-2.15.15-darwin-ppc.tar.bz2 also  
failed with the LilyPond Error  Console / Terminate dialog box. Selecting  
Console gave the traceback info below.


Attachments:
Console ppc Traceback  2.6 KB


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

Re: Issue 1943 in lilypond: lilypond after 2.15.8 fails on x86 Macs

[lilypond]

Comment #8 on issue 1943 by stans...@gmail.com: lilypond after 2.15.8 fails  
on x86 Macs

http://code.google.com/p/lilypond/issues/detail?id=1943

On iMac running OS 10.5.8 it failed, this time with a dialog box  
saying "LilyPond Error" and giving me the choice of going to Console or  
Terminate(ing) LilyPond. The Console message reporting Exception Type,  
Exception Codes, Crashed Thread, And Dyld Error Message was identical to  
the message previously reported (comment #5 attachment).


I double-clicked the executable (LilyPond.app/Contents/MacOS/LilyPond).  
Terminal opened and provided the attached Traceback.



Attachments:
traceback  1.1 KB


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

Re: Issue 1567 in lilypond: Add documentation for footnotes

[lilypond]

Updates:
Labels: -Priority-Medium Patch-review

Comment #14 on issue 1567 by pkx1...@gmail.com: Add documentation for  
footnotes

http://code.google.com/p/lilypond/issues/detail?id=1567

Patch ready for review.

Passes make and a full make doc

http://codereview.appspot.com/5315053/

Thanks

James


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

Re: Issue 1943 in lilypond: lilypond after 2.15.8 fails on x86 Macs

[lilypond]

Comment #7 on issue 1943 by chh...@gmail.com: lilypond after 2.15.8 fails  
on x86 Macs

http://code.google.com/p/lilypond/issues/detail?id=1943

For this next try I have used the official Python distribution form Mac  
(fat i386/PPC) from python.org. I tested the x86 version on 10.7.


I'd like to get feedback from any PPC system and x86 systems <= 10.6.

x86: http://klarinett.li/lilypond/lilypond-2.15.15-darwin-x86.tar.bz2
ppc: http://klarinett.li/lilypond/lilypond-2.15.15-darwin-ppc.tar.bz2
app-bundle-only: http://klarinett.li/lilypond/lilypond-template.fat.tar.bz2


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

Re: Issue 1943 in lilypond: lilypond after 2.15.8 fails on x86 Macs

[lilypond]

Comment #6 on issue 1943 by stans...@gmail.com: lilypond after 2.15.8 fails  
on x86 Macs

http://code.google.com/p/lilypond/issues/detail?id=1943

lilypond-2.15.15-1.darwin-x86.tar.bz2 also crashes following expansion on  
my iMac. Once again, "Get Info" about the expanded file incorrectly reports  
version as 2.14.2. The last working version, 2.15.8-1, correctly reports  
the version using "Get Info."


I am not a programmer, but the following may be helpful. Using Terminal,  
the version of python reported with  2.15.8-1   
using "LilyPond.app/Contents/MacOS/python --version" is Python 2.6.2. The  
same command using 2.15.15-1 generates a error message as follows: dyld:  
unknown required load command 0x8022

Trace/BPT trap.

Looking at the included python file (LilyPond.app/Contents/MacOS/python)  
for 2.15.15 shows big differences from the python file included in 2.15.8.  
The most obvious is the repeated inclusion of "Apple Inc.1&0$UApple  
Certification Authority10U". There are 18 matches in the file. The  
2.15.8-1 included python has no instances of the phrase.



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

Re: Issue 1984 in lilypond: Patch: parser.yy: make Scheme and music expressions equivalent as function arguments.

[lilypond]

Updates:
Status: Fixed
Labels: -Patch-countdown

Comment #5 on issue 1984 by d...@gnu.org: Patch: parser.yy: make Scheme and  
music expressions equivalent as function arguments.

http://code.google.com/p/lilypond/issues/detail?id=1984

Pushed as 1cef8d54c0cc91af6ea6f84bd5bace83989b6b80


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

Re: Issue 1987 in lilypond: Patch: Get rid of most of the insane string-tunings API

[lilypond]

Updates:
Owner: d...@gnu.org
Cc: carl.d.s...@gmail.com

Comment #11 on issue 1987 by d...@gnu.org: Patch: Get rid of most of the  
insane string-tunings API

http://code.google.com/p/lilypond/issues/detail?id=1987

Regarding comment #10: it is totally annoying that git cl upload, as a  
rule, can't find the associated issue number, asks for it, and when given  
it, posts the usually outdated review header as if it reflected current  
development.


So in contrast to comment #10: The codereview contains the patch state  
intended to be pushed (as a single merge commit of a branch containing two  
commits).


It can go through the usual channels, and if the version bumps before it  
finishes, I'll be tearing my hairs out.


Since the original API seems to be by Carl, the review might benefit from  
his opinion about the change all in all.



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

Re: Issue 1987 in lilypond: Patch: Get rid of most of the insane string-tunings API

[lilypond]

Updates:
Labels: Patch-new

Comment #10 on issue 1987 by d...@gnu.org: Patch: Get rid of most of the  
insane string-tunings API

http://code.google.com/p/lilypond/issues/detail?id=1987#c10

Get rid of most of the insane string-tunings API

convert-ly rules are there.  Translations should compile again after  
applying convert-ly, but of course the changes to text and examples should  
be propagated eventually with the usual processes.


This is intended for dev/staging as soon as staging contains a  
convert-ly-clean tree.


http://codereview.appspot.com/5318046


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

Issue 1992 in lilypond: Patch: Fixes all duplicate declarations of Flag #'transparent

[lilypond]

Status: New
Owner: 
Labels: Type-Enhancement Patch-new

New issue 1992 by mts...@gmail.com: Patch: Fixes all duplicate declarations  
of Flag #'transparent

http://code.google.com/p/lilypond/issues/detail?id=1992

Fixes all duplicate declarations of Flag #'transparent

http://codereview.appspot.com/5312056


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

Re: Patch-needs_work vs. others

[Graham Percival]

On Tue, Oct 25, 2011 at 01:20:33PM +0200, David Kastrup wrote:
> Graham Percival  writes:
> 
> > convenient).  It should only contain patches that have completed a
> > countdown, and/or patches that the author wishes to skip the
> > review process.
> 
> Shrug.  That means to me that this patch is dead.  There is no
> conceivable reason that anybody should change its status to anything
> else.

I already changed the status back to Patch-new when I removed my
objection.

> We have its current state "Patch-new" -> Patch has received no obvious
> checks Of course, I checked the patch.  But even if I decide to put the
> "Patch-review" state on myself, this will merely mean: "Patch has passed
> obvious checks, and needs review".  Well, it is under review.  Who
> should decide to change its need of review, and why?

- if somebody reviews the patch and finds problems (ideally solid
  technical problems), they change it to patch-needs_work.
- if it's still patch-review when Colin makes the next countdown,
  it becomes patch-countdown.

> And in any case, it is _impossible_ to let the patch series get checked
> before having a plan for which version the convertrules.py needs to be.
> After applying the reviewed patch, one needs to autoconvert before a
> check can be made.

Right.  This is a special case of having a collective convert-ly
clustermao.  I started a new email thread for that.  Short answer:
just make a patch that combines all your rules, we'll ram that
through (quite possibly avoiding the review process), and get on
with life because this has become a farce.

- Graham

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

Re: Patch-needs_work vs. others

[David Kastrup]

Graham Percival  writes:

> On Tue, Oct 25, 2011 at 10:08:34AM +, lilyp...@googlecode.com wrote:
>> I think that "Needs-evidence" is sufficient for indicating the need
>> for discussion.  The patch status would remain Patch-review (meaning
>> that the patch may or may not be acceptable in his current form but
>> is not going forward).
>
> Let's move discussion to -devel.  And the answer is "no".
>
> I do not want to require that the patch meister, much less Patchy,
> understand the difference between various types of Patch-review
> items.  Patch-review should mean "no known problems, and it can go
> on a countdown".
>
> I'm ok with having two "non-review, non-new" types if you want,
> although I don't see the point of introducing that much
> granularity.  We could have Patch-discuss vs. Patch-needs_work.
>
>> Once Mike gets through with making master or dev/staging
>> convert-ly-clean, I'll likely prepare a single-commit version (as a
>> merge with the results of the convert-ly run) and put it to
>> dev/staging for final review/countdown.
>
> No.  dev/staging means "merge and push ASAC" (as soon as
> convenient).  It should only contain patches that have completed a
> countdown, and/or patches that the author wishes to skip the
> review process.

Shrug.  That means to me that this patch is dead.  There is no
conceivable reason that anybody should change its status to anything
else.

We have its current state "Patch-new" -> Patch has received no obvious
checks Of course, I checked the patch.  But even if I decide to put the
"Patch-review" state on myself, this will merely mean: "Patch has passed
obvious checks, and needs review".  Well, it is under review.  Who
should decide to change its need of review, and why?

And in any case, it is _impossible_ to let the patch series get checked
before having a plan for which version the convertrules.py needs to be.
After applying the reviewed patch, one needs to autoconvert before a
check can be made.

And I can't put up several patches with their own convertrules.py if I
don't even know the order of acceptance.

I don't see how to get out of that corner except by deciding I "wish to
skip the review process".  I do that all of the time, basically because
I am an irresponsible asshole.  But it is not fun being an irresponsible
asshole if there is no other choice.

-- 
David Kastrup


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

Re: Issue 1663 in lilypond: Images missing on web site

[lilypond]

Comment #55 on issue 1663 by percival.music...@gmail.com: Images missing on  
web site

http://code.google.com/p/lilypond/issues/detail?id=1663

Thanks, I've changed Patchy to use git apply instead of patch(1).
https://github.com/gperciva/lilypond-extra/commit/d2c3d648ec3b51ef67d84583544f7e837e9b7fdd


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

Patch-needs_work vs. others

[Graham Percival]

On Tue, Oct 25, 2011 at 10:08:34AM +, lilyp...@googlecode.com wrote:
> I think that "Needs-evidence" is sufficient for indicating the need
> for discussion.  The patch status would remain Patch-review (meaning
> that the patch may or may not be acceptable in his current form but
> is not going forward).

Let's move discussion to -devel.  And the answer is "no".

I do not want to require that the patch meister, much less Patchy,
understand the difference between various types of Patch-review
items.  Patch-review should mean "no known problems, and it can go
on a countdown".

I'm ok with having two "non-review, non-new" types if you want,
although I don't see the point of introducing that much
granularity.  We could have Patch-discuss vs. Patch-needs_work.

> Once Mike gets through with making master or dev/staging
> convert-ly-clean, I'll likely prepare a single-commit version (as a
> merge with the results of the convert-ly run) and put it to
> dev/staging for final review/countdown.

No.  dev/staging means "merge and push ASAC" (as soon as
convenient).  It should only contain patches that have completed a
countdown, and/or patches that the author wishes to skip the
review process.

- Graham

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

Re: Issue 1988 in lilypond: Patch: Rename \markuplines to \markuplist (before running convert-ly)

[lilypond]

Updates:
Owner: d...@gnu.org

Comment #7 on issue 1988 by d...@gnu.org: Patch: Rename \markuplines to  
\markuplist (before running convert-ly)

http://code.google.com/p/lilypond/issues/detail?id=1988

I think that "Needs-evidence" is sufficient for indicating the need for  
discussion.  The patch status would remain Patch-review (meaning that the  
patch may or may not be acceptable in his current form but is not going  
forward).  Patch-needs_work is for the case where it has been determined  
that the patch will not get accepted in its current form.


Once Mike gets through with making master or dev/staging convert-ly-clean,  
I'll likely prepare a single-commit version (as a merge with the results of  
the convert-ly run) and put it to dev/staging for final review/countdown.



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

Re: Issue 1988 in lilypond: Patch: Rename \markuplines to \markuplist (before running convert-ly)

[lilypond]

Comment #5 on issue 1988 by percival.music...@gmail.com: Patch: Rename  
\markuplines to \markuplist (before running convert-ly)

http://code.google.com/p/lilypond/issues/detail?id=1988

ok, I'm convinced, and remove my objection.

"Patch-needs_work" is just a catch-all for "there is a known disagreement  
with the patch".  The "work" needed could be a rewritten patch, or it could  
be just a matter of adding comments, discussing stuff, or even just asking  
people to think about it a bit more.  In the latter case, the "work" is  
done by the reviewer(s), not the patch author.


If the name is misleading, I could go along with renaming  
it "Patch-objection" or something like that.  I thought that "needs work"  
was a bit "gentler" than "objection", I'm totally open to changing the name.



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

Re: \override Beam #'consistent-slope = ##t should be default

[David Kastrup]

m...@apollinemike.com writes:

> 3) Aside from what I mention in (2), are there any other criteria
> that, in your opinion, seem to govern slope breaking?  Could these
> criteria vary from work to work, edition to edition, style to style?
> Does Elaine Gould have anything to say on the subject?  I can change
> the name of consistent-broken-slope to slope-style (with styles like
> hardcore-contemporary, 'peters-fin-de-siecle, 'break-without-unifying,
> etc.).  But it'd be good to do this now before I have to start dealing
> with convert-ly rules (ugggh :).
>
> I know beam-quanting.cc pretty well now, so any changes to the scorer
> wouldn't take me a long time.  What is most important is that we
> brainstorm this thing correctly so that we can get as much right as
> possible with this patch.

Well, I still maintain that maintaining stem length consistency is
overrated.  However, just optimizing on the constraints

a) beam slope is identical before and after break
b) stem lengths are scored independently before and after break

is not quite sufficient: If we have something like [c c b, \break c' c'
b] then we would get a consistently falling slope which is
counterintuitive.  The overall slope orientation needs to be chosen
according to the overall melody line.  But we need not keep it at full
tilt, since otherwise we are quite close to the original "maintain stem
length".

A first approach would be
a) calculate slope and stem lengths as though we have total consistency.
b) do the break
c) allow the stem lengths before and after the break to relax
   independently from the respective other group.
d) allow the slopes before and after the break to relax in lockstep, but
   in a manner that is stiffer when horizontal.  Like scoring on
   differences in the cotangent of the beam angle while maintaining its
   sign.

The important thing is keeping the character, since we might have a
repeated phrase with just one beam in one repetition being broken.
There must be a certain optical qualitative similarity, balanced against
ugliness of the individual broken pieces.

-- 
David Kastrup


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

Re: \override Beam #'consistent-slope = ##t should be default

[m...@apollinemike.com]

errata: more note flat = more not flat
On Oct 25, 2011, at 10:06 AM, m...@apollinemike.com wrote:

> On Oct 25, 2011, at 5:32 AM, Keith OHara wrote:
> 
>> There are lots of broken beams in Scriabin's first prelude
>> 
>> The original publisher makes no attempt at consistent slopes.
>> Peters Edition prints nearly-equal slopes across the line-breaks, but
>> lets the beam height 
>> 
>> There is a Lilypond version at 
>> 
>> Applying consistent-broken-slope = #t (beware the error in this thread 
>> subject line) produces output with distractingly strange stem lengths.
>> 
>> The patch at 
>> seems to help.  The odd stem lengths, required to match the vertical
>> position of the beam across the line-break, are still distracting.
>> 
>> Consistent slopes seem to help readability somewhat.
>> 
> 
> Hey Keith,
> 
> Thanks for the suggestion!
> I've uploaded a new patch set that brings my work closer to the Peters.
> 
> A few thoughts:
> 
> 1) For hardcore contemporary music, I actually like the aesthetic of 
> completely consistent slopes.  I'll code a property for that once I've gotten 
> comments on the newest version of this patch.
> 
> 2) I get the sense from the Peters that the rule seems to be "the OKness of 
> slope modifications is directly proportional to the absolute value of the 
> slope."  That is, for flat slopes breaking across lines, a change in slope 
> seems very bad, whereas for slopes that are @ 20ish degrees, a change in 
> slope seems OK.  Although I don't know anything about human 
> psychology/cognition, my gut tells me that this corresponds to the way we 
> perceive slopes: if something goes from flat to not flat it sticks out, but 
> if something goes from not flat to more note flat it sticks out less.
> 
> 3) Aside from what I mention in (2), are there any other criteria that, in 
> your opinion, seem to govern slope breaking?  Could these criteria vary from 
> work to work, edition to edition, style to style?  Does Elaine Gould have 
> anything to say on the subject?  I can change the name of 
> consistent-broken-slope to slope-style (with styles like 
> 'hardcore-contemporary, 'peters-fin-de-siecle, 'break-without-unifying, 
> etc.).  But it'd be good to do this now before I have to start dealing with 
> convert-ly rules (ugggh :).
> 
> I know beam-quanting.cc pretty well now, so any changes to the scorer 
> wouldn't take me a long time.  What is most important is that we brainstorm 
> this thing correctly so that we can get as much right as possible with this 
> patch.
> 
> Cheers,
> MS
> ___
> bug-lilypond mailing list
> bug-lilypond@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-lilypond


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

Re: \override Beam #'consistent-slope = ##t should be default

[mike]

On Oct 25, 2011, at 5:32 AM, Keith OHara wrote:

> There are lots of broken beams in Scriabin's first prelude
> 
> The original publisher makes no attempt at consistent slopes.
> Peters Edition prints nearly-equal slopes across the line-breaks, but
> lets the beam height 
> 
> There is a Lilypond version at 
> 
> Applying consistent-broken-slope = #t (beware the error in this thread 
> subject line) produces output with distractingly strange stem lengths.
> 
> The patch at 
> seems to help.  The odd stem lengths, required to match the vertical
> position of the beam across the line-break, are still distracting.
> 
> Consistent slopes seem to help readability somewhat.
> 

Hey Keith,

Thanks for the suggestion!
I've uploaded a new patch set that brings my work closer to the Peters.

A few thoughts:

1) For hardcore contemporary music, I actually like the aesthetic of completely 
consistent slopes.  I'll code a property for that once I've gotten comments on 
the newest version of this patch.

2) I get the sense from the Peters that the rule seems to be "the OKness of 
slope modifications is directly proportional to the absolute value of the 
slope."  That is, for flat slopes breaking across lines, a change in slope 
seems very bad, whereas for slopes that are @ 20ish degrees, a change in slope 
seems OK.  Although I don't know anything about human psychology/cognition, my 
gut tells me that this corresponds to the way we perceive slopes: if something 
goes from flat to not flat it sticks out, but if something goes from not flat 
to more note flat it sticks out less.

3) Aside from what I mention in (2), are there any other criteria that, in your 
opinion, seem to govern slope breaking?  Could these criteria vary from work to 
work, edition to edition, style to style?  Does Elaine Gould have anything to 
say on the subject?  I can change the name of consistent-broken-slope to 
slope-style (with styles like 'hardcore-contemporary, 'peters-fin-de-siecle, 
'break-without-unifying, etc.).  But it'd be good to do this now before I have 
to start dealing with convert-ly rules (ugggh :).

I know beam-quanting.cc pretty well now, so any changes to the scorer wouldn't 
take me a long time.  What is most important is that we brainstorm this thing 
correctly so that we can get as much right as possible with this patch.

Cheers,
MS
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Issue 1127 in lilypond: Piano staff centred dynamics

[lilypond]

Comment #7 on issue 1127 by perpeduu...@gmail.com: Piano staff centred  
dynamics

http://code.google.com/p/lilypond/issues/detail?id=1127

+1 for Keith's work second result. I guess I have to rephrase my demand  
to "sensibly centered dynamics".
To yield this, I wonder whether it already suffices just /not/ to keep a  
common baseline for the Dynamics. Instead, adjust each DynamicScript  
independently of the others. (No clue how hard this is to do, though. From  
my naive POV, it should be equivalent to instantiate a new Dynamics context  
for each DynamicScript, but in fact it's not as simple as that...)


Also +1 for Werner's idea of a correction factor between "staff"  
and "skyline" spacing.


Don't forget, though: we need the syntactic option to denote groups of  
dynamics to be aligned together (e.g., several hairpins close together on  
the same baseline).



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

Re: Issue 1986 in lilypond: Patch: Fixes slope errors from incorrect X extents in Beam::print.

[lilypond]

Updates:
Labels: Patch-new

Comment #4 on issue 1986 by mts...@gmail.com: Patch: Fixes slope errors  
from incorrect X extents in Beam::print.

http://code.google.com/p/lilypond/issues/detail?id=1986#c4

Fixes slope errors from incorrect X extents in Beam::print.

http://codereview.appspot.com/5293060


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