lilypond-devel
[Top][All Lists]
Advanced

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

Re: Allows slurs to break at barlines. (issue 7424049)


From: dak
Subject: Re: Allows slurs to break at barlines. (issue 7424049)
Date: Wed, 20 Mar 2013 13:22:22 +0000

On 2013/03/20 12:35:37, Ian Hulin (gmail) wrote:

\fake and \broken are concise but "feel" wrong, implying something's
wrong with something else but the name doesn't describe it.

Without pointing out what makes you think they feel wrong, that's not
helpful.

I think a function name where we've got to resort to being clever

"clever" is pretty much the opposite of "descriptive", so I consider
that a mischaracterization of the discussion.

maybe indicate we're trying to solve the wrong problem: we're trying
to make the name short at the expense of descriptiveness. Brevity is
good, but a top-level LilyPond function name has to describe what it
does reasonably accurately.

Again, I feel you are mischaracterizing what we are doing.

Let's maybe invent a descriptive function name like \slurInRepeat.

If the design needs it at both ends of the repeated block you could
consider a single keyword parameter for the function,
o \slurInRepeat #'begin - to appear at the end of the block and
indicate you're
starting a new, partial slur and
o \slurInRepeat #'complete - to appear at the beginning of the block
and
indicate you need to generate the rest of of the slur.

Oh great.  And let's invent another similarly "descriptive" unique
function name not related to the actual phrasing slur command for
partial phrasing slurs.  And yet another function name for partial
dynamics.

My, how simple life is going to get for users!

This would also fit better with the current set of \slur* commands
which are basically slur property setter commands e.g. \slurDotted
\slurUp \slurSolid.

But they are not matched with slur property setter commands (which set
permanent overrides) but with actual slur start and end commands.
Which an editor (and the human observer) will hopefully match with
written start and end commands, so it makes sense to have them
visually matched with actually written start and end commands.  And
since with repeat constructs, the actually _true_ start and end
commands _don't_ need to match, it makes perfect sense to use the same
commands as part of visual slur starts and ends (which _have_ to match
together with the actual slur starts and ends) that we do for the
actual slur starts and ends.

I think that the advantages of that scheme are clear enough that
discussing far more awkward approaches does not make sense.

We still need a name we can agree on.  Other names than \fake with a
more positive connotation would be \visual or \virtual.


https://codereview.appspot.com/7424049/



reply via email to

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