translate.py uses old GUILE syntax

[jeremy9959]

Music21 Version

9.7.0

Operating System(s) checked
Mac OS 15.5

Problem summary
The lilypond translation uses old GUILE syntax. So for example

\override VerticalAxisGroup #'remove-first = ##t

should be

\override VerticalAxisGroup.remove-first=##t

There are many places in translate.py where this happens.

Steps to reproduce

import music21 as m21

music=[m21.note.Note('G4'),m21.note.Note('A4')]
s = m21.stream.Score(music)

s.show('lily')

Note also that lilypond \RemoveEmptyStaffContext is now \RemoveAllEmptyStaves.

Expected vs. actual behavior
Basically all of the many examples of
ClassName #'attribute = value
need to be changed to
ClassName.attribute=value
in translate.py.

More information
I'm willing to put a PR together if this is a change that you're interested in making. But it could cause problems for people using older versions of lilypond.

[mscuthbert]

Thanks Jeremy! This is something I don't know much about.

Does the current syntax work with current versions of Lilypond? Or with a warning? Or not at all?

When did the GUILE syntax change? Are we talking about a 2023 change or a 2012 change?

If this change has taken place more than 5 years ago OR the current syntax does not work on the current version of Lilypond then I think we should make the change.

I would love to never see the ClassName #'attribute = value syntax again -- It always seemed to me to be very out there compared to most other languages.

If spaces around operators are allowed in the new syntax, I'd prefer them, but if they're not allowed, then don't.

Thanks!

[jeremy9959]

I honestly can't tell when this changed. Looking in the documentation for 2.24.4 which is the current version, it seems to be taken for granted that something like

\override Property.attribute = value

is standard. I tried hunting through release notes, and apparently back in version 2.6 or so the older syntax was still in use, but I couldn't find an explicit change note.

The current version of translate.py doesn't seem to work with lilypond 2.24 (and GUILE 3.0). Here's what happens
on the tiny file shown above. Although weirdly I still get a png file that looks ok.

The lilypond code looks like this:

\version "2.24"
\include "lilypond-book-preamble.ly"

color = #(define-music-function (parser location color) (string?) #{
        \once \override NoteHead #'color = #(x11-color color)
        \once \override Stem #'color = #(x11-color color)
        \once \override Rest #'color = #(x11-color color)
        \once \override Beam #'color = #(x11-color color)
     #})

\header { }
\score  {
 \new Voice { g' 4
          a' 4
           }


  }

\paper { }
\layout {
  \context {
    \RemoveEmptyStaffContext
    \override VerticalAxisGroup #'remove-first = ##t
  }
 }

and the compilation yields this:

GNU LilyPond 2.24.4 (running Guile 3.0)
Processing `tmp3xt5czkr.ly'
Parsing...
tmp3xt5czkr.ly:23:5: error: unknown escaped string: `\RemoveEmptyStaffContext'

    \RemoveEmptyStaffContext
tmp3xt5czkr.ly:24:5: error: syntax error, unexpected \override, expecting '='

    \override VerticalAxisGroup #'remove-first = ##t
tmp3xt5czkr.ly:24:33: warning: deprecated: missing `.' in property path VerticalAxisGroup.remove-first
    \override VerticalAxisGroup
                                #'remove-first = ##t
tmp3xt5czkr.ly:26:2: error: syntax error, unexpected '}'

 }
tmp3xt5czkr.ly:26:3: error: Unfinished main input
 }

Interpreting music...
Preprocessing graphical objects...
Calculating line breaks...
Drawing systems...
Converting to `tmp3xt5czkr.pdf'...
fatal error: failed files: "tmp3xt5czkr.ly"

If I modify the lilypond code to this:

\version "2.24"
\include "lilypond-book-preamble.ly"

color = #(define-music-function (parser location color) (string?) #{
        \once \override NoteHead #'color = #(x11-color color)
        \once \override Stem #'color = #(x11-color color)
        \once \override Rest #'color = #(x11-color color)
        \once \override Beam #'color = #(x11-color color)
     #})

\header { }
\score  {
 \new Voice { g' 4
          a' 4
           }


  }

\paper { }
\layout {
  \context {
    \RemoveEmptyStaves
    \override VerticalAxisGroup.remove-first = ##t
  }
 }

it compiles fine:

GNU LilyPond 2.24.4 (running Guile 3.0)
Processing `update.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...
Calculating line breaks...
Drawing systems...
Converting to `update.pdf'...
Success: compilation successfully completed

[mscuthbert]

Great -- you've convinced me -- feel free to open a PR -- and thanks for using space around operators.

If you could make sure that the Color works in the new output I'd really appreciate that -- one of the main early uses for Lilypond in music21 was to color notes back when no other notation format did that.

(Btw -- if you or any other lilypond user you know is on Windows, I'd appreciate a look at PR #1773 which I can't test myself).

[jeremy9959]

unfortunately I don't use windows, so I can't help with #1773 .

If it's ok I'll tackle the color issue separately. That's not something I looked at, but I'm happy to try.

[jeremy9959]

Is there a standard test suite to run my changes against? -- never mind, I found the unittests.

[jeremy9959]

A few comments not related to the issue here but worth investigating.

• the lilypond conversion to png doesn't work well on things that are longer than one line, because the png file gets created in pieces.
• because of this, it's better to use pdf (as in s.show('lily.pdf')) which handles bigger pieces fine. But for this little example I stick with png.

The colors seem to work. Here's a sample.

from music21 import *

a = note.Note('A4')
a.style.color = 'blue'
b = note.Note('G4')
b.style.color = 'green'
s = stream.Score()
s.append([a,b])
s.show('lily')

yields:

The lilypond errors are gone.

$ python demo.py
GNU LilyPond 2.24.4 (running Guile 2.2)
Changing working directory to: `/tmp/music21'
Processing `/tmp/music21/tmp9h6wcb6z.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...
Calculating line breaks... 
Drawing systems... 
Converting to PNG...
Success: compilation successfully completed

What's odd is that the code inserts a scheme function called color into the lilypond, but doesn't actually use it. I wonder if this is a relic of past implementations? Or it has some other purpose?