subject:"Re\: Error message"

Re: Error message using AikenHeads with NullVoice

2022-07-07 Thread Jean Abou Samra





On 7/7/22 18:23, David F. wrote:

On Jul 7, 2022, at 1:59 AM, Valentin Petzel  wrote:

A different way to approach the problem would be to also specify something like

\context {
  \NullVoice
  shapeNoteStyles = ##()
}

It is still questionable why NullVoice would hickup on simply changing the
NoteHead style, so think this is worth creating a bug report.

Cheers,
Valentin

Yes, it does seem odd—and avoidable—that NullVoice would have a problem with 
shape notes.

With aikenHeads, there is one note-head shape (the triangle that is not a 
pyramid) that depends on the stem direction.  My assumption is that’s where the 
error is coming from.


Yup.


But if the note is not being shown at all, that logic doesn’t need to be 
executed.


The definition of NullVoice in ly/engraver-init.ly contains

  %% provide non-printing NoteHeads with proper extents for lyric alignment
  \consists Note_heads_engraver
  \omit NoteHead
  \override NoteHead.X-extent = #(lambda (g)
    (ly:stencil-extent (ly:note-head::print g) X))


Best,
Jean

Re: Error message using AikenHeads with NullVoice

2022-07-07 Thread David F.

> On Jul 7, 2022, at 1:59 AM, Valentin Petzel  wrote:
> 
> A different way to approach the problem would be to also specify something 
> like
> 
> \context {
>  \NullVoice
>  shapeNoteStyles = ##()
> }
> 
> It is still questionable why NullVoice would hickup on simply changing the 
> NoteHead style, so think this is worth creating a bug report.
> 
> Cheers,
> Valentin

Yes, it does seem odd—and avoidable—that NullVoice would have a problem with 
shape notes.

With aikenHeads, there is one note-head shape (the triangle that is not a 
pyramid) that depends on the stem direction.  My assumption is that’s where the 
error is coming from.  But if the note is not being shown at all, that logic 
doesn’t need to be executed.

David F.

Re: Error message using AikenHeads with NullVoice

2022-07-07 Thread David F.




> On Jul 6, 2022, at 12:40 PM, David Wright  wrote:
> 
> On Wed 06 Jul 2022 at 11:56:52 (-0600), David F. wrote:
>> [ … ]
>> The command to use aikenHeads comes from a separate style file that gets 
>> included for each hymn.  But there is an unfortunate interaction between 
>> aikenHeads and NullVoice: Lilypond outputs the following error message:
>> 
>> programming error: must have stem dir for note head
>> continuing, cross fingers
>> 
>> And it outputs a lot of these messages.  I need to find a way to stop 
>> Lilypond from outputting this error.  Any kind of quick fix or hack would be 
>> sufficient.
> 
> $ lilypond source-file.ly |& tee /tmp/complete-errors | grep -v 'programming 
> error: must have stem dir for note head' | grep -v 'continuing, cross fingers'
> 
> Is this hackish enough? The unfiltered errors are available
> for consultation in /tmp/complete-errors. I would need sed
> rather than grep to filter out the second line only when
> preceded by this particular first line.
> 
> Cheers,
> David.

Yes, that would be an option.  I’m already filtering the warning I get from 
setting a custom variable from the command line:

"2>&1 | grep -v '^warning: no such internal option: 
\(aspect-ratio\|style\)$’”

But in this case, I’d be suppressing the error completely.  Which means that, 
in the future, if something I did were to also cause this error, I wouldn’t see 
it.

David F.

Re: Error message using AikenHeads with NullVoice

2022-07-07 Thread Valentin Petzel

A different way to approach the problem would be to also specify something like

\context {
  \NullVoice
  shapeNoteStyles = ##()
}

It is still questionable why NullVoice would hickup on simply changing the 
NoteHead style, so think this is worth creating a bug report.

Cheers,
Valentin

Am Mittwoch, 6. Juli 2022, 23:06:48 CEST schrieb David F.:
> > On Jul 6, 2022, at 1:20 PM, Jean Abou Samra  wrote:
> > 
> > How about changing \Staff into \Voice?
> > 
> > \layout {
> > 
> > \context {
> > 
> > \Voice
> > 
> > \aikenHeads
> > 
> > }
> > 
> > }
> > 
> > That way, it won't affect those NullVoice contexts.
> > 
> > Best,
> > Jean
> 
> Perfect.  That does exactly what I wanted.
> 
> Thanks!
> 
> David F.



signature.asc
Description: This is a digitally signed message part.

Re: Error message using AikenHeads with NullVoice

2022-07-06 Thread David F.



