David Kastrup [Tue, 23 Apr 2013 14:49:19 +0000 (16:49 +0200)]
Implement option -dstrokeadjust in order to get stroked stems and strokeadjustment
This makes the stroke drawing primitives for long rounded rectangles
dependent on the setting of currentstrokeadjust. As a result,
low-resolution bitmap devices (up to 150 dpi or so) will get stroke
adjustment applied automatically. The option needs to get invoked
explicitly to get stroke adjustment for PDF, giving a large file size
increase and markedly better previews on a number of PDF previewers.
David Kastrup [Thu, 11 Apr 2013 15:27:14 +0000 (17:27 +0200)]
Issue 2658: Be serious about setstrokeadjust in PostScript primitives
This particularly concerns draw_round_box which is used for drawing
lines with a rounded ending. If the width/height ratio or its inverse
exceeds 2, the box is considered to be a "line". In this case, first
a clipping path is established representing the whole shape and
extended widely in the area of the "main stroke". The reason for this
extension is to avoid both clip area and stroke competing for the
outline. While this is not a problem for the PostScript or PDF
rendering model, the Cairo bitmap rendering library employs
Porter-Duff compositing for antialiasing amounting to "cheap man's
antialiasing" not requiring a higher rendering resolution but relying
on edges affecting a single pixel to be independent.
Porter-Duff requires us not to have multiple parallel strokes or clip
areas if we want to avoid wrong sub-pixel grayness levels (and
consequently lines appearing too thick or thin) in Cairo-based
previewers like Evince.
After establishing the clip area, a stroke is drawn through. This
stroke may (at the PostScript device's discretion) employ
strokeadjustment further correcting the apparent thickness.
Ghostscript employs stroke adjustment when rendering at a resolution
below 150dpi. Stroke adjustment does not pass into PDF, however, when
ps2pdf runs.
Ghostscript performs sub-pixel rendering for antialiasing which
reduces the amount of discontinuities possibly caused by joining
stroke-adjusted shapes with full shapes.
It turns out that sharper contours can be achieved by using strokepath
and fill instead of a plain stroke. However, the resulting crisper
stems tend to combine worse with beams, so this approach has not been
pursued.
Devon Schudy [Sun, 24 Nov 2013 12:07:10 +0000 (07:07 -0500)]
Support articulations and breaths in MIDI. (issue 3664)
Articulations and breaths can alter the length and volume of the note.
(Breaths affect the previous chord.) This is controlled by their
midi-length and midi-extra-velocity properties. The standard articulations
now have these properties where appropriate.
(seconds->moment s context) is a convenience function for making
absolute durations.
Devon Schudy [Sun, 24 Nov 2013 03:39:50 +0000 (22:39 -0500)]
Support properties on articulations.
Shorthand articulations like -. can now be ArticulationEvents, not just
articulation names. Previously a shorthand created a new ArticulationEvent
with its name, so there was no way to give it properties. Now it can be (and
is, by default) an ArticulationEvent.
Note that redefining a shorthand to a string (e.g. dashDot = "staccatissimo")
still creates propertyless articulations, regardless of \staccatissimo.
Janek Warchoł [Fri, 29 Nov 2013 15:47:43 +0000 (16:47 +0100)]
let RhythmicStaff use default barline extent
There is no reason to make barlines in RhythmicStaff special.
The purpose of the deleted code was probably to ensure that
the barlines were visible at all (despite the fact that there
is just one staffline in a RhythmicStaff). However, currently
barline code takes care of this by default.
This makes barlines in DrumStaff and RhythmicStaff similar.
A comment by Keith:
The book by Kurt Stone happens to have some bar-lines in single-line percussion
staves that are as tall as a 4/4 time-signature. Other examples in the same
book have short bar-lines like these here, and looking at some scores the short
bar-lines are more common.
David Kastrup [Sun, 24 Nov 2013 23:59:55 +0000 (00:59 +0100)]
Issue 3675: Make convert-ly -d only ever update on changed files
Previously, it updated unconditionally whenever a new stable version
came out, leading to merge conflicts. When the final applied
conversion is to an unstable version and the following stable version
is not beyond the conversion target, the following stable version is
used.
Note that this rule does not make a factual difference for continuous
updates of a code base (the normal use case for
scripts/auxiliar/update-with-convert-ly.sh), but it makes a difference
for the conversion/import of code that may have fallen behind a lot
(like with the LSR import, or when converting archived files).
Devon Schudy [Fri, 29 Nov 2013 03:05:13 +0000 (19:05 -0800)]
Grace notes: only shorten previous note if overlapping
Previously a grace note after a rest shortened the last note before the
rest.
This patch shortens the previous note to the start of the grace note
rather than by the length of the grace note, so notes before rests
aren't affected unless the grace notes are longer than the rest.
Devon Schudy [Fri, 29 Nov 2013 03:00:02 +0000 (19:00 -0800)]
Fix spurious error playing initial grace notes (issue 1412)
This happens because the MIDI output starts at tick 0, regardless of
when the first event is. Initial grace notes start start at negative
ticks, so midi_walker::output_event thinks they're out of order. Fixed
by starting at the first event.
David Kastrup [Mon, 25 Nov 2013 18:33:34 +0000 (19:33 +0100)]
Issue 3676: Bar checks display the wrong location
This one is just embarrassing. The lexer used last_input_ where it
should have been using here_input (), resulting in music identifiers
and some other stuff to be located one token early.
David Kastrup [Sun, 17 Nov 2013 18:29:06 +0000 (19:29 +0100)]
Issue 3663: Crash with \repeat ... \alternative and \remove "Bar_engraver"
This approach is just poking around in the dark and removing Scheme
error messages. In particular substituting the original glyph for
left-bar-line and right-bar-line (when missing) in calls to
span-bar::compound-bar-line seems fishy, and the original logic
for setting left-bar-broken if left-bar-line is not even present
is also not clear to me.
The results for the example in the bug report:
form = \new Staff \with {
\remove "Bar_engraver"
} \repeat volta 2 {
s1
} \alternative {
s1 % first ending
s1 % second ending
} % form
\score {
<<
\form
>>
} % score
are also not identical with the 2.16 results: the volta brackets now
run into each other; before there was a gap.
It fixes the crash. I have no idea what a proper fix would look like.
David Kastrup [Mon, 18 Nov 2013 11:37:59 +0000 (12:37 +0100)]
Issue 3668: Let NullVoice have an existence in MIDI
Issue 3457 omitted to introduce the NullVoice context into MIDI. This
implementation is incomplete (see the TODO in performer-init.ly), but
at least it does not let the context structure go off the deep end in
MIDI.
David Kastrup [Sat, 16 Nov 2013 12:24:11 +0000 (13:24 +0100)]
Let a PITCH_IDENTIFIER optionally be followed by octave modifiers
This makes pitch identifiers more similar to note names. There is no
point in keeping the distinction just for triggering syntax errors
on music that has no sensible other interpretation.
"unpitched" simply means that this is rendered as a normal NoteEvent,
but the pitch information is missing and has to be filled in by some
other means. The example using RhythmicStaff is not actually
commendable as the MIDI rendition still requires a pitch or drum
type. It's just that as of this patch, there are no immediately
useful applications. The rhythmic shorthand { c4 4. 8 4 } is
introduced by a later patch.
David Kastrup [Tue, 5 Nov 2013 16:12:17 +0000 (17:12 +0100)]
Let #{ 4 #} be a duration while #{ 4 \cm #} stays a length
An UNSIGNED not followed by a NUMERIC_IDENTIFIER inside of #{ ... #}
is interpreted as a duration rather than a number. Also, inside
of #{ ... #} no "numeric expressions" using binary operators +-*/ are
interpreted.
The behavior of (signed and unsigned) integers and numeric expressions
in assignments and as function arguments rather than inside
of #{ ... #} is not affected.
David Kastrup [Sun, 3 Nov 2013 07:54:21 +0000 (08:54 +0100)]
Issue 3644: A \score-lines markup list command for multi-lines embedded scores
Originally requested as issue 1334.
Like the \score markup, \score-lines is not called through the normal
markup list command mechanisms as it would require something awkward
along the lines of
\score-lines ##{ \score { ... } #}
to get this through. Instead, a reserved word \score-lines in the
parser will manually call the command with an embedded score, leading
to just
\score-lines { ... }
This is somewhat clumsy in several ways: it requires an additional
reserved identifier (no other reserved identifier contains a dash),
and it means that a score may occur in a file without an explicit
enclosing \score command.
Nevertheless, the previous semantics implemented as issue 1334 were
not tenable: particularly after issue 3270 had been passed, it was
close to impossible for the average user to come up with a way of
getting an actual markup list from a score.
Note that there are as of yet no user-level commands spacing a markup
list in a way similar to the spacing inside of a \score markup.
David Kastrup [Sun, 3 Nov 2013 14:30:53 +0000 (15:30 +0100)]
Issue 3645: Allow \partial to occur in mid-piece
This is done by moving measurePosition to negative values when at the
beginning of a measure, and to a respective distance before the end of
the measure in case the measure has already been started.