Carl Sorensen <[email protected]> writes: > On 5/7/10 7:21 AM, "David Kastrup" <[email protected]> wrote: >> >> Hi, how would I do something like the following _properly_: >> >> { \clef bass << >> { <e gis b>\glissando s4 <dis a b>4 } >> \new Voice { \hideNotes <gis b e>\glissando s4 <a b dis>4 } >> \new Voice { \hideNotes <b e gis>\glissando s4 <b dis a>4 } >>>> >> } >> >> Note that this has several deficiencies: We get clashing notecolumn >> warnings, and the s4 that is required for proper length glissando lines >> takes musical time. The obvious solution, writing s4*0 instead, does >> not change the spacing at all! > > Have you looked at > <http://thread.gmane.org/gmane.comp.gnu.lilypond.general/56071/focus=56151>
Just right now, after a pointer from Kieren. > I recognize that it takes a different tack than you want, because it only > goes note for note instead of chord for chord. But it shows the way to get > the spacing you want and to avoid the clashing note columns. > > \once \override Glissando #'minimum-length = #5 > \once \override Glissando #'springs-and-rods = > #ly:spanner::set-spacing-rods > > is the way to get the spacing. Ok, that helps. Not sure I understand this, though. > To avoid the clashing note columns, you could do > > \override NoteColumn #'ignore-collision = ##t > > before your function, and > > \revert NoteColumn #'ignore-collision > > after the function. This does not change the composition of the chord? > It would be pretty simple for you to adjust the inner workings of > chord-glissando.ly to make it work by rotating the chord, rather than > by carving out individual notes. Well, looks like a fair piece of work. And if one invests all this work... I guess it would be nicer if one could write <c\glissando e\glissando g\glissando> <d e f> and notes got matched one by one. And possibly let <c e g>\glissando be the same as that spelled-out first chord. Putting aside the obvious "patches will be thoughtfully considered" to a later point of time, anybody with a hunch why this would be a bad idea and/or terribly complicated to implement and/or leading to a lot of unpredictable behavior? Thanks, -- David Kastrup _______________________________________________ lilypond-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/lilypond-devel
