Segmentation fault with 2.17.14

[Paul Scott]

I get segmentation faults with 2.17.14 on a medium to large set of files 
which compile fine with 2.17.13.  I have gotten these errors with some other 
recent 2.17.xx versions.  I don't believe I will get errors with a minimal 
example.

What evidence can I provide that might help find the problem?

Paul Scott




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

Re: Segmentation fault with 2.17.14

[Trevor Daniels]

Paul Scott wrote Wednesday, March 20, 2013 7:56 AM


>I get segmentation faults with 2.17.14 on a medium to large set of files 
> which compile fine with 2.17.13.  I have gotten these errors with some other 
> recent 2.17.xx versions.  I don't believe I will get errors with a minimal 
> example.
> 
> What evidence can I provide that might help find the problem?

Well, start removing things from your code until the error goes away.
Start with large sections.  Put back what you have just removed and 
continue removing other things or smaller pieces.  When there is nothing 
left that can be removed without also removing the error you have a 
minimal example.  

The chances are in carrying out this process that you will discover
what is causing the problem.  Tell us what it is.

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

Re: Segmentation fault with 2.17.14

[David Kastrup]

"Trevor Daniels"  writes:

> Paul Scott wrote Wednesday, March 20, 2013 7:56 AM
>
>
>>I get segmentation faults with 2.17.14 on a medium to large set of files 
>> which compile fine with 2.17.13.  I have gotten these errors with
>> some other
>> recent 2.17.xx versions.  I don't believe I will get errors with a
>> minimal
>> example.
>> 
>> What evidence can I provide that might help find the problem?
>
> Well, start removing things from your code until the error goes away.
> Start with large sections.  Put back what you have just removed and 
> continue removing other things or smaller pieces.  When there is nothing 
> left that can be removed without also removing the error you have a 
> minimal example.  
>
> The chances are in carrying out this process that you will discover
> what is causing the problem.  Tell us what it is.

That's more or less cut&paste from the instructions for a minimal
example.  There is no guarantee that the code removed along with the
segfault is responsible for the segfault.  But there is a good chance
that you have arrived at a version where the segfault is easier to
diagnose, because we'll be searching for the needle in a quite smaller
haystack.

-- 
David Kastrup


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

Re: Segmentation fault with 2.17.14

[David Kastrup]

Paul Scott  writes:

> I get segmentation faults with 2.17.14 on a medium to large set of files 
> which compile fine with 2.17.13.  I have gotten these errors with some
> other
> recent 2.17.xx versions.  I don't believe I will get errors with a
> minimal example.
>
> What evidence can I provide that might help find the problem?

I tend to do something like

git log release/2.17.13-1..release/2.17.14-1

for "problem occured between x and y" to look for a likely candidate
based on the commit message, and I just did that.  Tell you what: easily
a third or more of all commits could be responsible.

There are two things for circling the problem: one is "git bisect" to
figure out the commit introducing the segfault.  If nothing else, we can
then revert the commit until figuring out the problem.  The other is
post-mortem-debugging the segfault to figure out the code where things
go wrong.

Either will require a developer being able to reproduce the problem.
Try reducing a file of yours to a point where the segfault still occurs
but most of the content could get thrown out.

-- 
David Kastrup


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

Re: Segmentation fault with 2.17.14

[Paul Scott]

On Wed, Mar 20, 2013 at 08:37:38AM -, Trevor Daniels wrote:
> 
> Paul Scott wrote Wednesday, March 20, 2013 7:56 AM
> 
> 
> >I get segmentation faults with 2.17.14 on a medium to large set of files 
> > which compile fine with 2.17.13.  I have gotten these errors with some 
> > other 
> > recent 2.17.xx versions.  I don't believe I will get errors with a minimal 
> > example.
> > 
> > What evidence can I provide that might help find the problem?
> 
> Well, start removing things from your code until the error goes away.
> Start with large sections.  Put back what you have just removed and 
> continue removing other things or smaller pieces.  When there is nothing 
> left that can be removed without also removing the error you have a 
> minimal example.  

I know how to produce a minimal example.  I had been removing code and hadn't 
seen results yet and going back to 2.17.13 immediately solved the problem.  I 
have done exactly that with other music with some other recent versions.

I was wondering if some kind of trace might provide someone with a clue.

I have several parts to finish tonight which I am doing quite successfully 
with 2.17.13.

I will give it another try when I can. 

> The chances are in carrying out this process that you will discover
> what is causing the problem.  Tell us what it is.

I appreciate that possibility.  I have said the same thing to a number 
of programming classes I have taught including the assembly language 
class I was teaching tonight.

Thanks and thanks for all the work you all do on this magnificent project.  
I'll be back.

Paul

> 
> Trevor


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

Re: Segmentation fault with 2.17.14

[David Kastrup]

Paul Scott  writes:

> I appreciate that possibility.  I have said the same thing to a number
> of programming classes I have taught including the assembly language
> class I was teaching tonight.

Sounds like you should be able to run lilypond in a debugger then and
get a useful backtrace.

How did you obtain your binary?  Is it compiled with the same procedure
and compiler version as the last one?

-- 
David Kastrup


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

musicxml2ly formatting

[Martin Tarenskeen]

Hi,

Musicxml2ly is a nice tool, even if the output is quite often not perfect 
and needs manual editing to - often easily - fix errors. (I have plans to 
test a large collection of xml scores, and make a list of all strange 
and/or bad results I'm encountering. But that's not what this message is 
about)


Fixing errors in complex lilypond files is easier when the file is nicely 
formatted. But IMO the output from music2xml, even if syntactically 
correct, often looks ugly. When I use frescobaldi's formatting tool 
things already look much better.


