Menu
▾
▴
#4093 put NullVoice in Staff by default
Originally created by: *anonymous
Originally created by: k-ohara5...@oco.net
Originally owned by: k-ohara5...@oco.net
NullVoice is called a Voice, so people might expect it to be inside a Staff.
One use of NullVoice was to print solfege numbers in vocal music (where \partcombine was used to merge voices, but the original voices were needed for the solfege).
This needed NullVoice to be in the Staff
1) so the numbers go around that staff, and
2) to reference the key signature in the Staff.
(LilyPond allows different Staves to have different keys, for horns, percussion, transposing instruments,etc.)
The workaround is \context {\Staff \accepts NullVoice }
when needed, and maybe that is the correct permanent solution,
Originally posted by: k-ohara5...@oco.net
The bug report
<http://lists.gnu.org/archive/html/lilypond-user/2014-09/msg00026.html>
Originally posted by: pkx1...@gmail.com
Passes make, make check and a full make doc but the reg tests are full of programming errors.
--snip--
input/regression/lyric-combine-nullvoice.log
@@ -3,6 +3,46 @@
Renaming input to: `/tmp/lilypond-autobuild/input/regression/lyric-combine-nullvoice.ly'
Interpreting music...
Preprocessing graphical objects...
+programming error: Grob `NoteHead' has no interface for property `duration-log'
+continuing, cross fingers
..
input/regression/music-function-post-event.log
@@ -13,3 +13,8 @@
Writing ./music-function-post-event-systems.tex...
Writing ./music-function-post-event-systems.count...
Writing timing to music-function-post-event.profile...
+programming error: Parsed object should be dead: #<Music function #<procedure #f (parser location text)>>
+continuing, cross fingers
+programming error: Parsed object should be dead: #<Prob: Music C++: Music((void . #t))((name . Music) (types general-music)) >
+
+continuing, cross fingers
...
Writing ./optional-args-predicate-systems.tex...
Writing ./optional-args-predicate-systems.count...
Writing timing to optional-args-predicate.profile...
+programming error: Parsed object should be dead: #<Music function #<procedure #f (parser location str int frac exp)>>
+continuing, cross fingers
+programming error: Parsed object should be dead: #<Prob: Music C++: Music((origin . #<location /tmp/build-lilypond-autobuild/out/share/lilypond/current/ly/script-init.ly:62:11>) (articulation-type . varcoda))((display-methods #<procedure #f (event parser)>) (name . ArticulationEvent) (types general-music post-event event articulation-event script-event)) >
+
+continuing, cross fingers
...
input/regression/augmentum.log
@@ -13,3 +13,7 @@
Writing ./augmentum-systems.tex...
Writing ./augmentum-systems.count...
Writing timing to augmentum.profile...
+programming error: Parsed object should be dead: #<Context_def VaticanaStaff /tmp/build-lilypond-autobuild/out/share/lilypond/current/ly/gregorian.ly:227:5>
+continuing, cross fingers
+programming error: Parsed object should be dead: #<Music function #<procedure #f (parser location music)>>
+continuing, cross fingers
...
etc.
Labels: -Patch-new Patch-needs_work
Originally posted by: dak@gnu.org
I have no idea why a month-old patch has been resubmitted as a new issue, but can we please take the regtest suite breaking down as a sign that my repeated statements in that patch review that messing up static grob internals in the middle of a context definition is a really bad idea?
Even if subsequent patch amendments will be able to paper over the load of rather scary problems now seeping out in the tests, there is a reason for the scope of those problems. This is messing with stuff that has not been designed for being messed with.
Originally posted by: k-ohara5...@oco.net
The code in the tested patch is the same as the first tested patch for issue 3825 (and 3834 and 3874).
We didn't see the "no interface" error back then because it is triggered only by the reg-test added with the patch for issue 3825, and it is only reported with debug switches on the command line.
I reproduced the "no interface" error, and added that interface to the list and got a clean make check. I cannot reproduce the "should be dead" errors.
NullVoice was in Staff in version 2.18, and I guess more people used in in surprising ways. I'll look for less-scary way to prevent NullVoice from interacting with the bookkeeping for accidentals.
Originally posted by: dak@gnu.org
And I protested against that patch even then.
To accommodate this properly might necessitate changes in C++. As a rule of thumb, take the first naive approach of trying to get the desired functionality and then "make it so that it works" by changing fundamentally what kept it from working. We don't want to implement things by poking around in internals. If the internals don't fit, we either need to change them outright, or provide clean knobs for adapting their behavior. Providing knobs is the worse alternative of the two since it means the user has to chose between useful functionalities rather than have all.
Originally posted by: dak@gnu.org
Ok, here is an excerpt from scm/define-context-properties.scm:
(melismaBusyProperties ,list? "A list of properties (symbols) to
determine whether a melisma is playing. Setting this property will
influence how lyrics are aligned to notes. For example, if set to
@code{'(melismaBusy beamMelismaBusy)}, only manual melismata and
manual beams are considered. Possible values include
@code{melismaBusy}, @code{slurMelismaBusy}, @code{tieMelismaBusy}, and
@code{beamMelismaBusy}.")
Now this just cries for a melismaBusyTranslator that listens to slur, tie (and note), and beam events and sets the respective busy flags. Obviously, this translator can work perfectly fine in either Midi or Layout. Equally obviously, it does not require _any_ grob to pass by in order to do its actions.
So with that translator, we can just remove all the grob-producing engravers and have things work fine in NullVoice.
Also we get the same melismata in Midi and Layout without effort.
That's so much less fickle than trying to produce grobs that can then be almost but not quite be ignored.
Originally posted by: dak@gnu.org
Regarding comment #6: I'll try casting this translator into code.
Originally posted by: k-ohara5...@oco.net
A melismaBusyTranslator would be a nice way to implement NullVoice. To make it work as well as the current unprinted note-heads we might need the patch for issue 3299, so that Lyrics are properly aligned when a NullVoice inserts a column where no other voice has notes.
However, a melismaBusyTranslator would not seem to allow the solfege-engraver to function, because it has no note-heads from which to find pitches. The failure of the solfege-engraver (comment #2) was the source of this bug report.
Originally posted by: k-ohara5...@oco.net
A less-scary way to make NullVoice work completely within a Staff context
http://codereview.appspot.com/117050043/
Labels: -Patch-needs_work Patch-new
Originally posted by: dak@gnu.org
Patchy the autobot says: passes tests.
Labels: -Patch-new Patch-review
Originally posted by: pkx1...@gmail.com
Patchy the autobot says: passes tests. includes a full make doc
Originally posted by: pkx1...@gmail.com
Patch on countdown for Nov 23rd
Labels: -Patch-review Patch-countdown
Originally posted by: pkx1...@gmail.com
Patch counted down - please push
Labels: -Patch-countdown Patch-push
Originally posted by: k-ohara5...@oco.net
commit [r03b5368b31bed546689477110ecff2aaf800c1c9]
Labels: -Patch-push Fixed2_19_16
Status: Fixed
Originally posted by: tdanielsmusic
(No comment was entered for this change.)
Labels: -Fixed2_19_16 Fixed_2_19_16
Originally posted by: k-ohara5...@oco.net
the bug report linked in comment 2 works
Status: Verified