Re: Disappearing dynamics
Hi k\Kevin and All, It ranks as one of the most bizarre bugs I have ever seen (and I speak as a software developer of many decades). It's only with Frescobaldi. Command line compilation is fine. It's only dynamic markings, which is puzzling - whatever is going on? Running sync of course I tried, thinking the same as you. but to no effect. Once the dynamics appear, then they continue to appear. A mystery of the cosmos. Perhaps dynamic markings have become shy or recalcitrant. It's difficult to know how to debug this. Same behaviour in printing Debian 9.6 and Ubuntu 18.10. Andrew On Tue, 13 Nov 2018 at 09:37, Kevin Barry wrote: > > How bizarre. I wonder what difference there could possibly be that > would make files appear to have different content. Does this issue > occur in Frescobaldi if opening after a successful (i.e. dynamics > appear correctly) compile from the cli and without making any edits? > Does running sync before compilation make any difference? Do dynamics > ever disappear after they have successfully appeared once? > > ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Disappearing dynamics
> Didn't seem to help unfortunately. So far it really seems that LilyPond > behaves inconsistently in this case when run as a subprocess of Frescobaldi. How bizarre. I wonder what difference there could possibly be that would make files appear to have different content. Does this issue occur in Frescobaldi if opening after a successful (i.e. dynamics appear correctly) compile from the cli and without making any edits? Does running sync before compilation make any difference? Do dynamics ever disappear after they have successfully appeared once? ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Disappearing dynamics
Am 12.11.18 um 22:15 schrieb Graham King: On 9 Nov 2018, at 14:07, Andrew Bernard wrote: I do not know how to get the lilypond command for compiling out of Frescobaldi to examine. ...but you might be able to get it out of the process table by using the Linux command "ps" with a suitable flag (see "man ps" on your distro). This needs to be done while Frescobaldi is executing lilypond, so you might need to run ps in a loop to catch it. Something like: while true ; do ps -C lilypond -f ; sleep 1 ; done might work. Run it, then compile the music in frescobaldi, then interrupt the while-loop using Ctrl-C, and inspect the output. Thank you for the input, but - moving this to private discussion - I gave him the lines of code to inject into Frescobaldi that print the generated command line. Didn't seem to help unfortunately. So far it really seems that LilyPond behaves inconsistently in this case when run as a subprocess of Frescobaldi. Urs ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Disappearing dynamics
On 9 Nov 2018, at 14:07, Andrew Bernard wrote: > I do not know > how to get the lilypond command for compiling out of Frescobaldi to examine. ...but you might be able to get it out of the process table by using the Linux command "ps" with a suitable flag (see "man ps" on your distro). This needs to be done while Frescobaldi is executing lilypond, so you might need to run ps in a loop to catch it. Something like: while true ; do ps -C lilypond -f ; sleep 1 ; done might work. Run it, then compile the music in frescobaldi, then interrupt the while-loop using Ctrl-C, and inspect the output. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: ChordNames change measure widths
Am Mo., 12. Nov. 2018 um 19:28 Uhr schrieb Malte Meyn : > > > > Am 12.11.18 um 18:07 schrieb Torsten Hämmerle: > > Hi Malte, > > > > That's strange, but it seems to be related to the *3 (length factor) used in > > g1*3. > > Restricting the use of these multipliers to full measure rests (i.e. writing > > g1 s1*2) I couldn't reproduce the effect. > > Can you confirm this? > > I can confirm for that particular code example. But I found another > (slightly bigger) example that doesn’t need such scaled durations: > > % > \version "2.19.82" > > << >\chords { > s1 s s s s s g >} >\relative { > \repeat unfold 32 b16 > b4 b b b > \repeat unfold 16 b16 > R1 R R R R >} > >> > % Hi, it has nothing to do with ChordNames. See (although not that obvious): << \new Staff { R\maxima d''1 } \new Staff { \repeat unfold 16 d''16 R\maxima } >> Rather it's the SpacingSpanner created by the Spacing_engraver which does bookkeeping of shortest starting and playing notes. So in the example we have 16th as shortest and maxima as longest notes and the intermediate duration of the whole note. I think LilyPond does it's best to space the whole note correctly in relation to maxima and 16tel. Don't forget there are not 8 times R1 but a _one_ MultiMeasureRest of length maxima which is _printed_ 8 times. Though, the output is poor admittedly, but could be improved by starting a new SpacingSpanner. See NR 4.5.2 New spacing section. Makes for: << \new Staff { R\maxima d''1 } %% hack to insert the line-break, if wanted %\new Dynamics { s1*3 \break } \new Staff { \repeat unfold 16 d''16 \newSpacingSection R\maxima } >> Cheers, Harm ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: ChordNames change measure widths
Am 12.11.18 um 18:07 schrieb Torsten Hämmerle: Hi Malte, That's strange, but it seems to be related to the *3 (length factor) used in g1*3. Restricting the use of these multipliers to full measure rests (i.e. writing g1 s1*2) I couldn't reproduce the effect. Can you confirm this? I can confirm for that particular code example. But I found another (slightly bigger) example that doesn’t need such scaled durations: % \version "2.19.82" << \chords { s1 s s s s s g } \relative { \repeat unfold 32 b16 b4 b b b \repeat unfold 16 b16 R1 R R R R } >> % ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: ChordNames change measure widths
Hi Malte, That's strange, but it seems to be related to the *3 (length factor) used in g1*3. Restricting the use of these multipliers to full measure rests (i.e. writing g1 s1*2) I couldn't reproduce the effect. Can you confirm this? Thanks Torsten -- Sent from: http://lilypond.1069038.n5.nabble.com/Bugs-f58488.html ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: ChordNames change measure widths
Am 12.11.18 um 17:05 schrieb Malte Meyn: Hi list, the following code produces measures of different length: The measures containing a ChordName are narrower than the others. That’s a bug, isn’t it? % \version "2.19.82" Same for 2.12.3 to 2.18.2 and the last version that I compiled from master. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
ChordNames change measure widths
Hi list, the following code produces measures of different length: The measures containing a ChordName are narrower than the others. That’s a bug, isn’t it? % \version "2.19.82" << \chords { s1*4 % try also s1*3 and see the line break move g1*3 d1 } \new Staff { \repeat unfold 16 d''16 R1*8 } >> % ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond