Re: bug-lilypond Digest, Vol 189, Issue 17

2018-08-26 Thread Christopher Heckman 
On Sun, Aug 26, 2018 at 7:04 AM,   wrote:
>
> Message: 3
> Date: Sun, 26 Aug 2018 11:43:44 +0200
> From: Thomas Morley 
> To: Pierre Perol-Schneider 
> Cc: bug-lilypond 
> Subject: Re: Doc 2.4.2: Indicating harmonics and dampened notes
> Message-ID:
> 
> Content-Type: text/plain; charset="UTF-8"
>
> 2018-08-26 11:14 GMT+02:00 Pierre Perol-Schneider
> :
>> Hi Bug Squad,
>> See:
>> http://lilypond.org/doc/v2.18/Documentation/notation/guitar.html#indicating-harmonics-and-dampened-notes
>> And:
>> http://lilypond.org/doc/v2.19/Documentation/notation/guitar.html#indicating-harmonics-and-dampened-notes
>>
>> 1. I don't understand the reason to put the NoteHead defs at a Staff level.
>
> Can't see a specific reason here. So I'd vote for deleting "Staff".
>
>> 2. Maybe a whole note is not the best example to show the 'harmonic-mixed
>> result.
>>
>> How about changing this snippet:
>>
>> \relative c' {
>>   \clef "treble_8"
>>   \override Staff.NoteHead.style = #'harmonic-mixed
>>   d^\markup { \italic { \fontsize #-2 { "harm. 12" }}} 1
>> }
>>
>> To:
>>
>> \relative c' {
>>   \clef "treble_8"
>>   \override NoteHead.style = #'harmonic-mixed
>>   d8^\markup { \italic { \fontsize #-2 { "harm. 12" }}} 4
>> }
>>
>> Cheers,
>> Pierre
>
>
> Agreed. Also, why not delete some of the superfluous brackets in the
> markup? Only keeping the surrounding ones for better viewable
> structure. I.e.
> \markup { \italic \fontsize #-2 "harm. 12" }

Bad suggestion. Currently, \italic takes one argument, the next token
(unless it's an opening bracket). If you want to change it so that
\italic takes the rest of the arguments (Scheme-style), then previous
code like

\italic "this is italic " "and this isn't"

will break.

--- Chris

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

modern-straight and flat- flags too thick and too spaced apart

2018-08-26 Thread edes 

Hello, list.

For some reason, when using modern-straight-flag or flat-flag, flags are
much thicker than normal beams, and the distance is also much bigger.

Straight and flat flags were widely used by modern composers like Pierre
Boulez and Karlheinz Stockhausen, and in all cases flags were treated like
beams, with the same distance and the same width.

Please see the attached examples and images (I'm using 2.12.0 from git).

BTW, the first flag does not align with the end of the stem.

Best,

e.

8< ---

\version "2.21.0"

\layout {
  \context {
\Score
  \override Flag.stencil = #flat-flag
  }
}

\relative c' {
<<
  { 
r8. d'16 d d d d  d r8 r32 d32 d[ d d d] d32 r16. }
  \\
  { r8. g,16 g g g g  g r8 r32 g32 g[ g g g] g32 r16. }
>>
}

8< ---

\version "2.21.0"

\layout {
  \context {
\Score
  \override Flag.stencil = #modern-straight-flag
  }
}

\relative c' {
<<
  { 
r8. d'16 d d d d  d r8 r32 d32 d[ d d d] d32 r16. }
  \\
  { r8. g,16 g g g g  g r8 r32 g32 g[ g g g] g32 r16. }
>>
}

8< ---



--
\version "2.21.0"

\layout {
  \context {
\Score
  \override Flag.stencil = #flat-flag
  }
}

\relative c' {
<<
  { 
r8. d'16 d d d d  d r8 r32 d32 d[ d d d] d32 r16. }
  \\
  { r8. g,16 g g g g  g r8 r32 g32 g[ g g g] g32 r16. }
>>
}\version "2.21.0"

\layout {
  \context {
\Score
  \override Flag.stencil = #modern-straight-flag
  }
}

\relative c' {
<<
  { 
r8. d'16 d d d d  d r8 r32 d32 d[ d d d] d32 r16. }
  \\
  { r8. g,16 g g g g  g r8 r32 g32 g[ g g g] g32 r16. }
>>
}___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: whiteout shouldn’t affect other grobs on same layer

2018-08-26 Thread David Kastrup 
Malte Meyn  writes:

> IMO it would be nice if a grob’s white box on one layer wouldn’t cover
> grobs on the same layer; or at least not grobs of the same type on the
> same layer.
>
> Would it be possible to put the whiteout part half a layer below so
> that \override NoteHead.layer = -1 puts the notehead at layer -1 and
> the surrounding white box at layer -1.5? (Or, if you want only
> integers: -1 
> puts the notehead at layer -2 and the white box at layer -3.)

I think that's a reasonable request but it would likely require
significant restructuring of the drawing process.  It would also mean
that whiteout would never work without assigning different layers.  In
practice, you cannot rely on its operation in other circumstances.

-- 
David Kastrup

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

whiteout shouldn’t affect other grobs on same layer

2018-08-26 Thread Malte Meyn 

Hi list,

in the following example the NoteHead.whiteout doesn’t only cover the 
tie but also one NoteHead whites out the other:


%%%
\version "2.19.82"

\relative <<
  {
\override NoteHead.whiteout = 3
\override NoteHead.layer = -1
r2 
  } \\ {
\override Tie.layer = -2
1~ q4
  }
>>
%%%

Of course, it would be possible to use a \tweak here:

r2 <\tweak whiteout 3 \tweak layer -1 f' a>

But that makes the code less readable and if more notes are affected 
it’s a pain.


IMO it would be nice if a grob’s white box on one layer wouldn’t cover 
grobs on the same layer; or at least not grobs of the same type on the 
same layer.


Would it be possible to put the whiteout part half a layer below so that 
\override NoteHead.layer = -1 puts the notehead at layer -1 and the 
surrounding white box at layer -1.5? (Or, if you want only integers: -1 
puts the notehead at layer -2 and the white box at layer -3.)


Cheers,
Malte

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

Re: musicxml2ly produces unexpected EOF in .ly file

2018-08-26 Thread David Kastrup 
Victor Rouanet  writes:

> Le 26/08/2018 à 15:15, Victor Rouanet a écrit :
>> Same result for me. According to Phil Homes in the lilypond-user
>> topic, the shlex module (used by musicxml2ly in utilities.py) didn't
>> support unicode input prior to Python 2.7.3.
> According to David Wright*
> I misread.

So we should upgrade Python in GUB?

-- 
David Kastrup

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

Re: musicxml2ly produces unexpected EOF in .ly file

2018-08-26 Thread Victor Rouanet 

Le 26/08/2018 à 15:15, Victor Rouanet a écrit :
Same result for me. According to Phil Homes in the lilypond-user 
topic, the shlex module (used by musicxml2ly in utilities.py) didn't 
support unicode input prior to Python 2.7.3.

According to David Wright*
I misread.

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

Re: musicxml2ly produces unexpected EOF in .ly file

2018-08-26 Thread Victor Rouanet 



Le 26/08/2018 à 12:56, Federico Bruni a écrit :

Victor, please keep the list in Cc.


Sorry, newbie error :-)

I was using lilypond packaged by Fedora, which uses python2 installed 
on the system (currently 2.7.15).
I've now installed 2.19.82 from lilypond.org, which uses the bundled 
python .

There's something wrong:

$ file jafanosumu.ly
jafanosumu.ly: data

There's some bad encoding. See attached file.

$ ls -lh ~/.local/lilypond/usr/bin/python*
-rwxr-xr-x 2 fede fede 5,1K 24 giu 14.11 
/home/fede/.local/lilypond/usr/bin/python
-rwxr-xr-x 2 fede fede 5,1K 24 giu 14.11 
/home/fede/.local/lilypond/usr/bin/python2.4


It's just my installation?


Same result for me. According to Phil Homes in the lilypond-user topic, 
the shlex module (used by musicxml2ly in utilities.py) didn't support 
unicode input prior to Python 2.7.3. That would explain why the 
conversion only fails with manually downloaded version of lilypond, 
which bundles python 2.4.5.
When I hand edit the musicxml2ly script, forcing it to use the system 
python version (2.7.13), the result file looks well encoded.


$ file -i jafanosumu_converted_using_python2.*
jafanosumu_converted_using_python2.4.5.ly: application/octet-stream; 
charset=binary

jafanosumu_converted_using_python2.7.13.ly: text/plain; charset=us-ascii


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

Re: musicxml2ly produces unexpected EOF in .ly file

2018-08-26 Thread Federico Bruni 

Victor, please keep the list in Cc.

I was using lilypond packaged by Fedora, which uses python2 installed 
on the system (currently 2.7.15).
I've now installed 2.19.82 from lilypond.org, which uses the bundled 
python .

There's something wrong:

$ file jafanosumu.ly
jafanosumu.ly: data

There's some bad encoding. See attached file.

$ ls -lh ~/.local/lilypond/usr/bin/python*
-rwxr-xr-x 2 fede fede 5,1K 24 giu 14.11 
/home/fede/.local/lilypond/usr/bin/python
-rwxr-xr-x 2 fede fede 5,1K 24 giu 14.11 
/home/fede/.local/lilypond/usr/bin/python2.4


It's just my installation?
This release had also some problems in the PDF manuals...

Il giorno ven 24 ago 2018 alle 13:19, Victor Rouanet 
<"victor.rouanet"@gmx.fr> ha scritto:
I use debian 9 (stretch). I tried to redownload the raw XML from the 
link I provided (with wget) and got the same error.


Do you know what python version were used by musicxml2ly when you 
tried?


Yes, I was initially planning to report an issue about this wrong 
output, but I upgraded lilypond before and had to edit the 
musicexp.py again



Le 24/08/2018 à 12:02, Federico Bruni a écrit :



Il giorno ven 24 ago 2018 alle 11:33, Victor Rouanet 
<"victor.rouanet"@gmx.fr> ha scritto:

Good morning,

I'm having an issue with musicxml2ly, installed with a manually 
downloaded version on lilypond 2.19.82.


I exported a musicxml file from Musescore, then converted it to 
lilypond source with musicxml2ly without error. However, when I 
try to compile it with lilypond, I get the following error: 
"syntax error, unexpected end of input, expecting \header". Here 
is the full output: https://hastebin.com/raw/navufewufu


And the musicxml file content: https://hastebin.com/jafanosumu.xml

This error happened with any musicxml file I tried to convert from 
Musescore.


After some research, I found this topic on the lilypond-user list 
http://lilypond.1069038.n5.nabble.com/XML-to-ly-and-Lilypond-again-td203101.html 
which looks like exactly the same.
The suggested workaround (replacing 
split_string_and_preserve_doublequoted_substrings by string.split 
in musicexp.py:139) makes it work, but I'm wondering if I'm doing 
something wrong.





Which operating system are you using?

On Linux, I don't get any EOF error.
Find attached the .ly file generated by musicxml2ly version 2.19.82.
There's a wrong input though:

$ /usr/bin/lilypond jafanosumu.ly
GNU LilyPond 2.19.82
Processing `jafanosumu.ly'
Parsing...
jafanosumu.ly:30:17: error: syntax error, unexpected '^'
   \tempo 4=80
   ^\markup{ \bold {Moderato} } | % 1
jafanosumu.ly:30:18: error: markup outside of text script or 
\lyricmode

   \tempo 4=80 ^
\markup{ \bold {Moderato} } | % 1
jafanosumu.ly:32:34: error: syntax error, unexpected '_'
   \mark \markup { \box { A } }
_\markup{ \italic {sempre forte} } | 
% 2
jafanosumu.ly:32:35: error: markup outside of text script or 
\lyricmode

   \mark \markup { \box { A } } _
 \markup{ \italic {sempre forte} } | 
% 2

jafanosumu.ly:33:51: error: syntax error, unexpected '^'
   \stemDown e4 \stemDown c4 \stemUp g2 \breathe
 ^\markup{ \italic
jafanosumu.ly:33:52: error: markup outside of text script or 
\lyricmode

   \stemDown e4 \stemDown c4 \stemUp g2 \breathe ^
  \markup{ \italic
jafanosumu.ly:41:5: error: errors found, ignoring music expression

   <<
fatal error: failed files: "jafanosumu.ly"





\version "2.19.82"
% automatically converted by musicxml2ly from jafanosumu.xml
\pointAndClickOff

\header {
encodingsoftware =  "MuseScore 2.3.2" 
encodingdate =  "2018-08-24" 
title =  Testing
}

#(set-global-staff-size 20.1587428571)
\paper {

paper-width = 21.01\cm
paper-height = 29.69\cm
top-margin = 1.0\cm
bottom-margin = 2.0\cm
left-margin = 1.0\cm
right-margin = 1.0\cm
indent = 1.61615384615\cm
short-indent = 1.29292307692\cm
}
\layout {
\context { \Score
autoBeaming = ##f
}
}
PartPOneVoiceOne =  \relative c' {
\clef "treble" \key c \major \numericTimeSignature\time 4/4 | % 1
\tempo 4=80 ^\markup{ \bold {Moderato} }
| % 1
\stemUp c4 _\f \stemUp e4 \stemUp g4 \stemDown c4 | % 2
\mark \markup { \box { A } } _\markup{ \italic
{sempre forte} } | % 2
\stemDown e4 \stemDown c4 \stemUp g2 \breathe ^\markup{
\italic {rit.} } | % 3
\stemUp c,4 r4 r2 \bar "|."
}


% The score definition
\score {
<<

\new Staff
<<
\set Staff.instrumentName = "Piano"
\set Staff.shortInstrumentName = "Pno."

\context Staff << 
\mergeDifferentlyDottedOn\mergeDifferentlyHeadedOn

Re: Doc 2.4.2: Indicating harmonics and dampened notes

2018-08-26 Thread Federico Bruni 




Il giorno dom 26 ago 2018 alle 11:43, Thomas Morley 
 ha scritto:


Agreed. Also, why not delete some of the superfluous brackets in the
markup? Only keeping the surrounding ones for better viewable
structure. I.e.
\markup { \italic \fontsize #-2 "harm. 12" }

Could you provide a patch?



Pierre, if you want to send a patch, here's the issue:
https://sourceforge.net/p/testlilyissues/issues/5404/

Thanks
Federico




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

Re: Doc 2.4.2: Indicating harmonics and dampened notes

2018-08-26 Thread Federico Bruni 




Il giorno dom 26 ago 2018 alle 11:14, Pierre Perol-Schneider 
<"pierre.schneider.paris"@gmail.com> ha scritto:

Hi Bug Squad,
See:
http://lilypond.org/doc/v2.18/Documentation/notation/guitar.html#indicating-harmonics-and-dampened-notes
And:
http://lilypond.org/doc/v2.19/Documentation/notation/guitar.html#indicating-harmonics-and-dampened-notes

1. I don't understand the reason to put the NoteHead defs at a Staff 
level.


I guess there isn't any reason, since Note_heads_engraver is part of 
the Voice context.


2. Maybe a whole note is not the best example to show the 
'harmonic-mixed

result.



Why? Because the diamond shape is more clear when the head is all black?


How about changing this snieppet:

\relative c' {
  \clef "treble_8"
  \override Staff.NoteHead.style = #'harmonic-mixed
  d^\markup { \italic { \fontsize #-2 { "harm. 12" }}} 1
}

To:

\relative c' {
  \clef "treble_8"
  \override NoteHead.style = #'harmonic-mixed
  d8^\markup { \italic { \fontsize #-2 { "harm. 12" }}} 4
}

Cheers,
Pierre
___



I agree. I will add an issue to the tracker.




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

Re: Doc 2.4.2: Indicating harmonics and dampened notes

2018-08-26 Thread Thomas Morley 
2018-08-26 11:14 GMT+02:00 Pierre Perol-Schneider
:
> Hi Bug Squad,
> See:
> http://lilypond.org/doc/v2.18/Documentation/notation/guitar.html#indicating-harmonics-and-dampened-notes
> And:
> http://lilypond.org/doc/v2.19/Documentation/notation/guitar.html#indicating-harmonics-and-dampened-notes
>
> 1. I don't understand the reason to put the NoteHead defs at a Staff level.

Can't see a specific reason here. So I'd vote for deleting "Staff".

> 2. Maybe a whole note is not the best example to show the 'harmonic-mixed
> result.
>
> How about changing this snieppet:
>
> \relative c' {
>   \clef "treble_8"
>   \override Staff.NoteHead.style = #'harmonic-mixed
>   d^\markup { \italic { \fontsize #-2 { "harm. 12" }}} 1
> }
>
> To:
>
> \relative c' {
>   \clef "treble_8"
>   \override NoteHead.style = #'harmonic-mixed
>   d8^\markup { \italic { \fontsize #-2 { "harm. 12" }}} 4
> }
>
> Cheers,
> Pierre


Agreed. Also, why not delete some of the superfluous brackets in the
markup? Only keeping the surrounding ones for better viewable
structure. I.e.
\markup { \italic \fontsize #-2 "harm. 12" }

Could you provide a patch?

Cheers,
  Harm

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

Doc 2.4.2: Indicating harmonics and dampened notes

2018-08-26 Thread Pierre Perol-Schneider 
Hi Bug Squad,
See:
http://lilypond.org/doc/v2.18/Documentation/notation/guitar.html#indicating-harmonics-and-dampened-notes
And:
http://lilypond.org/doc/v2.19/Documentation/notation/guitar.html#indicating-harmonics-and-dampened-notes

1. I don't understand the reason to put the NoteHead defs at a Staff level.
2. Maybe a whole note is not the best example to show the 'harmonic-mixed
result.

How about changing this snieppet:

\relative c' {
  \clef "treble_8"
  \override Staff.NoteHead.style = #'harmonic-mixed
  d^\markup { \italic { \fontsize #-2 { "harm. 12" }}} 1
}

To:

\relative c' {
  \clef "treble_8"
  \override NoteHead.style = #'harmonic-mixed
  d8^\markup { \italic { \fontsize #-2 { "harm. 12" }}} 4
}

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