Re: music function semantics

[David Kastrup]

Jan Warchoł <address@hidden> writes:

> David,
>
> 2011/7/27 David Kastrup <address@hidden>:
>> Neil Puttock <address@hidden> writes:
>>
>>> On 26 July 2011 22:41, David Kastrup <address@hidden> wrote:
>>>
>>>> So the question basically is: which of those mechanisms is actually
>>>> being in use?  Are there examples for existing music functions
>>>> interpreting a postevent or a chord constituent?
>>>
>>> \tweak would be the most common usage for both of these cases:
>>>
>>> c1-\tweak #'color #red -\fermata
>>>
>>> and
>>>
>>> < \tweak #'color #red c>1
>>
>> So much for my "nobody needs that" theory.  The problem I have is that
>> accepting \transpose in all the same places as \tweak does not seem like
>> a good idea.
>>
>> On the other hand, whether an error gets thrown by the parser or by the
>> expression builder might not make that much of a difference to the end
>> user than it feels like making to me.
>
> if i understood you correctly (it's about the difference in syntax
> between tweak and override?), i agree that it's quite a serious
> problem.

There is not all that much, really.  Take a look at music-functions.scm,
for example style-note-heads.  It's sort of polymorphic since it can be
called in various places.  It looks at the type of received music
expression in order to figure out where it was called, and does a tweak
or an override depending on what will work in that context.

> ...ah, so it is possible to modify ties in a chord separately!  Do you
> realize that i didn't know about it?  I'd say that this means the
> current state of things is too complicated.

The documentation for music functions sucks a lot.  Some things are
currently done with music functions that you would not guess possible
from their documentation (I was surprised that \tweak is a music
function, for example, though it acts less intelligent about it than
style-note-heads).

> I vote for changing the way things work completely (GLISS time
> approaches, after all :P).

Documenting the existing way would help a lot already.  My patch does
that, and it extends the behavior and functionality somewhat, so that
the documentation is less embarrassing.

> sorry if this is not very helpful... maybe i'll have specific ideas
> later.

I am not all too far from committing.

-- 
David Kastrup