http://codereview.appspot.com/6248080/diff/23001/Documentation/notation/simultaneous.itely File Documentation/notation/simultaneous.itely (right):
http://codereview.appspot.com/6248080/diff/23001/Documentation/notation/simultaneous.itely#newcode94 Documentation/notation/simultaneous.itely:94: \repeat unfold 4 { c4 e } c1\f On 2012/06/02 19:29:26, Keith wrote:
That example gives me a headache.
Compared to yours? Your proposal was a compressed bunch of symbol shortcuts, the kind that is controversal. You now introduce a complication "if the crescendo should end on the last note" that nobody has asked for and give an example using simultaneous music which is going to be introduced later in the notation manual. Then you come back with "s1*0 will work just fine:". I don't know how often I have to repeat myself: this patch is not supposed to replace s1*0 with <>. It is supposed to introduce and explain <> at a basic level and put it into context with << >> which also has been explained insufficiently so far. If you are unable to focus on anything but s1*0, I'll need to create a separate issue for discussing this patch, even though getting a sane explanation for <> and <<>> is part of paving the ground for tackling 2522, by making it possible to exchange a suggestion of one reasonably documented behavior with a different reasonably documented behavior. Because whatever choice we make, it should not be based on wanting to hide the undocumented truth. The truth is that there are cases where s1*0 works just as well as <>, and others where it doesn't. I will not construct more contrived examples just to be able to make a better case for <> instead of s1*0. That's a separate issue. http://codereview.appspot.com/6248080/ _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
