lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Defining a new markup command (e.g. \lower by a specified amount)


From: David Kastrup
Subject: Re: Defining a new markup command (e.g. \lower by a specified amount)
Date: Wed, 16 May 2012 07:57:42 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux)

Thomas Morley <address@hidden> writes:

> If you found "define-music-function code much easier to handle" you
> may want to express your thankfulness to David Kastrup and his great
> parser-work.
> http://news.lilynet.net/?The-LilyPond-Report-24

Well, let's be fair: I've not really changed much of the relative
easiness to handle.  markup commands have always been defined using a
defining _macro_ (and creating macros for the sake of the markup macro),
and define-music-function using a more straightforward function.

I've vastly increased the power of music functions, and #{ ... #} has
become much more versatile (including being able to use it in markups,
so that's a tie-up).  $ and # have been regularized in behavior; again,
no difference to markup commands.  An actual simplification has been the
removal of the three-part division of music function behavior in
postevents, inside chords, and else.  That required removing EventChord
around elementary rhythmic elements.  One consequence being that
LilyPond's data structures now tend to be more suitable to manipulation
by music functions.

So basically they have become a quite more powerful tool at a moderate
increase in complexity, with a lot of streamlining of functionality
around them and documentation.  But as long as you stay in the area that
could previously be covered by music functions already, they have not
really become easier to handle.  Their whole design has been more
straightforward than that of markup commands from the start.

I actually did a number of simplifications to markup commands as well
(like stopping different versions being used in user code and LilyPond)
including some documentation, but that has been comparatively minor.

-- 
David Kastrup




reply via email to

[Prev in Thread] Current Thread [Next in Thread]