Han-Wen wrote: "You want a command that changes the input, and not
the process of converting the input to symbols."
I think that what we want for note head shapes etc. is indeed to
change the process of converting to symbols, in other words,
something that is totally consistent with Lily's current use of
property. Let me try another way of putting it:
A property Staff.x has a value while you read the resulting sheet
music from start to end within one staff context. A complete sheet of
music can have many staffs, so property Staff.x applies only within
the staff for which it is specified - other staves go on
independently. For example, changing the clef of a fiddle part does
not affect the clef used for the parallel horn part. Ditto for key
signatures and many other details.
A property Voice.y applies only within one voice - several voices can
exist on one staff, but they can be beamed differently without one
affecting the others - or the note shapes, stem directions etc. can
be changed for one without affecting parallel voices, whether they
are on the same staff or not.
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.
The whole idea of property inheritance is, that if a specific Voice.y
is to apply to all voices on a staff, then that property y can be
specified at the staff level, so it will be inherited by all voices
on that staff, but not by voices on other staves on the same piece of
paper. Thus, Lily's defaults are simply a top-level set of
properties, staff.x, voice.y, note.z etc., so that Lily starts with
those values, then they are changed within the appropriate contexts
by the Mudela code.
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?
John
