Re: Markup module patch (Issue 2026)

[David Kastrup]

Han-Wen Nienhuys <address@hidden> writes:

> On Tue, Dec 13, 2011 at 5:56 PM, Ian Hulin <address@hidden> wrote:
>
>> I pulled out and tested the examples in separate .ly file and the
>> format that fails is
>> #(define-markup-command (double-box layout props text) (markup?)
>>  "Draw a double box around text."
>>  (interpret-markup layout props
>>    #{\markup \override #'(box-padding . 0.4) \box
>>            \override #'(box-padding . 0.6) \box { $text }#}))
>> \markup \double-box A
>
> Since the person writing the code is writing Scheme already, requiring
> the inner markups to be in Scheme is a reasonable restriction, IMO.

With that kind of logic, #{ ... #} should be removed altogether.  And
while we are at it, Scheme macros along with them.  Since the person
writing the code is writing Scheme already, requiring the inner markups
to be in Scheme rather than being actually written by a system of Scheme
macros would be quite in the same book.

> That said, it would be nice if #{ #} could be made to work, but I not
> enough insight into how it works.

There does not appear to be any problem apart from "parser" not being
defined in the module that Ian switches to.  Since other user-defined
variables and functions would be similarly afflicted, it would not
appear that throwing the functionality of #{ ... #} overboard would
solve the underlying problem to a degree where the user won't get to see
it anyway as soon as he tries working with variables.

> What is the rationale for putting the markups in a separate module?

Right question.

As an illustration of why I consider your sentence

    Since the person writing the code is writing Scheme already, requiring
    the inner markups to be in Scheme is a reasonable restriction, IMO.

as not being founded in a reality composed of users with a bell-shaped
distribution of skill sets, compare the appended version of a Bach
prelude written in the current version of LilyPond (actually, I am
cheating here since this will require a patch to parallelMusic that I am
going to commit after the doc run finishes successfully) with the
version you'll find at
<URL:http://nicolas.sceaux.free.fr/prelude/prelude.html>.  In both
cases, the user is in the situation of "writing Scheme already", and so
the "reasonable restriction" of requiring the inner music expressions to
be in Scheme would apply.

When I first encountered Nicolas' example of Lilypond programming on the
Web, I was in awe.  This showed a mastery of LilyPond that I considered
to be beyond me.  Compare this to the rather bland version that I append
at the end of this mail.  It is just a straightforward assembly of
standard LilyPond functionality, and there is nothing frightening about
the Scheme code.

And actually, if you retrace the systematic approach of Nicolas in a few
months from now, you'll find that \displayMusic and its friends will
produce quite simpler output, and even doing it in the analytic and
Scheme-centric manner that he employed will lead to quite simpler code.

Much of my ongoing work will appear as a waste of time to the LilyPond
masters like you and Nicolas as one can't do anything one could not do
before.  And one still needs to use Scheme.

But I trust that there will be users who appreciate it.  This is _my_
way of advertising LilyPond.  And I have a reasonable amount of
confidence that it forms an essential part of lowering the barriers of
entry in a manner that will raise the absolute number of contributing
LilyPond power users while lowering their percentage of the whole user
base.  Because it will no longer require a power user to do
comparatively simple tasks.

Yes, one _still_ needs to use Scheme.  But not to a frightening degree.
GUILE lists LilyPond as one of three long-running success projects of
GUILE on <URL:http://www.gnu.org/s/guile/>.

And what does GNUCash, one of the other two, has to say about it?  See
<URL:http://wiki.gnucash.org/wiki/Roadmap#Scheme_minimization> and the
next item.  I want Scheme to be a _strength_ of LilyPond, not a
liability.  And that means simple tasks should be simple to do and work
in predictable ways.  And if you don't notice a qualitative difference
in required skills between the above example from Nicolas and the below
example from me, I am not worried.  Because there _are_ people that
will.  And their number will only increase over time.  Of course, it
took Nicolas less time and skills to compose his example than it did me
to compose mine.  Because most of my actual work on it is not in the
example, but in LilyPond.

Not likely work that you would find worth paying for.  But I am banking
on hoi polloi.

\version "2.15.22"

\header{
    title = "Preludium"
    opus = "BWV 846"
    composer = "Johann Sebastian Bach (1685-1750)"
}
\paper {
  indent = 5\mm
}
#(set-global-staff-size 13)

ph = #(define-music-function (parser location p1 p2 p3 p4 p5)
       (ly:pitch? ly:pitch? ly:pitch? ly:pitch? ly:pitch?)
       #{ \repeat unfold 2 { r8 $p3 16 $p4 $p5 $p3 $p4 $p5 } |
          \repeat unfold 2 { r16 $p2 8. ~ $p2 4 } |
          \repeat unfold 2 { $p1 2 } |
       #})

\parallelMusic #'(high middle low)
{
        \voiceOne | \voiceTwo | \oneVoice |
        \ph c'   e'  g' c'' e''
        \ph c'   d'  a' d'' f''
        \ph b    d'  g' d'' f''
        \ph c'   e'  g' c'' e''
        \ph c'   e'  a' e'' a''
        \ph c'   d'  fis' a' d''
        \ph b    d'  g' d'' g''
        \ph b    c'  e' g' c''
        \ph a    c'  e' g' c''
        \oneVoice | \change Staff = "down" \voiceOne | \voiceTwo |
        \ph d    a   d' fis' c''
        \ph g    b   d' g' b'   
        \ph g    bes e' g' cis''
        \ph f    a   d' a' d''  
        \ph f    aes d' f' b'   
        \ph e    g   c' g' c''  
        \ph e    f   a c' f'  
        \ph d    f   a c' f'  
        \ph g,   d   g b f' 
        \ph c    e   g c' e'  
        \ph c    g   bes c' e'
        \ph f,   f   a c' e'  
        \ph fis, c   a c' ees'
        \ph aes, f   b c' d'  
        \ph g,   f   g b d' 
        \ph g,   e   g c' e'  
        \ph g,   d   g c' f'  
        \ph g,   d   g b f' 
        \ph g,   ees a c' fis'
        \ph g,   e   g c' g'  
        \ph g,   d   g c' f'  
        \ph g,   d   g b f' 
        \ph c,   c   g bes e'
      }

\score {
  \new PianoStaff
      <<
        \context Staff = "up" {
          << \high \\ \middle >>
          r8 f16 a c' f' c' a c' a f a f d f d
          r8 g'16 b' d'' f'' d'' b' d'' b' g' b' d' f' e' d'
          <e' g' c''>1 \bar "|."
        }
        \context Staff = "down" {
          \clef bass
          \low
          << { r16 c8. ~ c4 ~ c2 r16 b,8. ~ b,4 ~ b,2 c1 }
             \\ { c,2 c, c, c, c,1 } >>
        }
      >>
  
  \midi {
    \context {
      \Score
      \with \settingsFrom { \tempo 4 = 80 }
      }
    }


  \layout {
    \context {
      \Staff
      \with \settingsFrom { \accidentalStyle modern }
    }
  }
}

-- 
David Kastrup