Re: Mark / Barcheck Bug (#1626) Appearing Again

[Jay Anderson]

On Sat, Oct 15, 2016 at 6:38 PM, Andrew Bernard
 wrote:
> Don't you have to provide an argument for \mark, I thought?
>
> I am not familiar with 2.18.2, but in 2.19.48 you do:

Yep. I think \mark requiring an argument explains the errors in the
examples fully:
- The first error it saying that the argument you gave to \mark was wrong
- Lilypond kept trying to make sense of things and kept processing.
Since the argument to \mark was already used there is now 1 too few
beats in that measure.

I think lilypond is behaving as expected here. You might be trying to
do \mark \default or \mark "C" instead.

-Jay Anderson

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

Re: Mark / Barcheck Bug (#1626) Appearing Again

[Christopher Heckman]

After playing around with Lilypond for a while, I found out that \mark
appears to "gobble up" the next token in the list. For example,

  \new Staff { c \mark |  c c c | }

and

 \new Staff { c c c c |  c c c \mark | c | c c c c | }

should give barcheck errors but don't. That's because the barcheck
interprets them as

  \new Staff { c c c c | }

and

 \new Staff { c c c c |  c c c c | c c c c | }

--- CCH

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

RE: Mark / Barcheck Bug (#1626) Appearing Again

[Andrew Bernard]

Hi,

Don't you have to provide an argument for \mark, I thought?

I am not familiar with 2.18.2, but in 2.19.48 you do:


Processing `/tmp/frescobaldi-pofhqya8/tmp1asznm_p/document.ly'
Parsing...
/tmp/frescobaldi-pofhqya8/tmp1asznm_p/document.ly:4:20: error: wrong type
for argument 1.  Expecting number or markup, found (make-music (quote
BarCheck))
\new Staff { \mark 
   | c4 c c c | r1 | \mark c4 c c c |  }
/tmp/frescobaldi-pofhqya8/tmp1asznm_p/document.ly:4:44: error: wrong type
for argument 1.  Expecting number or markup, found (ly:make-pitch -1 0)
\new Staff { \mark | c4 c c c | r1 | \mark 
   c4 c c c |  }
Interpreting music...
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Layout output to `/tmp/lilypond-jzd1sq'...
Converting to `document.pdf'...
fatal error: failed files:
"/tmp/frescobaldi-pofhqya8/tmp1asznm_p/document.ly"



Andrew


-Original Message-
From: bug-lilypond
[mailto:bug-lilypond-bounces+andrew.bernard=gmail@gnu.org] On Behalf Of
Christopher Heckman
Sent: Sunday, 16 October 2016 12:13 PM
To: bug-lilypond@gnu.org
Subject: Mark / Barcheck Bug (#1626) Appearing Again

This was mentioned about five years ago, but I re-discovered it. Does the
so-called patch fix this? The bug is as follows:

Placing the \mark can have an effect on the bar check. If you run Lilypond
with the following code, the barcheck will fail exactly once.

--- CCH

\new Staff { \mark | c4 c c c | r1 | \mark c4 c c c |  }

\version "2.18.2"



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

Mark / Barcheck Bug (#1626) Appearing Again

[Christopher Heckman]

This was mentioned about five years ago, but I re-discovered it. Does
the so-called patch fix this? The bug is as follows:

Placing the \mark can have an effect on the bar check. If you run
Lilypond with the following code, the barcheck will fail exactly once.

--- CCH

\new Staff { \mark | c4 c c c | r1 | \mark c4 c c c |  }

\version "2.18.2"

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

Re: probably an oversight in a link on the home page

[Jean-Charles Malahieude]

Le 15/10/2016 à 16:19, Federico Bruni a écrit :


If you don't mind, and as I'm about to merge
master->translation->staging, I'll take care of it.
I'll also take care of the Japanese and French versions as Federico
mentioned on the translation list.


Ok, go ahead.
Don't forget what Masamichi pointed out (in the translation mailing
list): 'make doc' (and 'make website', I guess) adds .it/.fr/.ja/etc to
the relative links of translated manuals. So the recommendation to
translators should be to keep the URL as is and change only the anchor
(after checking the anchor name created by texinfo in the localized HTML
manual).

I didn't have the time to test it yet, but I trust Masamichi.



He is right: the LL part of the URL is inserted during the build process.

Nevertheless, when I replace
  @uref{examples.html#g_t_53e4_697d, 古楽}
with
  @uref{examples.html#Gu-Le-, 古楽}
as mentioned in out-www/web/
  
  古楽
I still only reach the top of examples.ja.html.

The only one that works is Schenker graphs (the only "non encoded" anchor).

Results are pushed and merged with staging now.


BTW, I won't be reachable tomorrow, my mom's 84th!

Cheers,
Jean-Charles


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

Re: extra note head

[Thomas Morley]

2016-10-15 16:53 GMT+02:00 Jack Wilson :
> Thanks for your quick reply; especially the thorough recommendations.
>

You're welcome.

Ofcourse there were other interesting replies, especially David's, pointing to
https://sourceforge.net/p/testlilyissues/issues/185/

Cheers,
  Harm

P.S.
Please always answer to the list (reinserting).

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

Re: flag and notehead collision with certain chords

[Gilberto Agostinho]

Hi all, thanks for the replies!

@Noeck

> I am pretty sure that I read that this is done on purpose, that the flag
> can touch the note head and that the distance of the elements of a 16th,
> 32nd, etc. flag are derived from the distance of staff lines.

I personally think there is a difference between touching and overlapping
(colliding) with a note head. Even some of the examples in Gould's book show
flags basically touching note heads, but never colliding (i think); in my
opinion, the case of LilyPond's stemmed down e' is indeed quite extreme.
About distances, she writes on p. 16 that the stem of both eighth and
sixteenth notes should be 3.5 staff spaces (I think considering that the
stem starts in the half of a note head, so for instance a f' stem should
finish exactly at the top staff line), and the flags should be 3 and 3.25
staff spaces, respectively.

@Trevor

Thanks for the link, I will check that discussion out!

@Simon

> Of course it isn’t constant, because stem length isn’t constant, and
> shouldn’t be. The ‘easiest’ description I can think of is that in
> classical engraving there is a kind of ‘gravity’ towards the center of
> the staff, which among other things makes stem length depend on staff
> position (of the note head(s)). 

I just had found it suspicious that the stemmed down notes affected by
collisions are exactly the ones that would normally take stem ups (a' or
lower). I was not aware that was intentional.

> ‘Tails’? Really? I’ve never heard that word in engraving context. 

I actually have heard of tails before, though flags is certainly much more
common. But for instance, you will find in /The Hutchinson Concise
Dictionary of Music/ on p. 523: quaver, "US eighth note [...] it is written
as a filled black note-head with a stem and flag (tail)." Anyway, I think
this is just choice of vocabulary and so it shouldn't really matter.

Cheers!
Gilberto



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/flag-and-notehead-collision-with-certain-chords-tp195330p195356.html
Sent from the Bugs mailing list archive at Nabble.com.

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

Re: probably an oversight in a link on the home page

[Federico Bruni]

Il giorno sab 15 ott 2016 alle 15:01, Jean-Charles Malahieude 
 ha scritto:

Le 15/10/2016 à 05:00, Paul a écrit :

On 10/14/2016 07:31 AM, Federico Bruni wrote:


Hi Paul

I think that you forgot to remove the absolute URL here. Or I'm
missing something?

+LilyPond is a powerful and flexible tool for engraving tasks of
+all kinds, for example
+@uref{http://lilypond.org/examples.html#Classical-Music, classical
music}
+(like the example above by J.S. Bach),
+@uref{examples.html#Complex-Notation, complex notation},

The first link should be relative, like all the others:

@uref{examples.html#Classical-Music, classical music}.


BTW, this comment:

@c anchor links, link to individual examples by their  tag

may be more informative (for translators also):

@c Translators should use the localized URLs, followed by their
translated anchor name (e.g. examples.it.html#Musica-Antica)



You're right, that was an oversight on my part.  Good catch, thanks!
Those edits all make sense to me.  Should I do them or would you like
to?  Either way is fine with me.



If you don't mind, and as I'm about to merge 
master->translation->staging, I'll take care of it.
I'll also take care of the Japanese and French versions as Federico 
mentioned on the translation list.


Ok, go ahead.
Don't forget what Masamichi pointed out (in the translation mailing 
list): 'make doc' (and 'make website', I guess) adds .it/.fr/.ja/etc to 
the relative links of translated manuals. So the recommendation to 
translators should be to keep the URL as is and change only the anchor 
(after checking the anchor name created by texinfo in the localized 
HTML manual).


I didn't have the time to test it yet, but I trust Masamichi.


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

Re: extra note head

[David Kastrup]

Noeck  writes:

>>> - I see no real bug here
>> 
>> To be fair, we do have
>> 
>> 
>
> ... which is justified IMHO, because even though the behaviour is
> understandable and follows from the way things work, it is not what a
> users wants in most cases - I don't know where it would be useful at all.

See the examples given in the discussion of the issue.

-- 
David Kastrup

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

Re: extra note head

[Noeck]

>> - I see no real bug here
> 
> To be fair, we do have
> 
> 

... which is justified IMHO, because even though the behaviour is
understandable and follows from the way things work, it is not what a
users wants in most cases - I don't know where it would be useful at all.

Joram

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

Re: probably an oversight in a link on the home page

[Paul]

On 10/15/2016 09:01 AM, Jean-Charles Malahieude wrote:

If you don't mind, and as I'm about to merge 
master->translation->staging, I'll take care of it.
I'll also take care of the Japanese and French versions as Federico 
mentioned on the translation list.


That would be fine with me, thanks!

-Paul

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

Re: extra note head

[David Kastrup]

Thomas Morley  writes:

> 2016-10-15 6:47 GMT+02:00 Jack Wilson :
>>
>> % I want to be able to use chords here
>> % in order to create accurate midi files
>> % but if I do, the layout is wrong
>> % reference: Snippets - Guitar strum rhythms
>>
>> \version "2.18.2"
>>
>> \new Voice \with {
>>   \consists "Pitch_squash_engraver"
>> } {
>>   \improvisationOn
>>   % chord causes extra note head to be produced
>>   a b < c e g > d
>> }
>
> Summary:
> - I see no real bug here

To be fair, we do have



-- 
David Kastrup

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

Re: probably an oversight in a link on the home page

[Jean-Charles Malahieude]

Le 15/10/2016 à 05:00, Paul a écrit :

On 10/14/2016 07:31 AM, Federico Bruni wrote:


Hi Paul

I think that you forgot to remove the absolute URL here. Or I'm
missing something?

+LilyPond is a powerful and flexible tool for engraving tasks of
+all kinds, for example
+@uref{http://lilypond.org/examples.html#Classical-Music, classical
music}
+(like the example above by J.S. Bach),
+@uref{examples.html#Complex-Notation, complex notation},

The first link should be relative, like all the others:

@uref{examples.html#Classical-Music, classical music}.


BTW, this comment:

@c anchor links, link to individual examples by their  tag

may be more informative (for translators also):

@c Translators should use the localized URLs, followed by their
translated anchor name (e.g. examples.it.html#Musica-Antica)



You're right, that was an oversight on my part.  Good catch, thanks!
Those edits all make sense to me.  Should I do them or would you like
to?  Either way is fine with me.



If you don't mind, and as I'm about to merge 
master->translation->staging, I'll take care of it.
I'll also take care of the Japanese and French versions as Federico 
mentioned on the translation list.


Cheers,
Jean-Charles




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

Re: wrong duration

[Thomas Morley]

2016-10-15 6:50 GMT+02:00 Jack Wilson :
>> I'm not top posting.
>
> \version "2.18.2"
>
> % layout should show default quarter notes, but
> % defining variable with non-default duration
> whole_rest = r1
> % impacts default duration in music expression
> \relative c' { c c c c }


Hi Jack,

the default duration is always updated by the last duration you wrote
in LilyPond-syntax.
This is a feature, no bug.

If you really, really want to circumvent it, define variables in scheme:

#(define whole_rest #{ r1 #})
\relative c' { c c c c }

Though, this will become very tedious, very fast.

 Imho, it should be no big problem to do
\relative c' { c4 c c c }

Cheers,
  Harm

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

Re: extra note head

[Thomas Morley]

2016-10-15 6:47 GMT+02:00 Jack Wilson :
>> I'm not top posting.
>
> % I want to be able to use chords here
> % in order to create accurate midi files
> % but if I do, the layout is wrong
> % reference: Snippets - Guitar strum rhythms
>
> \version "2.18.2"
>
> \new Voice \with {
>   \consists "Pitch_squash_engraver"
> } {
>   \improvisationOn
>   % chord causes extra note head to be produced
>   a b < c e g > d
> }



Hi Jack,

actually LilyPond creates a "slash"-note-head for every _NoteHead_ of
a NoteColumn. This is done via `improvisationOn'. The
Pitch_squash_engraver, reading `squashedPosition' from the settings
given as well by `improvisationOn', prints the "slash"-note-heads all
at same vertical position.
For chords, where all containing NoteHeads are in the same NoteColumn,
this means the NoteHeads are (partly) printed one upon the other.

Can be made visible with:

\new Voice \with { \consists "Pitch_squash_engraver" }
{
  \improvisationOn
  \once \override NoteColumn.after-line-breaking =
  #(lambda (grob)
(for-each
  (lambda (i nh) (ly:grob-set-property! nh 'extra-offset (cons i i)))
  (iota 4 1 1)
  (ly:grob-array->list (ly:grob-object grob 'note-heads
  < c e g>4
}

I do understand it's unexpected behaviour for you. But what exactly is the bug?
The code works as expected, albeit you want a different behaviour.

For getting what you want I see three possibilities:

(1) Set all NoteHead.stencil of a NoteColumn #f, but give NoteColumn a stencil.

Though I can't recommend it. NoteColumn has no default-stencil, it
serves as a" container" for the NoteHeads and a bit other stuff. A
stencil for NoteColumn will likely break things elsewhere.
Nevertheless, here a naive sketch. It's not elaborated and will not
play nicely with changed fontSize and other durations, though.

\new Voice \with { \consists "Pitch_squash_engraver" }
{
  \improvisationOn
  \once \override NoteColumn.after-line-breaking =
  #(lambda (grob)
(ly:grob-set-property! grob 'stencil
  (grob-interpret-markup grob (markup #:musicglyph "noteheads.s2slash")))
(for-each
  (lambda (nh) (ly:grob-set-property! nh 'stencil #f))
  (ly:grob-array->list (ly:grob-object grob 'note-heads
  < c e g>4
}

(2) Reduce every chord to a single note and use two scores for layout and midi.

 Leading to:

eventChordReduce =
#(define-music-function (parser location m)(ly:music?)
(event-chord-reduce m))

mus = {
  \improvisationOn
  a4 b < c e g> d
}

\score {
  \new Voice
\with { \consists "Pitch_squash_engraver" }
{ \eventChordReduce \mus }
}

\score {
  \new Voice
\with { \consists "Pitch_squash_engraver" }
\mus
  \midi {}
}

`eventChordReduce' as a music-function is missing in our source,
although we have the `event-chord-reduce'-procedure.
I'd call it a valid feature-request so far.

(3) Use tags.

Because it's anyway good practise to have two scores, one for layout,
another for midi you could use tags as documented.
Leading to:

mus = {
  \improvisationOn
  a4 b
  \tag #'midi < c e g>
  \tag #'layout c
  d
}

\score {
  \new Voice
\with { \consists "Pitch_squash_engraver" }
\removeWithTag #'midi \mus
}

\score {
  \new Voice
\with { \consists "Pitch_squash_engraver" }
\removeWithTag #'layout \mus
  \midi {}
}

Summary:
- I see no real bug here
- event-chord-reduce should be turned into a music-function and
implemented  into the source
- Eventually we could improve the docs about the improvisation-topic.
Suggestions?


Cheers,
  Harm

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