lilypond-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]