Now that #31 has been merged lyluatex applies protrusion and correctly determines the correct line width. But this raises further questions, on a typographical, technical, and interface level. Attached is a detailed PDF* demonstrating the issues. The questions to be discussed in order to allow further development are (additions welcome):

• Should protrusion be used always or are there valid reasons to avoid it?
• What is the correct way to deal with the issue (from the typographical perspective)?
• Which interface should be provided for package users?

*(the source code used to produce this can be found as test-alignment.tex)

Having finally looked into lyluatex I think (even more than initially) that lyluatex and my musicexamples package would go together very well, and we should discuss how that could work best.

lyluatex manages LilyPond source code and compilation with suitable dimensions but “only“ integrates them in the final document as images included with \includegraphics or \includepdf.
musicexamples provides commands and environments to properly integrate music examples into LaTeX documents but is only able to deal with PDFs generated separately. So actually there is absolutely no overlap currently, and each package implements what the other misses, which makes them ideal companions.

Among the elements musicexamples adds to the mix are

• floating and non-floating environments for music examples
  (=> allows the use of captions and labels)
• Many different environment styles (wrapped, full-line, sideways)
• Support for full-page scores where captions are moved to the header/footer
• Support for multi-page scores where the current text is not interrupted (i.e. text flows until the end of the page and continues after the multipage score)
• Support for multi-page scores that start on the next odd or even page (so there may be 1 1/2 pages of text until the score starts) to enforce page turns. (This isn't fully worked through and will have to be adjusted to a lyluatex use case)
• Print separate list of musicexamples

What options do we have?

1. integrate musicexamples into lyluatex
2. integrate lyluatex into musicexamples
3. Don't integrate them but make sure they work together seamlessly (and bring musicexamples to a state where it can be published on CTAN)
4. as 3. but "use" musicexamples from within lyluatex

I vote for 3. or 4. I would not strictly bind the two together because musicexamples should work with any TeX engine, and I don't think it's a good idea to add luatex as a requirement (although I personally use luatex exclusively).
OTOH it would be good to have the functionality available in one single package. Of course it would be possible to wrap the lyluatex functions to only be available when run on luatex, but probably that's overly complicated.

One alternative could be to reimplement lyluatex using pythontex. While this would still add a heavy dependency - Python - it would still allow any TeX engine to be used.
Or we could try to reimplement everything in pure (La)TeX, based on the code shared by Knut Petersen (although I'm not sure to what extent this code can be made as maintainable as lyluatex's current one - at least I will not be of much help here).

So my suggestion is to

• Continue developing lyluatex as it is, aiming for more versatility and configurability
• Bring musicexamples up to par (and publish it), review the implementation, and remove all the attempts at working on the LilyPond compilation part
• Update the documentation of both packages showing how they can be used together
• Wait and see if there comes an option to make lyluatex less dependent on luatex

As far as I can see the line width of the scores can only be changed with the package option and the local command options, but I'm not sure I've understood the code.

If that's correct I suggest adding a command that changes the line width for subsequent scores.

Hi
My project is failing with the following error message:

(compiling luc: /usr/local/texlive/2015/texmf-var/luatex-cache/generic/fonts/otf
/lmroman17-regular.luc)(load luc: /Users/ambs/Library/texlive/2015/texmf-var/lua
tex-cache/generic/fonts/otf/lmroman17-regular.luc)(compiling luc: /usr/local/tex
live/2015/texmf-var/luatex-cache/generic/fonts/otf/lmsans17-regular.luc)(load lu
c: /Users/ambs/Library/texlive/2015/texmf-var/luatex-cache/generic/fonts/otf/lms
ans17-regular.luc)(compiling luc: /usr/local/texlive/2015/texmf-var/luatex-cache
/generic/fonts/otf/lmroman12-bold.luc)(load luc: /Users/ambs/Library/texlive/201
5/texmf-var/luatex-cache/generic/fonts/otf/lmroman12-bold.luc)sh: lilypond: command not found

! LuaTeX error ./lyluatex.lua:137: attempt to index local 'i' (a nil value)
stack traceback:
    ./lyluatex.lua:137: in function 'retour_tex'
    ./lyluatex.lua:68: in function 'inclure_ly'
    [\directlua]:1: in main chunk.
\keycmd->includely ...{\commandkey {staffsize}} )}

This seems like lilypond is not being found in the program path.
I tried to change the .lua file like this:

LILYPOND = '/Applications/LilyPond.app/Contents/Resources/bin/lilypond'

but the error persists.
Ideas?

I want to make lyluatex aware of the presence of lilyglyphs.

If lilyglyphs is loaded inline music can be rendered as lilyglyphs commands +by passing the resulting image to the lilyImage command

It seems the paper layout techniques used with the fullpagealign=staffline option disturb LilyPond's spacing algorithms: it can happen that Lily tries to squeeze more systems in the page than would be good.

I'll have to investigate this further.

Bonjour,

chez moi, il semble que la compilation ne veule pas se faire pour la musique lilypond. Il me renvoie ceci, sans faire la compilation :
! LuaTeX error ./lyluatex.lua:82: attempt to index local 'p' (a nil value)
stack traceback:
./lyluatex.lua:82: in function 'compiler_ly'
./lyluatex.lua:66: in function 'inclure_ly'
[\directlua]:1: in main chunk.
\keycmd->includely ...{\commandkey {staffsize}} )}

