"Br. Samuel Springuel" <rpspring...@gmail.com> writes: > I'm not a heavy user, so take my thoughts with whatever grain of salt > you want, but this is how I would naively expect these constructs to > work: > > << \\ \\ \\ >> > The voices would be entered in order from top to bottom. In this way > the physical structure of the code would resemble the structure of the > music I'm entering (thanks to line breaks in the code between the > voices). > > \voiceOne \voiceTwo \voiceThree \voiceFour > The numbers here are confusing. They could be a top-down enumeration > of the voices or a more musical outside to inside pattern. Further, > the fact that they don't match up with the 1/2/3/4 numbers of the > implicit code above is even more confusing. If we stick with numbers, > then numbers should match. However it would probably better if we got > away from numbers altogether here. Kieren's suggestion of \voiceUp.1 > and \voiceDown.1 seems somewhat more natural, but the numbers still > have the potential for confusion. I do not know how to solve this (if > it's solvable).
That's why I wanted to use something more akin to directions. > Finally, as a coder I always favor a phased process for changes to the > user interface so that people have time to adapt to the change. A > flag which can flip between the new and old behavior is definitely in > order until 3.0.0 comes out. Yes, something like this will be provided for << \\ \\ \\ >> but there is nothing that can help with \voiceOne/\voiceTwo/\voiceThree/\voiceFour since those work without context. So I'd rather phase out those name choices for something nicer. > I'd default the flag to the old behavior while the new one is being > worked on and then default it to the new behavior once a stable state > has been reached. I don't see that "the new one" will be worked on for any significant amount of time. The change is not involved. Its implications aren't. Without a rather good track record of convert-ly on LilyPond's code base, this change is not going to go through. Most convert-ly rules are "robust" in that you can run them multiple times and only the first application will cause a change. Also the syntax without convert-ly run tends to be bad, causing errors. Neither will be the case here, so that is going to end up a bit of a support headache for a while. On the plus side, \\ is rarely used for more than two voices, or if it is, the voice settings tend to get overridden manually. In which case a conversion does not need to do much. I think that a convert-ly rule should likely not change the order of entered voices but should just add a command for "flipping the flag" instead if more than two \\-separated voices are detected without explicit voice setting commands. -- David Kastrup _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user