> On Jul 6, 2022, at 1:20 PM, Jean Abou Samra  wrote:
>
> How about changing \Staff into \Voice?
>
> \layout {
> \context {
> \Voice
> \aikenHeads
> }
> }
>
> That way, it won't affect those NullVoice contexts.
>
> Best,
> Jean
>

Perfect.  That does exactly what I wanted.

Thanks!

David F.

Re: Error message using AikenHeads with NullVoice

2022-07-06 Thread Jean Abou Samra

On 7/6/22 19:56, David F. wrote:

I have a collection of SATB hymns that I would like to engrave using shape 
notes.  The Lilypond files are all structured the same, as seen below—treble 
clef with music and a NullVoice for aligning lyrics, then the lyrics, then the 
bass clef.

%
\version "2.22"
\language “english"

% included from another file
\layout {
 \context {
 \Staff
 \aikenHeads
 }
}

\score {
 <<
 \new Staff <<
 % music here
 \new NullVoice = "melody" { e'8 fs'8 }
 >>
 % \new Lyrics \lyricsto "melody" { Ly -- rics }
 % bass clef here
 >>
 \layout {}
}
%

The command to use aikenHeads comes from a separate style file that gets 
included for each hymn.  But there is an unfortunate interaction between 
aikenHeads and NullVoice: Lilypond outputs the following error message:

programming error: must have stem dir for note head
continuing, cross fingers

And it outputs a lot of these messages.  I need to find a way to stop Lilypond 
from outputting this error.  Any kind of quick fix or hack would be sufficient.