Is muscxml2ly's ugly output formatting a matter of  personal taste and 
style, or is this an issue worth to be added to the buglist?


--

MT

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

Re: Segmentation fault with 2.17.14

[Paul Scott]

Ok.  False alarm but hopefully useful info:

The error was triggered by two instances of \times which should have been 
\time .  Now my code compiles with either 2.17.13 or 2.17.14.

If it helps I am using lilypond-2.17.14-1.linux-64

Maybe this difference between 2.17.14 and 2.17.13 could be related to 
work on \tuplet .

Thanks,

Paul


On Wed, Mar 20, 2013 at 10:03:23AM +0100, David Kastrup wrote:
> Paul Scott  writes:
> 
> > I get segmentation faults with 2.17.14 on a medium to large set of files 
> > which compile fine with 2.17.13.  I have gotten these errors with some
> > other
> > recent 2.17.xx versions.  I don't believe I will get errors with a
> > minimal example.
> >
> > What evidence can I provide that might help find the problem?
> 
> I tend to do something like
> 
> git log release/2.17.13-1..release/2.17.14-1
> 
> for "problem occured between x and y" to look for a likely candidate
> based on the commit message, and I just did that.  Tell you what: easily
> a third or more of all commits could be responsible.
> 
> There are two things for circling the problem: one is "git bisect" to
> figure out the commit introducing the segfault.  If nothing else, we can
> then revert the commit until figuring out the problem.  The other is
> post-mortem-debugging the segfault to figure out the code where things
> go wrong.
> 
> Either will require a developer being able to reproduce the problem.
> Try reducing a file of yours to a point where the segfault still occurs
> but most of the content could get thrown out.
> 
> -- 
> David Kastrup
> 
> 
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user
> 


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

Re: Segmentation fault with 2.17.14

[Paul Scott]

On Wed, Mar 20, 2013 at 10:27:27AM +0100, David Kastrup wrote:
> Paul Scott  writes:
> 
> > I appreciate that possibility.  I have said the same thing to a number
> > of programming classes I have taught including the assembly language
> > class I was teaching tonight.
> 
> Sounds like you should be able to run lilypond in a debugger then and
> get a useful backtrace.
> 
> How did you obtain your binary?  Is it compiled with the same procedure
> and compiler version as the last one?

I always run linux-x86 versions on my desktop and linux-64 versions 
on my laptop from http://lilypond.org/development.html on Debian Sid.

Thanks,

Paul



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

Re: R shorthand

[Kieren MacMillan]

Hi Evan,

> FWIW the multimeasure rest syntax has been a bit of an annoyance with what 
> I've been working on recently (Mars).

First of all, could you please email me the note code for "Mars" when you're 
done? I'm working on a wicked-cool Lilypond demo, and "Mars" was exactly the 
piece I was considering using for the example — if I could leverage your input 
effort, it would be greatly appreciated.

> To me it's quite counter-intuitive that a "full measure rest" can mark any 
> durations other than a multiple of a full measure

I can imagine that, somewhere out there, someone uses (e.g.)

R1*15/16 s16\> s1\!

However, this (IMO) is not a compelling enough reason to avoid implementing my 
suggested syntax — we should improve Lilypond to the point where such 
non-intuitive code as the above is unnecessary.

> the proposed suggestion is a significant local improvement.

Glad to hear!

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

Re: R shorthand

[David Kastrup]

Kieren MacMillan  writes:

> Hi Evan,
>
>> FWIW the multimeasure rest syntax has been a bit of an annoyance
>> with what I've been working on recently (Mars).
>
> First of all, could you please email me the note code for "Mars" when
> you're done? I'm working on a wicked-cool Lilypond demo, and "Mars"
> was exactly the piece I was considering using for the example — if I
> could leverage your input effort, it would be greatly appreciated.
>
>> To me it's quite counter-intuitive that a "full measure rest" can
>> mark any durations other than a multiple of a full measure
>
> I can imagine that, somewhere out there, someone uses (e.g.)
>
> R1*15/16 s16\> s1\!
>
> However, this (IMO) is not a compelling enough reason to avoid
> implementing my suggested syntax — we should improve Lilypond to the
> point where such non-intuitive code as the above is unnecessary.

Whatever you mean by "improve".  What is supposed to be the result of

{ \time 3/4 << { R15 \time 2/4 R3 } \\
   { R3 \time 4/4 R10 }
>>
}

and who is going to figure it out?  Note that time changes happen
synchronously in all contexts, unless the Timing_translator gets moved.
So what happens if you quote music with full measure rests in contexts
with different time signature.

>> the proposed suggestion is a significant local improvement.
>
> Glad to hear!

You can agree however much you want to, but you won't manage to lobby
any programmer into successfully coding the impossible.  Any
"improvement" would just mean things breaking in more obscure ways.

-- 
David Kastrup


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

Re: Lilypond Woodwind-Diagram for Bassoon missing half-hole option for first finger

[ryanmichaelmcclure]

I'm unable to post the fingering chart from my professor's book because it's
owned by the publisher and not him... There goes that idea. My only other
suggestion that I have found for the current fingering chart is that on the
right hand on the back, where there are only four keys, the round key is not
large enough to be proportional with the others. It is larger than the other
keys in that area.



-
Ryan McClure

Luna Music Engraving
--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Lilypond-Woodwind-Diagram-for-Bassoon-missing-half-hole-option-for-first-finger-tp142777p143115.html
Sent from the User mailing list archive at Nabble.com.

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

Re: Segmentation fault with 2.17.14

[David Kastrup]

