Originally created by: *anonymous
Originally created by: *anonymous
Originally created by: gpermus@gmail.com
Originally owned by: dak@gnu.org
% the chords produce two noteheads; it would be nice if they % produced a single notehead. \new RhythmicStaff { \time 4/4 <c>2 <e>2 <c e g>2 <c e g>4 <c e g>4 }
Originally posted by: v.villenave
(Reproduced with 2.11.47) Yes indeed.
Originally posted by: reedmace...@gmail.com
Workaround: pass your music expression through a function that discards all notes but one from chords before putting it on a RhythmicStaff. Several such functions have been posted on the mailing list, for example:
For a variant that works with older versions check http://lists.gnu.org/archive/html/lilypond-user/2011-11/msg00196.html by Thomas Morley.
Originally posted by: p...@johannesrohrer.de
Make RhythmicStaff show single notes for chords (issue 185)
RhythmicStaff uses Pitch_squash_engraver to move all note heads to a
common vertical position. With chords, at least two problems arise:
(1) As all notes from one chord collide now, so some of them used to
be moved aside. Hence, for each chord, two adjacent note heads
would appear in the output.
(2) For chords with dotted duration, Dot_column_engraver would put one
dot per note head into a DotColumn, where they would be spaced
apart. So for every note in the chord, one separate dot would be
visible.
Solve (1) by explicitly setting X-offset to 0 for squashed note heads
in the Pitch_squash_engraver.
Solve (2) by replacing Dot_column_engraver with a new
Squashed_dot_column_engraver. This variant puts only at most one dot
per time step onto a DotColumn, and marks any further ones as
transparent.
Update regression test rhythmic-staff.ly to include two chords.
http://codereview.appspot.com/6495107
Related
Issues: #185
Originally posted by: p...@johannesrohrer.de
The doubled note heads can be merged by setting their X-offset to 0. Additionally, for chords with dotted duration, you have to get rid of all but one lenghtening dot, as they get spaced apart in their DotColumn.
Here is a kludgy patch that does both, the latter by implementing a simple new Squashed_dot_column_engraver:
http://codereview.appspot.com/6495107/
(This is my first work with the LilyPond source code, please review critically.)
With the patch, this works as intended:
Limitation: If you want to sqash multiple voices, you have to move the Squashed_dot_column_engraver to the Voice level. (You might want to do the same with the Pitch_squash_engraver anyway to define a separate squashedPosition for each.)
Originally posted by: dak@gnu.org
Wouldn't it make sense to let the Pitch_squash_engraver suicide all duplicate grobs at a time step? It would actually be even better if it could just kill the respective events before other engravers even get to see them. Also it would seem that only duplicates in the same Voice should be squashed. I find that with something like
there is already too much squashing going on, so we probably need to go into an entirely different direction.
Owner: gra...@percival-music.ca
Originally posted by: p...@johannesrohrer.de
Having the Pitch_squash_engraver do all the work would certainly be more user friendly, though this would deprive the engraver of its elegant simplicity.
As for squashing by voice, I would just have moved the engraver to the Voice level where needed. Forgive my ignorance (as mentioned, I am new to the LilyPond code): how can I elegantly differentiate by voice whithin the staff-level Pitch_squash_engraver? Can I read some grob property that tells me to what voice an object belongs?
Originally posted by: dak@gnu.org
Objects don't "belong" to voices. The correlation is not between object and context-specific engraver instance, but between announcement and context-specific engraver instance. If you don't listen at Voice-level, there is no Voice-level correlation.
It turns out that collision avoidance is not actually done at Voice-level: my example looks fine by just adding
Obviously, this will acerbate the problem of this issue.
Maybe we need an engraver listening to Stems and shooting all NoteHeads except the first per stem. This should take place before collision resolution.
Cc: p...@johannesrohrer.de
Originally posted by: dak@gnu.org
Regarding comment #7: I forgot that an acknowledger is called not just with a grob but also with the originating engraver instance announcing the grob, and so one can indeed figure out the originating context of an announcement if the grob is produced from a Voice-level engraver instance.
Originally posted by: p...@johannesrohrer.de
Interesting. Adding
Collision_engraver
andRest_collision_engraver
to the RhythmicStaff group might be worthwile independently of fixing this issue.(It does not even play too badly with my kludge:
works as intended. Not really elegant, admittedly.)
About listening to Stems to get a handle on notes belonging to the same chord: would that work reliably even for notes with no visible stems, like whole notes?
Originally posted by: dak@gnu.org
This is actually causing a problem for issue 3648 now.
Labels: -Type-Enhancement -Priority-Low Type-Defect
Related
Issues:
#3648Originally posted by: dak@gnu.org
Regarding comment #9: as far as I know, whole notes have Stem grobs just like other notes do. That does not mean that the Stem is necessarily the "correct" construct to go by and the question is whether one can indeed kill off all spurious noteheads before they influence spacing, but I don't know of anything more appropriate right now.
Originally posted by: dak@gnu.org
Issue 185: Remove Pitch_squash_engraver
Actually, this issue is called "RhythmicStaff squishing chords should
produce single notes" and that's one thing that it does. But in the
course of it, it completely replaces the Pitch_squash_engraver since
the Note_heads_engraver has to look at squashedPosition anyway in
order to decide how many note events to handle.
Articulations and fingerings on spurious noteheads get lost when
squashing. It would be conceivable to transfer them to the remaining
note event, but it's not clear that this would not cause problems of
its own.
Contains convert-ly rules as well.
Additional commits:
Perfunctorily remove bad links to Pitch_squash_engraver in translations
A few documentation fixes after removing Pitch_squash_engraver
Run scripts/auxiliar/update-with-convert-ly.sh
http://codereview.appspot.com/35080044
Labels: Patch-new
Owner: dak@gnu.org
Status: Started
Related
Issues: #185
Originally posted by: dak@gnu.org
Patchy the autobot says: passes tests.
Labels: -Patch-new Patch-review
Originally posted by: pkx1...@gmail.com
just to a full make doc (because I can) ;)
Labels: -Patch-review Patch-new
Originally posted by: pkx1...@gmail.com
Patchy the autobot says: passes make, make check and a full make doc.
Labels: -Patch-new Patch-review
Originally posted by: dak@gnu.org
At least the Completion_heads_engraver would need changing as well.
Labels: -Patch-review Patch-needs_work
Originally posted by: dak@gnu.org
Regarding #2: there is
commit [rec5fd52f03ae1abe8de998e8b3ab27f12443805b]
Author: David Kastrup <dak@gnu.org>
Date: Wed Dec 4 10:00:38 2013 +0100
Implement event-chord-reduce for reducing chords to single notes
which should do the "chord reduction" piece of work pretty thoroughly. It won't do anything about parallel music, though.
I think it would make sense to generally provide a user-level command for doing that: it seems like a straightforward operation with possibly other uses that would be easy to apply manually. We just need a good name. \thinout seems too vague.
\unChord maybe?
Diff: