Re: Defining a new markup command (e.g. \lower by a specified amount)
Philip Thomas philip.tho...@bluewin.ch writes:
I am having great difficulty getting the hang of defining new markup commands.
The examples given in the Extending
manual in section 2.2.3 New markup command definition are
comprehensible to me in their own right, but they aren't
exactly simple examples, and I have so far failed to adapt definitions
found in the scm/define-markup-commands.scm file
to make my own new commands.
The particular problem that I'm trying to get to grips with at the
moment is this:
I
want to use the \lower command at about 15 places in text in a \markup
block (i.e. outside the \score block). The
\lower command works just fine to get the spacing I want between
sections of text (whereas both \override #'(baseline-
skip . xx) and \vspace #xx have proved quirky). The problem is that I
don't at this stage know exactly how much I want
to lower the text by (\lower #xx). When the overall layout of the
score is settled, I would like to experiment with
different values of N, without having to change each \lower command
separately. The solution seemed to me to be to
define a new markup command (e.g. \dropNextline) which specifies the
amount to which the line should be lowered. Then
my 15 entries could all read \dropNextLine { text text text }, and the
experiment would only involve changing the value
of xx in the define-markup-command code until the overall spacing is
correct when judged by the eye. But I'm bu**ered
if I can get it to work. Sorry if I'm ignorant of something I should
have found in the documentation.
For what it's worth, define-markup-command is a macro, and in particular
the command name it defines is treated in a macroesque way. That pretty
much implies that a useful command calling define-markup-command with a
non-constant name will need to be a macro as well, or alternatively call
primitive-eval manually (a macro does not evaluate its arguments as
usual, but interprets its body _twice_ instead).
You can write something like
(define-markup-command (drop-next-line layout props m) (markup?)
(interpret-markup layout props #{ \markup \lower #3 #m #}))
This will provide a command \drop-next-line taking a markup. Note that
{ text text text } is not actually a markup, but a markup list (a top
level markup would wrap it into a \line without asking), so maybe you
want to go for
(define-markup-command (drop-next-line layout props m) (markup-list?)
(interpret-markup layout props #{ \markup \lower #3 \line #m #}))
instead.
Note the spelling: markup commands usually don't use CamelCaps by
convention but rather dashed-names.
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Defining a new markup command (e.g. \lower by a specified amount)
2012/5/15 Philip Thomas philip.tho...@bluewin.ch:
I am having great difficulty getting the hang of defining new markup commands.
The examples given in the Extending
manual in section 2.2.3 New markup command definition are comprehensible to
me in their own right, but they aren't
exactly simple examples, and I have so far failed to adapt definitions found
in the scm/define-markup-commands.scm file
to make my own new commands.
The particular problem that I'm trying to get to grips with at the moment is
this:
I
want to use the \lower command at about 15 places in text in a \markup block
(i.e. outside the \score block). The
\lower command works just fine to get the spacing I want between sections of
text (whereas both \override #'(baseline-
skip . xx) and \vspace #xx have proved quirky). The problem is that I don't
at this stage know exactly how much I want
to lower the text by (\lower #xx). When the overall layout of the score is
settled, I would like to experiment with
different values of N, without having to change each \lower command
separately. The solution seemed to me to be to
define a new markup command (e.g. \dropNextline) which specifies the amount
to which the line should be lowered. Then
my 15 entries could all read \dropNextLine { text text text }, and the
experiment would only involve changing the value
of xx in the define-markup-command code until the overall spacing is correct
when judged by the eye. But I'm bu**ered
if I can get it to work. Sorry if I'm ignorant of something I should have
found in the documentation.
I guess I have
two questions:
(1) How to define a suitable \dropNextLine command?
I'm not sure what the new command should do. A _short_ example would
have been helpful.
Perhaps:
\version 2.15.36
#(define add-amount 2)
#(define-markup-command (custom-lower layout props amount arg)
(number? markup?)
(ly:stencil-translate-axis (interpret-markup layout props arg)
(- (* amount add-amount)) Y))
\markup \column {
\custom-lower #10
\custom-lower #20
}
Play around with the value of add-amount.
BTW, why do you reject baseline-skip?
(2) Is there an explanation anywhere from which I
can learn in a graded, structured, way how to define my own markup commands
so I don't have to presume repeatedly upon
the kindness of other users on the forum? Are there some examples which would
lead me by the hand a bit more gently,
starting from the commands scm/define-markup-commands.scm and working them up
into a useable result?
Well, starting with manipulating lily-code I found the instruction of
the Extending-manual quite helpful.
Perhaps you find these steps helpful (which I performed, to teach myself) :
1. copy a _simple_ predifined markup-comand in a file
2. rename it
3. test the renamed version. Does it work? If yes, fine. If not, check
all again. No mistake? - ask the list
4. try to manipulate/add non-invasive properties, perhaps fontsize,
color, rotate etc.
5. If succes, try to code more complicated stuff. If not, don't worry,
try again :) and/or ask the list.
And study all the altered and new defined markup-commands you can catch.
By the way, I
have found define-music-function code much easier to handle, although I
readily admit to being rather a beginner.
Different tools, different rules.
Writing music-functions can be very complicated, too. Depends on what
is intended.
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
Cheers, Philip
HTH,
Harm
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Defining a new markup command (e.g. \lower by a specified amount)
Thomas Morley thomasmorle...@googlemail.com 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
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