Paul Scott  writes:

> Ok.  False alarm but hopefully useful info:
>
> The error was triggered by two instances of \times which should have
> been \time .  Now my code compiles with either 2.17.13 or 2.17.14.

That's no excuse for segfaulting, however.

-- 
David Kastrup

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

Re: R shorthand

[Kieren MacMillan]

Hi David,

> Whatever you mean by "improve".



> What is supposed to be the result of
> { \time 3/4 << { R15 \time 2/4 R3 } \\ { R3 \time 4/4 R10 } >> }

One context consisting of a sequence of multi-measure rests totalling 51 
quarter notes, simultaneously with a second context consisting of a sequence of 
multi-measure rests totalling 49 quarter notes.

> Note that time changes happen synchronously in all contexts, unless the 
> Timing_translator gets moved.
> So what happens if you quote music with full measure rests in contexts
> with different time signature.

An excellent question, which I am happy to leave up to those working on the 
low-level code.

> You can agree however much you want to, but you won't manage to lobby
> any programmer into successfully coding the impossible.  Any
> "improvement" would just mean things breaking in more obscure ways.

This is precisely why I posed the question in the first place: So that those 
with more knowledge than I in these matters could comment on whether it was 
possible. Despite the spectacular — though hardly unexpected — lack of tact in 
your response, I was able to parse out the answer.

Thanks,
Kieren.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

More sophisticated/complicated display of harmonics

[David G]

I'm trying to create a function to display harmonics as shown in the
attached images.

harmonic1.png is in the alto clef with the sounded pitches written in the
treble clef
[image: Inline images 3]


harmonic4.png is an acciaccatura all in the alto clef
[image: Inline images 4]

This is where I got to:

harmonicFingered =
#(define-music-function
  (parser location note) (ly:music?)
  #{
  \stemNeutral #note
  #})

harmonicActual =
#(define-music-function
  (parser location note) (ly:music?)
  #{
  \once \override Accidental #'font-size = #-4
  \once \override Accidental #'extra-offset = #'(2 . 0)
  \tweak Stem #'stencil ##f
  \tweak Flag #'stencil ##f
  \tweak #'font-size #-4
  \tweak #'X-offset #1.75
  #note
  #})

harmonicActualGrace =
#(define-music-function
  (parser location note) (ly:music?)
  #{
  \once \override Accidental #'font-size = #-4
  \tweak Stem #'stencil ##f
  \tweak Flag #'stencil ##f
  \tweak #'font-size #-4
  #note
  #})

harmonicBoth =
#(define-music-function (parser location fingered actual) (ly:music?
ly:music?)
#{
<<{\harmonicFingered $fingered } \new Voice {\harmonicActual $actual }>>
\oneVoice
#})

harmonicGrace =
#(define-music-function (parser location fingered actual) (ly:music?
ly:music?)
#{
<<{\harmonicFingered $fingered } \new Voice {\harmonicActualGrace $actual
}>> \oneVoice
#})

(for everything except acciaccaturas/grace notes I am putting the sounded
pitch after the fingered pitch to be consistent (the original score has
some before and some after) - for acciaccaturas I am aligning them
vertically).

Which gets things more or less right for most situations -
e.g. \harmonicBoth 4_\flageolet e'}

However, I would be very grateful if someone could help me to

a) clean up the function a bit to be more Lilypondian - I don't think I
have done things in the correct/logical way here (I am quite new to this!)

b) if possible allow adding a treble clef or ottava to the sounded pitch

c) make slurs/tuplet brackets etc. avoid the notehead in the same way as
they do  normal noteheads.


As an aside, why do \flageolets always appear above the note unless
specified with a _?


Many thanks!
<><>___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Lilypond Woodwind-Diagram for Bassoon missing half-hole option for first finger

[Wim van Dommelen]

On 20 Mar 2013, at 14:32 , ryanmichaelmcclure wrote:

I'm unable to post the fingering chart from my professor's book  
because it's

owned by the publisher and not him... There goes that idea.
No problem, I don't want you to violate any rights. If however you  
find a suitable usable version on the Internet, you can always post me  
a link.



My only other
suggestion that I have found for the current fingering chart is that  
on the
right hand on the back, where there are only four keys, the round  
key is not
large enough to be proportional with the others. It is larger than  
the other

keys in that area.

Will have to look at just a real bassoon.

Main questions: Did you accomplish the hack? And are you happy (= can  
you proceed) with the current result for the 'one1h' option?





-
Ryan McClure

Luna Music Engraving
--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Lilypond-Woodwind-Diagram-for-Bassoon-missing-half-hole-option-for-first-finger-tp142777p143115.html
Sent from the User mailing list archive at Nabble.com.

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



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

Re: R shorthand

[David Kastrup]

Kieren MacMillan  writes:

> Hi David,
>
>> Whatever you mean by "improve".
>
> 
>
>> What is supposed to be the result of
>> { \time 3/4 << { R15 \time 2/4 R3 } \\ { R3 \time 4/4 R10 } >> }
>
> One context consisting of a sequence of multi-measure rests totalling
> 51 quarter notes, simultaneously with a second context consisting of a
> sequence of multi-measure rests totalling 49 quarter notes.
>
>> Note that time changes happen synchronously in all contexts, unless
>> the Timing_translator gets moved.
>> So what happens if you quote music with full measure rests in contexts
>> with different time signature.
>
> An excellent question,

Actually, a rather bad question since once sentence above I essentially
stated that there usually _are_ no contexts with different time
signature, the time signature being infectious across contexts.

> which I am happy to leave up to those working on the low-level code.

Well, since I was not even able to phrase a well-working question, my
chances on actual low-level code would be worse.

