Re: Inquiry about Feature Suggestions for LilyPond
Thanks, I'll check it out. On Wed, Sep 27, 2023 at 2:38 PM Jean Abou Samra wrote: > > Le 27 sept. 2023 à 23:33, Peter X a écrit : > > Could you kindly guide me on the appropriate channel or procedure to > formally suggest this feature? I understand that there might be a specific > format or platform where such suggestions are reviewed and discussed. > > > > Welcome. The procedure for requesting features is mostly the same as for > reporting bugs. See https://lilypond.org/bug-reports.html . In short, you > should write to the bug-lilypond mailing list. >
Inquiry about Feature Suggestions for LilyPond
Dear LilyPond Development Team, I hope this email finds you well. My name is Peter Xu, and I have been a dedicated user of LilyPond for some time now. First and foremost, I would like to express my gratitude for the hard work and dedication you have put into developing such an exceptional software. LilyPond has greatly enhanced my workflow and has been instrumental in many of my projects. Recently, while working with the software, I came across a potential feature or improvement that I believe could benefit many users. I'm keen on sharing this with the team and contributing to the ongoing betterment of LilyPond. Could you kindly guide me on the appropriate channel or procedure to formally suggest this feature? I understand that there might be a specific format or platform where such suggestions are reviewed and discussed. Thank you in advance for your assistance and direction on this matter. I'm looking forward to contributing in any way I can to further enhance this wonderful software. Best regards, Peter Xu peterandu...@gmail.com
Re: Binaries of LilyPond 2.23.5 with Guile 2.2
Hi Jonas, your version works on my MXLinux Laptop. Tomorrow I am going to try Ubuntu and MacOS Monterey on Apple Silicon. Thanks for these works to you and all others engaged in this endeavor! Jan-Peter Am 03.12.21 um 19:17 schrieb Jonas Hahnfeld via Discussions on LilyPond development: > Hi all, > > here are the binaries of LilyPond 2.23.5 with Guile 2.2, created > exactly with the scripts contained in the official source tar: > https://gitlab.com/hahnjo/lilypond/-/packages/4049140 > (For now I've published them on my repo, but I can also add them to the > official one and link it from the GitLab release if people think so.) > > "Installation" is quite simple: > 1. Unpack the right archive for your OS (Linux, macOS, Windows). > 2. Use it from any location you want, for example by setting PATH or > just pointing Frescobaldi to bin/lilypond. > > Please give this some serious testing as this might become official at > some point. I'd be especially grateful for testing on macOS (later than > 10.14) since I don't have a system myself and cannot test outside of > the MacStadium node that I used for building (but that obviously has > stuff installed to compile LilyPond, so I might not have noticed if > some library is missing...) > > Cheers > Jonas
Re: Export from LilyPond to MusicXML (Thomas Morley)
> Am 08.10.2021 um 12:04 schrieb David Kastrup : > > Jan-Peter Voigt writes: > >> Hi all, >> >> probably what I am writing now is not new to most of you. About a year >> ago there was a discussion regarding the license of Lilypond, triggered >> by Urs' question about the future of OLL. Again and again the >> documentation was referred to, which says that Lilypond is a compiler >> that translates the source code into a PDF. For God's sake, I don't want >> to discuss the licensing consequences again, but I want to point out >> that this representation is not exactly complete. In fact, each source >> file is translated into a Lilypond internal executable, the execution of >> which then generates the PDF. > > Uh, no? Calling LilyPond's internal representation of music an > "executable" is nonsensical since it does not imply any actions but is a > structural representation of music. Ok, my designation as internal executable is certainly not a good picture. My point is that this process is not a pure translation language A to language B. Whatsoever, this is not the topic I want to discuss. > There never is any linear > representation being "executed", and source files are interpreted rather > than compiled, with no file-level representation ever being explicit. Well at least a (Scheme) Engraver can be used to instruct that a note head be painted red if it is the third moment in the measure. Alternatively, this information can be given to each affected notehead via override. The source file is interpreted, as you write, and not compiled, as written in the documentation. (https://lilypond.org/windows.html, https://lilypond.org/macos-x.html, https://lilypond.org/unix.html: "Compiling a file") > That's not an academic difference since it is a non-trivial question > just what the structure of a MusicXML file is supposed to represent from > a given LilyPond input file. Yes, that is essentially what I wanted to say. Jan-Peter
Re: Export from LilyPond to MusicXML (Thomas Morley)
Hi all, probably what I am writing now is not new to most of you. About a year ago there was a discussion regarding the license of Lilypond, triggered by Urs' question about the future of OLL. Again and again the documentation was referred to, which says that Lilypond is a compiler that translates the source code into a PDF. For God's sake, I don't want to discuss the licensing consequences again, but I want to point out that this representation is not exactly complete. In fact, each source file is translated into a Lilypond internal executable, the execution of which then generates the PDF. This architecture is representable in XML, if it is possible at all, only with extensions to MEI or MusicXML. So the goal should only be to implement the graphical representation accordingly. But this also means that structures that serve a better organization of the lilypond source code will most likely be lost during export and re-import. Several solutions for the export have now been mentioned. Behind these are three concepts, all of which have their justification: 1. convert source-based (python-ly accessible through frescobaldi). 2. lilypond internal generation of an intermediate code 3. scheme based generation of an intermediate code If the sources comply, i.e. do not contain Scheme, then the python-ly solution is quite charming, fast and batchable. But I would find the internal generation of an intermediate code, as envisioned and developed by Jacques, the nicest. The Scheme based solution I started from the pragmatic consideration that if it works, it can be quickly adapted and deployed in different environments. I'm very glad to see this discussion revisited. Maybe something more can be developed together in this direction. For this reason, I am also pushing the discussion to the devel list. ;-) I'll be on the road for the next week, but I plan to get back to the topic after that. Cheers, Jan-Peter Am 07.10.21 um 22:51 schrieb Thomas Morley: > Am Do., 7. Okt. 2021 um 13:32 Uhr schrieb Jean Abou Samra > : >> >> Harm, >> >> Le 07/10/2021 à 11:46, Thomas Morley a écrit : >>> Not sure Jan-Peter's approach is the best method ... >> >> What makes you think so? >> >> Best, >> Jean > > Maybe my wording was misleading. > > I tested ly->musicxml with > (1) openlilylib, i.e. Jan-Peter > (2) python-ly > (3) Frescobaldi > (4) https://github.com/de-wolff/lilypond.git > > Then tried reimporting the resulting xml-file via > (a) musicxml2ly > (b) xml2ly > > All results were terrible. Here I stopped frustrated. > I did not look into any code, thus I simply don't know which one is > the most promising approach. > > Cheers, > Harm >
Re: music21
Am 13.09.20 um 22:57 schrieb Jean Abou Samra:
> The Net is a surprisingly vast place. Did you ever hit this link?
>
> http://web.mit.edu/music21/
>
> It's a Python library that, among musicological tasks, features
> import from a dozen of different file formats, including MusicXML,
> MIDI and ABC, as well as export to LilyPond.
>
> Performing the conversion seems to be as simple as
>
> from music21 import *
> converter.parse('/path/to/input.[ext]').write('lilypond',
> '/path/to/output.ly')
>
> I have been unsuccessfully trying to show `make check` output when
> using this converter… See the dev/jas/test-music21-2 branch in case
> you're interested. Anyway, here is a simple ABC file:
>
> X:1
> T:Notes
> M:C
> L:1/4
> K:C
> C, D, E, F,|G, A, B, C|D E F G|A B c d|e f g a|b c' d' e'|f' g' a' b'|]
>
> Attached are four LilyPond files. Two of them are produced using abc2ly
> and music21. The remaining two are the result of processing music21
> MusicXML output via musicxml2ly and xml2ly.
>
> Neither option is perfect; the xml2ly route seems to do the best job
> though.
>
> I'm running out of time for LilyPond right now, but I wanted to
> mention this
> thing. Maybe we can make a good anything2ly converter out of it, possibly
> pairing its MusicXML support with xml2ly. Being a Python library makes it
> easy to include in Frescobaldi.
>
> Cheers,
> Jean -- in a puzzled state of mind.
>
Music21 is a great tool I had to use recently. MusicXML im- and export
is very good. The Lilypond-export should be improved and Lily-import
would need some preprocessing, but I am going to look at it.
Jan-Peter
Re: (scheme-)engraver in 2.20/21
Am 24.09.20 um 16:28 schrieb Aaron Hill: > I doubt this is the sort of thing convert-ly could patch, so the > proposed change in behavior would break user-created engravers that > expect to always get a pair of (start|stop)-translation-timestep calls. > As such, it makes far more sense that LilyPond automatically take care > of invoking start-translation-timestep after initialize. OK that sounds reasonable > The argument for uniform behavior is sound, though one must be careful > the behavior to which you are aligning is correct. My vote is that > "starts" and "stops" must always be paired. If there were cases where > "start" was not occurring, *that* is the faulty behavior to address. I agree. For now I can live with the faulty but uniform behaviour, but a change in that direction should be developed.
private ly:version?
Hi all, I now have a use case for ly:version? documented in http://lilypond.org/doc/v2.21/Documentation/usage/writing-code-to-support-multiple-versions But the function is module-private in lily. The example on that page does not compile and so doesn't any external file. I can work around it with #(define ly:version? (@@ (lily) ly:version?)) But I guess that is not intended? I might change the define to define-public in 'scm/lily-library.scm'? Jan-Peter
Re: (scheme-)engraver in 2.20/21
Hi Dan, Am 24.09.20 um 13:42 schrieb Dan Eble: > On Sep 24, 2020, at 05:51, Jan-Peter Voigt wrote: >> >> Hi all, >> >> after some other very involving projects I can now refocus on lilypond :-) >> >> I probably missed a change in 2.20/21. If I create a scheme-engraver the >> "start-translation-timestep" slot is not called, if the "initialize" >> slot has been called in this particular timestep. If this the intended >> behaviour I appreciate it because it is consistent. The "start-trans.." >> slot wasn't called before for instant voices, but for regular installed >> contexts. So now I have to finish "initialize" of the engraver with >> "start-trans..." in any case. >> >> So my question is if this is intended and not likely to change? >> Sorry, if I missed discussion about this! > > This change was intended. thank you! I stumbled across this looking at the edition-engraver. Even though Aaron's objection is not entirely unjustified, I prefer this uniform behavior. That means, the last action of "initialize" is always "start-trans...". > > https://gitlab.com/lilypond/lilypond/-/merge_requests/292 > > specifically, commit fe9242659305dce587bd1fcdcc7b0ac62df25ad6 > — > Dan >
Re: (scheme-)engraver in 2.20/21
Am 24.09.20 um 13:40 schrieb Aaron Hill: > On 2020-09-24 2:51 am, Jan-Peter Voigt wrote: >> Hi all, >> >> after some other very involving projects I can now refocus on lilypond >> :-) >> >> I probably missed a change in 2.20/21. If I create a scheme-engraver the >> "start-translation-timestep" slot is not called, if the "initialize" >> slot has been called in this particular timestep. If this the intended >> behaviour I appreciate it because it is consistent. The "start-trans.." >> slot wasn't called before for instant voices, but for regular installed >> contexts. So now I have to finish "initialize" of the engraver with >> "start-trans..." in any case. >> >> So my question is if this is intended and not likely to change? >> Sorry, if I missed discussion about this! >> >> I have a demo below, where you can see that "start-trans..." is not >> called, if "initialize" has been called before in the same timestep. > > It would seem that initialize/finalize are primarily concerned with the > lifetime of the context whereas (start|stop)-translation-timestep deal > with moving from one moment to the next in music. As such I do not see > these things as related, so what would be the reason for initialize to > trump start-translation-timestep? > I am curious more about the statement that start-translation-timestep > was not "called before for instant voices, but for regular installed > contexts". Do you have a MWE that demonstrates this behavior? Running > the code you already provided against 2.18.2 and 2.19.55 (both via > lilybin.com), and 2.20.0 locally show the call to > start-translation-timestep after initialize for all three contexts. > > > -- Aaron Hill > The problem occured with the edition-engraver addressing instant voices. When I run my example with 2.19.84 the voice-contexts created by <<...>> miss the start-trans..-slot, but it is called for the first voice and moment.
(scheme-)engraver in 2.20/21
Hi all,
after some other very involving projects I can now refocus on lilypond :-)
I probably missed a change in 2.20/21. If I create a scheme-engraver the
"start-translation-timestep" slot is not called, if the "initialize"
slot has been called in this particular timestep. If this the intended
behaviour I appreciate it because it is consistent. The "start-trans.."
slot wasn't called before for instant voices, but for regular installed
contexts. So now I have to finish "initialize" of the engraver with
"start-trans..." in any case.
So my question is if this is intended and not likely to change?
Sorry, if I missed discussion about this!
I have a demo below, where you can see that "start-trans..." is not
called, if "initialize" has been called before in the same timestep.
Jan-Peter
\version "2.21.5"
#(define (show trans slot)
(let ((port (current-error-port)))
(display slot port)(display "\t" port)
(display (ly:context-current-moment (ly:translator-context trans))
port)
(newline port)))
eng =
#(make-engraver
((initialize trans)
(show trans "* initialize"))
((start-translation-timestep trans)
(show trans "> start-translation-"))
((process-music trans)
(show trans " process-music"))
((stop-translation-timestep trans)
(show trans "< stop-translation-"))
((finalize trans)
(show trans "! finalize ")) )
\layout {
\context {
\Voice
\consists #eng
}
}
\relative { c''8 b bes a << { as g fis g } \\ { es e dis e } >> }
Goodbye
Circumstances have dictated that I shall no longer be able to take part in discussions on this platform. I would like to take this opportunity to thank everyone here for their help, and offer my apologies, especially to Federico, Harm and David, for not being able to follow through with the help you have given me with the documentation. Best wishes to all, Peter mailto:lilyp...@ptoye.com www.ptoye.com
Re: Doc: Some miscellaneous suggestions from Peter Toye (issue 579280043 by michael.kaepp...@googlemail.com)
Sunday, February 9, 2020, 2:09:09 PM, you wrote:
>> On 9 Feb 2020, at 13:23, lilyp...@ptoye.com wrote:
>>
>> -
>> Friday, February 7, 2020, 8:39:36 PM, you wrote:
>>
>>> Am 06.02.2020 um 22:55 schrieb
>>> thomasmorle...@gmail.com:
https://codereview.appspot.com/579280043/diff/563480043/Documentation/learning/common-notation.itely
File Documentation/learning/common-notation.itely (right):
https://codereview.appspot.com/579280043/diff/563480043/Documentation/learning/common-notation.itely#newcode162
Documentation/learning/common-notation.itely:162: @notation{note names}
and @notation{accidentals},
Here I disagree.
> From wikpedia https://en.wikipedia.org/wiki/Alteration
"In music, alteration is the use of a neighboring pitch in the chromatic
scale in place of its diatonic neighbor."
An _accidental_ is the printed ♯-sign or ♭-sign, etc, indicating the
alteration.
Thus "accidentals" is plain wrong here. Please keep "alterations"
>>> That were my thoughts, too.
>>> But I ascribe more importance to Peter's
>>> opinion (as a native speaker)
>>> than to mine, so
>>> it is difficult for me to decide now...
>>
>> Is 'alteration' an American English term? I've never heard it in British
>> English. But our languages diverge... Are there any US speakers in this
>> discussion? Wikipedia tends to have a US bias IMHO.
> +1, with respect to accidentals. I'm an en_GB speaker.
>>
>> 'Alteration' does not appear at all as a heading in the Oxford Companion to
>> Music. However, 'accidental' is defined as a 'sign used in musical
>> notation', which rather leaves open the question of how to describe a change
>> to a note in the abstract. Something I've not really thought about. Hmmm...
> From a speed-reading of Gould, it appears that
> she uses the verb "alter" and the adjective
> "altered", but _not_ the noun "alteration" in this context.
> It is worth noting that "alteration" has a very
> specific and well-established meaning in early
> music. This meaning has nothing whatsoever to
> do with pitch. I've, ahem, altered that
> Wikipedia disambiguation page accordingly.
> The original section header in the LM seemed
> fine to me, but if it needs to change, how about
> "Note names and use of accidentals" ? It seems
> to me that a user wanting to use the document to
> figure out how to specify an accidental, is
> quite likely to search for that word.
I like that one.
>>
>> But this leaves me very unhappy about NR 1.1.1.4, which is called
>> 'accidentals' when the first sentence is describing alterations: cis in D
>> major is an alteration, not an accidental.
>>
Probably:
@notation{note names} and their @notation{alterations},
https://codereview.appspot.com/579280043/
Re: Doc: Some miscellaneous suggestions from Peter Toye (issue 579280043 by michael.kaepp...@googlemail.com)
-
Thursday, February 6, 2020, 3:00:35 PM, you wrote:
> An important nit to check...
> Besides this, LGTM, thanks!
> https://codereview.appspot.com/579280043/diff/567170044/Documentation/notation/input.itely
> File Documentation/notation/input.itely (right):
> https://codereview.appspot.com/579280043/diff/567170044/Documentation/notation/input.itely#newcode464
> Documentation/notation/input.itely:464:
> @code{αβγXII} or @code{Теноры}
> work.
> Not sure whether this works. We are using
> Computer Modern fonts for
> typesetting the PDF manuals; this font family
> comes with some (limited)
> Greek support, but it doesn't contain glyphs for Russian... Please
> check the resulting PDFs to be sure!
I didn't know this. But check
https://www.fontsquirrel.com/fonts/computer-modern which says that Computer
Modern supports the Russian language (which I assume means that it has Cyrillic
glyphs).
> https://codereview.appspot.com/579280043/
Re: Documentation suggestions.
Dear Michael, That's very kind of you. When my life gets sorted out I may return to the fray. I've got a few comments below. I don't have a Reitveld account so can't reply there. Should I get one? I have another small patch for LR: Section 1.1.4 the first example needs the version number correcting to whatever the next publication references. The other uses of \version are OK. Best regards, Peter - Wednesday, February 5, 2020, 1:08:55 PM, you wrote: > Hello Peter, > Am 04.02.2020 um 10:44 schrieb Peter Toye: >> I'm posting this here, as no-one on the devel list has answered, although >> most of the discussion went on in that list. > I think that many developers spend their effort on core topics like the > guile-2/3 transition, > or improving the contribution process, etc. at the moment. > I prepared a patch, mostly following your suggestions. Now every > developer can discuss your suggestions > during the formal code review procedure. I thought that too. > The review is here: > http://codereview.appspot.com/579280043 > The tracker issue is: > https://sourceforge.net/p/testlilyissues/issues/5738/ >> LM 1.2.1 Simple notation. Add a paragraph after the 1st music example: >> >> Note-names in all examples use the English or Dutch naming system >> (white piano keys are C-B). > As Kieren pointed out it cannot be the English system (at least if > alterations come into play), > I think it is sufficient to mention the Dutch system. I didn't give you a very good patch - I really should have said "Note-names in all examples in this section...". Later sections use alterations/accidentals freely, of course. I'm slightly worried that new users who aren't Dutch will immediately be put off LilyPond by not understanding the very first real example, or thinking that they have to learn Dutch names for all the musical elements. Users of the Do-Si notation styles may like to know that they can use their native musical language. >> LM 2.1.2 Pitches and key signatures. Subsection Pitch alterations. 3rd >> paragraph >> (1)after 'alterations' add 'and note-names'. >> (2) append: >> >> The default language for note-names and alterations is >> nederlands (Dutch). >> >> A question: is "alterations" a good word throughout this subsection? The >> normal English one is "accidentals", which is used in the Music Glossary >> reference. > IMHO, alteration applys to the underlying > process of "altering" a note, > which is part of the input, > "accidental" is the graphical sign that does > show the alteration, hence > rather part of the rendering. You don't think it necessary to reference the default? Maybe that should be in Hmmm. I've never heard the word 'alteration' used in this context. If I refer (in English) to 'F sharp' I call the 'sharp' an accidental, whether it's printed or merely played/heard. 'Alter' can refer to any sort of change, not just semitone pitch adjustments. It might be an ottava sign, for instance. I also note that the corresponding section in NR 1.1.1 is titled 'Accidentals'. We should be consistent here. I agree that accidentals aren't always alterations - they may be there as a courtesy to the player, or even prefixed to every note whether or not it is necessary. >> >> NR 3.1.5 File Structure. Subsection Using variables. Add a "Known Issues" >> subsection at end: >> >> >> In addition to the normal convention for variable names [add >> reference to LM 2.4.1] variable names can include non-ASCII characters and >> non-adjacent single underscores and dashes. Any combination of characters is >> allowed if the variable name is enclosed in double quotation marks. In this >> case backslashes and double quotation marks need to be escaped with >> backslashes. I mostly used David Kastrup's text here. I see that lemzwerg has objected on the grounds that "'Alphabetic characters' and 'non-ASCII characters' are not different sets but are overlapping".. I would point out that LM 2.4.1 uses the term 'alphabetic', presumably meaning [A-Z] and [a-z]. These are all ASCII characters. My text admits the use of single underscores and dashes, lemzwerg's does not. A reference manual shold be complete, while pointing out the difference between best practice (Alpha) and other forms of variable name. I like the examples he gives, but should point out that 'HornIII' is composed entirely of ASCII characters. Maybe more useful than the made-up Greek would be a real example- try 'Теноры' >> --- >> NR 1.2.5 Bars. Sub sec
Re: Documentation suggestions.
I've now consolidated the various replies to my original suggestions - sorry
it's been so long. Unfortunately I spent far too much time fighting VirtualBox
and Linux without as much success as I'd like. So here are my - fairly small-
documentation ideas. Sorry I couldn't make formal patches but I'll be far too
busy with the real world for the next month.
Peter
LM 1.2.1 Simple notation. Add a paragraph after the 1st music example:
Note-names in all examples use the English or Dutch naming system
(white piano keys are C-B).
LM 2.1.2 Pitches and key signatures. Subsection Pitch alterations. 3rd paragraph
(1)after 'alterations' add 'and note-names'.
(2) append:
The default language for note-names and alterations is
nederlands (Dutch).
A question: is "alterations" a good word throughout this subsection? The normal
English one is "accidentals", which is used in the Music Glossary reference.
NR 3.1.5 File Structure. Subsection Using variables. Add a "Known Issues"
subsection at end:
In addition to the normal convention for variable names [add reference
to LM 2.4.1] variable names can include non-ASCII characters and non-adjacent
single underscores and dashes. Any combination of characters is allowed if the
variable name is enclosed in double quotation marks. In this case backslashes
and double quotation marks need to be escaped with backslashes.
---
NR 1.2.5 Bars. Sub section Bar and bar number checks. Add a "known issues"
section at end:
If MIDI output is selected and volta repeats are in place, the bar
number check may fail. It is best to suppress MIDI output whle checking bar
numbers.
--
NR 3.3.2 Different editions from one source. Subsection Using tags. Add before
paragraph 3 ("The arguments..."):
\tag, \keepWithTag and \removeWithTag are music functions which take a
music expression as their second argument. Thus they cannot be used to filter
items such as \book or \score blocks.
--
NR 3.2.1 Creating titles headers and footers. Subsection Default layout of
headers and footers. Rename to:
Default layout of page headers and footers
and index it as "page headers", "page footers", "headers, page", "footers,
page".
Possibly also promote it to a 3rd-level section? It doesn't have anything in
common with the previous two subsections.
Re: Is the CG out of date?
Monday, January 20, 2020, 10:17:42 AM, Michael Käppler wrote: > Am 20.01.2020 um 11:04 schrieb Michael Käppler: >> >> Attached is an extract of the CG pages we're discussing, with my recent >> (yet only local) changes. >> > Urgh, sorry. Really(tm) attached now. Just noticed a silly typo here - in 'Installing LilyDev in VirtualBox" step 11 /keybord/keyboard/ Hope it's not too late, but doesn't really matter. I was hoping to get my amendments to NR and LM organised, but haven't been able to as I've been having problems with VirualBox and am very busy now. Best regards, Peter
Re: Looking for help in configuring LilyDev in VirtualBox
Tuesday, January 28, 2020, 1:38:45 PM, Federico Bruni wrote: > Il giorno gio 23 gen 2020 alle 22:11, Federico Bruni > ha scritto: >> I will let you know when v2 is released. > Now released: > <https://github.com/fedelibre/LilyDev/releases/tag/v2> Grazie molto Best regards, Peter
Re: Looking for help in configuring LilyDev in VirtualBox
Friday, January 24, 2020, 3:29:54 PM, David Kastrup wrote: > Peter Toye writes: >> Friday, January 24, 2020, 1:32:32 PM, David Kastrup wrote: >> >> But if bash can't find the app in the first place, >> clearing the hash table wno't make much >> difference! > I have no idea what you mean by "in the first place". I mean that trying to execute lsusb by typing its name produces the bash error message saying that it can't be found. SO clearing the hash table won't have any effect. > Have you tried > hash -r > or haven't you? It is not clear from what you wrote. Yes I did, but same result. But I've found that dpkg (which I've only just found out about) says that the package isn't installed, which would explain a lot. So I've just tried using apt-get again. It came up with what look like the same set of messages, and this time lsusb works. Don't understand what went wrong the first time, but now it's sorted. Thanks for the help. Best regards, Peter
Re: Looking for help in configuring LilyDev in VirtualBox
Friday, January 24, 2020, 1:32:32 PM, David Kastrup wrote: > Peter Toye writes: >> Friday, January 24, 2020, 11:34:24 AM, Peter Toye wrote: >> >> That's easier said than done. I found the relevant package name and >> used apt-get to install it. At least, I think I did, but typing lsusb >> comes up with bash: lsusb: command not found so that's obviously not >> right. i tried searching for a file called lsusb but came up with no >> result. > hash -r > or open a new terminal window. But if bash can't find the app in the first place, clearing the hash table wno't make much difference! >> So (newbie Linux question again) - where does apt-get put the >> installed package? Or do I have to do something else first? > Should be installed where it's getting found as long as your shell is > not convinced otherwise from previous tries. But it's not getting found - that's the issue! Best regards, Peter
Re: Looking for help in configuring LilyDev in VirtualBox
Friday, January 24, 2020, 11:34:24 AM, Peter Toye wrote: > Thursday, January 23, 2020, 5:40:00 PM, Michael Käppler wrote: >> Do you think that 'lsusb' could be necessary? I think Federico's >> intention was to keep the image as small as possible, >> because one can easily install every debian >> package in the stretch repo >> afterwards. > Fine, Makes sense. I'll work out how to get it. That's easier said than done. I found the relevant package name and used apt-get to install it. At least, I think I did, but typing lsusb comes up with bash: lsusb: command not found so that's obviously not right. i tried searching for a file called lsusb but came up with no result. So (newbie Linux question again) - where does apt-get put the installed package? Or do I have to do something else first? Sorry for my ignorance. I think I shall have to buy a book - there's a wholeload in the catalogues, but I suspect most of them don't deal with this sort of question. I used to use Frisch for Unix admin help, but that looks very out of date (2009) now. Best regards, Peter
Re: Looking for help in configuring LilyDev in VirtualBox
Thursday, January 23, 2020, 9:11:34 PM, Federico Bruni wrote: > Il giorno gio 23 gen 2020 alle 18:30, Michael Käppler > ha scritto: >> >> What we both noticed was that startup occassionally fails with a >> console prompt "Enter Maintenance mode...". >> Have you ever noticed this behaviour, too? I was not able to >> reproduce it reliably, so >> it's hard to track down. > No, but I tested VirtualBox just a few times. It happens about half the time on my system, and doesn't seems to correlate with any actions I've taken when booting the guest in. As Michael suggested, I just hit ctrl-D and ignore it. > I will let you know when v2 is released. Best regards, Peter
Re: Looking for help in configuring LilyDev in VirtualBox
Thursday, January 23, 2020, 5:40:00 PM, Michael Käppler wrote: > Am 23.01.2020 um 11:45 schrieb Peter Toye: >> >> I hadn't realised that your new instructions were for the next issue >> of LilyDev. Are there any other missing bits? I noticed that some of >> the utilities for listing hardware like lsusb aren't there. > Do you think that 'lsusb' could be necessary? I think Federico's > intention was to keep the image as small as possible, > because one can easily install every debian > package in the stretch repo > afterwards. Fine, Makes sense. I'll work out how to get it. > Best regards, > Michael Best regards, Peter
Re: Looking for help in configuring LilyDev in VirtualBox
Wednesday, January 22, 2020, 10:35:45 PM, Michael Käppler wrote: Am 22.01.2020 um 14:03 schrieb Peter Toye: > Yes, I would suggest that you start from scratch again. That's because the keyboard-layout package is not installed in LilyDev v1 by default. In LilyDev v2, it will be there. I hadn't realised that your new instructions were for the next issue of LilyDev. Are there any other missing bits? I noticed that some of the utilities for listing hardware like lsusb aren't there. So the basic question is: why isn't it starting up? I used to be a Solaris sysadmin, but that ended 20 years ago and my copy of Frisch is long gone. I don't really know because I can't reproduce this behaviour on my machine. Oh dear. It looks as if I'll have to work out how to do it myself. I know there's a way of starting up programs on boot, but I've completely forgotten what it is. Will do some research. Best regards, Peter
Re: Looking for help in configuring LilyDev in VirtualBox
Wednesday, January 22, 2020, 6:43:48 AM, Michael Käppler wrote: > Am 21.01.2020 um 20:44 schrieb Peter Toye: >> Re: Looking for help in configuring LilyDev in VirtualBox >> This time after the reboot I got the same result. No sharing of >> clipboard, no more processes. Tried closing VBox and restarting it, >> but same result. > Try to start the client manually and see what happens: > /usr/bin/VBoxClient --clipboard >> >> There's one slight oddity: often (but not always) when booting the >> LilyDev guest I get an error message - a bit too long to copy the text >> so here's a screenshot: >> >> I don't know if it's significant. It doesn't change the clipboard >> behaviour. > From time to time, this happens on my machine, too. > I thought it would be a problem specific to my > combination of VirtualBox > version / host os > and guest os, but if you encounter the same problem it could be a > general issue. It's not important as long as it's not significant. I thought it might be affecting the boot process. >> It's possible that my hamfisted attempts to install LilyDev as a guest >> without all the instructions has screwed something up. I could start >> again tomorrow using the instructions you sent me and see if it makes >> any difference. > Yes, I would suggest that you start from scratch again. I made a new guest machine using your instructions. There are a few issues here: Step 3: the file names are LilyDev-1-debian-vm and the raw fle is .iso not .raw Step11: I got an error from the command: [dev@LilyDev:~]$ sudo dpkg-reconfigure keyboard-layout [sudo] password for dev: debconf: unable to initialize frontend: Dialog debconf: (No usable dialog-like program is installed, so the dialog based frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 76.) debconf: falling back to frontend: Readline dpkg-query: package 'keyboard-layout' is not installed and no information is available Use dpkg --info (= dpkg-deb --info) to examine archive files, and dpkg --contents (= dpkg-deb --contents) to list their contents. /usr/sbin/dpkg-reconfigure: keyboard-layout is not installed [dev@LilyDev:~]$ So I used the mechanism in the current CG Step 8 to change the keyboard - probably a better idea and more user-friendly. Unless, of course, the clipboard is working. After all that I tried your idea of starting the clipboard manually - it worked!! Or I'd never have managed to get the above text right :) So the basic question is: why isn't it starting up? I used to be a Solaris sysadmin, but that ended 20 years ago and my copy of Frisch is long gone. > Best regards, > Michael Best regards, Peter
Re: Context paths (and the Edition Engraver)
Am 21.01.20 um 18:50 schrieb Dan Eble:
> On Jan 21, 2020, at 11:31, Jan-Peter Voigt wrote:
>> I'd like that, though it would be a quite invasive change.
>> And if we stay with the string for the context id and then use
>> lists/paths in the \context statement like
>> \new Staff = "choir" << \new Voice = "soprano" …
>>
>> and then use
>> \context Voice = choir.soprano
>>
>> it would be inconsistent with \new = "…"
>>
>> I will write down some more text about this topic later.
>
> I see similarities with languages like CSS and XPATH select nodes in a DOM.
> Notation borrowed directly from them will not integrate well into LilyPond,
> but it might be fruitful to ask how we could modify expressions like these to
> fit in.
>
> %% find the voice in the example quoted above, very specifically
> \context Staff#choir > Voice#soprano { … } % CSS
> \context Staff[@id=choir]/Voice[@id=soprano] { … } % XPATH
>
> %% ditto, but using context type only
> \context Staff > Voice { … } % CSS
> \context Staff/Voice { … } % XPATH
>
> %% ditto, but using ID only
> \context #choir > #soprano { … } % CSS
> \context [@id=choir]/[@id=soprano] { … } % XPATH
>
> %% find the context where the rehearsalMark property is defined
> \context [rehearsalMark] { … } % CSS
> \context [@rehearsalMark] { … }% XPATH
> —
> Dan
>
I am amazed what kind of discussion is raised on this topic :)
I'd suggest alternative commands to create something like an
XQuery/CSS/whatever functionality. Elsewhere in this thread David (K)
answered to syntax ideas that would break the current model.
To have the possibility to address contexts *like* in CSS has some
appeal. But IMHO it shouldn't disturb the current input scheme. So
alternate commands might help here.
Perhaps *like*:
\getContext the.path.to.the.context
... or ...
\getContext \thisContext."..".otherContextsName
*don't know if implementing \thisContext is trivial*
The idea that an ID of a context is a list and not a string does attract
me, but I see a major change that has to be done very carefully.
If the ID is a string (or symbol) the path can be easily constructed
with ly:context-parent.
Something like:
%%
\version "2.19.83"
logContextPath = \applyContext
#(lambda (context)
(define (context-path context)
(let ((parent (ly:context-parent context)))
(if (ly:context? parent)
`(,@(context-path parent) ,(ly:context-id context))
(list (ly:context-id context)))
))
(ly:message "context path: ~A" (context-path context)))
\new Score = "mymusic" {
\new StaffGroup = "choir" <<
\new Staff = "soprano" <<
{ c''4 \logContextPath } \\
{ g'4 \logContextPath }
>>
>>
}
%%
Just some thoughts.
I hope to be able to write some more text about it soon.
But I have another task that will take up a lot of my time in the coming
weeks. You are welcome to ask me questions which I will try to answer.
But I will not be able to be active for the next weeks.
Jan-Peter
Re: Looking for help in configuring LilyDev in VirtualBox
Tuesday, January 21, 2020, 6:24:25 PM, Michael Käppler wrote: Am 21.01.2020 um 11:13 schrieb Peter Toye: Re: Looking for help in configuring LilyDev in VirtualBox Monday, January 20, 2020, 10:24:13 PM, you wrote: Am 20.01.2020 um 16:04 schrieb Peter Toye: Re: Looking for help in configuring LilyDev in VirtualBox Monday, January 20, 2020, 10:26:55 AM, you wrote: Am 20.01.2020 um 11:08 schrieb Peter Toye: Re: Looking for help in configuring LilyDev in VirtualBox Hmm...weird. Could you please check if the virtual box modules are loaded with lsmod | grep vbox Which VirtualBox version do you use? What is you host OS? lsmod gives: vboxguest2949120 There should be some more kernel modules running. Please try reinstalling the guest additions at first with: sudo apt install --reinstall virtualbox-guest-dkms virtualbox-guest-x11 virtualbox-guest-utils That didn't work: got a message: E: Command line option 'r' [from -reinstall] is not understood in combination with the other options. Seems you accidentally omitted one dash (should be --reinstall, not -reinstall) Oops - the problems of not being able to do cut-and-paste between machines. On my terminal the two '-'s merged into one. That command produced a load of output. Maybe I should have redirected it to a file. Then reboot your virtual machine. If that does not work, please post the output of ps aux | grep '/usr/bin/VBoxClient --clipboard' This time after the reboot I got the same result. No sharing of clipboard, no more processes. Tried closing VBox and restarting it, but same result. There's one slight oddity: often (but not always) when booting the LilyDev guest I get an error message - a bit too long to copy the text so here's a screenshot: I don't know if it's significant. It doesn't change the clipboard behaviour. Without rebooting (there didn't seem much point) I got: dev7010.00.011108932pts/0 S+11:100:00 grep /usr/bin/VBoxClient --clipboard which I guess is the process that I just ran. so that we can see if the shared clipboard service is running Best regards, Michael All the best, Peter It's possible that my hamfisted attempts to install LilyDev as a guest without all the instructions has screwed something up. I could start again tomorrow using the instructions you sent me and see if it makes any difference. Best regards, Peter
Re: Context paths (and the Edition Engraver)
Hi there,
> [Single-level quotes are David Kastrup’s; double-level quotes are Dan Eble’s.]
>
>> Comments from the EE crowd?
>
> Not sure how much of a "crowd" we are… ;)
at least we are 2 :)
>>> One of the things in Kieren's intro to the Edition Engraver (EE) that
>>> resonated with me was the context paths.
> […]
>>> The ability to refer to contexts this way is a great idea, though IMHO it
>>> needs some work to reduce ambiguity.
>
> I agree on both points. (Perhaps one of my first contributions in 2020 should
> be a less-ambiguous set of documented examples for the EE?)
that would of course be helpful, because my examples will always along
my development ideas and not along a foreign users view ...
>>> \context along.Voice.B { ... }
>>> \set along.Voice.B.property = #...
>>> \change Voice = ChoirStaff.A.Staff.B
>
> An interesting proposal.
I'd like that, though it would be a quite invasive change.
And if we stay with the string for the context id and then use
lists/paths in the \context statement like
\new Staff = "choir" << \new Voice = "soprano" …
and then use
\context Voice = choir.soprano
it would be inconsistent with \new = "…"
I will write down some more text about this topic later.
>> I think that this would warrant closely analysing what the EE does and
>> checking whether its way of specifying things is a natural match to what
>> might be useful with LilyPond, or at least can be made so without
>> impacting its usefulness.
>
> Agreed.
>
> Perhaps instead of the current
>
>\new Staff = "piano_upper"
>
> mechanism, we could have a
>
>\new Staff piano.upper
Though I'd like such a scheme, I'd not recommend it, because I see
breaking changes coming up ;)
> "id" that could be used for addressing by both Lilypond proper *and* the EE
> [or any other extension/addon]? Other than the obvious coding requirement to
> make the switch, is there any real impact on Lilypond itself switching from
> '= "name"' syntax to 'name' syntax? Even if Lilypond didn’t yet
> recognize/react to a path like "score.ps.piano.upper.Voice.A" (the way the EE
> already does), such a change would at least align the two
> labelling/addressing methods.
>
> Alternatively, we could consider changing the EE to do addressing the way
> it’s done in Lilypond proper… but I feel like that would be a step backwards.
>
>>> It would be wise to ask whether there are use cases
>>> for any "pronouns" (like `.` and `..` in file paths, and `this`
The dots are from the dot-notation of lists. If you type
lst = "..".hui.buh
#(display lst)
you can see that `lst` is a list with symbols #'(.. hui buh)
In my templates package I have function to canonicalize such paths. I
will import that to the EE.
> Interesting… Because of the way timing works (or, in this case, doesn’t!) in
> the EE, I sometimes have to write (e.g.)
>
>\editionMod my-edition 10 1/4 id-to-a-staff.Score \override …
this works? I thought you'D need
\editionMod my-edition 10 1/4 id-to-a-staff \override Score.…
I hope to work on the discussed topics soon, but my desktop is stuffed ...
It was an amzing weekend! Thank you all :)
Jan-Peter
Re: Looking for help in configuring LilyDev in VirtualBox
Monday, January 20, 2020, 10:24:13 PM, you wrote: Am 20.01.2020 um 16:04 schrieb Peter Toye: Re: Looking for help in configuring LilyDev in VirtualBox Monday, January 20, 2020, 10:26:55 AM, you wrote: Am 20.01.2020 um 11:08 schrieb Peter Toye: Re: Looking for help in configuring LilyDev in VirtualBox Hmm...weird. Could you please check if the virtual box modules are loaded with lsmod | grep vbox Which VirtualBox version do you use? What is you host OS? lsmod gives: vboxguest2949120 There should be some more kernel modules running. Please try reinstalling the guest additions at first with: sudo apt install --reinstall virtualbox-guest-dkms virtualbox-guest-x11 virtualbox-guest-utils That didn't work: got a message: E: Command line option 'r' [from -reinstall] is not understood in combination with the other options. Then reboot your virtual machine. If that does not work, please post the output of ps aux | grep '/usr/bin/VBoxClient --clipboard' Without rebooting (there didn't seem much point) I got: dev 701 0.0 0.0 11108 932 pts/0 S+ 11:10 0:00 grep /usr/bin/VBoxClient --clipboard which I guess is the process that I just ran. so that we can see if the shared clipboard service is running Best regards, Michael All the best, Peter
Re: Looking for help in configuring LilyDev in VirtualBox
Monday, January 20, 2020, 10:26:55 AM, you wrote: Am 20.01.2020 um 11:08 schrieb Peter Toye: Re: Looking for help in configuring LilyDev in VirtualBox Hmm...weird. Could you please check if the virtual box modules are loaded with lsmod | grep vbox Which VirtualBox version do you use? What is you host OS? lsmod gives: vboxguest 294912 0 VirtualBox 6.1 Windows 10 Home update 1903 Hope this helps. As it seems that you are keeping the CG up to date there's no point in my trying to help. We'll just get in each other's way. No, definitely not! Your help is very much appreciated! When LilyDev v2 will be out and the CG patch is in review (in a few days, maybe), it would be great if you could walk your way through the install steps again and comment on every ambiguity you noticed. And after that there will be >many< further sections in the CG that would deserve further clarification / extension. Cheers, Michael Thanks, Peter
Re: Looking for help in configuring LilyDev in VirtualBox
Michael, I have to go out now - will reply this afternoon (UK time). Best regards, Peter mailto:lilyp...@ptoye.com www.ptoye.com - Monday, January 20, 2020, 10:26:55 AM, Michael Käppler wrote: > Am 20.01.2020 um 11:08 schrieb Peter Toye: >> Re: Looking for help in configuring LilyDev in VirtualBox >> No, I didn't receive it. And it's not in my junk mailbox either, so it >> must have disappeared entirely. That's a nuisance. >> Clipboard was already activated as bidirectional. But it's not >> working. I copied text from Lilydev but there was nothing in the host >> (Windows) clipboard. I copied text from the host, and the Lilydev >> clipboard had what I just copied from Lilydev. So it seems that the >> clipboards aren't integrating. Or am I doing something wrong? > Hmm...weird. Could you please check if the > virtual box modules are loaded > with > lsmod | grep vbox > Which VirtualBox version do you use? What is you host OS? >> As it seems that you are keeping the CG up to date there's no point in >> my trying to help. We'll just get in each other's way. > No, definitely not! Your help is very much appreciated! > When LilyDev v2 will be out and the CG patch is in review (in a few > days, maybe), it would be great if you could > walk your way through the install steps again and comment on every > ambiguity you noticed. > And after that there will be >many< further sections in the CG that > would deserve further clarification / extension. > Cheers, > Michael
Re: Looking for help in configuring LilyDev in VirtualBox
Monday, January 20, 2020, 9:46:58 AM, Michael Käppler wrote: Am 20.01.2020 um 10:34 schrieb Peter Toye: Reposted with additions: I'm slowly working my way through CG Section 2.1, but have reached an impasse. In "Configuring LilyDev in VirtualBox". Step 1 tells me to "install Guest Addition...". That's been changed to "Insert..." but that's obvious. The VBoxGuestAdditions.iso CD is in the virtual drive, but it seems but there's no autorun, and clicking on it merely asks if I want to eject it. I've now worked out how to mount the CD, and I followed the instructions in the VirtualBox FAQ page to install the missing bits. But when I try to install the Guest Additions it says they're already installed. has the LilyDev distro changed to include the Guest Additions? Because, if so, I can't get the shared clipboard to work, and that's rather necessary for my setup. Hi Peter, I did answer almost immediately: Am 18.01.2020 um 13:40 schrieb Peter Toye: I'm slowly working my way through CG Section 2.1, but have reached an impasse. In "Configuring LilyDev in VirtualBox". Step 1 tells me to "install Guest Addition...". That's been changed to "Insert..." but that's obvious. The VBoxGuestAdditions.iso CD is in the virtual drive, but it seems but there's no autorun, and clicking on it merely asks if I want to eject it. It looks as if there's a step missing, as the CD doesn't seem to be mounted in the file system, which would explain everything. But I'm not sure (as a Linux newbie) where to look for it. You won't need that. The guest additions have been incorporated into LilyDev. My patch for the CG will reflect this change. If you have problems resizing the VM window to full size, try to change the Display->Graphics controller to VBoxVGA in VirtualBox settings. You can activate clipboard sharing in General->Advanced->Bidirectional. So it seems you did not receive my response? I did only reply to the list, but you should have received it, anyway. No, I didn't receive it. And it's not in my junk mailbox either, so it must have disappeared entirely. That's a nuisance. Clipboard was already activated as bidirectional. But it's not working. I copied text from Lilydev but there was nothing in the host (Windows) clipboard. I copied text from the host, and the Lilydev clipboard had what I just copied from Lilydev. So it seems that the clipboards aren't integrating. Or am I doing something wrong? As it seems that you are keeping the CG up to date there's no point in my trying to help. We'll just get in each other's way. Cheers, Michael All the best, Peter
Re: Looking for help in configuring LilyDev in VirtualBox
Reposted with additions: I'm slowly working my way through CG Section 2.1, but have reached an impasse. In "Configuring LilyDev in VirtualBox". Step 1 tells me to "install Guest Addition...". That's been changed to "Insert..." but that's obvious. The VBoxGuestAdditions.iso CD is in the virtual drive, but it seems but there's no autorun, and clicking on it merely asks if I want to eject it. I've now worked out how to mount the CD, and I followed the instructions in the VirtualBox FAQ page to install the missing bits. But when I try to install the Guest Additions it says they're already installed. has the LilyDev distro changed to include the Guest Additions? Because, if so, I can't get the shared clipboard to work, and that's rather necessary for my setup. If someone could help I'd be most grateful. I realise that this mailing list isn't for support, but it seemed more relevant than the user mailing list. Peter
Re: Is the CG out of date?
Thursday, January 16, 2020, 7:40:55 PM, you wrote: > Hello, > On 16/01/2020 14:52, Peter Toye wrote: >> Tuesday, January 14, 2020, 10:31:49 PM, you wrote: >> >> It looks as if one of my jobs is going to be bringing the CG up to date. But >> as I'm a total newbie here I'll need support in making sure that anything I >> write is accurate. Will the LilyDev system be likely to change in the near >> future? In that case there wouldn't be any point. >> > Perhaps the best way would be to 'remove' > information from the CG and > replace it with reference/links to the github location rather than > duplicate instructions. Good idea.. But until I can get an answer to the mail I posted on this list on 18th I can't do anything at all :( > James Peter
Looking for help in configuring LilyDev in VirtualBox
I'm slowly working my way through CG Section 2.1, but have reached an impasse. In "Configuring LilyDev in VirtualBox". Step 1 tells me to "install Guest Addition...". That's been changed to "Insert..." but that's obvious. The VBoxGuestAdditions.iso CD is in the virtual drive, but it seems but there's no autorun, and clicking on it merely asks if I want to eject it. It looks as if there's a step missing, as the CD doesn't seem to be mounted in the file system, which would explain everything. But I'm not sure (as a Linux newbie) where to look for it. If someone could help I'd be most grateful. I realise that this mailing list isn't for support, but it seemed more relevant than the user mailing list. Regards, Peter mailto:lilyp...@ptoye.com www.ptoye.com
Re: Is the CG out of date?
Dear Federico, Thanks. The GitHub file has the changed file name (which I'd worked out), but links to the CG documentation which says to install it as Fedora rather than Debian. I'm a Linux newbie, and don't know if it will make any difference. Any hints are welcome. Best regards, Peter mailto:lilyp...@ptoye.com www.ptoye.com - Tuesday, January 14, 2020, 10:31:49 PM, you wrote: > Il giorno mar 14 gen 2020 alle 18:21, Peter > Toye > ha scritto: >> I'm trying to work out how to run LilyDev in VirtualBox on a Windows >> system., but the information in section 2.1 of the CG seems to be >> inaccurate, and I suspect it's a bit out of date. >> >> Under "Installing LilyDev in VirtualBox" the filename is given as >> lilydev-vm-fedora-VERSION.raw but the downloaded version form the >> website was LilyDev-1-debian-vm.zip >> >> I assume that this is correct, but in that case should I install it >> as Debian rather than Fedora? >> > Yes, the CG is not up-to-date. > Please follow the README files in Github.
Is the CG out of date?
I'm trying to work out how to run LilyDev in VirtualBox on a Windows system., but the information in section 2.1 of the CG seems to be inaccurate, and I suspect it's a bit out of date. Under "Installing LilyDev in VirtualBox" the filename is given as lilydev-vm-fedora-VERSION.raw but the downloaded version form the website was LilyDev-1-debian-vm.zip I assume that this is correct, but in that case should I install it as Debian rather than Fedora? Regards, Peter mailto:lilyp...@ptoye.com www.ptoye.com
Re: Poster for music engraving conference
Hello Fellows, in December Werner asked for a poster for the conference. Did somebody actually produce something? The last days I tried something based on the baposter-LaTeX-class. I'll not be able to finish the poster on my own until monday ... , but if you'd like to collaborate on this topic or you have a poster, I can donate some content to, please let me know! Jan-Peter Am 04.12.19 um 12:05 schrieb Werner LEMBERG: > > Folks, > > > the music engraving conference in Salzburg (January 17.-19.) aims to > present as much note engraving programs as possible. While some > companies send representatives (e.g., Dorico, Capella, Finale) – some > even with talks – we don't have something similar for LilyPond in the > main part of the conference. > > Instead, we would like to have a poster (in A0 format) that shows how > LilyPond works, together with some showcase results. > > Now my question: Are there people who are willing to produce such a > poster? Has anyone already done something similar for other > conferences? > > > Werner >
Re: How to use LilyDev without systemd
Thursday, January 9, 2020, 11:08:57 AM, Federico Bruni wrote: > Hi Peter > Il giorno gio 9 gen 2020 alle 10:18, Peter Toye > ha > scritto: >> Dear Federico, >> Thomas Morley forwarded you an email from >> http://lilypond.1069038.n5.nabble.com/A-suggestion-add-rf-to-built-in-dynamics-td226659.html >> One issue in it was that my Linux distro (antiX) does not have >> systemd, and it appears from the documentation that LilyDev needs it. >> I am a Linux newbie, and don't fully understand the container system. >> Apparently you are the expert on this. > Only the container (Lilydev-1-debian.tar.xz file) needs systemd. > The virtual machine (LilyDev-1-debian-vm.zip > file) can be installed in > VirtualBox or GNOME Boxes (or any libvirt frontend). > Another option, if you want to keep your > lilypond dev environment > separated from your system, is Debootstrap: > https://wiki.debian.org/Debootstrap > but then you must set up the system following the CG: > http://lilypond.org/doc/v2.19/Documentation/contributor/requirements-for-compiling-lilypond#ubuntu > http://lilypond.org/doc/v2.19/Documentation/contributor/requirements-for-building-documentation > and build guile-1.8 using these commands: > https://github.com/fedelibre/LilyDev/blob/master/mkosi/debian/mkosi.postinst#L42 > (copy lines 23-35 of that file to ~/.bashrc > before compiling guile-1.8) >> Is there any chance you could find time to let me know whether the >> container version of LilyDev will run under any of the >> easily-available container managers (Docker, LXC...)? If it wn't, I >> suppose that I will have to try to find a Linux version that will >> run on my rather ancient laptop. > Yes, if you can install Docker, you can use the Dockerfile contributed > by Dan Eble: > https://github.com/fedelibre/LilyDev/tree/master/docker > It would be very useful to upload that Docker > image to Docker Hub but I > haven't found the time to do it yet (especially because I'm using > Fedora, which switched to Podman as alternative to Docker.. and Podman > doesn't have yet the Docker-compose feature..). Thanks very much for this. It seems I have quite a few choices. I'll have to go away and have a big think. Best wishes, Peter
How to use LilyDev without systemd
Dear Federico, Thomas Morley forwarded you an email from http://lilypond.1069038.n5.nabble.com/A-suggestion-add-rf-to-built-in-dynamics-td226659.html One issue in it was that my Linux distro (antiX) does not have systemd, and it appears from the documentation that LilyDev needs it. I am a Linux newbie, and don't fully understand the container system. Apparently you are the expert on this. Is there any chance you could find time to let me know whether the container version of LilyDev will run under any of the easily-available container managers (Docker, LXC...)? If it wn't, I suppose that I will have to try to find a Linux version that will run on my rather ancient laptop. Best regards, Peter mailto:lilyp...@ptoye.com www.ptoye.com
Re: A suggestion: add \rf to built-in dynamics
Sunday, January 5, 2020, 10:28:43 PM, you wrote: > Am So., 5. Jan. 2020 um 14:20 Uhr schrieb Peter Toye : >> But I'm really not familiar in any detail with the whole patching process, >> whether or not I use git directly or via LilyDev and/or lily-git and/or >> git-cl (the relationship between these components is a bit pobscure to me). > git-cl is a different tool I thought so - thanks for the confirmation. > Once you've access to the source-files then > many parts fall into the > right place automatically, at least I hope so ;) So do I :) >> there's the business of submitting it. CG section 3 says at the head "Send >> patch files to the appropriate place:". > Using git-cl will do the job for you. Thanks. > Well, the idea of mentoring is a very nice one. As far as I can tell it never > worked really. > Though, you'll get always support here. At least as long as people are > available. > Speaking only for me, tomorrow my winter-break ends, meaning I'll have less > time for LilyPond. I see - I'll have to get to grips with git-cl then. > I'm not a programmer, and I never got any formal lessons on it, i.e. I'm an > autodidact. I was a programmer (and I think quite a good one) many years ago, but the thought of learning another programming style at my age (I last looked at list processing languages at university in the 1960s) is a bit daunting. >> Also, I'm a Linux newbie - still trying to get my head around the whole >> 'container' concept. There seem to be a number of different container >> management systems: Docker and LXC to name but two. Does it matter which one >> I use? My system is systemd-free (on purpose), and the instructions you >> pointed out to me earlier imply that I should have it. Is this a >> show-stopper? > Don't know. I hope Federico does. cc-ing him. Thanks - I hope he has time to answer. >Well, I have some practise in _writing_ mails, but you never heard my _spoken_ >english ;) Better than my spoken German, I assure you. Best regards, Peter
Re: A suggestion: add \rf to built-in dynamics
Sunday, January 5, 2020, 5:11:16 PM, you wrote: > On 05/01/20 13:20, Peter Toye wrote: > Any particular reason you're systemd-free? > Okay, my pc is, also, but I > run gentoo which defaults to OpenRC. I decided to go for antiX as I was able to get it to install on my antique laptop, which Ubuntu won't - diesn't have the right driver for the graphics card. And they don't like systemd. > Most distros are systemd these days, it's much > simpler and more reliable > than SysVInit, and the people who are so vocal > against it seem mostly to > be in the "fanatic" category - "I don't like it so you should do the > work so I don't have to use it". Sorry, linux doesn't work like that! I'm not knowledgeable enough to know whether the antiX team are fanatics or not. And I don't want to get into a flame war, thanks. > Linux is only "free" as in "freedom" - if you want something you have > to pay for it one way or another. If you > want "\rf" then you do it > yourself or you get someone to do it for you - > and if you do the latter > then whether in money or kind you're expected to pay. I was engraving some 19th century music which uses rf throughout, and was surprised not to find it built into LilyPond. I created a custom dynamic without difficulty (and several others which aren't built in). It's simply that I thought that adding \rf to the list of "normal" LP dynamics so that it would be useful. The reason I'm installing Linux (which I've not used before) and all the rest is so that I can help the community. I don't expect anything - apart possibly from some advice - for free, and I don't know why you should think I do. > Anyways, I'll give you a little tip, and attach my "dynamics.ily" file. > All my custom dynamics live in here, and I > include it in any work that > might need them. I'm *guessing* that it's very similar to the standard > definitions that exist in lilypond, so all you will need to do is edit > the standard file and they'll appear by magic. > Only snag, if you modify > your local version of lilypond, they'll > disappear with any upgrade :-( Thanks - I've got a similar one with a different selection! > Cheers, > Wol Best regards, Peter
Re: A suggestion: add \rf to built-in dynamics
Saturday, January 4, 2020, 6:46:56 PM, you wrote: > Am Sa., 4. Jan. 2020 um 16:44 Uhr schrieb Peter > Toye : > Well, coding new functionality is only one possibility. ...and debugging someone else's code is even worse. Especially in a language I dn't speak fluently. But I'm really not familiar in any detail with the whole patching process, whether or not I use git directly or via LilyDev and/or lily-git and/or git-cl (the relationship between these components is a bit pobscure to me). And even when I've worked out exactly what text/code needs to go where, there's the business of submitting it. CG section 3 says at the head "Send patch files to the appropriate place:". But I don't have an official mentor (How does one get one? Ask for one here?), nor am I an "experienced developer" in any way. I imagine you are. Also, I'm a Linux newbie - still trying to get my head around the whole 'container' concept. There seem to be a number of different container management systems: Docker and LXC to name but two. Does it matter which one I use? My system is systemd-free (on purpose), and the instructions you pointed out to me earlier imply that I should have it. Is this a show-stopper? > Sometimes there are typos/grammar/syntax to correct. That's slightly more my line. > Furthermore, our documentation always needs people working on it. > Not being a native speaker I often hesitate > doing so myself and if I > try, it's a major task for me... You could have kidded me - I think your English is at least as good as mine. > Cheers, > Harm Best regards, Peter
Re: A suggestion: add \rf to built-in dynamics
Saturday, January 4, 2020, 1:57:25 PM, you wrote: > Am Sa., 4. Jan. 2020 um 14:02 Uhr schrieb Peter > Toye : >> Thanks. CG chapter 2 starts off by saying that LilyDev has everything I >> should need, but then only mentions how to install it under VirtualBox >> (which I don't know at all) in Windows or MacOS. I'm a Linux newbie and >> haven't used Unix since about 2000 (on a Sun box), so it's all a bit of a >> learning curve. >> >> Should I be looking at lily-git instead? > Nope. > Personally I'd follow "CG 3.2 Starting with Git", doing all stuff > myself where needed. As said before. Ah - the hair-shirt approach :) I'm too soft - spent too much time on Windows. > If you want a LilyDev then: > For LINUX probably best to download > LilyDev-1-debian.tar.xz > from > https://github.com/fedelibre/LilyDev/releases > and follow the instructions in section "Container" from here: > https://github.com/fedelibre/LilyDev/tree/master/mkosi So LilyDev always runs in a VM. Now I see what the documentation is getting at. I'm not sure my antique laptop is powerful enough so may end up with VirtualBox anyway. >> I'm not an experienced git user, and it's beginning to look as if a minor >> change to three text files is going to end up with me being swamped in new >> software :) > Well, to submit a patch you'll need git. > Once the setup works, you may want to do more than one patch. I was rather hoping my coding days were over :( > Doing development-work will always come along > with some new software ;) True > At least the LilyDev-container will help a bit. > Maybe Federico steps in, he knows his stuff best, of course > Cheers, > Harm All the best, Peter
Re: A suggestion: add \rf to built-in dynamics
Apologies. - Saturday, January 4, 2020, 3:23:30 PM, Dan Eble wrote: > On Jan 4, 2020, at 06:09, Peter Toye > wrote: >> Thanks for that. As everyone seems to be on all the mailing lists. I sort of >> assumed that cross-links wouldn't be necessary. > I am subscribed to lilypond-devel only. > — > Dan Apologies Peter
Re: A suggestion: add \rf to built-in dynamics
Thomas, Thanks. CG chapter 2 starts off by saying that LilyDev has everything I should need, but then only mentions how to install it under VirtualBox (which I don't know at all) in Windows or MacOS. I'm a Linux newbie and haven't used Unix since about 2000 (on a Sun box), so it's all a bit of a learning curve. Should I be looking at lily-git instead? I'm not an experienced git user, and it's beginning to look as if a minor change to three text files is going to end up with me being swamped in new software :) Best regards, Peter mailto:lilyp...@ptoye.com www.ptoye.com - Saturday, January 4, 2020, 12:10:23 PM, Thomas Morley wrote: > Am Sa., 4. Jan. 2020 um 12:09 Uhr schrieb Peter > Toye : >> Yes, I'm on Windows, but have just resurrected an old laptop and have >> managed to get a Linux (antiX) system on it. And there's a spare partition >> to install LilyDev. I'll download it today. > Well, if you have a LINUX-machine, you may consider not to install > LilyDev at all, i.e. clone the git-repo directly. > LilyDev is meant to be used by windows users in a VirtualBox on their > windows-system. > It comes along with some other preinstalled things you will want. > If you don't use LilyDev you'll need to get those stuff yourself. > Otoh, going for LilyDev has it's own hassles. > Your decision. > Speaking only for me, I started with LilyDev, > although being on LINUX. > After some time I switched to my host-system for any LilyPond-work. > Though I kept all old and outdated LilyDevs, to keep the possibility > to compile checkouts of old patches for research-purposes. > Using old versions of gcc, ghostscript etc > I doubt you'll need that. > Cheers, > Harm
Re: A suggestion: add \rf to built-in dynamics
Thomas, Thanks for that. As everyone seems to be on all the mailing lists. I sort of assumed that cross-links wouldn't be necessary. Yes, I'm on Windows, but have just resurrected an old laptop and have managed to get a Linux (antiX) system on it. And there's a spare partition to install LilyDev. I'll download it today. CG is a bit blank on what to do with the downloaded tarball though. Does it have a stand-alone disk image to install in its own partition, or should I install VirtualBox under Linux? CG also seems a bit out of date as it mentions both Fedora and Debian . Github only seems to have Debian on it. Shouldn't be a problem - antiX is based on Debian. Best regards, Peter mailto:lilyp...@ptoye.com www.ptoye.com - Saturday, January 4, 2020, 10:36:09 AM, Thomas Morley wrote: > Hi Peter, > Am Sa., 4. Jan. 2020 um 11:04 Uhr schrieb Peter > Toye : >> I suggest that \rf (for rinforzando) be added to the built-in dynamic list. >> I suggested this on the users list, and got two replies, one fairly >> positive, one negative. > Please link to previous discussions you refer to. > Afaict, it's > http://lilypond.1069038.n5.nabble.com/A-suggestion-add-rf-to-built-in-dynamics-td226397.html >> My rationale is that it's accepted as a synonym of rfz, and was used as such >> by both Beethoven (who also used rfz and rinf.) and Brahms. And also by a >> far lesser composer whose work I've just engraved. >> As far as I can see, it would need an addition to dynamic-scripts-init.ly >> and modifications to both LM and NR (a rare occasion in which both manuals >> have the same information!). I'd be willing to do this myself if it's >> accepted, once I've got my head round the modification process (I may need a >> mentor here...). > Iirc, you are on windows. > I think best would be to set up LilyDev first. > Cheers, > Harm
A suggestion: add \rf to built-in dynamics
I suggest that \rf (for rinforzando) be added to the built-in dynamic list. I suggested this on the users list, and got two replies, one fairly positive, one negative. My rationale is that it's accepted as a synonym of rfz, and was used as such by both Beethoven (who also used rfz and rinf.) and Brahms. And also by a far lesser composer whose work I've just engraved. As far as I can see, it would need an addition to dynamic-scripts-init.ly and modifications to both LM and NR (a rare occasion in which both manuals have the same information!). I'd be willing to do this myself if it's accepted, once I've got my head round the modification process (I may need a mentor here...). Regards, Peter mailto:lilyp...@ptoye.com www.ptoye.com
Re: Documentation suggestions.
-
Tuesday, December 31, 2019, 8:06:06 PM, Kieren MacMillan wrote:
> Hi Peter (et al.),
>> 2. Neither LM nor NR mention that the default language for entering pitches
>> is English.
> It is?! When did that change?
> If I write
> \version "2.19.83"
> { fis'4 }
> it compiles without error. So I think the default is not English.
Dealt with in previous emails to the mailing list
>> 6. NR Section 3.2 'Titles and Headers" is very confusing: the word "header"
>> is used both for the \header command and for page headers. It is obviously
>> far too late to change the former
> It’s never too late to improve the Lilypond codebase. ;)
> Indeed, that’s exactly what convert-ly is for.
But easier I think to change the documentation as I suggested.
>> Also - should it be "Contributors' Guide". Presumably you have more than one
>> contributor.
> It’s fine as is: it’s a guide for you to use if you’re a contributor.
> One doesn’t [usually] find a "Users’ Guide", right?
Sorry - missing smiley :(
Best regards,
Peter
mailto:lilyp...@ptoye.com
www.ptoye.com
Documentation suggestions.
I originally sent this to the bug mailing list. Thomas Morley suggests that it would be better on this list. As an occasional and fairly new Lilypond user I've found that the documentation is occasionally obscure or misleading. I've made a few suggestions below. I've used the 2.19.83 documentation as the baseline. Have a great 2020. Regards, Peter mailto:lilyp...@ptoye.com www.ptoye.com 1. There is no index entry in NR for the \language command. It is mentioned only once: in Section 1.1.1 'Note names in other languages' - I suggest adding an index entry for it. 2. Neither LM nor NR mention that the default language for entering pitches is English. This might be confusing to non-English newbie engravers. I suggest adding to LM Section 1.2.1 'Pitches' something like: 'By default, note names are written using English notation. You can change this using the \language command. See [add reference to NR 1.1.1 "Note names in other languages"]' 3. In NR 1.2.5 'Bar and bar number checks' I suggest adding a paragraph at the bottom of the section: 'Note that if MIDI output is selected and volta repeats are in place, the bar number check will fail. It is best to suppress MIDI output whle checking bar numbers.' 4. The characters allowed in variable names are only briefly touched upon: in LR 2.4.1 the use of only alphabetic characters is mentioned as a convention, while NR 3.1.5 states this as a requirement. In a LilyPond-user email David Kastrup said "It's alphabetic characters in the ASCII set plus all non-ASCII characters, potentially interspersed with isolated single underlines or dashes." From other hints and experiments it appears that any characters are allowed if the name is enclosed in double quotation marks. I suggest in NR 3.1.5 'File Structure' in the bullet point 'A variable...' the last sentence is replaced by: 'By convention, the name of a variable consists of upper- and lower-case alphabetic characters only. In addition, non-ASCII characters and non-adjacent single underscores and dashes are also allowed. Any combination of characters is allowed if the variable name is enclosed in double quotation marks.' I've changed David's wording slightly to be marginally more accurate (IMO). This may need to be checked for accuracy. 5. The context of the various \tag commands is not described. I had assumed that they were lexical items, similar to many directives for conditional compilation; this was not correct! I suggest adding the following text to NR 3.3.2 'Using Tags', but I'm not sure of the best placement. Either close to the top of the section, before the examples, or at the very end, before "see also": 'Note that \keepWithTag and \removeWithTag are themselves music expressions and so must appear within a \score block.' 6. NR Section 3.2 'Titles and Headers" is very confusing: the word "header" is used both for the \header command and for page headers. It is obviously far too late to change the former, so I suggest that where page headers are implied they should be mentioned explicitly. In detail, in NR 3.2.1 and 3.2.2 the sections '...layout of headers and footers' be retitled: '...layout of page headers and footers'. 7. Contributor's Guide is a bit confusing. Section 1.2 'Overview of work flow' paragraph 3 says that a contributor's patch needs to be approved for inclusion (usually through the mailing list). But which mailing list? devel, bug or user? And who does the approving? Consensus? I made one suggestion on the user list and got 2 replies, one pro and one against. I can't suggest any concrete text here as I don't (but would like to) know the answer. Also - should it be "Contributors' Guide". Presumably you have more than one contributor. ===8<===End of original message text=== As an occasional and fairly new Lilypond user I've found that the documentation is occasionally obscure or misleading. I've made a few suggestions below. I've used the 2.19.83 documentation as the baseline. Have a great 2020. Regards, Peter [1]mailto:lilyp...@ptoye.com [2]www.ptoye.com 1. There is no index entry in NR for the \language command. It is mentioned only once: in Section 1.1.1 'Note names in other languages' - I suggest adding an index entry for it. 2. Neither LM nor NR mention that the default language for entering pitches is English. This might be confusing to non-English newbie engravers. I suggest adding to LM Section 1.2.1 'Pitches' something like: 'By default, note names are written using English notation. You can change this using the \language command. See [add reference to NR 1.1.1 "Note names in other languages"]' 3. In NR 1.2.5 'Bar and bar number checks' I suggest adding a paragraph at the bottom of the section: 'Note that if MIDI output is selected and volta repeats are in place, the
Re: How should I submit ideas?
David, Thanks David. I'll think about it! Best regards, Peter mailto:lilyp...@ptoye.com www.ptoye.com - Saturday, December 28, 2019, 12:23:26 PM, David Kastrup wrote: > Peter Toye writes: >> I hope this email gets through - I tried to subscribe, but haven't had any >> confirmation. >> During my newbie attempts to use LilyPond I've had various problems, >> all solved with the help of the community. I feel that some of them >> could have been solved with slightly better documentation, and have >> some suggestions. >> I see from the CG that I should submit documentation patches to the >> bug mailing list. I've got five. Should I put them all into a single >> file submission or submit five separate emails? > Trivial clear improvements like typo fixes can > usually be bundled. More > extensive additions may warrant separate > Emails/patches/commits/issues.
How should I submit ideas?
I hope this email gets through - I tried to subscribe, but haven't had any confirmation. During my newbie attempts to use LilyPond I've had various problems, all solved with the help of the community. I feel that some of them could have been solved with slightly better documentation, and have some suggestions. I see from the CG that I should submit documentation patches to the bug mailing list. I've got five. Should I put them all into a single file submission or submit five separate emails? Regards, Peter mailto:lilyp...@ptoye.com www.ptoye.com
Re: Poster for music engraving conference
Hi Werner, hi Bernhard, and especially Urs ;-), what about using a LaTeX a0poster-template together with lyluatex? That would make collaboration with GIT straightforward. A quick search brought up these templates: https://www.cfd.tu-berlin.de/~panek/tex/poster/poster.html http://www.latextemplates.com/cat/conference-posters Though, the template(s) need some adaption to work with lualatex. Even though my schedule is quite tight I would like to contribute. I have obtained the permission from two publishers to use single excerpts/pictures from the St.Mark passion (Ortus Berlin, I will talk about it) and a contemporary score composed by Hermann Keller (Edition Juliane Klein Berlin). Jan-Peter Am 04.12.19 um 12:05 schrieb Werner LEMBERG: > > Folks, > > > the music engraving conference in Salzburg (January 17.-19.) aims to > present as much note engraving programs as possible. While some > companies send representatives (e.g., Dorico, Capella, Finale) – some > even with talks – we don't have something similar for LilyPond in the > main part of the conference. > > Instead, we would like to have a poster (in A0 format) that shows how > LilyPond works, together with some showcase results. > > Now my question: Are there people who are willing to produce such a > poster? Has anyone already done something similar for other > conferences? > > > Werner >
Re: guilev1/2 musing
Hi Paul, sorry for missing to mention your contribs! And thank you for the XML port. I didn't look into the gsoc code lately, but perhaps the two projects dont need to compete? I hope I can focus on my lily projects the next weeks. Jan-Peter Am 26. Januar 2019 18:18:48 MEZ schrieb Paul Morris : >On 1/25/19 10:43 AM, David Kastrup wrote: > >> Paul Morris writes: >>> One area where guile2 (and upcoming guile3) would be useful is for >>> MusicXML export. David Garfinkle's summer of code project (mentored >>> by David Kastrup) made a start on using guile2's sxml and pattern >>> matching procedures (which aren't in guile1) >> They exist as Guile1 library, it's just that they are by default in >> Guile2. If we decided prepackaging Guile1 was the way to go, >including >> the respective library version should be feasible as well. >> >> No guarantees, but that was my impression. > > >Ah, good to know they exist as guile1 libraries. (I just assumed that >since guile2 was used for the gsoc project, that they didn't exist for >guile1.) > >Does anyone know where to locate them? I did some searching and came >up >short. They are "Pattern Matching (ice-9 match)" and "SXML" modules in > >the current guile2: >https://www.gnu.org/software/guile/manual/html_node/Guile-Modules.html > > >>> Since guile2 appears to work well enough at this point, aside from >>> performance, would it be worth setting up a "guile2 and musicxml >>> export" branch where we could land David Garfinkle's code and enable >>> further work on MusicXML export? It seems like a guile2 branch >>> already exists to some extent? >> Not really, and I don't think it makes sense to commit functionality >to >> Guile2-only at this moment. > > >Okay, and since the needed libraries exist for guile1, then work on >(that approach to) musicxml export doesn't need to be blocked waiting >on >guile2. > >>> Then at some future point... either LilyPond moves to a future guile >>> or we back-port the guile2 procedures to guile1. >> "some future point" is just going to cause additional work. We don't >> really have the personnel to do non-essential/non-trivial work on two >> separate implementations. > >Makes sense, and sounds like we don't need to wait for guile2 anyway. > >>> (Jan-Peter Voigt has also done separate work on MusicXML export, but >>> my sense is that in the long run, the approach in the summer of code >>> project would be preferable.) >> I haven't looked at Jan-Peter's approach. David Garfinkle's code is >> mostly in the state of a solid first sketch, so a distribution-viable >> production-ready code is still quite a bit of work away. Without >> anybody committed to take it considerably further, making decisions >> based on its existence would seem to be a bit premature. Like with >many >> open ends, this is more or less the "who decides to invest >significant >> work gets to decide on the approach". There is not much of a point >in >> planning out in detail what nobody will pick up. > > >Indeed, although, I've contributed a bit to Jan-Peter's code for this, >and would like to contribute more (as time allows) to see this feature >added to LilyPond. But I've wondered which approach would make more >sense for eventual landing in LilyPond. More consensus about the >approach, could encourage contributions by removing such questions. > >Cheers, >-Paul > > >___ >lilypond-devel mailing list >lilypond-devel@gnu.org >https://lists.gnu.org/mailman/listinfo/lilypond-devel -- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: guilev1/2 musing
Hi there, just a few words on my work on musicxml export: There is an openlilylib project that provides an export command. It is based on an engraver that collects all events and builds an abstract structure that can be serialized by an export module. One of them writes MusicXML. Alex Roitman did a lot of work on it recently. The functions to build XML are copied from guile 2 so they can be easily adapted if they are included in a guile 1 fork or via guile 2. The idea is to provide an export infrastructure that can be modified to add an export block like layout and midi are. OTOH this project is based on the need to export files with the current used lily version. Jan-Peter Am 25. Januar 2019 16:43:55 MEZ schrieb David Kastrup : >Paul Morris writes: > >> On 1/24/19 3:08 PM, Thomas Morley wrote: >> >>> From my point of view (and limited knowledge) other newly >implemented >>> guilev2-procedures are not _that_ important. >> >> One area where guile2 (and upcoming guile3) would be useful is for >> MusicXML export. David Garfinkle's summer of code project (mentored >> by David Kastrup) made a start on using guile2's sxml and pattern >> matching procedures (which aren't in guile1) > >They exist as Guile1 library, it's just that they are by default in >Guile2. If we decided prepackaging Guile1 was the way to go, including >the respective library version should be feasible as well. > >No guarantees, but that was my impression. > >> to convert LilyPond's internal music data structures into MusicXML >> output. > >> Since guile2 appears to work well enough at this point, aside from >> performance, would it be worth setting up a "guile2 and musicxml >> export" branch where we could land David Garfinkle's code and enable >> further work on MusicXML export? It seems like a guile2 branch >> already exists to some extent? > >Not really, and I don't think it makes sense to commit functionality to >Guile2-only at this moment. > >> Then at some future point... either LilyPond moves to a future guile >> or we back-port the guile2 procedures to guile1. > >"some future point" is just going to cause additional work. We don't >really have the personnel to do non-essential/non-trivial work on two >separate implementations. > >> (Jan-Peter Voigt has also done separate work on MusicXML export, but >> my sense is that in the long run, the approach in the summer of code >> project would be preferable.) > >I haven't looked at Jan-Peter's approach. David Garfinkle's code is >mostly in the state of a solid first sketch, so a distribution-viable >production-ready code is still quite a bit of work away. Without >anybody committed to take it considerably further, making decisions >based on its existence would seem to be a bit premature. Like with >many >open ends, this is more or less the "who decides to invest significant >work gets to decide on the approach". There is not much of a point in >planning out in detail what nobody will pick up. > >> Thanks for the insights into the guile1/2 situation and what's >causing >> the performance hit. > >-- >David Kastrup > >___ >lilypond-devel mailing list >lilypond-devel@gnu.org >https://lists.gnu.org/mailman/listinfo/lilypond-devel -- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Export to MusicXML
Hi Kieren, Am 16.10.18 um 16:54 schrieb Kieren MacMillan: > Hi Jan-Peter, > >> 2. I wrote a rudimentary engraver-based solution last year which is >> waiting for clean-up and completion to support MEI, MusicXML > >> The code in the project is able to export a MusicXML-File for a simple >> lilypond-score. The resulting files are not always correct/functional so >> this is more sketch of the idea. The base is an engraver that fetches >> and collects events and on score-finalization calls the specified export >> module with this (normalized) music collection. >> The collection is some scheme-structure, but should probably be better a >> normal LilyPond music-expression. > > 1. Why would it be "better" as a normal Lilypond music-expression? hm, did I misorder my words? Now I think it maybe be better to store the music in plain lilypond expressions e.g. SequentialMusic. Right now the music is stored in an alist by measure and moment. That way the exporter can easily iterate over the measures and moments and place the events in the resulting export format, but my intuition says that it might be better if the exporter modules rely on something lilypond can reuse itself directly. In other words: I think it would be better *not* to create another structure. But it is just something to have in mind and to consider while developing further. > 2. Is it currently in a state where someone with limited Scheme chops, but > good XML chops, could take the MusicXML portion to the goal line? Right now it is a sketch of an idea, so it might or might not fulfill anyones needs: 1. it is incomplete in that it doesn't translate all elements. 2. the MusicXML is created "manually" with simple string-concatenation. That is not a problem if the resulting file is correct, but ... 3. some files are incorrect and cannot be loaded by MuseScore It would be very helpful to have an XML-lib at hand for the export. I started a simple function that takes an alist structure end writes it as XML. But I am hesitant to really use that because if it is injected it might stop the integration of the standard libs when they are available. Jan-Peter > > Thanks, > Kieren. > > > Kieren MacMillan, composer > ‣ website: www.kierenmacmillan.info > ‣ email: i...@kierenmacmillan.info > ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Export to MusicXML
... by the way: what is the current state of guile2 in lilypond? I recently noticed some mails on the list. Jan-Peter Am 16.10.18 um 17:32 schrieb David Kastrup: > Paul Morris writes: > >> For Google Summer of Code 2015 David Garfinkle worked on MusicXML export. >> >> (See mailing list archives: >> https://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=Garfinkle=Search%21=lilypond-devel=20=normal=score >> ) >> >> I don't know if the code he wrote was ever checked in somewhere, on a >> branch or something. (It's not mentioned in the issue for this >> feature.) I have a copy of it somewhere that he sent me, but I'd >> assume that Jan-Peter's work on this would be the better place to >> start / collaborate. > > I posted it a few times on the mailing list, having acted as the mentor. > One problem is that it will be of best utility once Guile-2 (and the > respective XML libraries) are in use, and it's more a technological > starting point than a result-oriented one. Of course, the ultimate goal > is the same. > ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Export to MusicXML
Hi Alex, you're very welcome! And I'm always open for questions and discussions about the code. For general questions you should use the list so that others can join or at least follow the discussion. (I think Urs said so already). If we get to the point where direct communication is reasonable we can also exchange jabber, skype, slack or signal contacts. Jan-Peter Am 16.10.18 um 20:13 schrieb Alex Roitman: > Thank you Jan-Peter! This looks really promising, and I’d love to contribute. > > I’m only vaguely familiar with Scheme so I’ll probably take a bit of time to > get my hands dirty with that. Would it be OK to bug you with questions every > now and then? Is this list a good place, or should I just email you > privately? I promise I won’t abuse your kindness :-) > > Alex > >> On Oct 16, 2018, at 2:04 AM, Jan-Peter Voigt wrote: >> >> Hello Alex, >> >> you don't have to apologize for this question! It comes up every now and >> then, but has not been answered satisfyingly yet. My answers to your >> questions are: >> 1. Yes >> 2. I wrote a rudimentary engraver-based solution last year which is >> waiting for clean-up and completion to support MEI, MusicXML, Humdrum, >> LilyPond (!) and any other format for which an export-module with a >> defined API exists. >> https://github.com/jpvoigt/lilypond-export/ >> >> The code in the project is able to export a MusicXML-File for a simple >> lilypond-score. The resulting files are not always correct/functional so >> this is more sketch of the idea. The base is an engraver that fetches >> and collects events and on score-finalization calls the specified export >> module with this (normalized) music collection. >> The collection is some scheme-structure, but should probably be better a >> normal LilyPond music-expression. >> >> Just a little piece of something ;-) >> HTH >> Jan-Peter >> >> >> Am 16.10.2018 um 06:49 schrieb Alex Roitman: >>> Hello, >>> >>> I apologize in advance if this was already asked and answered on this list. >>> I’m looking into exporting some of my lilypond music into the MusicXML >>> format. All I could find so far was the python-ly package that attempts to >>> translate ly files into MusicXML. It has some issues that could be fixed, >>> and some that I don’t think could be so easily fixed, e.g. whether or not >>> to place accidentals, beams, and so on. >>> >>> It seems to me that the nature of the MusicXML format is such that in can >>> only be correctly written when the music is interpreted in context. Which >>> is what lilypond does. So I’m guessing that the right way to go about this >>> is to create a new Translator, alongside Performer and Engraver, that >>> instead of midi/graphical objects just dumps XML. >>> >>> Finally, here are my questions: >>> 1. Does this seem like a right approach? >>> 2. Was this ever attempted and is there any work left that one can continue? >>> >>> Thanks in advance for any help! >>> Alex >>> >>> ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Export to MusicXML
Hello Alex, you don't have to apologize for this question! It comes up every now and then, but has not been answered satisfyingly yet. My answers to your questions are: 1. Yes 2. I wrote a rudimentary engraver-based solution last year which is waiting for clean-up and completion to support MEI, MusicXML, Humdrum, LilyPond (!) and any other format for which an export-module with a defined API exists. https://github.com/jpvoigt/lilypond-export/ The code in the project is able to export a MusicXML-File for a simple lilypond-score. The resulting files are not always correct/functional so this is more sketch of the idea. The base is an engraver that fetches and collects events and on score-finalization calls the specified export module with this (normalized) music collection. The collection is some scheme-structure, but should probably be better a normal LilyPond music-expression. Just a little piece of something ;-) HTH Jan-Peter Am 16.10.2018 um 06:49 schrieb Alex Roitman: > Hello, > > I apologize in advance if this was already asked and answered on this list. > I’m looking into exporting some of my lilypond music into the MusicXML > format. All I could find so far was the python-ly package that attempts to > translate ly files into MusicXML. It has some issues that could be fixed, > and some that I don’t think could be so easily fixed, e.g. whether or not to > place accidentals, beams, and so on. > > It seems to me that the nature of the MusicXML format is such that in can > only be correctly written when the music is interpreted in context. Which is > what lilypond does. So I’m guessing that the right way to go about this is > to create a new Translator, alongside Performer and Engraver, that instead of > midi/graphical objects just dumps XML. > > Finally, here are my questions: > 1. Does this seem like a right approach? > 2. Was this ever attempted and is there any work left that one can continue? > > Thanks in advance for any help! > Alex > > > ___ > lilypond-devel mailing list > lilypond-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/lilypond-devel > ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: crash running translator
Hi David,
wow, thank you!
I will try to follow your explanations soon and read the mentioned code.
Jan-Peter
Am 17.09.2018 um 16:38 schrieb David Kastrup:
> Jan-Peter Voigt writes:
>
>> Dear all,
>>
>> I stumbled over something that looks like a bug.
>> If one uses ly:run-translator to process some music a dotted rest
>> crashes lilypond:
>>
>> \version "2.19.82"
>> #(ly:run-translator #{ r2. #} #{ \layout {} #})
>>
>> The error message is:
>> Wrong number of arguments to #
>>
>> Does anybody know a way to circumvent this?
>
> Well, looking up the definition of ly:run-translator I read:
>
> LY_DEFINE (ly_run_translator, "ly:run-translator",
>2, 1, 0, (SCM mus, SCM output_def),
>"Process @var{mus} according to @var{output-def}. An"
>" interpretation context is set up, and @var{mus} is"
>" interpreted with it. The context is returned in its"
>" final state.\n"
>"\n"
>"Optionally, this routine takes an object-key to"
>" to uniquely identify the score block containing it.")
> [...]
>
> Which makes me barf. The final paragraph is just gobbledygook. It
> doesn't help that this mysterious optional object-key is _accepted_ but
> the function signature does not even contain a parameter declaration for
> it.
>
> Ok, onward. Running with -dverbose I get
>
> -*- mode: compilation; default-directory: "/tmp/" -*-
> Compilation started at Mon Sep 17 15:45:07
>
> lilypond -dverbose gok.ly
> GNU LilyPond 2.21.0
> ]
> ]
> ]
> ]
> ]
> [... we should probably do something about those, dozens more]
> Processing `gok.ly'
> Parsing...
> Interpreting music...Backtrace:
> In unknown file:
>?: 0* [lilypond-main ("gok.ly")]
> In /usr/local/share/lilypond/2.21.0/scm/lily.scm:
> 1032: 1* (let* ((failed #)) (if (ly:get-option #) (begin #)) ...)
> 1032: 2* [lilypond-all ("gok.ly")]
> 1045: 3 (let* ((failed #) (separate-logs #) (ping-log #) ...) (gc) ...)
> 1057: 4* [for-each # ("gok.ly")]
> In unknown file:
>?: 5* [# "gok.ly"]
> In /usr/local/share/lilypond/2.21.0/scm/lily.scm:
> 1059: 6* (let* (# # #) (if separate-logs #) (if ping-log #) ...)
> 1070: 7* [lilypond-file # "gok.ly"]
> 1105: 8 [catch ly-file-failed # #]
> In unknown file:
>?: 9* [#]
> In /usr/local/share/lilypond/2.21.0/scm/lily.scm:
> 1106: 10* [ly:parse-file "gok.ly"]
> In gok.ly:
>Now it's getting interesting:
>
>2: 11* [ly:run-translator # #]
> In unknown file:
>?: 12* [# #]
>?: 13* [# # #]
>?: 14* [# # # Rest > ...]
>?: 15* [ly:rest::width #]
>?: 16* [lookup-font # ((# # # #) (# # # # ...) ())]
>
> ERROR: In procedure lookup-font:
> ERROR: Wrong number of arguments to # alist-chain)>
>
> Compilation exited abnormally with code 1 at Mon Sep 17 15:45:08
>
> Ok, so we have
> SCM
> Rest::width (SCM smob)
> {
> return generic_extent_callback (unsmob (smob), X_AXIS);
> }
>
> and
>
> Rest::generic_extent_callback (Grob *me, Axis a)
> {
> /*
> Don't want ledgers: ledgers depend on Y position, which depends on
> rest collision, which depends on stem size which depends on beam
> slop of opposite note column.
>
> consequence: we get too small extents and potential collisions
> with ledgered rests.
> */
> SCM m = brew_internal_stencil (me, a != X_AXIS);
> return ly_interval2scm (unsmob (m)->extent (a));
> }
>
> and
>
> Rest::brew_internal_stencil (Grob *me, bool ledgered)
> {
> SCM durlog_scm = me->get_property ("duration-log");
> if (!scm_is_number (durlog_scm))
> return Stencil ().smobbed_copy ();
>
> int durlog = scm_to_int (durlog_scm);
>
> string style = robust_symbol2string (me->get_property ("style"), "default");
>
> Font_metric *fm = Font_interface::get_default_font (me);
> string font_char = glyph_name (me, durlog, style, ledgered, 0.0);
> Stencil out = fm->find_by_name (font_char);
> if (out.is_empty ())
> me->warning (_f ("rest `%s' not found", font_char.c_str ()));
>
> return out.smobbed_copy ();
> }
>
>
> Actually, looking at the traceback it would seem like lookup-font is not
> actually called with the wrong number of arguments but something is
> confused by the first argument being *undefined*. Which is a value that
> usually is used in the C API for signifying "there isn't a prop
crash running translator
Dear all,
I stumbled over something that looks like a bug.
If one uses ly:run-translator to process some music a dotted rest
crashes lilypond:
\version "2.19.82"
#(ly:run-translator #{ r2. #} #{ \layout {} #})
The error message is:
Wrong number of arguments to #
Does anybody know a way to circumvent this?
Jan-Peter
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LilyDev - some questions
My gear: Mac Pro Desktop, Yosemite 10.10.5, VBox 5.2.10 + Guest Additions and LilyDev VM setup and runnable. I’m familiar with VBox and VM’s. Also marginally familiar with Linux (Debian via Raspbian ->Raspberry Pi 2B) I am working with the Contributor’s Guide for LilyPond 2.19.81 My questions: (1) The LilyDev vdi is on a partition on one of my HD’s. The HD has EFI. The LilyDev.box is in my ~/VirtualBox VMs/LilyDev folder on the MacOS boot drive which has EFI EFI is enabled in the VM When booting the VM console shows a message saying boot failed EFI DVD/CDROM. Plus a bunch of other console messages which fly by too fast for me to capture. ( I don’t know where to look for the console log file) But booting continues OK to the point of being able to login dev. Should I care about the console messages? (2) Hardware Clock in UTC time is checked in VM System Settings (as is EFI) On my host machine I use a 24 hour clock display. My local time is UTC – 4 (DST). So for example Toronto time is presently 16:07 and UTC is 20:07. But LilyDev shows 22:07 on the login screen. Sorry but I do not how to correct this. Should I care? (3) I ran the Terminal and did ./setup.sh. It appears to have downloaded the needed got repo’s. Looking at that script it seems I do not need to exec lily-git.tcl? (actually lilypond-git I think) (4) The main desktop screen shows a popup about 770 updates for dnfdragora-update. What does this mean and what am I rto doubt it? TIA respect Peter ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Error compiling Lilypond 2.19.81
Hi Karlin, thank you -- this is very good reading. It's making my head spin, which means I'm learning something :) I was able to install guile 1.8 via the repository for Debian Jessie. as far as I know I'm not using guile 2.x for anything anyway, so i don't mind having 1.8 installed instead. Perhaps it is wacky to install from the repository from an earlier version of Debian? Is that unusual? I'm fairly new to Linux though i have some background in programming, and I don't fully understand package management. Thanks again, Peter On Wed, Apr 11, 2018 at 2:03 PM Karlin High <karlinh...@gmail.com> wrote: > On 4/11/2018 3:48 PM, Peter Engelbert wrote: > > In the meantime, I also noticed that for some reason Lilypond 2.18.2 is > not > > in the Debian Stretch (9) repository for ARM, but it IS in the Debian > > Jessie (8) repository. So I was able to install 2.18.2 for the raspberry > pi > > by adding the Jessie repository. Is it’s absence in the Stretch > repository > > an oversight, or is there some reason for it? > > LilyPond depends on Guile 1.8; more recent versions are incompatible so > far. Newer Debian versions have removed Guile 1.8. Here are a few > threads from the lilypond-devel list that may be of interest. > > LilyPond in Debian > <https://lists.gnu.org/archive/html/lilypond-devel/2017-09/msg00042.html> > > compiling lilypond in debian stretch with self-compiled guile-1.8 > <https://lists.gnu.org/archive/html/lilypond-devel/2017-10/msg00098.html> > -- > Karlin High > Missouri, USA > ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Error compiling Lilypond 2.19.81
Thanks for the response, David. It prompted me to do my research regarding
make vs make install—I hadn’t previously realized there was a difference
between the two.
I’ll give it another shot, this time being sure to run make before make
install. I’ll report back after I’ve done that!
In the meantime, I also noticed that for some reason Lilypond 2.18.2 is not
in the Debian Stretch (9) repository for ARM, but it IS in the Debian
Jessie (8) repository. So I was able to install 2.18.2 for the raspberry pi
by adding the Jessie repository. Is it’s absence in the Stretch repository
an oversight, or is there some reason for it?
Once again, thanks for the response, and I’ll post back if the make doesn’t
go smoothly.
Be well,
Peter
On Wed, Apr 11, 2018 at 00:54 David Kastrup <d...@gnu.org> wrote:
> Peter Engelbert <pmengelb...@gmail.com> writes:
>
> > Hello illustrious Lilypond Developers,
> >
> > I am attempting to compile Lilypond from source. I am most definitely in
> > over my head--but I did manage to install all of the dependencies, such
> > that running configure did not reveal any errors.
> >
> > I am compiling on Linux (specifically Raspbian, which is Debian Stretch
> on
> > ARM Architecture for Raspberry Pi). The reason I'm compiling from source
> > is that there's no build available for ARM architecture from the lilypond
> > website. When compiling (by running sudo make install), I receive the
> > following error. I have no idea what it means, so I can't do anything to
> > fix it. I am hoping that someone here can shed some light on what it
> means
> > so that I can get lilypond running on my Raspberry Pi! Here is the error
> > message:
> >
> > rm -f ./out/parser.dep; DEPENDENCIES_OUTPUT="./out/parser.dep
> > ./out/parser.o" g++ -c -Woverloaded-virtual -I/usr/include/python2.7
> > -I/usr/include/arm-linux-gnueabihf/python2.7 -fno-strict-aliasing -g
> > -fdebug-prefix-map=/build/python2.7-kKRR4y/python2.7-2.7.13=.
> > -fstack-protector-strong -g -fwrapv -DHAVE_CONFIG_H
> > -I/home/pi/repos/lilypond/lily/include -I./out
> > -I/home/pi/repos/lilypond/flower/include -I../flower/./out
> > -I../flower/include -I/home/pi/repos/lilypond/lily/out -O2
> > -finline-functions -g -pipe -I/usr/include/freetype2
> > -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0
> > -I/usr/include/glib-2.0 -I/usr/lib/arm-linux-gnueabihf/glib-2.0/include
> > -I/usr/include/freetype2 -W -Wall -Wconversion -o out/parser.o
> > out/parser.cc
> > ./out/parser.cc: In function 'int yyparse(Lily_parser*,
> > scm_unused_struct**)':
> > ./out/parser.cc:2927:12: warning: conversion to 'yytype_int16 {aka short
> > int}' from 'int' may alter its value [-Wconversion]
> >*yyssp = yystate;
> > ^~~
> > make[1]: *** No rule to make target '../flower/./out/library.a', needed
> by
> > 'out/lilypond'. Stop.
> > make[1]: Leaving directory '/home/pi/repos/lilypond/build/lily'
> > /home/pi/repos/lilypond/stepmake/stepmake/toplevel-targets.make:30:
> recipe
> > for target 'install' failed
> > make: *** [install] Error 2
> >
> > Thanks, and Godspeed.
>
> Do not run make install before running make.
>
> The extract of the log here is weird: it looks like Make is trying to
> link LilyPond before it is half-way finished compiling it or its
> prerequisites.
>
> So either your Make is seriously broken or your system date/time is
> running haywire and confusing it in this manner.
>
> --
> David Kastrup
>
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Error compiling Lilypond 2.19.81
Hello illustrious Lilypond Developers,
I am attempting to compile Lilypond from source. I am most definitely in
over my head--but I did manage to install all of the dependencies, such
that running configure did not reveal any errors.
I am compiling on Linux (specifically Raspbian, which is Debian Stretch on
ARM Architecture for Raspberry Pi). The reason I'm compiling from source
is that there's no build available for ARM architecture from the lilypond
website. When compiling (by running sudo make install), I receive the
following error. I have no idea what it means, so I can't do anything to
fix it. I am hoping that someone here can shed some light on what it means
so that I can get lilypond running on my Raspberry Pi! Here is the error
message:
rm -f ./out/parser.dep; DEPENDENCIES_OUTPUT="./out/parser.dep
./out/parser.o" g++ -c -Woverloaded-virtual -I/usr/include/python2.7
-I/usr/include/arm-linux-gnueabihf/python2.7 -fno-strict-aliasing -g
-fdebug-prefix-map=/build/python2.7-kKRR4y/python2.7-2.7.13=.
-fstack-protector-strong -g -fwrapv -DHAVE_CONFIG_H
-I/home/pi/repos/lilypond/lily/include -I./out
-I/home/pi/repos/lilypond/flower/include -I../flower/./out
-I../flower/include -I/home/pi/repos/lilypond/lily/out -O2
-finline-functions -g -pipe -I/usr/include/freetype2
-I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0
-I/usr/include/glib-2.0 -I/usr/lib/arm-linux-gnueabihf/glib-2.0/include
-I/usr/include/freetype2 -W -Wall -Wconversion -o out/parser.o
out/parser.cc
./out/parser.cc: In function 'int yyparse(Lily_parser*,
scm_unused_struct**)':
./out/parser.cc:2927:12: warning: conversion to 'yytype_int16 {aka short
int}' from 'int' may alter its value [-Wconversion]
*yyssp = yystate;
^~~
make[1]: *** No rule to make target '../flower/./out/library.a', needed by
'out/lilypond'. Stop.
make[1]: Leaving directory '/home/pi/repos/lilypond/build/lily'
/home/pi/repos/lilypond/stepmake/stepmake/toplevel-targets.make:30: recipe
for target 'install' failed
make: *** [install] Error 2
Thanks, and Godspeed.
Peter
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: broadcasting override-events (was [Re: Edition Engraver bug?])
Am 07.03.2018 um 15:30 schrieb David Kastrup: Jan-Peter Voigt <jp.vo...@gmx.de> writes: Am 07.03.2018 um 11:25 schrieb David Kastrup: Check the source code in lily/property-iterator.cc to see what to generate here for the various events (Push/Pop correspond to override/revert). Thank you David! This allows me to refactor the code. Actually, Push/Pop correspond to "temporary override/revert". A normal override is translated into Pop+Push in sequence if I remember correctly. yep, and I will repair the handling of _not_ \temporary \overrides. Right now EE handles all overrides as temporary. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: broadcasting override-events (was [Re: Edition Engraver bug?])
Am 07.03.2018 um 11:25 schrieb David Kastrup: Check the source code in lily/property-iterator.cc to see what to generate here for the various events (Push/Pop correspond to override/revert). Thank you David! This allows me to refactor the code. Jan-Peter ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
broadcasting override-events (was [Re: Edition Engraver bug?])
Hi David and all,
I stuck with successfully sending override-events from an engraver. I
created an example where I broadcast 3 events, one of them being an
override, but the override is not applied while the other 2 events are
processed as expected.
All events are sent using the same procedure. What might be the error in
this procedure. Is there something missing?
TIA
Jan-Peter
Am 05.03.2018 um 13:01 schrieb Jan-Peter Voigt:
* I will refactor the EE to also broadcast overrides.
\version "2.19.80"
% this is a broadcast-function for single events like \p or c''4
#(define (broadcast-music context music)
; get attributes for this music expression
(let ((evcls (ly:assoc-get (ly:music-property music 'name) music-descriptions '(
; log time and music
(ly:message "~A ~A ~A"
(ly:context-property context 'currentBarNumber)
(ly:context-property context 'measurePosition)
(with-output-to-string (lambda() (displayLilyMusic music
; broadcast event
(ly:broadcast (ly:context-event-source context) ; broadcast to this context
(ly:make-stream-event
(ly:assoc-get 'types evcls '()) ; get event class from attributes
(ly:music-mutable-properties music)) ; get properties for this music-event
)
))
% 3 tests
evA = \p
evB = \once \override NoteHead.color = #red
evC = g'4
% a demo engraver
eng = #(make-engraver
((start-translation-timestep trans)
(let ((context (ly:translator-context trans)))
(cond
((equal? (ly:context-property context 'measurePosition) (ly:make-moment 1/4))
(broadcast-music context evA)) ; on moment 1/4 broadcast \p
((equal? (ly:context-property context 'measurePosition) (ly:make-moment 2/4))
(broadcast-music context evB)) ; on moment 2/4 broadcast \override ...
((equal? (ly:context-property context 'measurePosition) (ly:make-moment 3/4))
(broadcast-music context evC)) ; on moment 3/4 broadcast g'4
)))
)
\layout {
ragged-right = ##f
\context {
\Voice
\consists #eng
}
}
% demo music
% Why are the overrides not applied?
\relative {
\repeat unfold 3 { c''4 c^"p" c^"red?" c^"+g" }
}
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
OLL-core and Win10 [was Re: edition-editor usage]
Hi Trevor,
I am working on Linux and have no Windows 10 running. I will try on Win7
later. IIRC there was a problem with oll-core on Windows 10, but maybe
someone else can tell?
The error message indicates a problem before EE is loaded.
If oll-core is loaded successfully EE *should* work.
Jan-Peter
Am 26.12.2017 um 09:41 schrieb Trevor:
Hi EE-Users
I thought I'd try to bring the edition engraver into use over the
holiday period, so I cloned edition-engraver and oll-core from git-hub
into a local repository, placed that in Frescobaldi's include path and
tried to compile the first example in edition-engraver. It fails with
the message:
C:/Users/tdani/openlilylib/oll-core/package.ily:57:2 <0>: error: GUILE
signaled an error for the expression beginning here
#
(if (not (defined? 'openlilylib-root))
C:/Users/tdani/AppData/Local/Temp/frescobaldi-u9vnw1qc/tmpuqjcysah/example-1.ly:35:1
<1>: error: unknown escaped string: `\loadPackage'
\loadPackage edition-engraver
Before I spend time investigating this further, I'm wondering if the
edition-engraver is known to work within Frescobaldi on Windows 10 with
LilyPond 2.19.80. Are there any such users?
Alternatively, any ideas what I might be doing wrong?
Trevor
-- Original Message --
From: "Jan-Peter Voigt" <jp.vo...@gmx.de <mailto:jp.vo...@gmx.de>>
To: lilypond-u...@gnu.org <mailto:lilypond-u...@gnu.org>; "Mason Hock"
<masonh...@gmail.com <mailto:masonh...@gmail.com>>
Sent: 24/12/2017 10:19:48
Subject: Re: edition-editor usage
Hello Mason,
it is possible to use \shapeII with the edition-engraver :-)
And it sounds like this is the use case the EE is originally meant for.
Yes, the wording is a bit inconsistent and/or irritating. I will try
to sum it up:
In the recent versions I used the terms target and context to divide
two dimensions. The target names the requested output like for example
'fullscore' or 'violinI-part'. If you "activate" an edition-target
with \addEdition violinI-part it uses all modifications that look like
\editionMod violinI-part{
\shapeII ... }
This is a real example I used inside the piano reduction:
\editionMod klavier 38 0/8 chor.ten.TenorStaff \once \shapeII #'(()(0
. 1)()()) Slur
It means:
with edition-target 'klavier' (the piano reduction) in measure 38 the
first eighth apply the shapeII-command inside the context identified
by 'chor.ten.TenorStaff'.
Moments are counted zero-based, so the first moment is zero. This
might irritating on first sight, but it is meaningful as the distance
from the beginning of the measure. The context in the example above is
the tenor staff inside the choir-staff.
I think the main point is understanding the three dimensions:
1. the edition-target - that is the condition if to apply the
modification ... apply this modification for the score of type T(arget)
2. the edition-context - that is where to apply the modification ...
the LilyPond context like Voice, Staff, Score etc.
3. the time - that is the musical timestamp when to apply the
modification ... moment X inside measure Y
HTH
I will send more details and information soon!
But for today and tomorrow I wish you a merry Christmas and all the
best for 2018!
Jan-Peter
Am 23. Dezember 2017 20:09:29 MEZ schrieb Mason Hock
<masonh...@gmail.com>:
I have a piece in which each performer reads from a version of the score
with their staff full-sized with the other parts on small staves. This
pieces also requires a lot of manual tweaking of slurs.
I've been using \shapeII for the slurs, which works great, except that
if I shape the slur correctly for the full-sized version of the part it
is shaped incorrectly for the small version of the part and vice versa.
In order for the slurs to look good in both situations I need two sets
of \shapeII tweaks.
edition-editor looks like a promising solution, but I'm having trouble
learning how to use it. The only documentation I can find is the usage
examples here.
https://github.com/openlilylib/edition-engraver/tree/master/usage-examples
Each example is very specific, which makes it difficult to decode how
edition-engraver works in general. I guess my questions are
(1) Will edition-engraver work for tweaking slurs with \shapeII?
(2) If so, what should be my approach in terms of organization? My guess
would be to have 8 editions, a full-size version and small version for
each of the 4 staves, where each pdf uses 1 full-size edition and 3
small editions.
(3) How do I make certain 'editions' (at this point I'm questioning
whether I'm using that term correctly) apply to certain staves in each pdf?
(4) What is the basic syntax for using edition-editor? It's difficult to
tell from the examples in the repo what is the basic syntax a
Re: Workaround for Issue 5001? (TupletNumber.avoid-slur)
Hi Harm,
thanks alot, this is really helpful!
Cheers
Jan-Peter
Am 05.11.2017 um 16:28 schrieb Thomas Morley:
Hi Jan-Peter,
2017-11-05 15:44 GMT+01:00 Jan-Peter Voigt <jp.vo...@gmx.de>:
Hello James,
thanks for pointing this out! The mentioned case also occurs in my current
score, but most times I deal with a slur over three notes:
\version "2.19.49"
\relative c'' {
\time 4/4
% the default case
\tuplet 3/2 {a8^( g a)}
% the "avoid-slur"-bug
\once \override TupletNumber.avoid-slur = #'outside
%% The bug seems to be not present for avoid-sur 'ignore
%% Hence you could workaround with less effort at the lines of:
\once \override TupletNumber.avoid-slur = #'ignore
%% probably take slur/tuplet-direction into account
\once \override TupletNumber.Y-offset =
#(lambda (grob) (+ (ly:tuplet-number::calc-y-offset grob) 1.1))
\tuplet 3/2 {a8^( g a)}
% this is, how it should look like, but unfortunately all have to
% be set with trial and error for different notes
\shape #'((0 . -2.1)(0 . -2.1)(0 . -2.1)(0 . -2.1)) Slur
\once \override TupletNumber.Y-offset = #4.5
\tuplet 3/2 {a8^( g a)}
}
Jan-Peter
Cheers,
Harm
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Workaround for Issue 5001? (TupletNumber.avoid-slur)
Hello James,
thanks for pointing this out! The mentioned case also occurs in my
current score, but most times I deal with a slur over three notes:
\version "2.19.49"
\relative c'' {
\time 4/4
% the default case
\tuplet 3/2 {a8^( g a)}
% the "avoid-slur"-bug
\once \override TupletNumber.avoid-slur = #'outside
\tuplet 3/2 {a8^( g a)}
% this is, how it should look like, but unfortunately all have to
% be set with trial and error for different notes
\shape #'((0 . -2.1)(0 . -2.1)(0 . -2.1)(0 . -2.1)) Slur
\once \override TupletNumber.Y-offset = #4.5
\tuplet 3/2 {a8^( g a)}
}
Jan-Peter
Am 05.11.2017 um 14:52 schrieb James Lowe:
Hello,
On Sun, 5 Nov 2017 13:02:43 +0100, Jan-Peter Voigt <jp.vo...@gmx.de> wrote:
Hi list,
I just ran into issue 5001
(https://sourceforge.net/p/testlilyissues/issues/5001/)
Does anybody know about a workaround?
Jan-Peter
Well the initial problem on the user list that caused tihs tracker says that
they used padding
http://lists.gnu.org/archive/html/lilypond-user/2016-11/msg00633.html
Is that what you wanted?
James
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Workaround for Issue 5001? (TupletNumber.avoid-slur)
Hi list, I just ran into issue 5001 (https://sourceforge.net/p/testlilyissues/issues/5001/) Does anybody know about a workaround? Jan-Peter ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
TupletNumber.avoid-slur regression?
Hi developers,
I just stumbled over a regression 2.19.80. The following code works as
expected in 2.18 but kills the beam in 2.19.80:
{
\override TupletNumber.avoid-slur = #'outside
\voiceOne \tuplet 3/2 { c''16[( b' a']) }
}
Or is there an undocumented change without a convert-ly rule?
Jan-Peter
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: triggering translation from engraver
Hi David, I started an experimental build with the waitFor-iterator. Right now it does not do doing anything, but it is already helpful for studying. Perhaps an edition-iterator that reports the mod-events to the contexts would be good. OTOH that is already done if a music expression is translated. If all mods are known before translation a SequentialMusic expression for each Context might be created and then added to the music. ... this is not thought to the end. Jan-Peter Am 23.08.2017 um 19:09 schrieb David Kastrup: Jan-Peter Voigt <jp.vo...@gmx.de> writes: Hi David, thank you for your work on this! I will try/investigate it later this evening or tomorrow in the morning. It's half-baked half-finished work. I vaguely remember that I could not figure out exactly how to make it do 100% of what I wanted it to do when it happened to end up shelved. But I guess as a starting point it's likely still a step forward from having nothing. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: triggering translation from engraver
Hi David, thank you for your work on this! I will try/investigate it later this evening or tomorrow in the morning. Best Jan-Peter Am 23. August 2017 18:33:15 MESZ schrieb David Kastrup <d...@gnu.org>: >David Kastrup <d...@gnu.org> writes: > >> David Kastrup <d...@gnu.org> writes: >> >>> Jan-Peter Voigt <jp.vo...@gmx.de> writes: >>> >>>> Do you have another idea how to do that? >>> >>> Timing is established by iterators and they work on music >expressions, >>> not events. So you need to have an iterator in the race from the >start. >>> Few iterators have variable length. The sequential iterator can >have an >>> elements-callback delivering music expressions. Those can have a >>> structure and/or length determined at callback time. >>> >>> Kicking this into orderly operation does not seem like it would be >>> reasonably workable. >>> >>> Iterators are not user-definable at the moment. Either a general >>> facility or a more specific "wait-iterator" would seem warranted. >> >> You might want to use \lyricsto to add your private control context >to >> the Score context. When switching off everything that can track >> melismata, you might get woken up once per event regardless of how >long >> your actual expressions are. >> >> But it might make more sense to work on actual infrastructure for >this >> rather than fudging around with existing facilities not intended for >it. > >As an example: I've created a \waitFor music function that does >something similar to what you want. It was just quite useless in the >original state since it waited for a particular expression, and you >cannot use it to wait for \mark "B" when the mark has been generated >with \mark \default . > >It turns out, looking at it, that the C++ code already does something >more useful, namely taking the "procedure" callback for evaluating a >triggering condition. While the LilyPond code does not yet match the >C++ code: so I probably gave up for some reason after noticing that >this >still wasn't what I could be using. > >So this definitely needs fleshing out into something more useful. But >it illustrates the kind of iterator you likely want to be using: I seem >to remember that I was able to make the original version (before >fudging >the procedure callback into the C++ code) do something. -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
triggering translation from engraver
Hi developers,
I have difficulties to find the right words for this question, but I'll try:
The edition-engraver comes into action, when it finds a mod
(tweak/override) for the current spot in time, that is measure/barNumber
and moment/measurePosition. These mods are applied in one of the
engravers slots, that is either (most times) in the
start-translation-timestep, acknowledger, listener or the process-music
function.
Now, if there is no stop/break in translation the function will not get
called:
\editionMod target 1 1/8 Voice \override ...
will not get called if the music is something like
{ c'4 c' }
because after step 0/4 step 1/4 will get called, but not the 1/8 step.
(I hope you can follow)
There are two things I'd like to accomplish:
1. allow the edition-engraver to apply tweaks outside the regular
"stops" of the music
2. add an offset to a mod and apply the tweak a given moment after the
current time
To do that I would like to trigger/broadcast an event that forces the
translator to stop again after a given moment has passed. The former
example will work if I add some skips to the music:
<< { c'4 c' } { s8 s s s } >>
But in my tests broadcasting a skip-event didn't show the desired
effect. Maybe I did something wrong or maybe this is the wrong way.
Do you have another idea how to do that?
TIA
Jan-Peter
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
lilypond export
Hi list-members,
I have been working on an export module for lilypond. The last month
there was no time to work on it. So I send you this link despite its
pre-alpha state, because otherwise the project might fall asleep ;-)
https://github.com/jpvoigt/lilypond-export
It is designed as an openlilylib-plugin so you should clone it next to
oll-core (if you want to try it) It comes with one example file that
shows the core commands.
Now, if you import lilypond-export/package.ily you have a command and a
context-mod in place to export music with or without typesetting it:
music = { ... }
\exportMusic \default xml \music
will export a MusicXML-file .xml in many cases. Well, it is in
pre-alpha stage, but for example if you have a simple choir piece, it
should produce a MusicXML-file that can be read by MuseScore.
The other exporter produces Humdrum, that can for example be tested at
http://verovio.humdrum.org/
The exporter uses some engravers to collect all note-events and store
them in a tree-structure. The exporter-modules then traverse the tree
and writes the corresponding strings to the output file. Right now ties
and slurs are not collected, but lyrics are exported to XML. Beams are
watched and exported.
This is one first sketch how it should work. There is a lot to do to add
basics, like ties and slurs, and to make it a stable export module that
is able to handle complex scores. But I appreciate any feedback and
maybe someone likes to collaborate?
Best
Jan-Peter
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
calc stem direction
Hi list,
in a scheme-engraver I want to get the stem-direction in the
acknowledger-slot. When I use ly:stem::calc-direction the calculated
direction is not always the visible one, when autobeaming is in effect.
A manual beam crashes lily.
So my question is: How can I retrieve the actual/current stem direction?
TIA
Jan-Peter
% snip %
\version "2.19.62"
#(define-public (stem-direction-engraver context)
(make-engraver
(acknowledgers
; store stem direction
((stem-interface engraver grob source-engraver)
; this function crashes, if a beam starts
(ly:message "stem info ~A" (ly:stem::calc-direction grob))
)
)
))
\layout {
\context {
\Voice
\consists #stem-direction-engraver
}
}
\score {
% the directions are not completely
\relative { c''8 b bes a g f e d }
}
\score {
% the function crashes with the beam-event
\relative { c''8 b[ bes] a g f e d }
}
% /snip %
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Scheme in LilyPond
Hi Charles, the make-note-ev function is hidden inside a closure and therefore not publicly visible. It depends on the duration defined in that closure. To create NoteEvents you should create them like this: (make-music 'NoteEvent 'pitch root 'duration some-duration) where 'some-duration' is defined with a duration: (ly:make-duration 2) for a quarter note. The begin-define-sequence implies using 'let': #(let ((root (ly:make-pitch 0 0 0)) (dur (ly:make-duration 2))) (display (make-music 'NoteEvent 'pitch root 'duration dur))) If there is a duration reachable in the scope you are acting, then you can use that one like you found in the mentioned file and probably copy the definition of make-note-ev. HTH Jan-Peter Am 01.06.2017 um 17:03 schrieb Charles Winston: Hi, I’m fooling around with using Scheme in lilypond files, making some way on my GSoC chords project. I’m trying to call the make-note-ev procedure found in scm/chord-entry.scm on line 196. I’ve written something simple: #(begin (define root (ly:make-pitch 0 0 0)) (display (make-note-ev root)) ) And I get an error saying that make-note-ev is an unbound variable. I thought that we could call Scheme procedures from the source in lilypond files. What am I missing here? Thanks, Charles ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: using run-translator
Hi Harm, Am 14.04.2017 um 11:18 schrieb Thomas Morley: 2017-04-14 9:13 GMT+02:00 Jan-Peter Voigt <jp.vo...@gmx.de>: Am 13.04.2017 um 22:01 schrieb David Kastrup: Jan-Peter Voigt <jp.vo...@gmx.de> writes: ... Do I have to consist some special engraver to the layout used in run-translator? Or do I have to look for something else? You should scorify the music expression: a number of stock transformations including voicification are done when doing that. Thank you! That was the missing piece. Jan-Peter Hi Jan-Peter, I never used ly:run-translator myself. May I ask for a more meaningful code-example? Currently I've no clue what it's all about. Thanks, Harm I am working on code, I am going share, when its readable ... and when easter vacation is over ;-) The interesting part in using ly:run-translator is that you can let (scheme-)engravers work on your music without actually engraving it. Technically this seems to be used for preparing quoted music and other stuff, when there is a message "interpreting music" (more than once). Right now I am collecting music by catching note- and rest-events and store it by time and voice in a hierarchical manner. That way I can serialize the collected music as lilypond strings and reuse music, collected by quoting individual instruments, in a piano part. The result has to be adapted in several ways, but at least, I have the right notes in place. And there is another more important use case I will present later, when its in a presentable stage. Jan-Peter ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: using run-translator
Am 13.04.2017 um 22:01 schrieb David Kastrup:
Jan-Peter Voigt <jp.vo...@gmx.de> writes:
Hi list,
I am using `ly:run-translator` to analyze a music expression.
If I use << \\ >> simultaneous expressions with voice separator and
set a key signature at the start of the expression, no voice
separation is done and lily gives a bunch of warnings about colliing
notes:
%%
% voicify does not work in ly:run-translator, when a keysignature is given
%mymusic = \new Staff { \time 3/4 \key f \major \relative << { bes'4 }
\\ { g8 f } >> }
%mymusic = \new Staff { \key f \major \relative << { bes'4 } \\ { g8 f
}
}
% this works without a problem
mymusic = \new Staff { \time 3/4 \relative << { bes'4 } \\ { g8 f } >> }
mylayout = \layout {}
#(ly:run-translator mymusic mylayout)
%%
Do I have to consist some special engraver to the layout used in
run-translator? Or do I have to look for something else?
You should scorify the music expression: a number of stock
transformations including voicification are done when doing that.
Thank you!
That was the missing piece.
Jan-Peter
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
using run-translator
Hi list,
I am using `ly:run-translator` to analyze a music expression.
If I use << \\ >> simultaneous expressions with voice separator and set
a key signature at the start of the expression, no voice separation is
done and lily gives a bunch of warnings about colliing notes:
%%
% voicify does not work in ly:run-translator, when a keysignature is given
%mymusic = \new Staff { \time 3/4 \key f \major \relative << { bes'4 }
\\ { g8 f } >> }
%mymusic = \new Staff { \key f \major \relative << { bes'4 } \\ { g8 f }
>> }
% this works without a problem
mymusic = \new Staff { \time 3/4 \relative << { bes'4 } \\ { g8 f } >> }
mylayout = \layout {}
#(ly:run-translator mymusic mylayout)
%%
Do I have to consist some special engraver to the layout used in
run-translator? Or do I have to look for something else?
TIA
Jan-Peter
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: displayLilyMusic and scheme-engraver
Hi David,
Am 05.02.2017 um 16:19 schrieb David Kastrup:
David Kastrup <d...@gnu.org> writes:
Jan-Peter Voigt <jp.vo...@gmx.de> writes:
Hi folks,
I just stumbled over a bug with \displayLilyMusic and
scheme-engravers. The following fails in recent devel:
%%%
\version "2.19.55"
\displayLilyMusic \new Staff \with {
\consists #(lambda (context)
(make-engraver))
} \relative { bes'4 a c b }
%%%
ERROR: In procedure symbol->string:
ERROR: Wrong type argument in position 1 (expecting symbol):
#
%%%
Until 2.19.53 or 54 this didn't crash, but the output was not a
serialization of the context-mod (\with), so I assume, someone is
working on it :-)
I will have a look into the internals after lunch.
I think you are understating the problem. \displayLilyMusic has nothing
to do with it.
yes, I do :-)
This is a "how did this ever pass testing" kind of case [checking the
regtests].
The regtests don't use \with at all but only layout redefinitions.
This is a showstopper in case anybody was thinking of rolling a
developer release right now.
Ok, no it isn't a showstopper. The problem here is that (make-engraver)
returns an empty list, and an empty list is not accepted right now as an
engraver. The moment you actually have anything that deserves the name
"engraver", it works.
Arguably, this wants fixing but it is sort of a "meh" example.
Thank you very much!
So I have empty engravers creeping around ... that is easy to fix!
Best
Jan-Peter
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
displayLilyMusic and scheme-engraver
Hi folks,
I just stumbled over a bug with \displayLilyMusic and scheme-engravers.
The following fails in recent devel:
%%%
\version "2.19.55"
\displayLilyMusic \new Staff \with {
\consists #(lambda (context)
(make-engraver))
} \relative { bes'4 a c b }
%%%
ERROR: In procedure symbol->string:
ERROR: Wrong type argument in position 1 (expecting symbol): ##f (context)>
%%%
Until 2.19.53 or 54 this didn't crash, but the output was not a
serialization of the context-mod (\with), so I assume, someone is
working on it :-)
I will have a look into the internals after lunch.
Jan-Peter
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: guile-2.0 and debian
Hi Antonio, Am 24.11.2016 um 16:10 schrieb Antonio Ospite: And about the choice between guile 1.8 or 2.0.12/13, it should be possible to have both guile-1.8 and guile-2.0 packages installed in the same image and then let lilypond choose which one to pick up at configure-time, shoudln't it? I doubt that. You can install guile 1.8 and 2.0 in one system, but not guile-dev 1.8 and 2.0 AFAICS. So one needs to separate systems for each version of guile. Or am I wrong? Cheers Jan-Peter ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: guile-2.0 and debian
Hi list, I am watching the guile-2-threads grow and really do appreciate that! Many thanks to Antonio, Harm, David, Federico, et al for allyour efforts on this! There is a another question I have in mind: What would it mean to create LilyDev as a container-based-solution? On my laptop and my working machine I regularly use LXC to start Apache or Tomcat inside a container for testing purposes. And if I have to test something I often do that inside a container (https://www.stgraber.org/2014/01/17/lxc-1-0-unprivileged-containers/). Is there a script, which prepares an ubuntu installation for lilydev (beside apt-get build-dep lilypond) and gub? That way one can set up a container, run the setup-script (prob. with options to select either guile 1.8 or 2.0.12/13). The lilydev-solution is just an iso to download. But if you want to test with different guile-versions, you have to provide a vm for each one of them. Containers are much lighter and smaller and use less cpu and take the memory they need - not a fixed amount in the vm-settings. Summary: Which steps/tasks need to be performed by a setup script to prepare a ubuntu-based installation for lilypond-development and gub (using the local lilypond-sources)? I say ubuntu-based as lilydev is based on it. But other distributions might as well work. Jan-Peter Am 24.11.2016 um 07:02 schrieb Paul: On 11/23/2016 06:09 PM, Thomas Morley wrote: Currently it seems I'm the only one being able to test Antonio's patches. This is not exactly optimal. [...] Having a LilyDev with guile 2.0.12/13 may help. I for one would be more likely to help with testing if there were a LilyDev with guile 2.0.12/13 Thanks Antonio, Harm, David, Federico, et al, for your work on this. -Paul ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Stepping down and moving on
Hi David, all the best for your new job and a million thanks for all the work you dedicated to LilyPond! I hope, we are not lost totally for LilyPond and its community! Best Jan-Peter Am 09.11.2016 um 18:09 schrieb David Kastrup: Hi folks and team, while I haven't really occupied an official function in LilyPond development, it's hard to deny that I have effectively functioned as acting chief architect and vetter (with a rather mottled performance). Partly in connection with a drop of my productivity particularly this year, the amount of financial support for my work from members of the LilyPond community went down from overall survivable to disastrous. Of course this is bitter for those of you that did contribute in significant amounts to my subsistence but I have to be moving on. I have accepted a full-time development (and team management) position with another company. Due to their project and team expansion plans, I will be starting already in December. This employment is in another city. I'll be travelling back and forth weekly for the foreseeable future. While I might be working on some LilyPond side projects interesting to me occasionally, I will not be able to do any serious amound of coordination or other activity involving me with LilyPond's community. As my communication style has proven to be a somewhat mixed blessing for the purpose of attracting long-term developers, I expect that this may help in the long run for finding a different balance of areas LilyPond is getting worked on. During his tenure as LilyPond leader, Graham has demonstrated that even without a central technical lead there is a lot of potential to focus the resources of people willing to work on and expand LilyPond and we have been continuing to reap the results of his talent for organizing people into useful teams even though I have not really figured out how to fill gaps in the various teams and tools managing LilyPond's infrastructure to offset the "natural" amounts of fluctuation. I'll try seeing through the release of 2.20 in the little time remaining to me both before and after starting my job. My main worry is the current comparative amount of instability with regard to font handling, and my main bad taste is that 2.20.1 will not be able to support Guile 2: there is no way that anything deserving the label of "stable" and including Guile 2 will come about in the rest of my tenure. There are also several half-completed features that are a nuisance. I do not expect to be able to to a significant amount of work on them in the foreseeable future. Once consequence, of course, is that my requirement for funding is over. I am greatly thankful to the people who have enabled me to keep working on LilyPond as long as I did, but what remains in my bank account, in spite of being quite less than what I started with when working on LilyPond, is sufficient to tide me over the time to my first paycheck. So I would ask you to cancel any regular bank payments you might still have in place as of December: I don't see that I will have a reasonable chance at returning a tangible value for them. Thanks for making me stay in the pond as long as I did! ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GSoC] spanners project update
Am 01.07.2016 um 09:21 schrieb Urs Liska: Am 01.07.2016 um 09:01 schrieb Nathan Chou: Thanks David and Urs for replying. There is a detail I would like to clarify. David suggested allowing \= to optionally specify the parent context in which a cross-voice spanner's information is shared (although I am not sure how that would be done with a key-list, since I think the spanner id itself is a string). Right. Maybe it should rather be a key? That would also make comparison generally faster than string comparisons. Would I convert a string input to a key, or should I only accept a key as a valid id? The latter seems more convenient but I imagine would break backward compatibility. Backward compatibility is not always a requirement. If a convert-ly rule can be written for the change then it isn't an issue at all. If this context is not specified, should it default to Score or Staff (or something else)? Nothing at all? Namely don't look anywhere else unless asked for? So cross voice spanners should only work if the context to share information is specified, right? If the context is not specified and there is no default, the spanner id would only be used within the same voice and not made known to any other contexts. Hm. If this is a limitation required by the implementation then it's acceptable. But from a user perspective I would be very surprised if an ID isn't recognized without an explicitly named context around it. Isn't that the (one) idea of an ID in general, defining an ID and have it addressable from anywhere? Well, the spanner-id is used right now to have multiple slurs (or other spanners) in the same Voice. So keeping the spanner-ids in the current Voice would only preserve the current behaviour, if no other context is given. But OTOH (IISC) it wouldn't break the current implementation, as long, as IDs are Score-unique and not only Voice-unique. My preference would be to place it in the Score-context. Jan-Peter ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: container as alternative to virtual machine: systemd-nspawn
Hi Fredrico, I have a similar setup running using LXC on my ubuntu machine. I really like using containers to avoid cluttering my work-environment with build-dependencies. There's a nice tutorial for "unprivileged" containers: https://www.stgraber.org/2014/01/17/lxc-1-0-unprivileged-containers/ You only have to add your user to the group |lxc-dnsmasq.| Then you can create a container with "lxc-create -t download -n lilydev -- -d ubuntu -r xenial -a amd64". Then start it with "lxc-start -n lilydev" and attach to it with "lxc-attach -n lilydev". Now you can install anything you need with apt, create the user and go on, like Frederico already explained. Using LXC or systemd-container is (IMO) a matter of taste - I chose LXC, because I found Stéphane Grabers tutorial. What I'd like to have now, is GUB running that container. I'll report, if I get it working. Jan-Peter Am 29.06.2016 um 18:27 schrieb Federico Bruni: This setup may be interesting for Linux users who want to avoid virtual machines. I started it today so I haven't tested it much yet. The size of OS is small initially, circa 380MB. But when you install the LilyPond dependencies it grows up significantly. # Instructions Install the packages `systemd-container` and `debootstrap`. Run as root the following commands (adapt it to your architecture): cd mkdir LilyDev debootstrap --arch=amd64 stable DebianJessie/ http://httpredir.debian.org/debian/ Start the container, set the root password systemd-nspawn -D LilyDev passwd and add a normal user: adduser lilydev id lilydev It's important that the user ID in your guest is the same as the user ID in your host system. This allows to edit the files in the LilyDev/home/lilydev directory either in your host or in your guest. Now you can boot the container (need to be run as root): systemd-nspawn -bD LilyDev Log in as root and install the dependencies, as described in the Contributor Guide. When you've done, change to the normal user: su lilydev and you are ready to compile lilypond. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GSoC] spanners project update
Am 26. Juni 2016 17:06:51 MESZ, schrieb David Kastrup <d...@gnu.org>: >Jan-Peter Voigt <jp.vo...@gmx.de> writes: > ... >> Whenever you are up to using static members, change it to properties >> of the Score context - or look for session global objects. > >"Session global" does not work with score markups in music: ah, I wasn't aware of this. > >Anything following the progress of typesetting has to run through >engraver-local variables and context properties. @Nathan: do it like this Jan-Peter -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GSoC] spanners project update
Hi all,
@David: thank you for your "emergency call"!
@Nathan: sorry, for giving you bad advise in this case!
To summarize, what to do with spanners, tagged with an ID: Use context
properties to store them "globally". You can consider the Score context
"global". If there is a context defined with \=Staff.myid, store it in a
context property of - in this case - the Staff context.
Whenever you are up to using static members, change it to properties of the
Score context - or look for session global objects.
Cheers
Jan-Peter
Am 24. Juni 2016 16:22:30 MESZ, schrieb David Kastrup <d...@gnu.org>:
>Jan-Peter Voigt <jp.vo...@gmx.de> writes:
>
>> Hi Nathan, hi Dan,
>>
>> the "nearest" context might be on Staff level - or, if (for example)
>> you have voices switching staves, on StaffGroup level, where a
>> StaffGroup also might be a GrandStaff or the like. If the context
>> property turns out to complex (I don't see all consequences yet),
>> you'll have to use this static engraver member. But you should try
>the
>> "nearest" context.
>
>A static engraver member would be a total disaster. What happens for
>stuff like
>
>{ c1-\markup \score { \new Staff { e1 } } }
>
>with global variables like that? What happens when the engraver is
>being collected but the static member stays around without protection
>from garbage collection? Or if it is protected, will it drag into the
>next file to be processed on the command line?
>
>Ids for \= could be specified as a key-list? and if it has two members
>(more would be an error) the first should be a context type symbol
>indicating the context the separate engravers choose to share their
>data
>over.
>
>--
>David Kastrup
--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GSoC] spanners project update
Hi Nathan, hi Dan, the "nearest" context might be on Staff level - or, if (for example) you have voices switching staves, on StaffGroup level, where a StaffGroup also might be a GrandStaff or the like. If the context property turns out to complex (I don't see all consequences yet), you'll have to use this static engraver member. But you should try the "nearest" context. Jan-Peter P.S. I am going on vacation this weekend, so I'll be online on monday again. Am 24. Juni 2016 14:28:44 MESZ, schrieb Dan Eble <d...@faithful.be>: >> On Jun 24, 2016, at 07:41 , Nathan Chou <starry...@gmail.com> wrote: >> >> Hello, >> >> spanners with an id are handled as potentially being cross-voice. >Each >> engraver maintains a static list member (so it is shared between all >> instances of an engraver) of named spanners and the voice each >spanner >> currently belongs to. > >Nathan, > >First, thanks for attacking this problem. > >Using a static member sounds like a convenient way to ramp up your >work, but limiting in the number of ways it can be used and maintained. >As soon as one tries to use this feature in a case in which there are >concurrent but unrelated instances of those engravers, side effects not >expected by the user will begin to appear. > >For the best solution, let your mentor advise you, but I suspect that >the most Lilypondish way would be to store your index as a property in >the nearest context that encloses all the voices you might want to >span. >— >Dan > > >___ >lilypond-devel mailing list >lilypond-devel@gnu.org >https://lists.gnu.org/mailman/listinfo/lilypond-devel -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GSoC spanners project
Hello list, hello Nathan, I want to second Nathans introduction and gracefully advocate for supporting him/us in this endeavor - to support polyphonic slurs and the like! More to come! Cheers Jan-Peter Am 07.05.2016 um 07:00 schrieb Nathan Chou: Hello all, I am a second-year student studying computer science at UCLA, and I will be working on the cross-voice spanners project this summer as part of the Google Summer of Code program. I'm glad to have this opportunity to contribute to Lilypond---I've written music with Lilypond before and liked how I could simply write the notes in text without fiddling around with a GUI. Currently I am still familiarizing myself with the existing code (especially the portions for parsing and engraving spanners), before considering how to change it. I will likely have more to say (and ask) once I have a better idea of how the project will proceed. Thanks to Jan-Peter (my mentor), Urs, and everyone for their support! Best, Nathan ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: difference between ly:context-now and ly:context-current-moment
OK Thank you! Am 14.03.2016 um 18:15 schrieb David Kastrup: Jan-Peter Voigt <jp.vo...@gmx.de> writes: Hi developers, can anybody please tell me: What is the difference between (ly:context-now context) and (ly:context-current-moment context) ? Or are they two names for the same thing? Different code, different documentation string, different place in lily/context-scheme.cc, absolutely the same functionality. Probably somebody overlooked one when creating the other. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
difference between ly:context-now and ly:context-current-moment
Hi developers, can anybody please tell me: What is the difference between (ly:context-now context) and (ly:context-current-moment context) ? Or are they two names for the same thing? Cheers Jan-Peter ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GSoC mentors once more
Hi Urs, you asked me off-list, if I would be a mentor (in hogwards they are called dementor, aren't they?) - I didn't answer yet, so I do it on-list now. I would be generally ready with being a mentor for the cross-voice-spanner-application. Still, I would like to know, how much effort would come up with it to me? Well, answering questions (or delegating them) and reviewing code should be no problem :-) Cheers Jan-Peter Am 14. März 2016 01:08:09 MEZ, schrieb Urs Liska <u...@openlilylib.org>: >Given the advent of a fifth potential applicant I find it inacceptable >that we don't seem to make any progress in raising our mentor number >beyond two. > >Is it really true that I am the only one pushing this? > >Urs >-- >Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail >gesendet. >___ >lilypond-devel mailing list >lilypond-devel@gnu.org >https://lists.gnu.org/mailman/listinfo/lilypond-devel -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
vero vio MEI to SVG
Hello list-members, this is just a short note about something, I came across these days. There is a library to convert MEI-xml to SVG: http://www.verovio.org/index.xhtml Lilypond can of course produce SVG by itself. But as mentioned on the website, the verovio-API invites to produce other out- and input-formats. Maybe this would be helpful for a converting lily to mei to lily? Cheers, Jan-Peter ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: srfi-1 not available in \layout
Hi Harm,
I think, its a matter of scope. You have to import srfi via
use-modules, but you can't do that inside \layout{} (IIUC).
You can use a self-defined wrapper-command, to access the needed functions:
\version 2.19.18
#(use-modules (srfi srfi-1))
#(define-public (disp-append-map a b)(display (append-map a b)))
\layout { #(disp-append-map identity '((1) (2))) }
{ c''1 }
HTH
Cheers,
Jan-Peter
Am 08.05.2015 um 02:49 schrieb Thomas Morley:
\version 2.19.18
\layout { #(display (append-map identity '((1) (2 }
{ c''1 }
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Generating music from a list of identifiers
Hi Trevor,
I compiled a short example, that should give you some hints.
HTH
Jan-Peter
Am 01.04.2015 um 13:18 schrieb Trevor Daniels:
Hi Schemers
I'm struggling to find how to do the following:
I have a list of the identifiers of variables which contain either music or #f
and I'd like to generate the parallel music of all of them which contain music.
I can do this by listing the identifiers explicitly, like this:
AllMusic =
#(if DescantMusic DescantMusic)
#(if SopranoMusic SopranoMusic)
...
#(if PianoLHMusic PianoLHMusic)
But I'd like to do the same thing without listing each one explicitly, using a
list like this, which is generated algorithmically:
#(define AllMusicNames
(list
DescantMusic
SopranoMusic
...
PianoLHMusic))
TIA
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
\version 2.18.2
% a list of needed var names as symbol-list
AllMusicNames = #'(DescantMusic SopranoMusic PianoLHMusic)
% define AllMusic as music function - to be called with \AllMusic
AllMusic = #(define-music-function
(parser location)()
(make-music
'SimultaneousMusic
'elements
(map
(lambda (n)
(let ((mus (ly:parser-lookup parser n))) ; get the object with the name n or an empty list
(if (ly:music? mus) ; if mus is music, return it, otherwise return void-music
mus
(make-music 'SequentialMusic 'void #t))
)) AllMusicNames))
)
DescantMusic = \relative c'' { ees4 e f fis }
SopranoMusic = \relative c'' { bes4 a c b }
\AllMusic
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Guitar right-hand fingering
Hi, I just noticed that in the documentation about right-hand fingerings in the common notation for fretted strings: http://www.lilypond.org/doc/v2.19/Documentation/notation/common-notation-for-fretted-strings#right_002dhand-fingerings the fifth finger isn't mentioned. I also tried|\rightHandFinger #5| and an 'x' was printed. As I understand it 'x' is printed for all non supported numbers. But although perhaps not so common the fifth finger is used (with the letter 'c'): 1 = p = pulgar, 2 = i = índice, 3 = m = mayor, 4 = a = anular,5 = c = chiquito My hope in writing this is that this could be easily added to LilyPond. One can of course easily use markup instead, but I think it would be nice for the sake of completeness. Best Peter ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
