Re: Disappearing dynamics

2018-11-12 Thread Andrew Bernard 
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

2018-11-12 Thread Kevin Barry 
> 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

2018-11-12 Thread Urs Liska 



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

2018-11-12 Thread 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.


___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: ChordNames change measure widths

2018-11-12 Thread Thomas Morley 
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

2018-11-12 Thread 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
  }
>>
%

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: ChordNames change measure widths

2018-11-12 Thread 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?

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

2018-11-12 Thread Malte Meyn 



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

2018-11-12 Thread 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"

<<
  \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