David Kastrup [Thu, 21 Jul 2016 09:51:44 +0000 (11:51 +0200)]
Issue 4941/1: Optional fraction after \afterGrace command
\afterGrace had its fraction determining the position of the aftergrace
notes hardwired to be read from the parser variable afterGraceFraction.
This change here allows for optionally specifying it right as the first
argument of the \afterGrace command.
Issue 4938 (2/3) Refactor handling of MIDI control changes
Handle the MIDI control value initialization from context properties
(Staff_performer::new_audio_staff), control value changes
(Midi_control_function_performer::announce_function_value_change), and
value conversion for output
(Midi_control_function_value_change::to_string) in the new
Midi_control_change_announcer class.
All MIDI control changes are now encoded using
{Audio,Midi}_control_change items. This change makes the old
{Audio,Midi}_control_function_value_change classes obsolete.
When optimizing, GCC now assumes the this pointer can never be null,
which is guaranteed by the language rules. Invalid programs which
assume it is OK to invoke a member function through a null
pointer (possibly relying on checks like this != NULL) may crash or
otherwise fail at run time if null pointer checks are optimized
away. With the -Wnull-dereference option the compiler tries to warn
when it detects such invalid code.
If the program cannot be fixed to remove the undefined behavior then
the option -fno-delete-null-pointer-checks can be used to disable
this optimization. That option also disables other optimizations
involving pointers, not only those involving this.
As a consequence, we cannot call a member function on a prospective null
pointer (which actually is a bad idea for a number of other reasons,
like when anything tries accessing the vtable) and then try sorting out
the condition in the routine itself.
This problem was first observed with Fedora 24. The Ubuntu GCC6
prerelease does not show this problem; presumably the respective
optimization has been disabled in the Ubuntu/Debian packaging because of
affecting other programs.
Commit-message-by: David Kastrup <dak@gnu.org> Signed-off-by: David Kastrup <dak@gnu.org>
David Kastrup [Mon, 4 Jul 2016 08:08:41 +0000 (10:08 +0200)]
Issue 4917: Remove some set_location calls from parser
Older versions of Bison (current is 3.0.4) had problems assigning
location data to rules with empty production, possibly related to the
definition of YYLLOCA_DEFAULT when N is zero.
This lead to several workarounds in the code base. A number of them
dropped through the floor in the course of refactoring without
apparent problem, and the original problem does not appear to be
reproducible with the current versions of Bison.
This removes the remaining instances. Should the original problem
reoccur at some point of time (or with some versions of Bison), it
would be noticeable as bad point-and-click messages and/or error
messages with bad location data.
Issue 4907: Midi_walker::do_start_note: skip ignored notes in stop_note_queue
For each semitone pitch value, stop_note_queue is likely supposed to
contain at most one Midi_note event with its "ignore_" flag set to
false, and the comparisons between notes of equal semitone pitch to be
always done between the input note and this unique queued note that is
not (yet) being ignored.
If notes which are already being ignored are not skipped in the loop,
the task of raising the "ignore_" flags for note events of equal
semitone pitch (overlapping in time) which stop before the maximum
stopping time of these notes may, due to breaking out of the loop,
fail to work if the queue grows to contain three or more notes of equal
semitone pitch, leading to the emission of premature "note off" events
for this pitch, as demonstrated, for example, in
<http://lists.gnu.org/archive/html/bug-lilypond/2016-06/msg00042.html>.
David Kastrup [Sat, 2 Jul 2016 23:40:04 +0000 (01:40 +0200)]
Issue 4914/2: convert-ly rule for removing Output_property_engraver
It's highly unlikely that users will redefine the Score context from
scratch, so the convert-ly rule just removes every occurence of
Output_property_engraver from user source. Obviously, when running the
rule on the LilyPond code base, we will need to fix up the Score
engraver manually to retain the Output_property_engraver .
David Kastrup [Sat, 2 Jul 2016 23:37:15 +0000 (01:37 +0200)]
Issue 4914/1: Move Output_property_engraver to Score level
This has the advantage of needing only one instantiation of the engraver
and not having \applyOutput mysteriously refrain from having an effect
in contexts without Output_property_engraver .
Due to the hierarchical nature of acknowledgers, acknowledgers in lower
contexts will now get to see the grobs before applyOutput has done its
work. However, grobs are still unfinished (except for type, properties
initialized via context properties and cause) at the time they are
announced, with other details only getting filled in by the engraver
after announcement, so the potential for trouble seems low.
Acknowledgers should usually just register a grob (or write grob data)
with any actual reading of grob data occurring at the end of the
timestep instead or in the process-acknowledged phase.
David Kastrup [Thu, 30 Jun 2016 15:26:01 +0000 (17:26 +0200)]
Issue 4911/3: Don't treat context modification identifiers special
This requires using \with before context modifications like
\RemoveEmptyStaves in order to make the syntax get along
with fewer special cases and exceptions.
John Gourlay [Thu, 23 Jun 2016 19:49:25 +0000 (15:49 -0400)]
Reimplement issue 4781 for musicxml2ly more literally. Reimplementation
was necessary as part of the implementation of issue 4751, but some of
the code changes for 4781 were omitted. This reproduces all the 4781 changes.
David Kastrup [Sat, 2 Jul 2016 08:08:42 +0000 (10:08 +0200)]
Issue 4912: Fix output definition use in \book and \bookpart
The only explicit output definition blocks allowed in \book and
\bookpart blocks were paper blocks. Output definitions supplied with
Scheme expressions were erroneously interpreted like global output
definitions, accepting all output definition types and overriding the
global defaults with them.
Now the only output definitions accepted as Scheme expressions are
paper blocks. As opposed to previously, they actually set the paper
block of the respective book or bookpart.
Masamichi Hosoda [Sun, 26 Jun 2016 03:15:33 +0000 (12:15 +0900)]
Issue 4876/5: Add direct parsing CFF for getting Postscript font name
FreeType 2.6 and 2.6.1 cannot get PS name from pure-CFF.
(FreeType 2.5.5 and earlier does not have this issue.
FreeType 2.6.2+ has this bug fixed.)
So we need direct parsing of the 'CFF' table, in this case.
Masamichi Hosoda [Sat, 25 Jun 2016 01:52:44 +0000 (10:52 +0900)]
Issue 4876/1: Add fontname replacing function for CFF (OTF/OTC) fonts
For CFF (OTF/OTC) fonts,
FT_Get_Postscript_Name ()
in FreeType 2.6+ gets the name in 'name' table.
However, we want the name in 'CFF' table instead of in 'name' table
because output postscript file is embedded only 'CFF' table of the font.
They are inconsistent for some OpenType/CFF Collection fonts (OTC).
This function can get the name in 'CFF' table.
TODO: Check conflicts between fonts which have same name in 'CFF' table
but different name in 'name' table.
projects / lilypond.git / log