[Top][All Lists]

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

Re: Making a \layout definition in Scheme

From: Urs Liska
Subject: Re: Making a \layout definition in Scheme
Date: Wed, 4 Apr 2018 22:21:48 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0

Am 04.04.2018 um 19:25 schrieb David Kastrup:
Urs Liska <address@hidden> writes:

OK, but now I have a follow-up question which is quite similar to my
other post from today (and I'm afraid the answer is similarly

I managed to install an editionID to a specific movement's score with
this code:

       (ly:score-add-output-def! score
           \layout {
             \context {
               #(editionID #f movement-path)

which actually works when I use that "movement-path" variable to
address  in \editionMod later.

However, I would like to be able to also write this without the
permanent switches,
Permanent switches?  Huh?

Well, 'permanent' is of course the wrong word. What I'm (somewhat) taking issue with is switching languages back and forth within one expression.

i.e. in pure Scheme syntax.
Why?  Seriously.

My project library is getting more and more pure Scheme code, and while sometimes I wonder if it's worth the effort it usually turns out to do so, for example because things immediately become easier to maintain or extend afterwards.

So that's why I'm looking for ways to "smoothen" code snippets like the one listed above.

But unlike \key I can't simply "call" layout.

My impression (after looking at the Scheme functions reference page
and a number of source files) is that I could use (ly:make-output-def)
to create the output definition and then use
ly:output-def-set-variable! to achieve the goal.
An output definition created from scratch will be neither layout
definition, midi definition, nor paper block.  You are better off
copying an existing template.  Which is what #{ \layout ... #} does
($defaultlayout or something like that).

But after trying out a number of things I must admit I don't get to an
  end with it.

So again I have to hope for any hint ...
If you want to replace the parser with your own Scheme code, your best
bet is to look in lily/parser.yy and check what the actual parser code
does.  There is no user-level documentation for rewriting any LilyPond
code in Scheme.  Because it would be sort-of pointless given the
user-level #{ ... #} construct.

The file I'm working on is only halfway "user-level", since it's the machinery hidden from the user in a black box. However, considering your comments above I assume that in *this* case it's the better choice to simply leave it as it is.


reply via email to

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