bug-lilypond
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: address@hidden
Subject: Re: \override Beam #'consistent-slope = ##t should be default
Date: Wed, 26 Oct 2011 09:54:29 +0200

On Oct 25, 2011, at 10:06 AM, address@hidden wrote:

> On Oct 25, 2011, at 5:32 AM, Keith OHara wrote:
> 
>> There are lots of broken beams in Scriabin's first prelude
>> <http://imslp.org/wiki/24_Preludes,_Op.11_(Scriabin,_Aleksandr)>
>> 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 
>> <http://www.mutopiaproject.org/cgibin/piece-info.cgi?id=1779>
>> Applying consistent-broken-slope = #t (beware the error in this thread 
>> subject line) produces output with distractingly strange stem lengths.
>> 
>> The patch at <http://codereview.appspot.com/5293060>
>> 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 (uggghhhhh :).
> 
> 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

Hey all,

I have a new patch up at:

http://codereview.appspot.com/5293060

That addresses Keith's and David's concerns and (hopefully) gets broken slopes 
closer to the way that they appear in the late-Romantic and early-modern 
literature.

The patch still has some crud in it (notes to self, etc.) but is more or less 
stable.

The problem is that, when I run regtests on it, it slows my machine down to a 
crawl.  I am not sure if this is because I have a problem with my machine or if 
because I have some sorta memory leakage in the patch.

So, if someone could please run the regtests and let me know if they run in a 
timely fashion (or if they slow your machine down too), I'd appreciate it!

Cheers,
MS



reply via email to

[Prev in Thread] Current Thread [Next in Thread]