One thought I had would be to re-enable regular note heads for the NullVoice:

 \new NullVoice = "melody" \with { \unset shapeNoteStyles } { e'8 
fs'8 }

But I couldn’t come up with anything that worked.

Any help or ideas would be greatly appreciated.

How about changing \Staff into \Voice?

\layout {
    \context {
    \Voice
    \aikenHeads
    }
}

That way, it won't affect those NullVoice contexts.

Best,
Jean

Re: Error message using AikenHeads with NullVoice

2022-07-06 Thread David Wright

On Wed 06 Jul 2022 at 11:56:52 (-0600), David F. wrote:
> [ … ]
> The command to use aikenHeads comes from a separate style file that gets 
> included for each hymn.  But there is an unfortunate interaction between 
> aikenHeads and NullVoice: Lilypond outputs the following error message:
> 
> programming error: must have stem dir for note head
> continuing, cross fingers
> 
> And it outputs a lot of these messages.  I need to find a way to stop 
> Lilypond from outputting this error.  Any kind of quick fix or hack would be 
> sufficient.

$ lilypond source-file.ly |& tee /tmp/complete-errors | grep -v 'programming 
error: must have stem dir for note head' | grep -v 'continuing, cross fingers'

Is this hackish enough? The unfiltered errors are available
for consultation in /tmp/complete-errors. I would need sed
rather than grep to filter out the second line only when
preceded by this particular first line.

Cheers,
David.

Re: Error message

2019-06-25 Thread Craig Dabelstein

Hi Aaron,

The inclusion of *\override Stem.neutral-direction = #'() *comes straight
from the LSR here:

http://lilypond.org/doc/v2.18/Documentation/snippets/pitches#pitches-automatically-changing-the-stem-direction-of-the-middle-note-based-on-the-melody

Here is another MWE to reproduce the problem:


\version "2.19.82"
\language english

\layout {
  \context {
\Staff
\consists "Melody_engraver"
\override Stem.neutral-direction = #'()
  }
}

\relative c'' {
  \time 3/2
  \tuplet 3/2 2 {
r4 df \f af gf' cf, ef gf, e' a,
  } |

  \tuplet 3/2 2 { r4 g' bf, f' e, r df' c, r } |
}


And the error message:

Starting lilypond 2.19.82 [mwe.ly]...

Processing `/Users/craigdabelstein/Desktop/mwe.ly'

Parsing...

Interpreting music...

Preprocessing graphical objects...

Finding the ideal number of pages...

Fitting music on 1 page...

Drawing
systems.../home/gub/NewGub/gub/target/darwin-x86/src/lilypond-git.sv.gnu.org--lilypond.git-stable-2.20/flower/include/drul-array.hh:35
<0>: failed assertion `d == 1 || d == -1'

Exited with exit status 1.

Craig


On Tue, 25 Jun 2019 at 22:56, Aaron Hill  wrote:

> On 2019-06-25 4:46 am, David Kastrup wrote:
> > Craig Dabelstein  writes:
> >
> >> And the guilty line is ...
> >>
> >> \consists "Melody_engraver"
> >> %\override Stem.neutral-direction = #'()
> >>
> >> Commenting out the \override Stem.neutral-direction line fixed the
> >> problem.
> >
> > More likely than not half of a red herring: garbage protection problems
> > are quite elusive to track down.  This propably changes the actions the
> > Melody_engraver takes.
>
> Unless I am completely lost myself, this is not the trampoline problem
> from before, though I suspect the appearance of "Melody_engraver" has
> confused things.
>
> Here is the proper repro MWE:
>
> 
> \version "2.19.82"
> {
>\override Stem.neutral-direction = #'()
>\tuplet 3/2 { r4 b' c'' }
> }
> 
>
> This is bad input because neutral-direction must be strictly UP or DOWN
> (or rather it can be a procedure that ultimately evaluates to 1 or -1).
>  From what I can see, the point of the property is to determine what
> happens to a note on the middle line of a staff when there is nothing
> else (like a beam) that can help sway the decision one way or the other.
>   Setting it to #'() would seem to be meaningless.
>
> Consider the output from the above MWE:
>
> 
> GNU LilyPond 2.19.82
> Processing `drul-array-bad-direction.ly'
> Parsing...
> Interpreting music...
> Preprocessing graphical objects...
> programming error: Stem dir must be up or down.
> continuing, cross fingers
> Finding the ideal number of pages...
> Fitting music on 1 page...
> Drawing systems...lilypond:
> /home/gub/NewGub/gub/target/linux-64/src/lilypond-git.sv.gnu.org--lilypond.git-stable-2.20/flower/include/drul-array.hh:35:
>
> T& Drul_array::at(Direction) [with T = double]: Assertion `d == 1 ||
> d == -1' failed.
> The terminal process terminated with exit code: 134
> 
>
> LilyPond is already emitting a programming error: "Stem dir must be up
> or down".  Whenever I see "cross fingers", I never make any assumption
> of what will work or not.  So a failing assertion afterwards is not
> surprising.
>
> Craig: Would you confirm whether your project output contains the
> programming error line?  I would say there is a bug if you are *only*
> seeing the failing assertion.
>
> Perhaps an additional check could be added to stem.cc:649 to ensure that
> neutral-direction has a sane value, which could catch this particular
> error earlier in the process.
>
>
> -- Aaron Hill
>
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user
>


-- 
[image: photograph]
*Craig Dabelstein*
Owner
email: cr...@maximesmusic.com.au
Maxime's Music, QLD, Australia
[image: facebook icon]  [image:
twitter icon]  [image: youtube icon]
 [image: instagram icon]
  maximesmusic.com.au
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Error message

2019-06-25 Thread Aaron Hill

On 2019-06-25 4:46 am, David Kastrup wrote:

Craig Dabelstein writes:

And the guilty line is ...

\consists "Melody_engraver"
%\override Stem.neutral-direction = #'()

Commenting out the \override Stem.neutral-direction line fixed the
problem.

More likely than not half of a red herring: garbage protection problems
are quite elusive to track down. This propably changes the actions the
Melody_engraver takes.

Unless I am completely lost myself, this is not the trampoline problem
from before, though I suspect the appearance of "Melody_engraver" has
confused things.

Here is the proper repro MWE:

\version "2.19.82"
{
\override Stem.neutral-direction = #'()
\tuplet 3/2 { r4 b' c'' }
}

This is bad input because neutral-direction must be strictly UP or DOWN
(or rather it can be a procedure that ultimately evaluates to 1 or -1).
From what I can see, the point of the property is to determine what
happens to a note on the middle line of a staff when there is nothing
else (like a beam) that can help sway the decision one way or the other.
Setting it to #'() would seem to be meaningless.

Consider the output from the above MWE:

GNU LilyPond 2.19.82
Processing `drul-array-bad-direction.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...
programming error: Stem dir must be up or down.
continuing, cross fingers
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...lilypond:
/home/gub/NewGub/gub/target/linux-64/src/lilypond-git.sv.gnu.org--lilypond.git-stable-2.20/flower/include/drul-array.hh:35:
T& Drul_array::at(Direction) [with T = double]: Assertion `d == 1 ||
d == -1' failed.

The terminal process terminated with exit code: 134

LilyPond is already emitting a programming error: "Stem dir must be up
or down". Whenever I see "cross fingers", I never make any assumption
of what will work or not. So a failing assertion afterwards is not
surprising.

Craig: Would you confirm whether your project output contains the
programming error line? I would say there is a bug if you are *only*
seeing the failing assertion.

Perhaps an additional check could be added to stem.cc:649 to ensure that
neutral-direction has a sane value, which could catch this particular
error earlier in the process.

92 matches

Mail list logo