Pourriez-vous m'aider, s'il vous plaît?

The following document

\documentclass{scrartcl}
\usepackage{lyluatex}
\begin{document}

\begin{ly}
{
  \repeat unfold 3 { c1 }
}
\end{ly}

\end{document}

triggers a strange error:

! Extra }, or forgotten \endgroup.
<argument> { \relative c' { \repeat unfold 3 { c1 } }
                                           } 
l.12 \end{ly}
           
?

Obviously it chokes about something in this input. The behaviour is the same with the ly environment or the \lily command.

If the document contains \tuplet 3/2 { c' d' e' } instead there is no problem.

Hello,

I am using lyluatex for my latest project, and I like it! One drawback (that lyluatex shares with lilypond-book so far): if I include a lilypond file in my lualatex document that has one or more
\include directives, chances in these included files do not cause lyluatex to recompile the music.

What about taking these include files into account? Something along the lines of
[snip]

local md5 = require 'md5'

function file_exists(name)
   local f=io.open(name,"r")
   if f~=nil then io.close(f) return true else return false end
end

function replaceIncludes(file)
   local content =""
   for Line in io.lines(file) do
       if Line:find("^%s*[^%%]*\\include") then
          local inclfile = Line:gsub("%s*\\include%s*\"(.*)\"", "%1")
          if file_exists(inclfile) then
             content = content .. replaceIncludes(inclfile)
          else
             content = content .. Line .. "\n"
          end
       else
          content = content .. Line .. "\n"
       end
   end
   return content
end

lyincl = replaceIncludes('test.txt')

print(md5.sumhexa(lyincl)) 

[snip]

This is not yet tested in real life situations, but
a) recursively checks for \include calls
b) ignores commented out lines
c) ignores nonexistent include files (mainly because lilypond will spot the error)

What do you think?

Best regards,

Marc

I will now start reviewing the musicexamples package, with three main targets:

