On Fri, Mar 8, 2013, at 09:06 AM, David Kastrup wrote: > Robert Schmaus <robert.schm...@web.de> writes: > > > Hi everyone, > > > > I haven't read all posts on this subject, so sorry should I write > > something that's already been written. > > Why not keep the \relative <pitch> { <music> } syntax as one supported > > way and simply change the \relative { <music> } syntax to what David > > proposed? > > Uh, that was the plan anyway. The question was rather whether we should > convert to using the second form preferably in documentation and > examples.
Oh, sorry, I interpreted your remark from an earlier mail ("But when upgrading, convert-ly will convert it to the form without explicit pitch if it can.") in that way, that the \relative <pitch> { <music> } is planned to disappear ultimately. > > I myself have always only used the first version (I didn't even know > > the other existed, to be honest), and I liked the idea of having a > > lever outside the music that shifted the music ocave-wise. > > \transpose c c'' is such a lever. I have thought of that too - it's just that transposition for me is something I'd apply to a complete score in concert pitch e.g. to produce a music sheet for Bb instruments. Something that comes after the actual music writing process - in my understanding anyway. Of course, one can use any command in lilypond however one sees fit ... > > Or, as an alternative, the \relative { <music> } syntax could rely on > > music that was written *before* the relative block. > > That one is not an actual alternative. > > xxx = \relative { c d e f g } > yyy = \relative { c d e f g } > > \new Voice { \yyy \xxx } > > Now what is the music "written before the relative block"? The whole > point of \relative is that it returns absolute music given relative > music. You propose it should return relative music given relative > music. But how would music then become absolute? It would, if there's either a default (pitch) for \relative { ... } with no music before it. Or if the compiler gives an error if a user were to write something like your example. After all, it's always up to the typesetter to write something that makes sense. > Making this proposal work in a sensible and predictable > manner would be quite harder than it might appear. There are probably not many persons who would know this better than you do ... and I don't think that any of what lilypond can produce is quite as easy as it appears! Each time I use it, I am amazed by something new! Best, Robert _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user