[EMAIL PROTECTED] writes:
> A property Note.z would apply only to a single note within a voice -
> several notes could exist within one voice, but if the note head
> shape or size z was changed for one note, it would not affect
> parallel notes, whether in the same voice, or staff, or not.
But how would you identify to which note your Note.z refers? For
example you have
< c4
\property Note.style = "diamond"
g4 >
Which note gets the diamond style? Remember: \properties are not
coupled to the input, so you can't say "the g because \property is
before g". If you don't believe me, try explaining what this should
do:
< \context Voice = va { < c4 g > }
\context Voice = vb { < d f > }
\context Voice = va { \property Note.style = diamond }
>
My previous suggestion (with ThreadContext) extends the
Score > Staff > Voice
hierarchy with ThreadContext, so you get
Score > Staff > Voice > Thread
The note heads live at Thread level, and by explicitly selecting which
Thread context each note goes in, you can set the note head style.
Example:
\context Voice <
\context Thread = TA c4
\context Thread = TB g4
\context Thread = TA \property Thread.noteheadStyle = diamond
>
The noteheadStyle is applied to the Thread called TA. Since the c4 is
only note in TA, only the c gets the diamond style. I think this what
you suggest in your mail (with the name Note in stead of Thread).
But--as you can see-- identifying which property goes to which note is
complicated.
I think I will reinstall Thread soon (It won't make things more
difficult, it should be backwards compatible), because it also makes
sense for fingering instructions.
But what you really want, (I think), is a mechanism that says:
\withstyle X someMusic
typeset whatever results from someMusic with style X
for example (hypothetical syntax)
< \withstyle Note = diamond c4
g4
e4
b4
>
this would typeset every note in default style except the c. I am
still thinking about this, because I think that implementing this
would give a large overhead: I am afraid the program might get a lot
slower.
> Does this help explain why I think we are asking for nothing new in
> the concept of property, but merely a clarification of the scope of
> properties as Lily uses them now?
In summary: what you want is already there but, it is not shipped by
default. But I think the mechanism is not good enough.
--
Han-Wen Nienhuys, [EMAIL PROTECTED] ** GNU LilyPond - The Music Typesetter
http://www.cs.uu.nl/people/hanwen/lilypond/index.html
