[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Solving Issue 185 "RhythmicStaff squishing chords should produce single
From: |
Johannes Rohrer |
Subject: |
Solving Issue 185 "RhythmicStaff squishing chords should produce single notes" |
Date: |
Sat, 08 Sep 2012 15:42:38 +0200 |
User-agent: |
KMail/4.8.4 (Linux/3.2.0-30-generic; KDE/4.8.4; x86_64; ; ) |
This is a follow-up on a discussion from the issue tracker comments at
<http://code.google.com/p/lilypond/issues/detail?id=185>,
where I suggested a kludgy fix for a favorite LilyPond pet peeve of
mine. I am interested in making it less kludgy. As I am new to the
LilyPond codebase, please bear with some ignorance.
Some context:
My original proposal
<http://codereview.appspot.com/6495107>
> 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.
* address@hidden comprehensibly suggested instead:
> 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.
and later
> Maybe we need an engraver listening to Stems and shooting all
> NoteHeads except the first per stem. This should take place before
> collision resolution.
but I fail to find an exploitable connection between stems and chords.
As far as I understand, Stems are grouped with note heads into
NoteColumns by Rhythmic_column_engraver only, which operates at Voice
level, hence too late.
Judging from this engraver, it looks to me like one could implement a
"Chord_thinout_engraver" at Voice level simply by acknowledging
rhythmic_heads and killing all but the first per timestep. But I need
this functionality at Staff level.
(One could include such an engraver into all Voice contexts, but trigger
it with a Staff-level property. Sounds kludgy again.)
So far, the most viable route to me seems to make use of this
> ...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.
to write a Staff-level "Chord_thinout_engraver" that still works per
voice. Is that the way to go? Other ideas?
Best regards,
Johannes Rohrer
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Solving Issue 185 "RhythmicStaff squishing chords should produce single notes",
Johannes Rohrer <=