LilyIssues / Issues / #185 RhythmicStaff squishing chords should produce single notes

Google Importer - 2008-05-30

Originally posted by: v.villenave

(Reproduced with 2.11.47) Yes indeed.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2012-07-20

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:

% by David Kastrup thinout = #(define-music-function (parser location music) (ly:music?) (for-some-music (lambda (m) (and (music-is-of-type? m 'event-chord) (let ((elts (ly:music-property m 'elements))) (if (pair? elts) (set-cdr! elts (filter! (lambda (m) (not (ly:music-property m 'duration #f))) (cdr elts)))) #t))) music) music) \new RhythmicStaff \thinout \relative c { <d, g d'>4 e f8 g a4 <d b g>2. c4 d4. e8 f4 g }

For a variant that works with older versions check http://lists.gnu.org/archive/html/lilypond-user/2011-11/msg00196.html by Thomas Morley.

Last edit: Simon Albrecht 2015-09-15
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2012-09-08

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~~

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2012-09-08

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:

\new RhythmicStaff { <c es g>4. <c e>8( <cis eis>16 <d f>-> e) r \times 2/3 { <c e>8 c c } }

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.)

Last edit: Simon Albrecht 2015-09-15

issue185-patched.png
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2012-09-08

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

mus = { << { d d } \\ d2 >> d4 d } \relative c' << \new Staff \mus \new RhythmicStaff \mus >>

there is already too much squashing going on, so we probably need to go into an entirely different direction.

Owner: gra...@percival-music.ca

Last edit: Simon Albrecht 2015-09-15
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2012-09-08

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?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2012-09-08

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

\layout { \context { \RhythmicStaff \consists "Collision_engraver" \consists "Rest_collision_engraver" } }

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

Last edit: Simon Albrecht 2015-09-15
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2012-09-08

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.

Last edit: Simon Albrecht 2015-09-15

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2012-09-08

Originally posted by: p...@johannesrohrer.de

Interesting. Adding Collision_engraver and Rest_collision_engraver to the RhythmicStaff group might be worthwile independently of fixing this issue.

(It does not even play too badly with my kludge:

\new RhythmicStaff \with { \consists "Collision_engraver" \consists "Rest_collision_engraver" \remove "Squashed_dot_column_engraver" } << \new Voice \with { \consists "Squashed_dot_column_engraver" }{ \voiceOne <c es g>4. <c e gis>8( <cis eis gis>16 <d e g>-> e) r \times 2/3 { <c e>8 c c } } \new Voice \with { \consists "Squashed_dot_column_engraver" }{ \voiceTwo c,8-> c4 <cis, cis>4. c4 } >>

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?

Last edit: Simon Albrecht 2015-09-15

issue185-2v.png
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2013-11-12

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: ~~#3648~~

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2013-11-12

Originally 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.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2013-11-29

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~~

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2013-11-29

Originally posted by: dak@gnu.org

Patchy the autobot says: passes tests.

Labels: -Patch-new Patch-review

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2013-11-29

Originally posted by: pkx1...@gmail.com

just to a full make doc (because I can) ;)

Labels: -Patch-review Patch-new

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2013-11-29

Originally posted by: pkx1...@gmail.com

Patchy the autobot says: passes make, make check and a full make doc.

Labels: -Patch-new Patch-review

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2013-11-30

Originally posted by: dak@gnu.org

At least the Completion_heads_engraver would need changing as well.

Labels: -Patch-review Patch-needs_work

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Google Importer - 2014-09-03

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?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Description has changed:

Diff:

--- old
+++ new
@@ -3,14 +3,17 @@
 *Originally created by:* [gpermus@gmail.com](http://code.google.com/u/gpermus@gmail.com/)
 *Originally owned by:* [dak@gnu.org](http://code.google.com/u/dak@gnu.org/)

+~~~~
+:::TeX
 % the chords produce two noteheads; it would be nice if they
 % produced a single notehead.

-\new RhythmicStaff \{
-&nbsp;&nbsp;&nbsp;&nbsp; \time 4/4
-&nbsp;&nbsp;&nbsp;&nbsp; &lt;c&gt;2
-&nbsp;&nbsp;&nbsp;&nbsp; &lt;e&gt;2
-&nbsp;&nbsp;&nbsp;&nbsp; &lt;c e g&gt;2
-&nbsp;&nbsp;&nbsp;&nbsp; &lt;c e g&gt;4
-&nbsp;&nbsp;&nbsp;&nbsp; &lt;c e g&gt;4
-\}
+\new RhythmicStaff {
+  \time 4/4
+  <c>2
+  <e>2
+  <c e g>2
+  <c e g>4
+  <c e g>4
+}
+~~~~

Needs: -->

Trevor Daniels - 2015-10-31

assigned_to: David Kastrup
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Trevor Daniels - 2017-01-16

It seems a shame not to finish off this issue. All it needs is a decision on the name for the user-level command to invoke the event-chord-reduce music function implemented over a year ago by David K, which reduces chords to single notes. I'd favour \reduceChord rather than \unChord. Any other suggestions?

Trevor

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Simon Albrecht - 2017-01-16

\reduceChord seems good to me. However, it would still be good to have this enabled by default, which of course is non-trivial with a music function. Maybe we could wrap event-chord-reduce into another music function, which operates only on music in a RhythmicStaff, and add that to toplevel-music-functions?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Trevor Daniels - 2017-01-16
  
  I'm not sure about enabling it by default, because it fails with parallel music. This can easily be explained if it is a user-level function, and the user can then choose whether to invoke it or not depending on his use case. If it is not appropriate the user can try a different approach.
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Trevor Daniels - 2017-01-19

Issue 185 Squishing chords

Add a user-level interface to the event-chord-reduce function.

Document its use for squishing chords in music being used to
provide the rhythms to RhythmicStaff and the Pitch_squash_engraver.

http://codereview.appspot.com/318300043

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Trevor Daniels - 2017-01-19

assigned_to: David Kastrup --> Trevor Daniels

Needs: -->

Type: -->
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2017-01-20

Patch: new --> review

Type: --> Enhancement
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

RhythmicStaff squishing chords should produce single notes

Issue Tracker for LilyPond

Searches

Help

#185 RhythmicStaff squishing chords should produce single notes

Related

Discussion

Related

Related

Related