On 2013/03/17 07:27:37, MikeSol wrote:
On 2013/03/13 21:38:59, thomasmorley65 wrote:
> https://codereview.appspot.com/7615043/diff/23001/scm/output-lib.scm > File scm/output-lib.scm (right): > >
https://codereview.appspot.com/7615043/diff/23001/scm/output-lib.scm#newcode1061
> scm/output-lib.scm:1061: (thick (* thick (layout-line-thickness
grob)))
> At first sight I was surprised about `layout-line-thickness´. Than I remembered, > it is defined in bar-line.scm > How about making it public, moving it to lily-library.scm? > It could be used then in local custom-definitions. > Same with `layout-blot-diameter´. > I know, it's another topic, though, what do you think about it?
Great idea!
I'd have expected _this_ change in another patch. At least it should be mentioned in the commit-message.
>
https://codereview.appspot.com/7615043/diff/23001/scm/output-lib.scm#newcode1078
> scm/output-lib.scm:1078: > What do you think about predefining sth like > ferneyhoughHairpinOn/Off > constanteHairpinOn/Off > in /lyproperty-init.ly? > i.e. > ferneyhoughHairpinOn = > \override Hairpin #'stencil = #ferneyhough-hairpin
I'm not against this idea at all - I'd like to see it proposed in a
different
patch set, if possible. I am teerrrrrible at judging UI issues
because I hack
so much. It is true that shortcuts help, but there are many, many
overrides
that are shortcut-worthy. I'm not sure what standard determines which
overrides
should get shortcuts and which shouldn't, so I leave that to a future
(and
important!) conversation.
ok
>
https://codereview.appspot.com/7615043/diff/23001/scm/output-lib.scm#newcode1082
> scm/output-lib.scm:1082: (define-public constante-hairpin > I'm not happy with constante-hairpin.
[...]
The constante indication means that the dynamic should not change at
all, so the
decision to use a hairpin that grows in a given direction is
admittedly a hack.
The idea of dimMolto (or crescMolto) with constante is a contradiction
(get very
quiet while not changing dynamic).
Yep. And this contradiction _is_ disturbing.
Insofar as a hairpin represents a change in dynamics, constante should, in theory, be a different grob. My
solution is not
ideal, but I think it is an OK middle-ground short of the creation of
a separate
grob. If people think it is too hackish, I will propose a new patch
with a
Constante grob (or make the hairpin grow-direction = #CENTER default
to
constante, which'd be difficult but doable).
For now I'd tend to let it as it stands. Nevertheless, it _is_ hackish and I think it should be replaced by one of your proposals later. Though, how about:
Is it possible to make the hook-direction depending on the position of
the
Hairpin i.e below or above the staff?
? https://codereview.appspot.com/7615043/ _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
