I would need to start working on my project again, using luatex, lilypond, lyluatex and lilyglyphs. But lilyglyphs appears to be missing from the ubuntu packages. This summer I upgraded to 20.04 though, and I found out to my surprise, lilyglyphs is missing. It is present in 'eoan' though.
I already contacted the developer but only heard from him it is missing indeed and he did not know why either.
Maybe someone here knows what has been going on.
If there won't be an update, adding lilyglyphs to the package texlive-music again, maybe someone here can help me with a workaround to get it installed. I already tried what was explained in the documentation, but that did not seem to work.
thanks for reminding.
Am Freitag, den 28.08.2020, 21:20 +0200 schrieb bart deruyter:
I asked on the texlive mailing list, and I got an answer, but I didn't manage following through
Am Freitag, den 03.07.2020, 07:41 +0900 schrieb Norbert Preining:
So the workaround would be to either update the helper scripts to Python 3 or to drop these scripts. Off the top of my head I don't know how important these scripts actually are or how complex it would be to update them.
They are used to create sets of new notation elements. IIRC.
My personal gut feeling would be to drop support for lilyglyphs altogether because lyluatex can do everything lilyglyphs can, and better - i.e. without the need for pre-compiled PDFs. But - and that's a big but - the advantage of lilyglyphs is that it doesn't need to run LilyPond. *I* will always have LilyPond around, but for a general audience this would be a major limitation, I think.
Thanks for the update, I'll look into how I can change my document so it uses lyluatex only. I used lyluatex to include complete scores in my document, not for single musical signs, for that I used lilyglyphs.
Actually I'm considering to drop the latex road and switch to libreoffice, for one big important reason: epub, and I need the epub format because of the pandemic. I expect more Covid-19 related shutdowns of the schools I work for, and my students use mobile devices very often. On these pdf's are often not good, they don't scale good, epub does.
There is one important reason to keep lilyglyphs: compatibility with older documents.
If I get what I need from lyluatex it's OK for me personally to drop support for it, I haven't used it that often, I can handle fixing that, but I doubt I'm the only one having documents using lilyglyphs.
I do revisit older files too and when my pdf's fail to compile because of issues like these, needing to update something urgently, I think everybody can agree that is not a very happy moment.
I was lucky it was not urgent. I really can't believe I'm the only one having used lilyglyphs, so I'm afraid, dropping support for it all together will result in many 'not very happy moments'.
Op vr 28 aug. 2020 om 22:06 schreef Urs Liska <[hidden email]>:
Am Samstag, den 29.08.2020, 14:14 +0200 schrieb bart deruyter:
That's the idea, yes.
A workaround is to use lyluatex with insert=bare-inline, which includes the music without a staff.
The significant advantage of this approach is that it doesn't have to choose between Emmentaler glyphs and composed music.
Indeed. I would prefer keeping lilyglyphs available. But I'm afraid there are issues beyond the Python dependency (which shouldn't be too complicated after all). I had started fiddling around with a LuaLaTeX-only version making use of new functionality, and IIRC I got stuck with various issues. Maybe the best way to go forward would be to reset lilyglyphs to the last released version and simply update the Python stuff ...
I hope to find the time to look inzto that.
|Free forum by Nabble||Edit this page|