On Monday 10 March 2008, Heikki Johannes Junes wrote:
> I have not so much paid attention on collision detection which have been
> developed with the LilyPond project lately.
Ah. I pay attention to what the PDF viewer shows, and don't normally worry
about the noise LilyPond sometimes makes. I don't care about the noise if
the end result is good. (We often produce a huge amount of noise if the
composition is of any complexity.)
> Maybe this rest direction syntax could be developed the way you started to
> develope it. It does not look so bad at all anymore :)
It wasn't working, because it was impossible to control. If it should ever
become necessary to go that route, it gets complicated. The \stemUp has to
come before a rest, but with the \stemUp coming from a separate event, it's
up to the user to position them in time so that the exporter finds and acts
on them in the correct sequence, and that is totally impossible to achieve
under some circumstances. So the only way we could realistically make that
work well is to give rests some new property to test, and make writing this
part of the rest processing code. That is not impossible, but consider that
rests are "negative space fillers" more than real events, and they tend to
lose properties at the drop of a hat. What would really be needed then, I
think, is some new kind of "hard rest" to carry these properties.
> I do not like height fine positioning to be used in place of actual rest
> positioning, because then the notation collision code may work with
> non-displaced rests.
I expect that our own collision avoidance code could just displace the rests
mechanically, rather than remaking rests with whole new sets of capabilities
that could have other properties to test against. If it just manipulated
DISPLACED_Y to shift the positions, the current export method would continue
to work seamlessly, which was the whole idea behind implementing it this way.
(Plus \stemUp or not, it is still the correct syntax to write rests this way.
Adding \stemUp would help LilyPond avoid having to try to resolve the
remaining collisions, but since it is able to resolve them successfully, I'm
not much worried about it.)
This is good enough for me. I'm trying to solve a specific problem first and
foremost, which is the three colliding rests at the end of the piano
tutorial. For the time being, it will be necessary for users to reposition
the rests by hand, but then they will export correctly. It is possible to
avoid the ugly result without hacking the exported LilyPond code, so I am
satisfied with that. (I solved the octave problem, and it works in all clefs
From here, I welcome anything else you or anyone else might do to make all of
this even better, but I am not open to anyone pronouncing that what I spent a
long weekend tormenting myself with is not good enough, or the wrong
approach. I'm glad you suggested an approach that could be made to work, so
don't flip on me now and start telling me the approach is wrong!
This (currently residing in the segment_overlaps branch) passes the very
specific test without breaking a handful of made up examples, and I'm more
than willing to run with that. My chief objective is to finish the piano
tutorial once and for all, and this rest business, plus a little time
signature fiddling, and it's really finished for all time, and Rosegarden
really produced the end result without any manual editing of the .ly file.
When I started that, I would have settled for having to wrap up with a few
edits to the .ly file, but I raised the bar along the way, and now it is
possible to avoid editing the .ly at all. I haven't finished the tutorial
because I'm waiting to get the new segment overlap handling cleaned up more
before I go back and start talking about that, but it is now possible to go
all the way to the finish line without cheating.
Let's not get so caught up in would have could have should have nonsense that
we lose sight of the real objective here. If you want to argue for the
\stemUp business after all, then find an example that can't be done without
it. That's how I want to continue from here, one real world example at a
time. This one is solved now, but the next one might break everything.
It usually does.
D. Michael McIntyre