On 5/7/10 8:29 AM, "David Kastrup" <d...@gnu.org> wrote: > Carl Sorensen <c_soren...@byu.edu> writes: > >> 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?
No -- it just ignores the collision. > >> 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? I don't have any ideas why it would be a bad idea. I'd be happy to have the behavior you describe. The reason it doesn't work now is that \glissando inside a chord construct creates an articulation, while \glissando outside a chord construct creates a separate event. For me, it was much easier to create a music function than to dive in and do the repairs necessary to get to the state you describe. So I did it. I appreciate your consistent questioning as to how we might be able to get LilyPond to behave in a way that seems consistent with our expectations. I wish I had the time to understand the internals of parsing better so I could contribute more in this area. But I don't, so I do the best I can with the time I have. Thanks, Carl _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