>> You can agree however much you want to, but you won't manage to lobby
>> any programmer into successfully coding the impossible.  Any
>> "improvement" would just mean things breaking in more obscure ways.
>
> This is precisely why I posed the question in the first place: So that
> those with more knowledge than I in these matters could comment on
> whether it was possible. Despite the spectacular — though hardly
> unexpected — lack of tact in your response, I was able to parse out
> the answer.

I gave the answer previously, including the rationale.  Since it was
tactfully being ignored, it seemed to require more emphasis.  Otherwise
I would likely have been blamed for ignoring users' wishes in spite of
them reaching perfect agreement.

-- 
David Kastrup

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

User comments on R shorthand

[James Harkins]

I apologize for weighing in on the R shorthand thread by sending a new
message. I read the digest and normally reply to messages by gmane.
However, for some unknown reason, "R shorthand" seems to be missing
entirely from gmane. It exists in the archives on lists.gnu.org.

My opinion (as a somewhat-more-than-casual Lilypond user, and as a
contributor to another music software package [SuperCollider]): Any
change in syntax that will break prior usage should be considered
very, very carefully to be sure the gains are worth it.

The proposal is:

- Old: R2  ==  a full measure rest in 2/4 time
- New: R2  ==  *two* full measure rests in any time signature

That breaks backward compatibility.

I do agree with Kieren that it's annoying to have to enter durations
for full measure rests, when the duration of the measure is known
elsewhere. So I think some change, if possible, would be nice to have.

I think Joram's suggestion, R*n, makes a lot more sense. It's related
to the current syntax, just more convenient, and it doesn't break
existing uses since the parser can distinguish among all of the
following unambiguously:

R2 (a full measure rest in 2/4 time)
R2*2 (two full measure rests in 2/4 time)
R*2 (two full measure rests in any meter)

The fact that Kieren's original proposal would change the meaning of
the number immediately after R raises a red flag for me -- breaking
compatibility, confusing current users once they are forced to adapt
to the new syntax -- and the only gain over the second proposal is to
lose a * after R. That falls far short of the threshold to justify
breaking existing syntax, IMO.

I'm strongly against Kieren's original idea. I'm cautiously in favor
of Joram's alternative.

hjh

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

Bug in PianoStaff and StaffGroup barlines

[James Worlton]

Hello,

While the basic output of barlines in grouped staves has improved in
2.17.14, there is still a problem if there is a dynamics staff included.
The following code produces the expected output in 2.16.1 but is broken in
2.17.14:

