Remove definition of the "instrumentName" property from Score_performer
This setting has no effect; furthermore, according to the discussion on
issue 3581 and the related patch review comments, no default settings for
MIDI controls should ever be enforced if they are not set explicitly.
David Kastrup [Mon, 7 Oct 2013 18:44:48 +0000 (20:44 +0200)]
Issue 3603: Make \tweak ... Grob equivalent to \override rather than \once \override
This simplifies several uses of tweak for both tweak and override.
When desired, one can use \once \tweak in order to get either tweak or
override-once semantics: in the case of the tweak semantics, \once
will just ignore the contained expression.
The replacement of Simple_music_iterator with Music_iterator in
lily/bar-check-iterator.cc made bar checks at the start of music
expressions inoperative altogether, even when not at a bar boundary:
{ a a { | } a a }
stopped producing a diagnostic. Issue 3205 instead needs to be fixed
together with issue 2392 which apparently may be called "Segfault in
Midi when Simple_music_iterator is used at the beginning of an
implicitly created context".
David Nalesnik [Fri, 12 Apr 2013 23:40:45 +0000 (18:40 -0500)]
Issue 3313: Add the command \offset
The ability to offset values of various properties would be a useful
enhancement of LilyPond. Currently, this is possible for default values
of the property 'control-points using the \shape command. The following
patch seeks to generalize the application of offsets to grob properties.
Both overrides and tweaks are supported, on the model of \shape and
\alterBroken.
Offsets are currently limited to three data types: number, number-pair,
and number-pair-list (this last is defined by this patch and represents
the type used, for example, by 'control-points). Offsets are limited to
the properties listed in the grob descriptions contained in
`scm/define-grobs.scm'. Offsets will be reckoned against an override
currently in effect; otherwise, the default setting from the grob
description will be used.
David Kastrup [Sun, 13 Oct 2013 11:53:22 +0000 (13:53 +0200)]
Merge branch 'issue3602' into staging
Done as a merge commit since otherwise the conversion rules and their
application would have required splitting into two parts in order to
keep all commits in master compilable: too much mess for too little
benefit.
Thomas Morley [Wed, 2 Oct 2013 21:31:50 +0000 (23:31 +0200)]
Making flat flags available
Issue 3591
The markup-command 'note-ny-number' and the relvant regression-
tests are extended, too.
The sippet 'using-alternative-flag-styles.ly' from
Documentation/snippets/new/ isn't changed for now, will be tackled
in a follow up.
Julien Rioux [Sat, 5 Oct 2013 08:03:16 +0000 (10:03 +0200)]
Doc: Relayout the download pages (issue 3595).
This slightly modifies the layout of the download pages to make
them more balanced (in the HTML version) and to accomodate wide
pictures.
For Unix, the "Specific packages" box is moved to the top right,
next to the "Generic packages" box, while the "Compiling a file"
box is now a centered, full-width box.
For MacOS and Windows, a similar change is made: the "Compiling a
file" box is moved below and turned into a centered, full-width box
to better accomodate the picture-full content.
David Kastrup [Mon, 7 Oct 2013 19:46:50 +0000 (21:46 +0200)]
Issue 3604: Fix function signature of overrideTimeSignatureSettings
Using fraction? rather than pair? is more discriminative, and using
the cheap-list? predicate rather than plain list? is not really a
significant time saver in a complex construct like this.
Although labelled as optional, perl is required to build the
.pfb font files, which are not included in the tarball. With
this commit, perl becomes a required dependency.
The convert-ly rule was only intended for making our documentation
somewhat snappier. Since it is only intended to remove manual
beamings that have now become redundant, it's mainly interesting for
documentation rather than user-level documents.
David Kastrup [Tue, 24 Sep 2013 09:30:12 +0000 (11:30 +0200)]
Issue 3579: Make "Adding extra fingering with scheme" snippet do something useful
This snippet was never operative in 2.16 due to the EventChord changes
of issue 2240. This updates it into using a few 2.16 features in
order to make things simpler while retaining the basic purpose.
David Kastrup [Tue, 24 Sep 2013 14:40:02 +0000 (16:40 +0200)]
Issue 3580: Replace unwarranted uses of map with for-each and other Scheme cleanups
Note that some uses of map actually relied on execution order (namely
expecting map to behave like map-in-order) and thus were not just
inelegant because of the side effect. There are also some other
mostly trivial simplification of Scheme constructs.
David Kastrup [Sun, 22 Sep 2013 16:34:11 +0000 (18:34 +0200)]
Issue3571: Stop \lyricmode { \skip 1.*3 } from failing.
The problem was that the lexer preferred to match ".*" as a word since
the matched pattern was longer than the explicit pattern matching ".".
The word pattern is now amended so that it does not compete with the
single-character patterns.
David Kastrup [Thu, 19 Sep 2013 12:52:26 +0000 (14:52 +0200)]
Issue 3565: Doc, EG: LilyPond's getting too smart for the "Inline Scheme code" section
The "Inline Scheme code" section already was embarrassing enough
during its last revision, when a trivial syntactic change was all that
was required in order to have the stated problem go away without
requiring to revert to Scheme.
Since then, the situation has further deteriorated: the originally
"what we would like to do but it fails" example works entirely
unchanged without a hitch.
David Kastrup [Wed, 18 Sep 2013 18:57:59 +0000 (20:57 +0200)]
Issue 3563: Allow define-*-function to accept currying definitions
This is actually only useful for define-scheme-function since the
purpose of a currying definition is to return a function rather than a
music expression. A typical usage case would be a function creating
an engraver closure:
projects / lilypond.git / log