[Patch] Fix #1333: beamed multi-note acciaccaturas

Fix #1333: beamed multi-note acciaccaturas with a slashed stem

This commit modifies the def-grace-function macro to make it
aware of wether its argument is a single note or a SequentialMusic
expression.  The appropriate rules are looked up and applied
accordingly; if a corresponding rule has not been defined, then the
standard GraceMusic rules are applied instead.

Where as single-note acciaccaturas are printed using a font glyph,
this implementation uses a modified stencil to print a slash on the
first stem of several beamed notes.  It allows for a pure-Scheme
implementation, albeit arguably not very elegant.

[Valentin Villenave, 2010-11-17 15:29:09]

Greetings everybody,

here's a patch (more of a workaround, really) to address
http://code.google.com/p/lilypond/issues/detail?id=1333
(aka Lily's inability to print beamed acciaccaturas with a slashed stem).

Whilst not very elegant, it does allow to handle multi-note grace expressions
differently, which might be interesting in the future.

Thanks for having a look!

[Valentin Villenave, 2010-11-18 08:43:28]

New patch set, with slightly better coding style . I'm not sure why, but the
side-by-side diff is unavailable ("upload in progress"). Unified diff is
available, though.

[Graham Percival (old account), 2010-11-18 17:55:27]

I can't view scm/music-functions.scm ; please upload again.

http://codereview.appspot.com/3169041/diff/3001/ly/grace-init.ly
File ly/grace-init.ly (left):

http://codereview.appspot.com/3169041/diff/3001/ly/grace-init.ly#oldcode4
ly/grace-init.ly:4: startGraceMusic =  {
Why are these being removed?

[Carl, 2010-11-18 19:31:28]

Valentin,

I couldn't comment inline on the scm file, because it gave me a server error
when I tried.

Here's the comments I put in on your new macro:


I'm concerned about redefining a public function so that the arguments mean
totally different things.  This will totally break any existing scores that use
def-grace-function.

At the very least it needs a convert-ly rule.

I'm concerned about code that requires functions to have a particular name in
order to work properly.  While we *can* do it with Scheme, I don't think it's a
good idea.

With the old code I have complete control over what I want to do to start and
stop grace music.  WIth this code my start and stop functions have to have a
particular name or they won't work.


I appreciate your work.  I think this is an important change to LilyPond, but I
the architecture I propose in music-functions-init.ly is better.

THanks,

Carl

http://codereview.appspot.com/3169041/diff/3001/ly/music-functions-init.ly
File ly/music-functions-init.ly (right):

http://codereview.appspot.com/3169041/diff/3001/ly/music-functions-init.ly#ne...
ly/music-functions-init.ly:35: #(def-grace-function AcciaccaturaMusic
BeamedAcciaccaturaMusic
Since the problem is only with acciaccatura, why not just change the definition
of acciaccatura so it's a music function with one ly:music? argument that
evaluates the music argument to see if it's a sequential music with more than
one element.  If so, then use a def-grace-function for StartBeamedAcciaccatura,
StopAcciaccatura, and then spit out the music?

This would keep the current infrastructure intact and require no conver-ly
rules, and wouldn't affect anything that is currently working.

[Neil Puttock, 2010-11-18 19:59:23]

Hi Valentin,

I'm afraid I share Carl's concerns here, though to my mind the most pressing
issue is how the slash is rendered.  I don't think it's enough to simply use a
stencil override, since it makes it too difficult for users to tweak the
appearance.

In your current implementation, the slash doesn't scale with varying
staff-space, and looks bad if the beam direction matches the slash direction
(e.g., see the snippet in the bugtracker).

I think rendering the slash with support for tweaking its appearance in a
consistent manner demands an implementation as a separate grob.

Cheers,
Neil

[Valentin Villenave, 2010-11-18 21:39:35]

On 2010/11/18 19:59:23, Neil Puttock wrote:
> Hi Valentin,

Hi Carl, hi Neil, thank for stopping by! :-)
Graham: that's the reason why I uploaded a new patch set, but it didn't succeed
either.  I'm having some kind of a WTF situation here.

> I'm afraid I share Carl's concerns here

I think he's right too. I wanted to take this as a chance to "correct" the way
grace-functions are defined now, which I don't really like (having to define
startGrace and stopGrace as empty expressions? really?). And I was confident
that this could be handled with a straightforward convert-ly rule. However,
you're both right in pointing out that it might be an unnecessary risk.

> though to my mind the most pressing
> issue is how the slash is rendered.  I don't think it's enough to simply use a
> stencil override, since it makes it too difficult for users to tweak the
> appearance.

Hence the "workaround" part that I did mention in my description.  I did see it
as a temporary hack, or more appropriately, a proof-of-concept, until we could
have a genuinely proper solution (see below).

> I think rendering the slash with support for tweaking its appearance in a
> consistent manner demands an implementation as a separate grob.

Unfortunately, this is precisely where I'm out of my league.  My secret hope was
that something like the harp-pedal thing would happen, i.e. my initial "naive"
effort could entice proper programmers into implementing something nicer in the
future :-)

That being said, I'd be happy to play ball and give this a go: if you were to
implement such a grob (I'm guessing something like
BeamedMultiAcciaccaturaInitialStemSlash, only shorter ;-), where would you
start? Would it require a glyph, like what we're doing with non-beamed
acciaccaturas, or would a simple line be enough? And how would you compute the
angle of the slash?

(Besides, I'm concerned with the overhead/bloat/namespace pollution/etc. Would
this grob really need to be added to the Stem_engraver by default? It would be
used quite rarely, I think.)

Bonus question: if we were to have an AcciaccaturaSlash grob, then would we
still need the current implementation for slashed single notes (e.g. combining a
slash glyph with the flag glyph, etc.)? Or could we use the same grob in both
cases for visual consistency?

... Duh. I thought I was out of my league before, but it's even worse now :(

Cheers,
Valentin.