\score {
  \new PianoStaff <<
\new Staff { c'1 }
\new Dynamics { s1\p }
\new Staff { c'1 }
  >>
}

\score {
  \new StaffGroup <<
\new Staff { c'1 }
\new Dynamics { s1\p }
\new Staff { c'1 }
  >>
}

James Worlton
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Bug in PianoStaff and StaffGroup barlines

[Xavier Scheuer]

On 20 March 2013 16:04, James Worlton  wrote:
> Hello,
>
> While the basic output of barlines in grouped staves has improved in
> 2.17.14, there is still a problem if there is a dynamics staff included. The
> following code produces the expected output in 2.16.1 but is broken in
> 2.17.14:
>
> \score {
>   \new PianoStaff <<
> \new Staff { c'1 }
> \new Dynamics { s1\p }
> \new Staff { c'1 }
>   >>
> }
>
> \score {
>   \new StaffGroup <<
> \new Staff { c'1 }
> \new Dynamics { s1\p }
> \new Staff { c'1 }
>   >>
> }
>

Right.

This is the -user mailing list, bug reports should be send to
bug-lilyp...@gnu.org .
But this one has already been reported:
"SpanBar - the problem still exists"
http://lists.gnu.org/archive/html/bug-lilypond/2013-03/msg00060.html

https://code.google.com/p/lilypond/issues/detail?id=3192

Cheers,
Xavier

-- 
Xavier Scheuer 

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

Re: User comments on R shorthand

[Werner LEMBERG]

> - Old: R2  ==  a full measure rest in 2/4 time
> - New: R2  ==  *two* full measure rests in any time signature

Actually, I like this.  This would also help in situations like


  tacet al 
   |--|


> That breaks backward compatibility.

convert-ly is your friend.


Werner

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

Re: User comments on R shorthand

[James Harkins]

On Wed, Mar 20, 2013 at 11:17 PM, Werner LEMBERG  wrote:
>
>> - Old: R2  ==  a full measure rest in 2/4 time
>> - New: R2  ==  *two* full measure rests in any time signature
>
> Actually, I like this.  This would also help in situations like
>
>   tacet al 
>|--|

Why would R*2 be so desperately painful that it would be worth
breaking compatibility?

I'm not saying I don't like the idea of R without a duration. I *am*
saying that changing the meaning of the number immediately following R
is a bad idea.

One character solves that problem.

>> That breaks backward compatibility.
>
> convert-ly is your friend.

Again... is it worth going this road over **one asterisk**? Really.

hjh

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

Re: Bug in PianoStaff and StaffGroup barlines

[James Worlton]

On Wed, Mar 20, 2013 at 10:16 AM, Xavier Scheuer wrote:

> On 20 March 2013 16:04, James Worlton  wrote:
> > Hello,
> >
> > While the basic output of barlines in grouped staves has improved in
> > 2.17.14, there is still a problem if there is a dynamics staff included.
> The
> > following code produces the expected output in 2.16.1 but is broken in
> > 2.17.14:
> >
> > \score {
> >   \new PianoStaff <<
> > \new Staff { c'1 }
> > \new Dynamics { s1\p }
> > \new Staff { c'1 }
> >   >>
> > }
> >
> > \score {
> >   \new StaffGroup <<
> > \new Staff { c'1 }
> > \new Dynamics { s1\p }
> > \new Staff { c'1 }
> >   >>
> > }
> >
>
> Right.
>
> This is the -user mailing list, bug reports should be send to
> bug-lilyp...@gnu.org .
> But this one has already been reported:
> "SpanBar - the problem still exists"
> http://lists.gnu.org/archive/html/bug-lilypond/2013-03/msg00060.html
>
> https://code.google.com/p/lilypond/issues/detail?id=3192
>
> Cheers,
> Xavier


Ah. I'm not subscribed to bug-lilypond, so I missed that. Sorry for the
noise.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: User comments on R shorthand

[Urs Liska]

Am 20.03.2013 16:25, schrieb James Harkins:

On Wed, Mar 20, 2013 at 11:17 PM, Werner LEMBERG  wrote:

- Old: R2  ==  a full measure rest in 2/4 time
- New: R2  ==  *two* full measure rests in any time signature

Actually, I like this.  This would also help in situations like

   tacet al 
|--|

Why would R*2 be so desperately painful that it would be worth
breaking compatibility?

I'm not saying I don't like the idea of R without a duration. I *am*
saying that changing the meaning of the number immediately following R
is a bad idea.

One character solves that problem.


That breaks backward compatibility.

convert-ly is your friend.

Again... is it worth going this road over **one asterisk**? Really.

hjh
I have the impression that Werner doesn't fight for the syntax *without 
asterisk* but that he is just in favor of a new option *without explicit 
duration*. I assume he would also feel "R*2" is an improvement.

Urs


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



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

Re: User comments on R shorthand

[Kieren MacMillan]

Hi James,

All good points!

> R2 (a full measure rest in 2/4 time)
> R2*2 (two full measure rests in 2/4 time)
> R*2 (two full measure rests in any meter)

Love it.

Cheers,
Kieren.

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

Re: Pseudo-handwritten font

[Xavier Scheuer]

On 14 March 2013 11:36, "Torsten Hämmerle"  wrote:
> Hello all,
>
> I've just noticed the my last mail didn't get through to the list for some
> reason. Well, here it is again in a second attempt:
>
> In the first place: I've attached a zip file containing the current (albeit
> unfinished) versions of the LilyJAZZ music and LilyJAZZ Text font plus the
> corresponding LilyJAZZ.ily include.
>
> (snip)
>

Hi Torsten,

I translated this message in French and posted in on the French users
mailing list, asking people testing LilyJAZZ to ask questions and
report bugs on this international mailing list (hence Denis' message).


On 19 March 2013 17:43, Denis Bitouzé  wrote:
>
> Very impressive! Very appreciated! Thanks a lot...
>
>> (well, I missed grace notes/acciaccaturas/appoggiaturas)
>
> (Maybe you're already aware but, just in case...) As pointed out by the
> following MCE, also are missing notes in tempo indication.

Once issue #3096 will be solved, it should be possible to have
"LilyJAZZ-style" metronome indications.
https://code.google.com/p/lilypond/issues/detail?id=3096

Cheers,
Xavier

-- 
Xavier Scheuer 

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

Re: User comments on R shorthand

[Nick Baskin]

On Wed, Mar 20, 2013 at 11:48 AM, Kieren MacMillan <
kieren_macmil...@sympatico.ca> wrote:

> Hi James,
>
> All good points!
>
> > R2 (a full measure rest in 2/4 time)
> > R2*2 (two full measure rests in 2/4 time)
> > R*2 (two full measure rests in any meter)
>
> Love it.
>
> Cheers,
> Kieren.
>
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user
>

I'm not sure this would work, actually. If I understand correctly, R
currently behaves like any other LilyPond music event when it comes to
duration, i.e. unless otherwise specified, it takes the value of the
preceding note/rest. So if you had something like

\time 2/4
R2 |
R |
\time 4/4
R*2 |

there would be some ambiguity as to what "R*2" should print out, yes? The
"R" prints out a single full-measure rest in 2/4; why would "R*2" in this
case print out two measures of full-measure rest in 4/4 (quadrupling the
length of the previous "R") instead of one measure (doubling the length of
the previous "R")?

-- 
And she forgot the stars, the moon, and sun,
And she forgot the blue above the trees,
And she forgot the dells where waters run,
And she forgot the chilly autumn breeze...

— Keats, "Isabella, or the Pot of Basil"
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: User comments on R shorthand

[David Kastrup]

Nick Baskin  writes:

> I'm not sure this would work, actually. If I understand correctly, R
> currently behaves like any other LilyPond music event when it comes to
> duration, i.e. unless otherwise specified, it takes the value of the
> preceding note/rest. So if you had something like
>
> \time 2/4
> R2 |
> R |
> \time 4/4
> R*2 |
>
> there would be some ambiguity as to what "R*2" should print out, yes?

No, syntax would not be a major impediment.  * can't start a duration,
so there would be no ambiguity.  But the semantics can't be supported
since "measure length" and/or "current meter" is a concept only
established in the Timing context.

-- 
David Kastrup


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

Re: User comments on R shorthand

[Kieren MacMillan]

Hi Nick,

> I'm not sure this would work, actually. If I understand correctly, R 
> currently behaves like any other LilyPond music event when it comes to 
> duration, i.e. unless otherwise specified, it takes the value of the 
> preceding note/rest. So if you had something like
> 
> \time 2/4
> R2 |
> R |
> \time 4/4
> R*2 |
> 
> there would be some ambiguity as to what "R*2" should print out, yes? The "R" 
> prints out a single full-measure rest in 2/4; why would "R*2" in this case 
> print out two measures of full-measure rest in 4/4 (quadrupling the length of 
> the previous "R") instead of one measure (doubling the length of the previous 
> "R")?

Interesting point…
I've never used R by itself (though I often use r, q, etc. by themselves), so I 
hadn't thought about this eventuality.

What about this being the right moment to use the [unused] @ symbol, i.e., R@2 
would mean 2 measures "at the current measure-duration"?

Thanks,
Kieren.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: R shorthand

[Kieren MacMillan]

Hi David,

> I gave the answer previously, including the rationale.  Since it was
> tactfully being ignored, it seemed to require more emphasis.  Otherwise
> I would likely have been blamed for ignoring users' wishes in spite of
> them reaching perfect agreement.

So to be perfectly clear: You can see no way to implement any sort of shorthand 
which saves the user having to know (and potentially return to modify, time and 
time again) the "current measure duration"?

Thank you,
Kieren.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: R shorthand

[David Kastrup]

Kieren MacMillan  writes:

> Hi David,
>
>> I gave the answer previously, including the rationale.  Since it was
>> tactfully being ignored, it seemed to require more emphasis.
>> Otherwise I would likely have been blamed for ignoring users' wishes
>> in spite of them reaching perfect agreement.
>
> So to be perfectly clear: You can see no way to implement any sort of
> shorthand which saves the user having to know (and potentially return
> to modify, time and time again) the "current measure duration"?

Quite so.

-- 
David Kastrup

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

Re: User comments on R shorthand

[Wim van Dommelen]

On 20 Mar 2013, at 17:03 , Nick Baskin wrote:

On Wed, Mar 20, 2013 at 11:48 AM, Kieren MacMillan > wrote:

Hi James,

All good points!

> R2 (a full measure rest in 2/4 time)
> R2*2 (two full measure rests in 2/4 time)
> R*2 (two full measure rests in any meter)

+1

Regards,
Wim.


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


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

Re: Column of music and a column of graphics... or creating invisible measures...

[Patrick or Cynthia Karl]

On Mar 19, 2013, at 9:45 PM, lilypond-user-requ...@gnu.org wrote:

> Message: 5
> Date: Tue, 19 Mar 2013 15:17:42 -0700 (PDT)
> From: rem-d 
> To: lilypond-user@gnu.org
> Subject: Column of music and a column of graphics... or creating
>   invisible   measures...
> Message-ID: <1363731462888-143065.p...@n5.nabble.com>
> Content-Type: text/plain; charset=us-ascii
> 
>  
> 
> Hi, first post on this forum.
> 
> I wish to have something similar to the image attached. At the moment my
> code is rather simple:
> 
> /upper = {
>  \override Score.KeyCancellation #'stencil = ##f
>  \set Score.explicitKeySignatureVisibility = #'#(#f #f #t)
>  \override Score.BarNumber #'stencil = ##f
>  \override Score.TimeSignature #'stencil = ##f
>  \time 2/4
>  \relative c''{
>   \key a \major
> 
> 
> \break
> \key bes \major
> 
> 
> \break 
> / . etc for the upper part. Similar for the lower /
> }
> 
> \score{
>   \new PianoStaff<<
> \new Staff  = "upper" \upper
> \new Staff = "lower" \lower
>>> /
> 
> 
> I've experimented with using columns in markup but this just didn't seem to
> do the trick. A slightly unsatisfying way to solve this would be to make the
> measures completely invisible so only the notes (or graphics: i.e the lines)
> would be visible.
> 
> Hope this makes sense. Apologies if this is something people have answered
> thousands of times!

It's difficult to tell from your code what you are after.  You do know that "/" 
is not the beginning of a comment in LilyPond, don't you.   In any case, the 
following seems to be close to the spirit of your attached image:

\version "2.16.2"

\paper {
ragged-bottom = ##t
ragged-last-bottom = ##t
ragged-right = ##t
}

upper =  \relative c''{
 \override Score.KeyCancellation #'stencil = ##f
 \set Score.explicitKeySignatureVisibility = #'#(#f #f #t)
 \override Score.BarNumber #'stencil = ##f
 \override Score.TimeSignature #'stencil = ##f


\break
\key bes \major


\break 
% . etc for the upper part. Similar for the lower /
}

global = {   \time 2/4 \key a \major }

\score {
  \new PianoStaff <<
  \new Staff  { \global \upper }
  \new Staff  { \global \upper }
  >>
  \layout { indent = 0 }
}   

HTH

 
> 
> Andy
> 
> 
> 
> --
> View this message in context: 
> http://lilypond.1069038.n5.nabble.com/Column-of-music-and-a-column-of-graphics-or-creating-invisible-measures-tp143065.html
> Sent from the User mailing list archive at Nabble.com.


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

Re: User comments on R shorthand

[David Raleigh Arnold]

On Wed, 2013-03-20 at 22:54 +0800, James Harkins wrote:
> I apologize for weighing in on the R shorthand thread by sending a new
> message. I read the digest and normally reply to messages by gmane.
> However, for some unknown reason, "R shorthand" seems to be missing
> entirely from gmane. It exists in the archives on lists.gnu.org.
> 
> My opinion (as a somewhat-more-than-casual Lilypond user, and as a
> contributor to another music software package [SuperCollider]): Any
> change in syntax that will break prior usage should be considered
> very, very carefully to be sure the gains are worth it.

Sorry I missed this before. If it's broke, fix it. It's broke.

http://www.openguitar.com/carcassi/index.html

See page 3, at the bottom, for two, three, and 
four measure rests. (I'm obliged to cite and give
credit for the scans.} How can these be implemented
without R2, R3, and R4? I submit that the
present lilypond implementation is broken
already. Sort of. Partly.

There should be no problem detecting the
measure lengths. The argument that R2 for a
measure rest of two beats is
not logical does not hold however, IMO. It could
be and probably was intended to
be read as "Instead of r2 put a measure
rest." A way of indicating the number of
measures rested by a number in the score
should of course remain, but R2, R3, and
R4 should be implemented as shown on page 3.
IMO.
 
Regards, daveA



-- 
Guitar teaching materials and original music for all styles and levels.
Site: http://www.openguitar.com (()) eMail: d.raleigh.arn...@gmail.com
Contact: http://www.openguitar.com/contact.html


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

Re: User comments on R shorthand

[Kieren MacMillan]

Hi David,

> See page 3, at the bottom, for two, three, and 
> four measure rests. (I'm obliged to cite and give
> credit for the scans.} How can these be implemented
> without R2, R3, and R4?

Assuming that staff is in 4/4 time (there is no time signature currently), then 
R1*2, R1*3, and R1*4 should work perfectly — do they not work for you?

> There should be no problem detecting the measure lengths.

That does seem intuitively true…
However, David K. (who knows way more about this than any of us) says it's 
false — I trust his judgement/opinion, until seeing concrete evidence to the 
contrary.

Thanks,
Kieren.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Custom footers

[Jérôme Plût]

Decimo tertio Kalendas Apriles MMXIII scripsit Thomas Morley :
> in the code below you'll see increasing page-numbers throughout the
> book as usual.

Ooh, now that I have had the time to read your code, I see what you
did, and I like it. The \on-the-fly side-effect is devious (and
un-Scheme-like, but who cares). Thanks!

> Though, I didn't manage to code "(1/3)" for consecutive bookparts,
> because I didn't understand how to get or calculate the
> bookpart-last-page-number.

The simplest way to do it would be the TeX way: saving the page count
for each section in a .aux file and reading this again on second
compilation. Unless, of course, the (open) Scheme function is disabled
in Lilypond. I will have a try at this.

-- 
Jérôme

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

Re: User comments on R shorthand

[Noeck]

Am 20.03.2013 19:11, schrieb David Raleigh Arnold:
> A way of indicating the number of
> measures rested by a number in the score
> should of course remain, but R2, R3, and
> R4 should be implemented as shown on page 3.

That is perfectly possible right now (and for a very long time):
R1*2 R1*3 R1*4 (for 4/4 measures and others analogue).

The discussion is about whether the duration of a measure must be specified.

Cheers,
Joram

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

Re: Custom footers

[Marc Hohl]

Am 20.03.2013 19:19, schrieb Jérôme Plût:

Decimo tertio Kalendas Apriles MMXIII scripsit Thomas Morley :

in the code below you'll see increasing page-numbers throughout the
book as usual.


Ooh, now that I have had the time to read your code, I see what you
did, and I like it. The \on-the-fly side-effect is devious (and
un-Scheme-like, but who cares). Thanks!


Though, I didn't manage to code "(1/3)" for consecutive bookparts,
because I didn't understand how to get or calculate the
bookpart-last-page-number.


The simplest way to do it would be the TeX way: saving the page count
for each section in a .aux file and reading this again on second
compilation. Unless, of course, the (open) Scheme function is disabled
in Lilypond. I will have a try at this.


Sorry for chiming in so late, but perhaps

http://lists.gnu.org/archive/html/lilypond-user/2013-01/msg00812.html

gives some ideas? You could use \label for defining where a part starts
and get the page number for this page. With these informations
calculating the offset/number of pages per part seems to be
straightforward ;-)

HTH,

Marc

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

Re: User comments on R shorthand

[David Kastrup]

Kieren MacMillan  writes:

> Hi David,
>
>> See page 3, at the bottom, for two, three, and 
>> four measure rests. (I'm obliged to cite and give
>> credit for the scans.} How can these be implemented
>> without R2, R3, and R4?
>
> Assuming that staff is in 4/4 time (there is no time signature
> currently), then R1*2, R1*3, and R1*4 should work perfectly — do they
> not work for you?
>
>> There should be no problem detecting the measure lengths.
>
> That does seem intuitively true…
> However, David K. (who knows way more about this than any of us) says
> it's false — I trust his judgement/opinion, until seeing concrete
> evidence to the contrary.

Not reliably, and I don't see a reliable way to complain about the
unreliable cases.  LilyPond needs to be able to calculate the length of
music in terms of whole notes in a number of "dry run" situations.

If we want to stipulate that bars and whole notes are interchangeable,
how many bars are there in

music = { \time 4/4 a1 a1 a1 a1 } ?

The answer appears intuitively simple.  Now look at the output of

music = { \time 4/4 a1 a1 a1 a1 }

\new Staff << \music \\ { f1 \time 12/4 f1 f1 f1 } >>

which is a perfectly valid though slightly capricious LilyPond file.
\music takes two bars.

-- 
David Kastrup


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

Re: User comments on R shorthand

[Phil Holmes]

[Snip possibly final comments.]

I've read all the emails on this, and personally agree that R*5 for 5 FMRs 
of whatever time sig would be a step forward.  Whether this is easy or 
difficult to implement is irrelevant to the way we handle enhancement 
requests.


Kieren - suggest you send an enhancement request to -bugs.

--
Phil Holmes 



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

Re: User comments on R shorthand

[David Kastrup]

"Phil Holmes"  writes:

> [Snip possibly final comments.]
>
> I've read all the emails on this, and personally agree that R*5 for 5
> FMRs of whatever time sig would be a step forward.  Whether this is
> easy or difficult to implement is irrelevant to the way we handle
> enhancement requests.
>
> Kieren - suggest you send an enhancement request to -bugs.

If it is entered into the tracker, I strongly suggest adding a link to
my mail with the LilyPond example for a startling bar count.  It might
keep people from wasting unnecessary time due to underestimating the
problem.

-- 
David Kastrup


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

Re: Custom footers

[Thomas Morley]

2013/3/20 Marc Hohl :
> Am 20.03.2013 19:19, schrieb Jérôme Plût:
>
>> Decimo tertio Kalendas Apriles MMXIII scripsit Thomas Morley :
>>>
>>> in the code below you'll see increasing page-numbers throughout the
>>> book as usual.
>>
>>
>> Ooh, now that I have had the time to read your code, I see what you
>> did, and I like it. The \on-the-fly side-effect is devious (and
>> un-Scheme-like, but who cares). Thanks!
>>
>>> Though, I didn't manage to code "(1/3)" for consecutive bookparts,
>>> because I didn't understand how to get or calculate the
>>> bookpart-last-page-number.
>>
>>
>> The simplest way to do it would be the TeX way: saving the page count
>> for each section in a .aux file and reading this again on second
>> compilation. Unless, of course, the (open) Scheme function is disabled
>> in Lilypond. I will have a try at this.
>>
> Sorry for chiming in so late, but perhaps
>
> http://lists.gnu.org/archive/html/lilypond-user/2013-01/msg00812.html
>
> gives some ideas? You could use \label for defining where a part starts
> and get the page number for this page. With these informations
> calculating the offset/number of pages per part seems to be
> straightforward ;-)
>
> HTH,
>
> Marc

Hi Marc,

I don't think it is that straightforward.
The problem is that one would want to print only that labeled
page-number which ends the bookparts.
It's not that easy to detemine what to print.

Below a first approach.
Several comments are inserted to explain drawbacks and how to make it
work with 2.12.3

I'd really prefer to directly read out the last bookpart-page-number somehow.
Any hint would be great.

Though, here the present code:


\version "2.16.2"
%\version "2.12.3"

#(define (looking-up layout props symbol)
   (define (ancestor layout)
 "Return the topmost layout ancestor"
 (let ((parent (ly:output-def-parent layout)))
   (if (not (ly:output-def? parent))
   layout
   (ancestor parent
   (ly:output-def-lookup (ancestor layout) symbol))

#(define (book-second-page? layout props)
   "Return #t iff the current page number, got from @code{props}, is the
book second one."
   (= (chain-assoc-get 'page:page-number props -1)
  (+ (looking-up layout props 'first-page-number) 1)))

#(define (not-second-page layout props arg)
   (if (not (book-second-page? layout props))
   (interpret-markup layout props arg)
   empty-stencil))

#(define (print-bookpart-numbers layout props arg)
   (let* ((book-page-number
(chain-assoc-get 'page:page-number props -1))
  (bookpart-first-page-number
(ly:output-def-lookup layout 'first-page-number))
  (book-part-numbers
(number->string (- book-page-number bookpart-first-page-number -1)))
  (book-part-number-markup
(markup book-part-numbers)))
  (interpret-markup layout props book-part-number-markup)))

#(define (get-equal-or-greater n l)
 "Return the first element of list, which is greater than n.
  l is supposed to be an ordered list of numbers."
  (if (null? l)
  0
  (if (< n (car l))
  (car l)
  (get-equal-or-greater n (cdr l)

%% Inserted to make it work with 2.12.3
#(define-markup-command (vspace layout props amount)
  (number?)
  "Create an invisible object taking up vertical space
   of @var{amount} multiplied by 3."
   (let ((amount (* amount 3.0)))
 (ly:make-stencil "" (cons 0 0) (cons 0 amount

#(define-markup-command
  (print-bookpart-last-page layout props label gauge default)
  (symbol? markup? markup?)
  "
  Depends on correctly set @code{\\label} command.
  @code{\\tocItem} is not disturbed, though, other settings of @code{\\label}
  will give unwanted results.

  Reference to a page number.  @var{label} is the label set on the referenced
  page (using the @code{\\label} command), @var{gauge} a markup used to estimate
  the maximum width of the page number, and @var{default} the value to display
  when @var{label} is not found."
  (let* ((gauge-stencil (interpret-markup layout props gauge))
 (x-ext (ly:stencil-extent gauge-stencil X))
 (y-ext (ly:stencil-extent gauge-stencil Y)))
(ly:make-stencil
 `(delay-stencil-evaluation
   ,(delay (ly:stencil-expr
 (let* ((table (ly:output-def-lookup layout 'label-page-table))
(label-page-number-list
   (sort (map (lambda (x) (cdr x)) table) <))
(part-first-page-number
   (ly:output-def-lookup layout 'first-page-number))
;; get the first, labeled page-number greater than
;; part-first-page-number.
;; Will be disturbed if additional labels are used.
;; TODO better method
(greater-than-part-first-page-number
   (if (null? label-page-number-list)
  0
   

all invisible bar lines reading as break in lilypond-book

[Timothy Heckenlively]

I recently upgraded to OSX Mountain Lion and suddenly encountered a technical 
problem with lilypond-book. All of the invisible bar lines ( \bar "") in my 
.lytex file are suddenly processing as full breaks. Has anyone heard of this 
bug or of a way to correct it? Many thanks for any insight you can offer.

Timothy Heckenlively
theckenliv...@gmail.com




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