• general coding review (I assume there's much to be improved)
• removing obsolete attempts to achieve what lyluatex now does
• ensuring compatibility with lyluatex

We should try to minimize functionality overlap as much as possible in order to make the two package perfect complements. Actually I even considered integrating musicexamples's functionality into lyluatex because that would be the most natural thing to do. However, I think musicexamples should continue to work with any LaTeX engine, so that's not an option.

The general idea should be that lyluatex generates an \includegraphics expression that can be inserted in a musicexamples environment. This will work very easily with fragments, but fullpage scores are a more complex issue (which I'll discuss in a separate issue when the time is there for that (after more review of the other package)).

My idea about the integation is the following: when lyluatex knows that musicexamples is loaded (this would mean musicexamples would have to be loaded first) it changes some parts of its operation and automatically wraps the \includegraphics commands in musicexamples environments. For the user the immediate difference would be that the scores aren't simply placed wherever they fall but are beautifully spaced by environments. And simply passing a caption in the optional argument will do all the magic of numbering, adding to a list of music examples etc.). This will lead to quite some more new options, but by now that shouldn't scare us anymore.

In compiler_ly there is already the notion of LilyPond's -I command line option, but it only makes use of the file path of the LilyPond file's directory.

There should be the possibility to specify a list of include paths, probably on a document-wide level (I'm not sure if it's necessary to change them along the way or even locally).

So the compiler_ly function should be modified to iterate over the include argument as a list, such a list has to be made available as a variable in the Lua file, and there should be a macro to set/define this list.

In addition I suggest to also add the directory of the LaTeX file to the include directories because it may be an option for many use cases to have include files in that directory. This should also be added to the command line when compiling fragments.

There is no reason to prohibit fragments to be fullpage. Think of auto-generated exercises or patterns that can very well be coded inline.

I think with the new option handling this should be much simpler, and it will also enable the removal of code redundancy between lilypond_file() and lilypond_fragment().

fullpage will of course be changed from a function argument to get_local_option() too.

When having the score encoded in separate files it may be desirable to only print a subset of the score. That way one can have one complete encoding of something and refer to specific points in score examples. Valid requests include (more suggestions welcome):

• The first system (incipit)
• A certain number of systems
  (“I want to show some amount of music or fill some amount of paper but don't care about the exact amount of music”)
• A certain range of measures

The first two would have to be done in the stage of write_tex() while for the third \set score.skipTypesetting commands would have to be injected in the `ly_code'' somehow. But that might be difficult without adding the edition-engraver as a dependency.

the lilypond temp directory will grow really fast, with a full set of files for any modification of any score (even size changes). There should be a nice way to purge the temp directory, although it may be difficult to decide what to throw out.

One idea (that could be implemented as a package option purge) would be to remove all files from the temp directory that are not actually used by the document. For this to work all generated hash filenames should be stored in a list (can conveniently be done in the new function hash_output_filename introduced in 923a28a) and at the end of the LaTeX run all files from the temp directory that don't belong to any of the hashes are removed.

Of course this could trigger unnecessary LilyPond runs, for example when the line width is temporarily modified and later reverted. But that's why it would be a package option and not built in.

By default, Lilypond uses a staff size of 20 which prints the lyrics in 12pt font. Since I want the lyrics text size to match the font size of the rest of the document, this means that in documents where the font size isn't 12 pt, I have to change the Lilypond staff size.

First, the universal variable for default staffsize is already a big step up on lilypond-book (where the staffsize has to be specified for each inclusion separately). However, the fact that it's a counter limits what I can do with it since counters are limited to integers. In my current projects using lilypond-book, I use a scheme expression for the staff size in order to facilitate the scaling. For example staffsize=(* 20 17/12) rescales the music for a 17pt large-print edition. Would it be possible to change the staffsize variable so that it can hold something like this?

Currently the file to be included by \lilypondfile is searched for

• as a relative path appended to CURRFILEDIR
• using kpse.find_file()

I'm not sure about the latter, but I assume it finds the files that LaTeX can find.

In addition it should be possible to find files as

• absolute paths
• paths that are relative to any of the given include paths

Apart from generally being not nice to hard-code directory names making the ly_tmp directory configurable should be implemented to help #24. Purging the temp directory would not be possible if there are multiple .tex files in the original directory (which now share the temp directory).

When a LilyPond compilation fails a Lua stack trace occurs in write_tex because it tries to read non-existent files.

This should be handled by at least suppressing the error. Of course the user should somehow be notified. In musicexamples missing files don't cause an error but an information box is printed instead. I think something similar to that would be a good idea.

With scholarLY annotations can be encoded in the score and exported to LaTEX input.

I want to write a complementary package to lyluatex that supports these annotations: after rendering the score the Tex output shall be collected and prepared to be used as a report (and much more).

It would be nice if it was the default that the fonts in use in the LaTeX document (default fonts, the currently active ones?) are also used in LilyPond.

Add a label argument (which will only make sense as a local option, of course).

• Insert a \label after the image
• Prefix the label with a configurable prefix
• Make sure this works well with musicexamples
• If a label is defined, use it for the FILELIST output

Is there a way to set a working directory for lilypond? I'm using a complex structure for my project, and when I compile my files only with lilypond, all \included files are found correctly; but when compiling with LuaLaTeX they are no longer found. This is because the relative path changes from one file to the other, so it would be nice to add some working directory parameter to lyluatex, so lilypond can find her files without having to symlink them.

\documentclass{article}

\usepackage{lyluatex}

\begin{document}
\lily{c' e' g'}

\end{document}

This document doesn't compile because lilypond runs into an error which indicates that it's running into the notes before it's ready to process music. To get the file to compile one must wrap the notes in a Staff or Voice block (e.g. \new Staff {c' e' g'}).

Produce ragged-right lines with natural spacing, i.e., ragged-right = ##t is added to the LilyPond snippet. Single-line snippets will always be typeset by default as ragged-right, unless noragged-right is explicitly given.

Each snippet will call these macros if they have been defined by the user.

There is also \betweenLilyPondSystem, but that is already present through our use of the -systems.tex file.

AFAICS it's currently only possible to specify a LilyPond executable through the package option. (A function ly_definir_programme would change that but there is no LaTeX interface available for it.

If that's correct I suggest to add a command, say \lilypondCmd that takes effect from the macro onwards and add an option to the LilyPond commands/environments to override the executable for a single score.

This is usually not relevant when writing about music but important when writing about LilyPond.

I suggest considering to change the line-width argument to linewidth

While line-width is the LilyPond name of the paper variable linewidth is more in line with LaTeX syntax/expectations and also the staffsize argument

Votre package me semble très intéressant, je vais le tester sur des documents plus importants pour voir comment se passe l'inclusion de bibliographie, index etc. Mais déjà bravo pour votre travail.

Une question: il me semble que les extraits de lilypond sont compilés à chaque fois, ce qui peut être fastidieux pour les gros fichiers. Pensez-vous y intégrer un système de contrôle des modifications pour ne compiler que les extraits modifiés depuis la dernière compilation?

If some small music is correctly generated by the ly environment, and later is replaced by another one, LuaLaTeX will fail to render the second one, printing always the first. Deleting the auxiliary files seems to be the only way to get the new snippet to the pdf.

Maybe a force option could be added to help with this issues?

With a defined left-margin option in the lilypond-score it will be possible to explicitly align the first barline to the text margin, which is something I'd greatly prefer.

Any value set here should be added to line-width. So a left margin of 0.5cm should add 0.5cm to the line width.

Hello,

my latest project based on lyluatex worked fine, but as soon as I renamed the directory where the .tex file was located, some cryptic errors occured – it looks as if lyluatex does not work correctly in directories containing spaces in its name (I am working under Ubuntu 14.04 LTS).

Greetings,
Marc

The sample project attached includes two lilypond scores, both of which can be compiled fine directly with lilypond. However, because they include another file (the common Format.lyi) errors are generated when lyluatex tries to do something with them. I believe that the included file isn't getting copied into the temporary directory correctly. It's probably necessary to iterate over the included lilypond files to look for \include statements and grab those files as necessary.

Test_Lily_include .zip

There should be a command that inserts a score as a sequence of systems interspersed with some glue space (like lilypond-book does). This will allow multi-system scores to flow over page breaks.

The individual system PDFs are already there in the temp directory anyway ...

While storing the scores by their content hash is of course indispensable it effectively renders the tmp_ly directory a black box.

Maybe there should be an index (in addition to the .list file already exported) that allows mapping some reference from the source to the hash.

A suggestion would be to combine that with a label. A key "label" would generate a label after the image and would add an entry to the index

Discussion in #36 made me realize that a score can also protrude to the right, and that should be taken into account as well. It's pretty easy to infer from the eps file (although not as directly as the left one).

The bounding box info in the EPS file gives four integer values: X/Y coordinates of the lower left and upper right corners. 0/0 refers to the left lower corner of the staff symbol, so the negative first value is the actual left protrusion in points (1/72 inch, not the LaTeX \pt).

The third value is the horizontal position of the right edge of the image, and that is zero-based (as per the paragraph above. So since we know the line width we can determine a difference as "third value minus line-width in points", and if that is a positive value we have a (rather rare) case of protrusion.

One caveat that does not apply to the left margin: the points given in the EPS files are integers, not floats, which means there are rounding errors. Which in turn means there may be "false positives" that should be ignored

Till now :

• we define a special command to change every global option within the doc ;
• we add special parts to the name of temporary files in hash_output_filename ;
• we define options in three places : at the beginning of lyluatex.sty, and when defining ly and lily.

This should be refactored :

• we should have only one command, say \lysetoption{OPTION}, that would change each parameter ;
• we should take all options in account in hash_output_filename, and include them in the hash instead of defining very long filenames (that may only get longer while adding options) ;
• we should have a lua function (or another way) to define ly and lily's options.

That way, every option could be defined :

• either globally as a package option ;
• or globally within the document ;
• or locally as a command option.

While it wouldn't necessarily mean something for every option, nothing prohibits to make it possible. Perhaps we would be amazed by users' ingeniousness…

I'll work on this as from wednesday.

I'd like to implement a third mode beside fullpage and fragment: inline. Basically this should produce an image and include it like a character - actually a lilyglyphs command but "live". Differences from fragments include

• other boilerplate
• options to hide/show stafflines, clef, key (default: omitted)
• no handling of indentation
• maybe a different staffsize heuristic

Set indentation of the first music system to zero. This option affects LilyPond, not the text layout. Since no indentation is the default, noindent is redundant normally.

line-width=size\unit

Set line width to size, using unit as units. unit is one of the following strings: cm, mm, in, or pt. This option affects LilyPond output (this is, the staff length of the music snippet), not the text layout.

If used without an argument, set line width to a default value (as computed with a heuristic algorithm).

If no line-width option is given, lilypond-book tries to guess a default for lilypond environments which don’t use the ragged-right option.

We currently support the line-width=size\unit option, but not the line-width option. As best I can tell, the keycommand package cannot support a key which is both boolean (given or not given) and general (given with a value). I'm not sure if other keyword packages (such as keyval or pfgkeys) provide the needed support.

One of the goals of our current efforts in completing lyluatex is to provide a tool that helps creating all sorts of beautiful music-related documents. But we are also interested in making that easy and manageable, which can spectacularly benefit from Pandoc integration.

I think we should provide a number of sample documents and templates for different typical use cases. I would like to have this issue as a platform to discuss useful approaches and to shape a list of such use cases.

We could provide additional LaTeX packages or document classes for these use cases, or one of these with configuration switches.

For Pandoc I think we could provide one template that can (through YAML configuration) switch between different document types.

A list of document types (please edit the description to modify the list rather than adding comments):

• Article
  A text document with interspersed music examples
• Sheet music
  A document with front/back matter, multiple scores and (possibly) text sections between
• teaching/exam sheets
  Short sections of text, alternating with (short) scores. Scores usually include emtpy staves and are larger to be filled in by hand.
• Song sheets for services (a document type for which I've mostly seen really ugly examples
  Alternating text and songs, usually with multiple stanzas. Text can be structured or include different types of verses

I'm somewhat confused, but I have the impression the label option is not recognized as a local option. It works as package option and with \lysetoption but not as a local option.

I can't see any reason in the code, though.

Is it intentional that the .eps files are still present in the output directory?

Now we have a proper manual in place we have to fill in the gaps, i.e. document the current state of the package. This should have kind of priority, i.e. new features should not be implemented at a faster pace than existing features are documented ;-)

Now that the manual is more or less complete we have to review it. Relevant questions are:

• Is everything documented?
• Are the explanations understandable?
• Are they consistent with the actual behaviour?
  • If not: should the manual be updated or the behaviour fixed?

To keep track of the progress here's a check list. Please update the issue (rather than commenting) by checking items and indicating when you are going to work on any sections. Add commits to the update-manual branch.

<many checked options deleted>
Do we need example files for the following topics?

• Score layout / dimensions
• Protrusion (@uliska will move the existing examples to a separate file)
• Vertical alignment of fullpage scores
• Staff display options (notime etc.)
• relative
• verbatim

Maybe this is a stupid question, but why do we have to use our "private" command/environment names (\lily, ly, \inlcudely) instead of directly using those from lilypond-book (\lilypond, lilypond, \lilypondfile)?

Wouldn't it be much better to simply reuse these names from lilypond-book? I find them very telling, and I don't see the reason to deviate from them and create an additional compatibility layer.

If compatibility with existing documents is the reason, are there really that many already out there in the wild (I mean, even in test.tex we use \lilypondfile)? And if so I would at least suggest to invert the situation, make the lilypond-book names the default and create aliases for the others.

I don't know if this is possible, since Lilypond is called by the lua script, but it would be nice to have an option that that allowed me to specify the lilypond executable to be used. I usually maintain two installations of Lilypond, the most recent stable (which is set up to be called with lilypond at the command line) and the most recent development version (which is called with lilypond-dev). Most of the time I use the stable version, but on occasion I have call to use the development version because of some feature that has been implemented there which isn't in the stable version. What I'd like is an option in the package file that would allow me to switch between these versions. Ideally, it would be something like the following:

\usepackage[location=/path/to/lilypond-dev]{lyluatex}

The location option would be a keyword option whose value was the location of the lilypond executable to use. This would be the most versatile option, allowing for non-standard executable locations which are not in PATH as well as supporting multiple installs. However, it would also be more complicated because it would mean passing the string option to the lua script.

A simpler implementation would be to simply create a variants of the lua scripts which called lilypond-dev instead of lilypond. The package option would then simply tell the package to use these scripts instead of the normal ones:

\usepackage[develop]{lyluatex}

If I'm not mistaken when a LilyPond file is included and fullpage is requested it is compiled as defined in the file itself.

However, we should also set the margins for the score according the the geometry of the text document. I think for this we should split lilypond_fragment_header into two separate functions, one injecting the system-by-system compilation behaviour (for fragments) and the other defining the \paper block, which would also be used for fullpage scores. I have checked that it is possible to append a paper block and staffsize settings to the end of a LilyPond file to override any earlier settings.

Defining the layout of fullpage scores is more involved, as the line width isn't the only relevant parameter anymore, we also have the four margins. And there should also be the differentiation between one- and two-page layout. Probably we should also try to figure out if the full-page score will start on an odd or even page and set the "first-page-number" accordingly.

However, it should be considered/discussed how inserting fullpage scores relates to the corresponding command in musicexamples. With all the fragment commands it is clear: they can simply be wrapped by the musicexamples environments, but this is a somewhat different case as (so far) musicexamples implements this as a command, not an environment.

Hello everybody,

I have a problem with running lyluatex and TexLive 2017.
OS: Windows 10.

According to a friend, the problem is here:

Package etex Warning: Extended allocation already in use.
(etex)                etex.sty code will not be used.
(etex)                To force etex package to load, add
(etex)                \RequirePackage{etex}
(etex)                at the start of the document.
) (c:/texlive/2017/texmf-dist/tex/latex/xkeyval/xkeyval.sty
<knip>

**! LaTeX Error: Option clash for package lyluatex.**

The complete output:

C:\Users\doesd\Documents\Laus Tibi Praios NIEUW\Oefening>lualatex -shell-escape erik.texThis is LuaTeX, Version 1.0.4 (TeX Live 2017/W32TeX) system commands enabled.(./erik.texLaTeX2e <2017-04-15>(using write cache: C:/texlive/2017/texmf-var/luatex-cache/generic)(using readcache: C:/texlive/2017/texmf-var/luatex-cache/generic C:/Users/doesd/.texlive2017/texmf-var/luatex-cache/generic)luaotfload \| main : initialization completed in 0.355 secondsBabel <3.15> and hyphenation patterns for 1 language(s) loaded.(c:/texlive/2017/texmf-dist/tex/latex/memoir/memoir.clsDocument Class: memoir 2016/05/16 v3.7f configurable book, report, article document class(c:/texlive/2017/texmf-dist/tex/generic/luatex85/luatex85.sty)(c:/texlive/2017/texmf-dist/tex/generic/oberdiek/ifpdf.sty)(c:/texlive/2017/texmf-dist/tex/latex/ifetex/ifetex.sty(c:/texlive/2017/texmf-dist/tex/plain/ifetex/ifetex.tex))(c:/texlive/2017/texmf-dist/tex/generic/ifxetex/ifxetex.sty)(c:/texlive/2017/texmf-dist/tex/generic/oberdiek/ifluatex.sty)(c:/texlive/2017/texmf-dist/tex/latex/memoir/mem14.clo(load luc: C:/texlive/2017/texmf-var/luatex-cache/generic/fonts/otl/lmroman12-regular.luc))(load luc: C:/texlive/2017/texmf-var/luatex-cache/generic/fonts/otl/lmroman10-regular.luc)(c:/texlive/2017/texmf-dist/tex/latex/memoir/mempatch.sty))(c:/texlive/2017/texmf-dist/tex/generic/babel/babel.sty(c:/texlive/2017/texmf-dist/tex/generic/babel/switch.def)(c:/texlive/2017/texmf-dist/tex/generic/babel/luababel.def)(c:/texlive/2017/texmf-dist/tex/generic/babel-dutch/dutch.ldf(c:/texlive/2017/texmf-dist/tex/generic/babel/babel.def(c:/texlive/2017/texmf-dist/tex/generic/babel/switch.def)(c:/texlive/2017/texmf-dist/tex/generic/babel/luababel.def))(c:/texlive/2017/texmf-dist/tex/generic/hyph-utf8/loadhyph/loadhyph-nl.texUTF-8 Dutch hyphenation patterns(c:/texlive/2017/texmf-dist/tex/generic/hyph-utf8/patterns/tex/hyph-nl.tex))))(c:/texlive/2017/texmf-dist/tex/latex/bera/bera.sty(c:/texlive/2017/texmf-dist/tex/latex/base/fontenc.sty(c:/texlive/2017/texmf-dist/tex/latex/base/t1enc.def)(c:/texlive/2017/texmf-dist/tex/latex/lm/t1lmr.fd))(c:/texlive/2017/texmf-dist/tex/latex/base/textcomp.sty(c:/texlive/2017/texmf-dist/tex/latex/base/ts1enc.def))(c:/texlive/2017/texmf-dist/tex/latex/bera/beraserif.sty(c:/texlive/2017/texmf-dist/tex/latex/graphics/keyval.sty)(c:/texlive/2017/texmf-dist/tex/latex/bera/t1fve.fd))(c:/texlive/2017/texmf-dist/tex/latex/bera/berasans.sty)(c:/texlive/2017/texmf-dist/tex/latex/bera/beramono.sty))(c:/texlive/2017/texmf-dist/tex/latex/base/alltt.sty)(c:/texlive/2017/texmf-dist/tex/latex/graphics/graphicx.sty(c:/texlive/2017/texmf-dist/tex/latex/graphics/graphics.sty(c:/texlive/2017/texmf-dist/tex/latex/graphics/trig.sty)(c:/texlive/2017/texmf-dist/tex/latex/graphics-cfg/graphics.cfg)(c:/texlive/2017/texmf-dist/tex/latex/graphics-def/luatex.def)))(c:/texlive/2017/texmf-dist/tex/latex/tikzsymbols/tikzsymbols.sty(c:/texlive/2017/texmf-dist/tex/latex/l3packages/xparse/xparse.sty(c:/texlive/2017/texmf-dist/tex/latex/l3kernel/expl3.sty(c:/texlive/2017/texmf-dist/tex/latex/l3kernel/expl3-code.tex)(c:/texlive/2017/texmf-dist/tex/latex/l3kernel/l3pdfmode.def)))(c:/texlive/2017/texmf-dist/tex/latex/pgf/frontendlayer/tikz.sty(c:/texlive/2017/texmf-dist/tex/latex/pgf/basiclayer/pgf.sty(c:/texlive/2017/texmf-dist/tex/latex/pgf/utilities/pgfrcs.sty(c:/texlive/2017/texmf-dist/tex/generic/pgf/utilities/pgfutil-common.tex(c:/texlive/2017/texmf-dist/tex/generic/pgf/utilities/pgfutil-common-lists.tex)) (c:/texlive/2017/texmf-dist/tex/generic/pgf/utilities/pgfutil-latex.def(c:/texlive/2017/texmf-dist/tex/latex/ms/everyshi.sty))(c:/texlive/2017/texmf-dist/tex/generic/pgf/utilities/pgfrcs.code.tex))(c:/texlive/2017/texmf-dist/tex/latex/pgf/basiclayer/pgfcore.sty(c:/texlive/2017/texmf-dist/tex/latex/pgf/systemlayer/pgfsys.sty(c:/texlive/2017/texmf-dist/tex/generic/pgf/systemlayer/pgfsys.code.tex(c:/texlive/2017/texmf-dist/tex/generic/pgf/utilities/pgfkeys.code.tex(c:/texlive/2017/texmf-dist/tex/generic/pgf/utilities/pgfkeysfiltered.code.tex)) (c:/texlive/2017/texmf-dist/tex/generic/pgf/systemlayer/pgf.cfg)(c:/texlive/2017/texmf-dist/tex/generic/pgf/systemlayer/pgfsys-luatex.def(c:/texlive/2017/texmf-dist/tex/generic/pgf/systemlayer/pgfsys-common-pdf.def)))(c:/texlive/2017/texmf-dist/tex/generic/pgf/systemlayer/pgfsyssoftpath.code.tex)(c:/texlive/2017/texmf-dist/tex/generic/pgf/systemlayer/pgfsysprotocol.code.tex)) (c:/texlive/2017/texmf-dist/tex/latex/xcolor/xcolor.sty(c:/texlive/2017/texmf-dist/tex/latex/graphics-cfg/color.cfg))(c:/texlive/2017/texmf-dist/tex/generic/pgf/basiclayer/pgfcore.code.tex(c:/texlive/2017/texmf-dist/tex/generic/pgf/math/pgfmath.code.tex(c:/texlive/2017/texmf-dist/tex/generic/pgf/math/pgfmathcalc.code.tex(c:/texlive/2017/texmf-dist/tex/generic/pgf/math/pgfmathutil.code.tex)(c:/texlive/2017/texmf-dist/tex/generic/pgf/math/pgfmathparser.code.tex)(c:/texlive/2017/texmf-dist/tex/generic/pgf/math/pgfmathfunctions.code.tex(c:/texlive/2017/texmf-dist/tex/generic/pgf/math/pgfmathfunctions.basic.code.tex)(c:/texlive/2017/texmf-dist/tex/generic/pgf/math/pgfmathfunctions.trigonometric.code.tex)(c:/texlive/2017/texmf-dist/tex/generic/pgf/math/pgfmathfunctions.random.code.tex)(c:/texlive/2017/texmf-dist/tex/generic/pgf/math/pgfmathfunctions.comparison.code.tex)(c:/texlive/2017/texmf-dist/tex/generic/pgf/math/pgfmathfunctions.base.code.tex)(c:/texlive/2017/texmf-dist/tex/generic/pgf/math/pgfmathfunctions.round.code.tex)(c:/texlive/2017/texmf-dist/tex/generic/pgf/math/pgfmathfunctions.misc.code.tex)(c:/texlive/2017/texmf-dist/tex/generic/pgf/math/pgfmathfunctions.integerarithmetics.code.tex)))(c:/texlive/2017/texmf-dist/tex/generic/pgf/math/pgfmathfloat.code.tex))(c:/texlive/2017/texmf-dist/tex/generic/pgf/basiclayer/pgfcorepoints.code.tex)(c:/texlive/2017/texmf-dist/tex/generic/pgf/basiclayer/pgfcorepathconstruct.code.tex)(c:/texlive/2017/texmf-dist/tex/generic/pgf/basiclayer/pgfcorepathusage.code.tex)(c:/texlive/2017/texmf-dist/tex/generic/pgf/basiclayer/pgfcorescopes.code.tex)(c:/texlive/2017/texmf-dist/tex/generic/pgf/basiclayer/pgfcoregraphicstate.code.tex)(c:/texlive/2017/texmf-dist/tex/generic/pgf/basiclayer/pgfcoretransformations.code.tex)(c:/texlive/2017/texmf-dist/tex/generic/pgf/basiclayer/pgfcorequick.code.tex)(c:/texlive/2017/texmf-dist/tex/generic/pgf/basiclayer/pgfcoreobjects.code.tex)(c:/texlive/2017/texmf-dist/tex/generic/pgf/basiclayer/pgfcorepathprocessing.code.tex)(c:/texlive/2017/texmf-dist/tex/generic/pgf/basiclayer/pgfcorearrows.code.tex)(c:/texlive/2017/texmf-dist/tex/generic/pgf/basiclayer/pgfcoreshade.code.tex)(c:/texlive/2017/texmf-dist/tex/generic/pgf/basiclayer/pgfcoreimage.code.tex(c:/texlive/2017/texmf-dist/tex/generic/pgf/basiclayer/pgfcoreexternal.code.tex))(c:/texlive/2017/texmf-dist/tex/generic/pgf/basiclayer/pgfcorelayers.code.tex)(c:/texlive/2017/texmf-dist/tex/generic/pgf/basiclayer/pgfcoretransparency.code.tex)(c:/texlive/2017/texmf-dist/tex/generic/pgf/basiclayer/pgfcorepatterns.code.tex)))(c:/texlive/2017/texmf-dist/tex/generic/pgf/modules/pgfmoduleshapes.code.tex)(c:/texlive/2017/texmf-dist/tex/generic/pgf/modules/pgfmoduleplot.code.tex)(c:/texlive/2017/texmf-dist/tex/latex/pgf/compatibility/pgfcomp-version-0-65.sty)(c:/texlive/2017/texmf-dist/tex/latex/pgf/compatibility/pgfcomp-version-1-18.sty)) (c:/texlive/2017/texmf-dist/tex/latex/pgf/utilities/pgffor.sty(c:/texlive/2017/texmf-dist/tex/latex/pgf/utilities/pgfkeys.sty(c:/texlive/2017/texmf-dist/tex/generic/pgf/utilities/pgfkeys.code.tex))(c:/texlive/2017/texmf-dist/tex/latex/pgf/math/pgfmath.sty(c:/texlive/2017/texmf-dist/tex/generic/pgf/math/pgfmath.code.tex))(c:/texlive/2017/texmf-dist/tex/generic/pgf/utilities/pgffor.code.tex(c:/texlive/2017/texmf-dist/tex/generic/pgf/math/pgfmath.code.tex)))(c:/texlive/2017/texmf-dist/tex/generic/pgf/frontendlayer/tikz/tikz.code.tex(c:/texlive/2017/texmf-dist/tex/generic/pgf/libraries/pgflibraryplothandlers.code.tex)(c:/texlive/2017/texmf-dist/tex/generic/pgf/modules/pgfmodulematrix.code.tex)(c:/texlive/2017/texmf-dist/tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibrarytopaths.code.tex))) (c:/texlive/2017/texmf-dist/tex/latex/tools/xspace.sty) (c:/texlive/2017/texmf-dist/tex/latex/l3packages/l3keys2e/l3keys2e.sty)(c:/texlive/2017/texmf-dist/tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibraryarrows.code.tex(c:/texlive/2017/texmf-dist/tex/generic/pgf/libraries/pgflibraryarrows.code.tex))(c:/texlive/2017/texmf-dist/tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibrarydecorations.pathmorphing.code.tex(c:/texlive/2017/texmf-dist/tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibrarydecorations.code.tex(c:/texlive/2017/texmf-dist/tex/generic/pgf/modules/pgfmoduledecorations.code.tex))(c:/texlive/2017/texmf-dist/tex/generic/pgf/libraries/decorations/pgflibrarydecorations.pathmorphing.code.tex))(c:/texlive/2017/texmf-dist/tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibrarytrees.code.tex)) (c:/texlive/2017/texmf-dist/tex/latex/tools/afterpage.sty)******************************************************Stock height and width: 845.04684pt by 597.50787ptTop and edge trims: 0pt and 0ptPage height and width: 845.04684pt by 597.50787ptText height and width: 639.15155pt by 448ptSpine and edge margins: 59.73816pt and 89.63971ptUpper and lower margins: 113.81102pt and 92.08427ptHeadheight and headsep: 17.5pt and 35ptFootskip: 35ptColumnsep and columnseprule: 10pt and 0ptMarginparsep and marginparwidth: 17pt and 51ptSidecapsep and sidecapwidth: 7pt and 51ptSidebarhsep and sidebarwidth: 7pt and 51ptSidebarvsep and sidebartopsep: 17.5pt and 0ptSidebarheight: 589.74994ptSidefoothsep and sidefootwidth: 7pt and 51ptSidefootvsep and sidefootheight: 17.5pt and 589.74994pt******************************************************(./lyluatex.sty(c:/texlive/2017/texmf-dist/tex/luatex/luatexbase/luatexbase.sty(c:/texlive/2017/texmf-dist/tex/luatex/ctablestack/ctablestack.sty))(c:/texlive/2017/texmf-dist/tex/latex/oberdiek/kvoptions.sty(c:/texlive/2017/texmf-dist/tex/generic/oberdiek/ltxcmds.sty)(c:/texlive/2017/texmf-dist/tex/generic/oberdiek/kvsetkeys.sty(c:/texlive/2017/texmf-dist/tex/generic/oberdiek/infwarerr.sty)(c:/texlive/2017/texmf-dist/tex/generic/oberdiek/etexcmds.sty)))(c:/texlive/2017/texmf-dist/tex/latex/keycommand/keycommand.sty(c:/texlive/2017/texmf-dist/tex/latex/etex-pkg/etex.styPackage etex Warning: Extended allocation already in use.(etex)                etex.sty code will not be used.(etex)                To force etex package to load, add(etex)                \RequirePackage{etex}(etex)                at the start of the document.) (c:/texlive/2017/texmf-dist/tex/latex/xkeyval/xkeyval.sty(c:/texlive/2017/texmf-dist/tex/generic/xkeyval/xkeyval.tex(c:/texlive/2017/texmf-dist/tex/generic/xkeyval/xkvutils.tex)))(c:/texlive/2017/texmf-dist/tex/latex/etoolbox/etoolbox.sty))(c:/texlive/2017/texmf-dist/tex/latex/environ/environ.sty(c:/texlive/2017/texmf-dist/tex/latex/trimspaces/trimspaces.sty))(c:/texlive/2017/texmf-dist/tex/latex/currfile/currfile.sty(c:/texlive/2017/texmf-dist/tex/latex/filehook/filehook.sty(c:/texlive/2017/texmf-dist/tex/latex/filehook/filehook-memoir.sty))))! LaTeX Error: Option clash for package lyluatex.See the LaTeX manual or LaTeX Companion for explanation.Type  H <return>  for immediate help. ...l.43?
--

Who can help me?

If lyluatex is to be a drop-in replacement for lilypond-book Then the goal should be to support all the lilypond-book music fragment options. This list is intended to keep track of what is currently supported and what is not:

• staffsize=ht
• ragged-right
• noragged-right
• line-width
• line-width=size\unit
• papersize=string
• notime
• fragment
• nofragment
• indent=size\unit
• noindent
• quote
• exampleindent
• relative
• relative=n

There are also the following options which are specifically designed for LilyPond's documentation and thus of lower priority:

• verbatim
• addversion
• texidoc
• doctitle
• nogettext
• printfilename

When we have insert=systems the vertical alignment should be handled differently when the system happens to be at the top or bottom of a page.

Currently to top edge of the PDF will be at the top edge of the type area, but actually it should be handled just like the margins for fullpage scores.

The following code doesn’t compile. \center-column seems to be split into \center and -column before the LilyPond parser can recognize it. (\column instead of \center-column works and only the LilyPond code fed to LilyPond directly also works.)

\documentclass{article}
\usepackage{lyluatex}

\begin{document}
\begin{lilypond}
	\relative {
		\set Staff.instrumentName = \markup \center-column { "abc" "def" }
		c'
	}
\end{lilypond}
\end{document}

from the LuaLaTeX/LilyPond log:

Analysieren...
-:35:49: Fehler: syntax error, unexpected NUMBER_IDENTIFIER
\relative { \set Staff.instrumentName = \markup 
                                                \center -column { "abc" "def" } c' }
-:35:57: Fehler: not a note name: -column
\relative { \set Staff.instrumentName = \markup \center 
                                                        -column { "abc" "def" } c' }

[…]

f/tex/latex/local/lyluatex.lua:137: attempt to index local 'i' (a nil value)
stack traceback:
	/home/malte/texmf/tex/latex/local/lyluatex.lua:137: in function 'retour_tex'
	/home/malte/texmf/tex/latex/local/lyluatex.lua:51: in function 'direct_ly'
	[\directlua]:1: in main chunk.
\env@compilerly@process ...g {\localstaffsize } )}
                                                  \env@ignore 
l.10 \end{lilypond}
                 
?