jperon / lyluatex Goto Github PK
View Code? Open in Web Editor NEWAlternative à lilypond-book pour lualatex
License: MIT License
Alternative à lilypond-book pour lualatex
License: MIT License
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.
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.
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
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).
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.
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?
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?
Is it intentional that the .eps
files are still present in the output 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.
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.
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.
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.
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
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.
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.
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 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.
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
\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'}
).
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.
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:
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?
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.
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):
*(the source code used to produce this can be found as test-alignment.tex
)
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
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
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).
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.
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?
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.
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.
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
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
What options do we have?
musicexamples
into lyluatex
lyluatex
into musicexamples
musicexamples
to a state where it can be published on CTAN)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
lyluatex
as it is, aiming for more versatility and configurabilitymusicexamples
up to par (and publish it), review the implementation, and remove all the attempts at working on the LilyPond compilation partThe 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.
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
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?
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):
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 ...
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.
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 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.
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.
Currently the file to be included by \lilypondfile
is searched for
CURRFILEDIR
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
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}
Till now :
hash_output_filename
;lyluatex.sty
, and when defining ly
and lily
.This should be refactored :
\lysetoption{OPTION}
, that would change each parameter ;hash_output_filename
, and include them in the hash instead of defining very long filenames (that may only get longer while adding options) ;ly
and lily
's options.That way, every option could be defined :
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.
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 \include
d 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.
I will now start reviewing the musicexamples
package, with three main targets:
lyluatex
now doeslyluatex
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.
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?
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:
There are also the following options which are specifically designed for LilyPond's documentation and thus of lower priority:
Add a label
argument (which will only make sense as a local option, of course).
\label
after the imagemusicexamples
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.
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}
?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.