Re: Regression test failure in 2.13.52

[m...@apollinemike.com]

I'm really sorry about that - I've pushed a fix.  Han Wen is trying to fix his 
beam collision stuff in the quanting, and I had pushed part of my old engraver 
which I thought would help fix some issues but actually breaks his code.  That 
is now cleaned up - everything should work.

Cheers,
MS

On Feb 27, 2011, at 11:19 AM, Trevor Daniels wrote:

> Several regression tests fail in 2.13.52.  Beams
> are misplaced, some randomly in different runs,
> and some fail with "no beam positions?" error.
> 
> Here's the output of one:
> 
> GNU LilyPond 2.13.52
> Processing `collision-merge-differently-dotted.ly'
> Parsing...
> Interpreting music... Preprocessing graphical objects...
> Finding the ideal number of pages...
> Fitting music on 1 page...
> Drawing systems...
> programming error: no beam positions?
> continuing, cross fingers
> Layout output to `collision-merge-differently-dotted.ps'...
> Converting to `./collision-merge-differently-dotted.pdf'...
> success: Compilation successfully completed
> 
> The problem is caused by commit 99503a78627620112cabb61bb9f1cee3fe9dfcb4
> pushed by Mike Solomon on 25 Feb 2011.
> 
> Trevor
> 
> 
> 
> 


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

Collision between maxima and lyric

[m...@apollinemike.com]

\relative c' { \override NoteHead #'style = #'mensural d\maxima }
\addlyrics { foo }

Cheers,
Mike

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

Re: Collision between maxima and lyric

[m...@apollinemike.com]

On Mar 22, 2011, at 6:20 PM, Neil Puttock wrote:

> On 22 March 2011 15:11, m...@apollinemike.com  wrote:
>> \relative c' { \override NoteHead #'style = #'mensural d\maxima }
>> \addlyrics { foo }
> 
> Looks like the same issue as this:
> 
> http://code.google.com/p/lilypond/issues/detail?id=826
> 

That must be it.
I don't have time to learn metafont for this piece, but I'll try to hack 
through it in a month or two if somebody else doesn't get there first.

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

Re: Beam collides with accidental

[m...@apollinemike.com]

The beam collision engraver currently only works w manual beams. I'm working on 
an auto beam solution that should be done in a month or so.

Cheers,
Mike

On Mar 26, 2011, at 13:29, Xavier Scheuer  wrote:

> Hi,
> 
> The new beam collision engraver is great, but in the following example
> the beam collides with the accidental.
> Shouldn't the new beam collision engraver handle this as well?
> 
> Many thanks!
> 
> 
> %% Reported on -user by Douglas Ridgway
> %%
> %% Beam collides with accidental
> %%
> 
> \version "2.13.55"
> 
> \relative c' {
>  \clef alto
>  ees,16 ees ees' ees
> }
> 
> 
> Cheers,
> Xavier
> 
> -- 
> Xavier Scheuer 
> 

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

Re: Issue 795 in lilypond: Beams do not take grace notes into account

[m...@apollinemike.com]

On Apr 2, 2011, at 8:08 PM, Colin Campbell wrote:

> On 11-04-02 05:18 PM, lilyp...@googlecode.com wrote:
>> 
>> Comment #5 on issue 795 by mts...@gmail.com: Beams do not take grace notes 
>> into account
>> http://code.google.com/p/lilypond/issues/detail?id=795
>> 
>> Hey Colin,
>> 
>> I'm not sure if this is a problem - the stem is just covered by the stem of 
>> the 8th note.  One can imagine that if the regtest had set the 8th notes 
>> lower, the quarter note stem would be subsumed into the 8th note stem.  ie:
>> 
>> quoteMe = \relative c' { fis4 r16  a8.-> b4-\ff c }
>> 
>> \addQuote quoteMe \quoteMe
>> original = \relative c'' { c8 d s2 \stemDown a8 fis8 }
>> 
>> <<
>>\new Staff {
>>\set Staff.instrumentName = "quoteMe"
>>\quoteMe
>>}
>>\new Staff {
>>\set Staff.instrumentName = "orig"
>>\original
>>}
>>\new Staff \relative c'' <<
>> 
>>\set Staff.instrumentName = "orig+quote"
>>\set Staff.quotedEventTypes = #'(note-event articulation-event)
>>\original
>>{ s4 \quoteDuring #"quoteMe" { s2. } }
>> >>
>> 
>> 
>> I think this addresses a larger issue, however, of being able to turn on and 
>> off certain grobs in the beam-collision-engraver.  This is doable via a 
>> modifiable property (ie Beam #'avoid = #'(stem beam note-head clef 
>> time-signature)), but that seems like it'd be appropriate for a separate 
>> patch.
>> 
> 
> I'm afraid I'm looking at it from a rather unsophisticated view, Mike: the 
> original showed reasonably clearly that there was a quarter note sharing a 
> head with one of the eighths, the patched version, by lengthening the stem of 
> the beamed notes, hides the quarter note completely. An amateur bass singer 
> such as I would not know it was there.
> 
> Colin
> 

I definitely see what you're saying.  My point above was not that the 
disappearing stem was a good (or bad) thing, but rather that in other 
circumstances (like the snippet I give above), the stem disappears even without 
the new patch. The protrusion of the quarter not stem is not a feature of 
quote-me but rather a product of happenstance.  The attached example, made 
without the proposed patch, provides another instance of the quarter note stem 
being gobbled up by the 8th note stem.

In your amateur choir scenario, in order to follow the bass line, it would be 
necessary that the two voices be typeset with stems in opposite directions.  
Otherwise, it is impossible to know who is singing what.

It's for this reason that I'm not averse to this change in the regtest.

Cheers,
MS



PastedGraphic-1.pdf
Description: Adobe PDF document

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

Re: Nouveau projet et personne ressource

[m...@apollinemike.com]

On Apr 7, 2011, at 2:53 PM, Danielle Paquet wrote:

> 
> Bonjour,
> 
> J'aimerais qu'une personne ressource en développement, au sein de votre 
> entreprise, me fasse parvenir le numéro de téléphone et le nom d'une personne 
> contact, idéalement, une personne qui parle français.  Nous aimerions pouvoir 
> communiquer avec elle demain le 8 avril dans la journée pour un projet.  
> Merci 
> de votre collaboration.
> 
> Danielle Paquet
> Adjointe administrative

Bonjour,

Merci de votre mail.  Le projet LilyPond n'est pas une entreprise, mais plutôt 
un organisme de bénévoles qui a pour but d'améliorer la gravure musicale par le 
biais du logiciel libre.

Il y a plusieurs utilisateurs francophones qui se trouvent partout dans le 
monde qui seraient ravis de discuter de LilyPond avec vous.  En revanche, nous 
n'avons pas l'habitude de diffuser nos numéros de téléphone sur cette liste.  
Pouvez-vous me contacter directement pour élaborer les détails de votre projet ?

Cordialement,
Mike SOLOMON
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Nouveau projet et personne ressource

[m...@apollinemike.com]

On Apr 7, 2011, at 6:32 PM, Valentin Villenave wrote:

> 2011/4/7 m...@apollinemike.com :
>> Il y a plusieurs utilisateurs francophones qui se trouvent partout dans le 
>> monde qui seraient ravis de discuter de LilyPond avec vous.  En revanche, 
>> nous n'avons pas l'habitude de diffuser nos numéros de téléphone sur cette 
>> liste.  Pouvez-vous me contacter directement pour élaborer les détails de 
>> votre projet ?
> 
> Hi Mike,
> 
> I'm available as well in case you need some backup; hopefully this is
> something interesting (and legit :-)
> Please do keep us in the loop!
> 
> Cheers,
> Valentin.

Will do...it does have scam written all over it, but if she wants to pay us 
lots of money, I'd be happy to take one for the team so that LilyPond can 
remain free.

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

Re: Nouveau projet et personne ressource

[m...@apollinemike.com]

On Apr 8, 2011, at 11:07 AM, Han-Wen Nienhuys wrote:

> On Fri, Apr 8, 2011 at 10:56 AM, Valentin Villenave
>  wrote:
> 
>> Well, their financials are notoriously opaque, so I wouldn't be
>> surprised if some money mysteriously gets lost in the process.
> 
> There is a hilarious video by a belgian satire program, where they
> take on SABAM, the belgian society for collecting performance rights.
> 
> article
> 
> http://translate.google.com/translate?js=n&prev=_t&hl=en&ie=UTF-8&layout=2&eotf=1&sl=auto&tl=en&u=http%3A%2F%2Fwww.gva.be%2Fnieuws%2Fmedia-en-cultuur%2Faid1011663%2Fbasta-sabam-maakt-facturen-voor-onbestaande-groepen.aspx&act=url
> 
> videos (dutch)
> http://www.een.be/programmas/basta/sabam-en-de-makro-artiesten
> 
> Apparently, they have inspectors that actually go to people's houses
> when there are personal parties.  They got back at them by organizing
> performances by "Kimberly Clark" (paper towel dispenser) and "Kenwood"
> (kitchen appliances).
> 
> Shortly thereafter, SABAM got sued.

The verdict's in!
So, the person who contacted us is the assistant to a big-wig in the French 
public service.  I just called her, who passed me along to him.

Basically, he has a personal project that he'd like to do through LilyPond 
involving the syrinx that he'd like to notate.  It has nothing to do with the 
Canadian government.  I told him about lilypond-user-fr, and I'll send his 
assistant the list address.

He also asked me to check & see if there are any people currently residing in 
Montreal that he could call / see for help.  I told him that we were a 
community of volunteers, but that I'd check w/ the French list to see if there 
was anybody in Montreal who'd be willing to give this guy a call and/or go see 
him.

He seems like a very nice gentleman who knows nothing about printed music, is 
an absolute beginner but fan of music, and who is so busy that his assistant 
coordinates everything for him (his job moves him around a lot).

I want an assistant...

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

Re: stemlength II

[m...@apollinemike.com]

On Apr 14, 2011, at 6:18 AM, James Lowe wrote:

> Hello,
> 
> )-Original Message-
> )From: bug-lilypond-bounces+james.lowe=datacore@gnu.org
> )[mailto:bug-lilypond-bounces+james.lowe=datacore@gnu.org] On
> )Behalf Of Phil Holmes
> )Sent: 14 April 2011 10:15
> )To: bug-lilypond@gnu.org
> )Subject: Re: stemlength II
> )
> )I've just downloaded and installed 13.59 and can confirm what James has
> )said.  Making the 3rd voice:
> )
> )   {
> )   \override Voice.Beam #'collision-voice-only = ##f
> )   s4 s8}
> )
> )Gets rid of the over-elongated beam.
> )
> )James,
> )
> )Are you aware of this being documented anywhere?
> )
> )
> 
> No, but I'm still not sure if this is a bug (either new or existing) unless I 
> missed something.
> 
> Regards
> 
> James 


You'd need:
\override Voice.Beam #'collision-voice-only = ##t

But to me this still seems like a bug - I'm not sure why the stem pulls down 
the beam whereas the NoteHead does not.

Try:

\new Staff {
 \time 6/8
 \key a \major
 \clef treble
 <<
   { 4 d'''16 b'' e'''4. }
   \\
   { d'4. e }
   \\

   \\
   { %\override Voice.Beam #'collision-voice-only = ##t
  \override Voice.Beam #'collision-interfaces = #'(beam-interface
   clef-interface
   inline-accidental-interface
   key-signature-interface
   note-head-interface
   ;stem-interface
   time-signature-interface)

s4 s8}
 >>
}

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

Re: stemlength II

[m...@apollinemike.com]

On Apr 14, 2011, at 11:08 PM, Han-Wen Nienhuys wrote:

> On Thu, Apr 14, 2011 at 9:00 AM, Phil Holmes  wrote:
 could argue that lengthening a stem to avoid a collision that isn't a
 collision is a bug, but I wouldn't do so without Mike's input.
>>> 
>>> Hm?  A bug with an explanation and a workaround is still a bug as far as
>>> I can see.  Mike's input may be needed in order to decide whether to
> 
>> OK.  http://code.google.com/p/lilypond/issues/detail?id=1613
> 
> I am testing a fix for this; it was an oversight of mine.
> 
> Graham,
> 
> this issue was exposed due to a (seemingly innocuous) one-line change
> by Mike.  Can I ask that you branch off the 2.14 branch so the release
> candidate does not get disturbed by other one-liners with unintended
> effects?  If you don't branch off a stable branch, 2.14 will never get
> finished.

I agree -  I think that if we branch off 2.14 after we fix the three remaining 
critical issues (all of which seem to have been recently introduced) and if 
everyone holds off on pushing new stuff for a bit (my MultiMeasureRest work, 
for example, won't make it into 2.14.0), we can still sit on it for a week or 
two before building it with GUB.  During this incubation phase, we'd only apply 
patches that fix critical or high priority problems.

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

Re: Beaming problem introduced with 2.13.60

[m...@apollinemike.com]

On Apr 17, 2011, at 1:45 AM, Nick Payne wrote:

> Example below demonstrates (a couple of bars taken from Bach's chaconne). 
> This problem did not exist in versions prior to 2.13.60:
> 
> %=
> \version "2.13.60"
> \language "english"
> 
> \relative c' {
>\time 3/4
>\key d \minor
>\stemUp
>d,16 bf''' bf gs gs f f d d b gs e |
>\stemDown cs a'' a fs fs ef ef c \stemUp c a fs( d) |
> }
> %=
> 
> The console log contains
> 
> Drawing systems...
> programming error: No viable beam quanting found.  Using unquanted y value.
> continuing, cross fingers
> /home/nick/lilypond/examples/test.ly:9:18: warning: weird stem size, check 
> for narrow beams
>\stemDown
>  cs a'' a fs fs ef ef c \stemUp c a fs( d) |
> programming error: No viable beam quanting found.  Using unquanted y value.
> continuing, cross fingers
> /home/nick/lilypond/examples/test.ly:9:39: warning: weird stem size, check 
> for narrow beams
>\stemDown cs a'' a fs fs ef ef
>   c \stemUp c a fs( d) |
> 
> And the output looks like
> 


This seems like one of the eventualities that precipitates from commit 
bf707a03756021f69e3f5d1a8246639a6a601099.  I don't have time to do a full 
git-bisect now, but this is the only commit to beam collision code that could 
have effected this behavior, and it is similar to other examples reported in 
Issue 1613.

Cheers,
MS


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

Re: beaming bug

[m...@apollinemike.com]

On Apr 18, 2011, at 4:13 AM, Federico Bruni wrote:

> I disabled emails from lilypond-bug so I hope this has not been reported
> already.
> The attached snippet worked fine with 2.13.58, it broke since 2.13.60 (I
> never tried 2.13.59).
> 
> Here's the error message in the console:
> 
> programming error: No viable beam quanting found.  Using unquanted y
> value.
> continuing, cross fingers
> beaming-bug.ly:20:30: warning: weird stem size, check for narrow beams
>   a4 r ais r | b8 dis e 
>  e, ~ e f fis r |
> Layout output to `beaming-bug.ps'...
> Converting to `./beaming-bug.pdf'...
> success: Compilation successfully completed
> 
> Thanks,
> Federico

The most recent master fixes this (commit 
0c50b37efbd1fd0171d09eac35c97c38ac807461 from Han-Wen).

Cheers,
MS


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

Re: Possible regression in 2.13 series? "no viable configuration" warning

[m...@apollinemike.com]

That said, the following code still produces the same message:

\version "2.13.59"

<<
 \new Staff = "md" \relative c' {
   r4 r8 s s2
   r4 r8 s s2
   r4 e, r2 |
 }
 \new Staff = "mg" \relative c'' {
   b8 f' c' \change Staff = "md" ~
   2 \change Staff = "mg" |
  \once \override Beam #'collision-interfaces = #'(;beam-interface
   ;clef-interface
   ;inline-accidental-interface
   ;key-signature-interface
   ;note-head-interface
   ;time-signature-interface
)
   bes8 fes' ces' \change Staff = "md" ~
   2 \change Staff = "mg" |
   R1
 }
>>

On Apr 20, 2011, at 9:50 AM, Han-Wen Nienhuys wrote:

> On Wed, Apr 20, 2011 at 4:56 AM, Valentin Villenave
>  wrote:
>>> The cross-staff beams look a bit odd (the first note has a really
>>> long stem).
>>> 
>>> I'm surprised that there's problems as far back as 2.13.7, since
>>> the main beaming work was quite recent.
>> 
>> Indeed. I suspect the vertical spacing (skyline and all) is at stake
>> here, since in 2.12 the staves are printed further apart (and the beam
>> slope is totally different).
> 
> The message about "viable" configurations comes from the beam code
> which now takes the flat symbol into account.
> 
> 
> -- 
> Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
> 
> ___
> bug-lilypond mailing list
> bug-lilypond@gnu.org
> http://lists.gnu.org/mailman/listinfo/bug-lilypond


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

Re: Doc build segfault

[m...@apollinemike.com]

On Apr 23, 2011, at 4:31 PM, Graham Percival wrote:

> On Sat, Apr 23, 2011 at 03:50:18PM -0400, m...@apollinemike.com wrote:
>> On Apr 23, 2011, at 1:32 PM, Graham Percival wrote:
>> 
>>> Confirmed.  :(
>>> If I can't fix it in the next hour, I'll add an issue.
>>> 
>> I just ran make doc on Mac OS X 10.6 and it worked just fine.
> 
> Oh joy, another intermittant error.
> (I'm assuming that you ran "make doc" from a completely fresh
> build dir?)

Yup.  It compiled the bach schenker snippet just fine when it went through the 
web builds.

Cheers,
MS


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

mergeDifferentlyHeaded inconsistency

[m...@apollinemike.com]

>From Damien Pallant:

\new Staff {
\key ees \major
\clef treble
\override Staff.NoteCollision #'merge-differently-headed = ##t
\override Staff.NoteCollision #'merge-differently-dotted = ##t

\relative c' {

<< { r8 g ( bes d-3 ) f4-5 -- ees-4 -- } \\ { s8 g,~ 2. } >>
<< { r8 aes ( bes ees-4 ) f4-5 -- ees-4 -- } \\ { s8 aes,~ 2. } >>
}
}

merge-differently-headed works on the first chord but not the second.

Is this a known issue?

Cheers,
MS


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

Re: mergeDifferentlyHeaded inconsistency

[m...@apollinemike.com]

On Apr 25, 2011, at 6:14 AM, David Kastrup wrote:

> "m...@apollinemike.com"  writes:
> 
>> From Damien Pallant:
>> 
>> \new Staff {
>> \key ees \major
>> \clef treble
>> \override Staff.NoteCollision #'merge-differently-headed = ##t
>> \override Staff.NoteCollision #'merge-differently-dotted = ##t
>> 
>> \relative c' {
>> 
>> << { r8 g ( bes d-3 ) f4-5 -- ees-4 -- } \\ { s8 g,~ 2. } >>
>> << { r8 aes ( bes ees-4 ) f4-5 -- ees-4 -- } \\ { s8 aes,~ 2. } >>
>> }
>> }
>> 
>> merge-differently-headed works on the first chord but not the second.
> 
> I have a hard time imagining what result you expect here.  The chords in
> the lower voice are stemmed with a single stem (one voice -> one stem).
> The aes-bes chord requires juggling the note heads to fit them on one
> stem, so that they are no longer vertically aligned.  How would you
> merge the resulting construct with the upper voice?
> 
> Do you have a scan or a handwritten version illustrating the desired
> result?

I think what the user wants are the two Bb merged the second time round.  So, 
keep the horizontal spacing of the lower voice and shift the upper voice such 
that the Bbs meet up.

Cheers,
MS


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

Re: emproving Documentation about chordGlissando [WAS:consecutive chordGlissando]

[m...@apollinemike.com]

> It appears to me right now that chordGlissando is a sufficiently rough hack
> that it should probably be removed from the distribution and just be present
> in the LSR.

+1.
I will have time this weekend to work on an implementation that uses a context 
property to control how glissandi are typeset for chords.

Cheers,
MS


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

Re: Drawing systems...ERROR: In procedure min: ERROR: Wrong type: lilyvartmpbh

[m...@apollinemike.com]

On Apr 26, 2011, at 8:02 AM, Nick Payne wrote:

> This code used to work for me about a year ago, but when I try to build it 
> using 2.13.60, I get the weird error shown in the console log output at the 
> bottom. Is this a bug or not? I'm running 2.13.60 on Ubuntu 10.04 amd64.
> 
> %===
> \version "2.13.60"
> 
> % e.g. \spanbox #-8 #'(-1 . -1)
> spanbox = #(define-music-function (parser location yval shorten) (number? 
> pair?) #{
>\once \override TextSpanner #'style = #'line
>\once \override TextSpanner #'bound-details #'left #'text = \markup { 
> \draw-line #'(0 . $yval) }
>\once \override TextSpanner #'bound-details #'right #'text = \markup { 
> \draw-line #'(0 . $yval) }
>\once \override TextSpanner #'bound-details #'left #'padding = #(car 
> $shorten)
>\once \override TextSpanner #'bound-details #'right #'padding = #(cdr 
> $shorten)
> #})
> 
> \relative c' {
>\spanbox #-8 #'(-1 . -1) c4\startTextSpan c c c\stopTextSpan
> }
> %===
> 
> Processing `/home/nick/lilypond/examples/box.ly'
> Parsing...
> Interpreting music...
> Preprocessing graphical objects...
> Finding the ideal number of pages...
> Fitting music on 1 page...
> Drawing systems...ERROR: In procedure min:
> ERROR: Wrong type: lilyvartmpbh


This should do the trick - the problem is that you need to quasiquote the list 
and then unquote the temp variable that lilypond uses to store yval.

spanbox = #(define-music-function (parser location yval shorten) (number? 
pair?) #{
   \once \override TextSpanner #'style = #'line
   \once \override TextSpanner #'bound-details #'left #'text = \markup { 
\draw-line #`(0 . ,$yval) }
   \once \override TextSpanner #'bound-details #'right #'text = \markup { 
\draw-line #`(0 . ,$yval) }
   \once \override TextSpanner #'bound-details #'left #'padding = #(car 
$shorten)
   \once \override TextSpanner #'bound-details #'right #'padding = #(cdr 
$shorten)
#})

\relative c' {
   \spanbox #-8 #'(-1 . -1) c4\startTextSpan c c c\stopTextSpan
}

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

Re: Bug in 64th-note sloped beams

[m...@apollinemike.com]

On Apr 27, 2011, at 11:31 AM, Phil Holmes wrote:

> "James Lowe"  wrote in message 
> news:ddfaf00dc0c80042bab7bba1b3838af9145f3...@mail-ftl2.datacoresoftware.com...
>> Fwding to email group as I was sent this privately:
>> 
>> )-Original Message-
>> )From: Bird [mailto:leader.b...@yahoo.com]
>> )Sent: 27 April 2011 10:00
>> )To: James Lowe
>> )Subject: RE: Bug in 64th-note sloped beams
>> )
>> )> Hello,
>> )
>> )> % Accidentals inside a sloped 64th-note beam % cause an error in
>> )> version 2.13.60.
>> )>
>> )> \version "2.13.60"
>> )> \relative c'' { c64[ des] }
>> )>
>> )> Can you define 'error'?
>> )>
>> )> James
>> )
>> 
>> Running on Mac OS X x86, this input generates the message
>> "programming error: No viable beam quanting found.  Using unquanted y
>> value." The output looks like
>> 
>> http://img845.imageshack.us/i/lilypond21360error.png/
>> 
>> I can get a similar error with 16th notes further apart:
>> 
>> \relative c'' { g16[ fis'] }
>> 
>> The same thing happens with autobeaming but it makes the example
>> longer. The problem is new since 2.13.53 and I haven't found anything
>> covering this single-staff, single- voice beaming problem in the bug
>> 
>> reports.
> 
> I am currently assuming that beaming problems are caused by 
> http://code.google.com/p/lilypond/issues/detail?id=1619
> 

This problem isn't in version 2.13.61.

Cheers,
MS



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

Re: Issue 1612 in lilypond: Change staff produces long stems

[m...@apollinemike.com]

On May 2, 2011, at 5:21 AM, lilyp...@googlecode.com wrote:

> 
> Comment #19 on issue 1612 by brownian.box: Change staff produces long stems
> http://code.google.com/p/lilypond/issues/detail?id=1612
> 
> I have missed something very probably, but: this issue is of type "Collision" 
> (not "Doc") still _and_ the initial snippet produces the very same picture 
> with 2.13.61 here. Sorry, what's wrong?
> 

I'm terrible at this whole backporting/branching thing, so I wouldn't know what 
label to apply, but this problem no longer exists in 2.15.0.  Graham - sorry in 
advance if this is not the right thing to report!

Cheers,
MS


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

Re: Beam avoidance of other voices and stem length for beamed notes

[m...@apollinemike.com]

On May 4, 2011, at 3:16 PM, Nick Payne wrote:

> Latest LP development version has inconsistency. See below.
> 
> \version "2.13.61"
> 
> \relative c'' {
>\time 3/4
>\key d \minor
> <<
>{ 8 r  r s }
>\\
>{ d, r cis r r4 }
>\\
>{ g'8. f16 g8. bes16 a8. g16 }
> >>
> }
> 
> Nick

Hey Nick,

The disparity in results comes (I think) from the fact that the flag of the 
stem in the left example ends after the beam begins on the X axis, and thus, 
the beam collision engraver moves the beam up to avoid the entire stem+flag.  
In the second example, on the other hand, the flag's rightmost X point falls to 
the left of the beam's leftmost X point.

Cheers,
MS


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

Re: Beam avoidance of other voices and stem length for beamed notes

[m...@apollinemike.com]

On May 5, 2011, at 2:12 AM, Nick Payne wrote:

> On 05/05/11 13:21, m...@apollinemike.com wrote:
>> On May 4, 2011, at 3:16 PM, Nick Payne wrote:
>> 
>>> Latest LP development version has inconsistency. See below.
>>> 
>>> \version "2.13.61"
>>> 
>>> \relative c'' {
>>>\time 3/4
>>>\key d \minor
>>> <<
>>>{8 r  r s }
>>>\\
>>>{ d, r cis r r4 }
>>>\\
>>>{ g'8. f16 g8. bes16 a8. g16 }
>>> }
>>> 
>> The disparity in results comes (I think) from the fact that the flag of the 
>> stem in the left example ends after the beam begins on the X axis, and thus, 
>> the beam collision engraver moves the beam up to avoid the entire stem+flag. 
>>  In the second example, on the other hand, the flag's rightmost X point 
>> falls to the left of the beam's leftmost X point.
> Yes, that seems to be why, as if I add \once \override NoteColumn 
> #'force-hshift = #1 at the beginning of voice 2, then both beams intersect 
> the rests above. However, if the collision avoidance mechanism does shift the 
> note at the beginning of voice 2 horizontally, why doesn't it shift the note 
> far enough for the stem/beam to avoid the flag on the note in voice 1, given 
> that it manages to do so successfully for the second beat in the bar. Or is 
> that difference due to the notes in the two voices being a third apart on the 
> first beat but only a second apart on the second beat.
> 

Hey NIck,
Not to get too technical (but I'm gonna get too technical), the mechanism that 
decides the X placements of grobs (and thus the bleed-over of stems into a 
beam's X extent) does not have anything to do with LilyPond's beam collision 
algorithms.  You'd want to report two separate bugs: one about the fact that 
the horizontal shift of the stem is inconsistent, and one that the 
beam-collision-engraver kicks in for even minuscule overlaps in grobs' 
X-extents.

In this instance, if you put \once \override Beam #'collision-voice-only = ##t 
before the first beam, you're golden.  Meanwhile, I'm working on something for 
the next devel version that gets beams to avoid rests.

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

Re: Stem length on beamed notes incorrect in 2.13.61

[m...@apollinemike.com]

On May 7, 2011, at 1:49 AM, Nick Payne wrote:

> A bar excerpted from the Mertz guitar transcription of Ständchen. When I last 
> worked on this score about ten months ago, using 2.13.27, I didn't have the 
> problem with the beam on the notes in the middle voice being placed below the 
> stem of the note in the lower voice - the beam was placed along the bottom 
> line of the stave - see 2.13.27.png, a screen shot from the PDF I made at the 
> time:
> 
> \version "2.13.61"
> 
> \relative c'' {
>\time 3/4
> <<
>{ cis'2. }
>\\
>{ a,,2. }
>\\
>{ \stemDown a''8 e  e  e }
> >>
> }
> 
> Nick

Hang tight - the current git has this problem fixed, and it'll be fixed in the 
next version of LilyPond available on the website.

Cheers,
MS


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

Re: Issue 1660 in lilypond: harmonicOn doesn't work in TabStaff

[m...@apollinemike.com]

On May 23, 2011, at 4:18 PM, lilyp...@googlecode.com wrote:

> 
> Comment #2 on issue 1660 by brownian.box: harmonicOn doesn't work in TabStaff
> http://code.google.com/p/lilypond/issues/detail?id=1660
> 
> Should this issue be tagged as Invalid then?

I'd say so.  The docstring for harmonicsOn doesn't claim that it does anything 
other than change the notehead style.
I'd send whoever reported this a note w/ the workaround and perhaps post the 
workaround on the LSR if it is useful.

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

Re: Cross-staff beaming

[m...@apollinemike.com]

On May 29, 2011, at 3:00 PM, Carl Sorensen wrote:

> On 5/29/11 5:42 AM, "Hilary Snaden"  wrote:
> 
>> Phil Holmes wrote:
>>> "Hilary Snaden"  wrote in message
>>> news:4de210b3.80...@newearth.demon.co.uk...
 Manual beamings of cross-staff note groups are mangled, but
 inconsistently. The beaming in this extract works for the first 6 bars,
 then fails on beats 1 and 3 on the following bars. (Beamings on beats 2
 and 4 are as they were.) Versions 2.12.2, 2.13.61 and 2.13.62 behave in
 the same way.
>>> 
>>> Could you prepare a tiny example that demonstrates this, please? (See
>>> http://lilypond.org/website/bug-reports.html)
>> 
>> The original example showed that the beam-mangling didn't start (in the
>> real-world case) for several bars and that the mangling occurred only on
>> the 1st and 3rd beats of the original 4/4. (Bugs within bugs?)
> 
> The beam-mangling is unrelated to the bar number (with the possible
> exception of bar 1).  It also can easily be made to occur on beats 2 and 4.
> See the code below for an example.
> 
> It most likely is related to a particular set of pitches compared with the
> neighboring pitches; Mike Solomon would have a better idea of what is broken
> here.  Hilary, if you can get the example even smaller, it would be helpful.
> 
> HTH,
> 
> Carl

Hey Hilary,

The problematic beams are positioned with respect to the staff on which they 
start, not the staff on which they end.  You'll need to set the values much 
higher to reach the upper staff.

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

Re: Odd-looking tie on a chord

[m...@apollinemike.com]

On Jul 4, 2011, at 11:45 AM, Dmytro O. Redchuk wrote:

> On Mon 04 Jul 2011, 15:39 James Harkins wrote:
>> \version "2.14.1"
>> 
>> \include "english.ly"
>> 
>> \score {
>> \new Staff {
>>   \key d \major
>>   \numericTimeSignature
>>   \time 4/4
>>   r4
>>   \times 4/5 { 16\< > d'' b''>~ }
>>   16 8.
>> 
>>   %% Here: the tie on the D's looks funny
>>   %% Too tall? Left-hand endpoint is not aligned with the B tie?
>>   ~ 
>> 
>>   8 [ ->\mf ]
>> }
>> }
>> 
>> It looks even funnier at lower resolution, somewhat better when viewed up 
>> close.
>> 
>> I'm aware of \override TieColumn #'tie-configuration but would just as soon 
>> avoid it if possible.
> I found this is an instance of known issue, 1126:
> http://code.google.com/p/lilypond/issues/detail?id=1126
> 
> I have added your example there thougth.
> 
> Thank you!

Hey James,

Ties, like beams and stems, vary widely in terms of aesthetic preference, and 
LilyPond offers a few properties to help express these preferences through 
various minima, maxima, and penalties.

Try setting:
\override Tie #'details #'outer-tie-length-symmetry-penalty-factor = #0

before your chords - I think this may be what you're after.

Here is a list of all the factors and their default settings :

   (ratio . 0.333)
   (center-staff-line-clearance . 0.6)
   (tip-staff-line-clearance . 0.45)
   (note-head-gap . 0.2)
   (stem-gap . 0.35)
   (height-limit . 1.0)
   (horizontal-distance-penalty-factor . 10)
   (same-dir-as-stem-penalty . 8)
   (min-length-penalty-factor . 26)
   (tie-tie-collision-distance . 0.45)
   (tie-tie-collision-penalty . 25.0)
   (intra-space-threshold . 1.25)
   (outer-tie-vertical-distance-symmetry-penalty-factor . 10)
   (outer-tie-length-symmetry-penalty-factor . 10)
   (vertical-distance-penalty-factor . 7)
   (outer-tie-vertical-gap . 0.25)
   (multi-tie-region-size . 3)
   (single-tie-region-size . 4)
   (between-length-limit . 1.0)

We always strive to have the best out-of-the-box result possible, so if you 
feel after experimenting with these settings that you arrive at a result that 
is more akin to what you see in musical rep, send us a scan of the rep and the 
parameters you used to get there and we can start considering how to encode 
this (these) exception(s) in LilyPond's default output.

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

Re: Ties colliding in single-staff polyphony

[m...@apollinemike.com]

On Jul 18, 2011, at 10:14 AM, Bertrand Bordage wrote:

> Hi all,
> 
> A bug I noticed years ago :
> 
> <<
>  { a'4~ a' a'~ a' ~  } \\
>  { c' c' c' c' } \\
>  { f'~ f' \shiftOff f'~ f' } \\
>>> 
> 
> Ties should take noteheads from other contexts into account.
> 
> Regards,
> Bertrand

I'm loath to write another collision engraver, but one solution to this problem 
would be to create a tie collision engraver that works just like the beam 
collision engraver.  Harvest all grobs from other voices that could potentially 
intersect in this engraver and throw them into a collision-grobs Grob_array.  
Then, in Tie_formatting_problem::score_ties, call a new function 
score_ties_collision that itself calls score_tie_collision.  In 
score_tie_collision, add a demerit for ties that collide with offending grobs.

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

Completion_rest_engraver fails with fractional rests

[m...@apollinemike.com]

\new Voice
\with { \remove "Rest_engraver" \consists "Completion_rest_engraver"  }
{ r1*6/4 r2 }

This gets me the attached output.



PastedGraphic-1.pdf
Description: Adobe PDF document


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

Re: Completion_rest_engraver fails with fractional rests

[m...@apollinemike.com]

On Jul 21, 2011, at 1:37 PM, Dmytro O. Redchuk wrote:

> On Thu 21 Jul 2011, 13:20 m...@apollinemike.com wrote:
>> \new Voice
>> \with { \remove "Rest_engraver" \consists "Completion_rest_engraver"  }
>> { r1*6/4 r2 }
>> 
>> This gets me the attached output.
> Please, what's the expected output?
> 



PastedGraphic-2.pdf
Description: Adobe PDF document


Cheers,
MS

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

Re: Issue 1773 in lilypond: Add Footnote_engraver to Staff context

[m...@apollinemike.com]

On Jul 22, 2011, at 9:57 AM, lilyp...@googlecode.com wrote:

> Status: Accepted
> Owner: 
> Labels: Type-Enhancement Priority-Low
> 
> New issue 1773 by pkx1...@gmail.com: Add Footnote_engraver to Staff context
> http://code.google.com/p/lilypond/issues/detail?id=1773
> 
> This came out of the third draft of a patch I did in
> 
> http://codereview.appspot.com/4751045/
> 
> For some grobs, the \footnoteGrob command needs the Staff context to be 
> explicitly set. This is a bit awkward frankly and I think, more often than 
> not, when using footnotes staff context are going to be needed for this 
> engraver..
> 
> Currently this is only (AFAICT) in the Voice context, I asked generally on 
> the thread above if it could be added into the Staff context *as well* and 
> Neil Puttock said:
> 
> --snip--
> 
> There are several engravers which exist in multiple contexts (e.g.,
> Parenthesis_engraver).  I haven't checked, but it seems to me that
> adding the Footnote_engraver to the Staff context should be harmless
> for Voice-level footnotes.
> 
> Cheers,
> Neil
> 

The Footnote_engraver has an acknowledge_grob.  Does this take more execution 
time than, say, acknowledge_rest?  If so, how much?  I think that adding this 
engraver to the Staff context as a default should only be done if doesn't slow 
LilyPond down appreciably: otherwise, users can just add it themselves with a 
\with { } block.

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

Re: Issue 1772 in lilypond: Completion_rest_engraver fails with fractional rests

[m...@apollinemike.com]

On Jul 22, 2011, at 12:24 PM, lilyp...@googlecode.com wrote:

> 
> Comment #1 on issue 1772 by lilyli...@googlemail.com: 
> Completion_rest_engraver fails with fractional rests
> http://code.google.com/p/lilypond/issues/detail?id=1772
> 
> As Neil Puttock reported Completion_heads_engraver behaves the same:
> http://lists.gnu.org/archive/html/bug-lilypond/2011-07/msg00606.html
> 
> I adapted his example a little bit:
> % ---8<--
> \version "2.15.5"
> <<
> % bad
> \new Voice
> \with { \remove "Note_heads_engraver" \consists "Completion_heads_engraver"  }
> { c''1*6/4 c''2 }
> 
> % good
> \new Voice
> \with { \remove "Note_heads_engraver" \consists "Completion_heads_engraver"  }
> { c''1. c''2 }
> 
> % ---8<--
> 
> Here one can see that both voices are correctly aligned horizontally, 
> although the durations of the "bad" example don't sum up correctly (-> the 
> value isn't only split up in wrong parts but completely wrong)
> While this may be totally clear to everybody I thought it should be 
> explicitely stated here in the tracker.
> 
> HTH
> Urs
> 

Just a thought: it may be easier to fix this by scrapping the completion 
engravers entirely and having music functions that operate on music streams.  
For example:

a4. a1 a2 a8

in the completion heads engraver becomes

a4. a2 ~ a8 ~ a4. a2 a8

This would be a lot nicer as

a4. a8 ~ a2 ~ a4. a2 a8

and even nicer as

a4. a8 ~ a2 ~ a4. a8 a2 (in addition to completing heads, rearranging based on 
beat conventions à la autobeam engraver).

A music function can glance ahead in time, see what the appropriate way to 
split would be, and then execute it.

The autobeam engraver can be rewritten the same way.

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

Re: Issue 36 in lilypond: collision cresc and kneed beams

[m...@apollinemike.com]

On Jul 27, 2011, at 12:22 PM, lilyp...@googlecode.com wrote:

> Updates:
>   Owner: ---
>   Labels: -Priority-High -Patch-needs_work Priority-Medium Patch-abandoned
> 
> Comment #6 on issue 36 by pkx1...@gmail.com: collision cresc and kneed beams
> http://code.google.com/p/lilypond/issues/detail?id=36
> 
> From Mike:
> 
> --snip--
> 
> On 2011/07/25 22:22:05, graham_percival-music.ca wrote:
>> On Mon, Jul 25, 2011 at 09:17:53AM +0200, mailto:m...@apollinemike.com
>> wrote:
>>> 
>>> We may want to just fix issue 36 via something in the docs-
>> ...
>>> but as there is no clear way to
>>> deal with these collisions, perhaps a section in the
>>> documentation "Dealing with collisions" that says something to
>>> the effect of "LilyPond does its best to avoid collisions
>>> between objects.  However, often there is more than one solution
>>> available to collision avoidance - white out, moving, rotating,
>>> etc..
> 
>> sounds good to me.  That's in Learning 4.5 Collisions of objects,
>> right?
> 
>> Cheers,
>> - Graham
> 
> Yup.
> I'm gonna close this Rietveld issue.  Could you downgrade the priority of the
> issue on the tracker to either medium or low (depending on what you think 
> would
> be appropriate) and add the right tags that show this needs to be a
> documentation suggestion (not a code base fix).
> 
> Cheers,
> MS
> 
> --snip--
> 
> Are we saying this is not fixable? or just that it's a bit tough and so we 
> need to think again?
> 

Because there are numerous ways to fix this problem, and because no one way is 
objectively "better," and because all ways are doable via overrides and short 
scheme engravers, it'd be better to have a section in the docs that presents 
several ways to avoid the same collision rather than going down the slippery 
slope of instituting all these ways in LilyPond.

Cheers,
MS


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

Re: Lilypond crashes when compiling snippet

[m...@apollinemike.com]

On Aug 2, 2011, at 11:15 PM, David Kastrup wrote:

> James Lowe  writes:
> 
>> From: lilypond-user-bounces+james.lowe=datacore@gnu.org
>> [lilypond-user-bounces+james.lowe=datacore@gnu.org] on behalf of
>> Tim Reeves [tim.ree...@tokamerica.com]
>> Sent: 02 August 2011 19:56
>> To: lilypond-u...@gnu.org
>> Subject: Lilypond crashes when compiling snippet
> 
>>> I tried to compile the "Creating music with Scheme (music box)"
>>> snippet ( http://lsr.dsi.unimi.it/LSR/Item?id=346 ) and when I do,
>>> Lilypond crashes
> 
> [...]
> 
>> 
>> Now all that said I have also run this on latest version from the
>> current tree (2.15.9) from tonight and I get a seg fault while
>> compiling.
> 
> Looks like the autobeamer.  Mike?
> 

As I have never worked on the auto-beam engraver, I think the fix would go 
faster if someone more familiar with it took it on.  I would be happy to, 
though, if no one has time.

I will say, though, that I am putting the finishing touches on the first draft 
of a set of .ly files called "lazy-lily" that I'll post on github soon.  It is 
a suite of music functions that makes certain pre-engraver decisions.  Right 
now, it has:

\lazyMultiMeasureRests
  turns all full-measure rests into multi-measure rests
\lazyUnslurRests
  slurs that cross over a rest are cut: ie a ( b c r r d e r f r ) becomes a ( 
b c ) r r d ( e ) r f r

I'm currently working on \lazyUntie, which turns anything like a32-|  ~ a32 
into a32-| r32.  Afterwards, I'll be working on \lazyProlation, which is like 
the completion notes/heads engraver on steroids (automatically groups and/or 
breaks notes and rests depending on their place in the measure and/or tuplet).

The auto-beam-engraver can and should be implemented more along these lines 
(\lazyAutoBeaming, which inserts beam events into the stream).

Of course, the problem at hand could have nothing to do with anything I say 
above, but I figured I'd mention it, as it is related to something that's been 
in my mind.

In general, it'd be great if all grobs were acknowledgeable (made using 
make_item or make_spanner) during the timestep when their causing event/grob is 
issued, and conditioning the event stream with lazy functions is a way to make 
this happen.

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

Re: Issue 1881 in lilypond: Multiple cyclic dependency errors for Beam/Stem

[m...@apollinemike.com]

On Sep 11, 2011, at 11:30 PM, lilyp...@googlecode.com wrote:

> Status: Accepted
> Owner: 
> Labels: Type-Critical
> 
> New issue 1881 by n.putt...@gmail.com: Multiple cyclic dependency errors for 
> Beam/Stem
> http://code.google.com/p/lilypond/issues/detail?id=1881
> 
> Following commit 6465274e66a851cccd4cd32a521abc853f3e79dd, `Restores stem 
> length and stem-begin-position.', even the simplest snippets with beaming 
> spit out multiple cyclic dependency errors:
> 
> \version "2.15.12"
> 
> \relative c' {
> c8 d e f
> }
> 
> 
> /tmp/tmpcPppzK/document.ly:2:2: programming error: cyclic dependency: 
> calculation-in-progress encountered for #'Y-extent (Stem)
> 
> c8 d e f
> /tmp/tmpcPppzK/document.ly:2:2: continuing, cross fingers
> 
> 
> c8 d e f
> /tmp/tmpcPppzK/document.ly:2:2: programming error: cyclic dependency: 
> calculation-in-progress encountered for #'quantized-positions (Beam)
> 
> c8 d e f
> /tmp/tmpcPppzK/document.ly:2:2: continuing, cross fingers
> 
> 
> c8 d e f
> /tmp/tmpcPppzK/document.ly:2:2: programming error: cyclic dependency: 
> calculation-in-progress encountered for #'quantized-positions (Beam)
> 
> c8 d e f
> /tmp/tmpcPppzK/document.ly:2:2: continuing, cross fingers
> 
> 
> c8 d e f
> /tmp/tmpcPppzK/document.ly:2:2: programming error: cyclic dependency: 
> calculation-in-progress encountered for #'quantized-positions (Beam)
> 
> c8 d e f
> /tmp/tmpcPppzK/document.ly:2:2: continuing, cross fingers
> 
> 
> c8 d e f
> 
> This is a serious problem for regression testing, since it obscures genuine 
> changes.
> 

Hey all,

I'm well on my way to getting a fix worked out for this.  I think that the 
problem only comes from lines that used the convention:

(void) me->get_property ("foo")

to trigger calculations if they hadn't happened yet.  The values were actually 
never used.

It may be useful to come up with a sort of "void_get_property" function that 
triggers a callback without returning a property.  It, in turn, would not throw 
an error for cyclic dependencies.  Thoughts?

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

Re: Issue 1008 in lilypond: Some warning/error messages are not prefixed with 'warning:'/'error:'

[m...@apollinemike.com]

On Sep 18, 2011, at 2:08 AM, lilyp...@googlecode.com wrote:

> Updates:
>   Status: Fixed
>   Owner: reinhold...@gmail.com
>   Labels: fixed_2_15_12
> 
> Comment #2 on issue 1008 by reinhold...@gmail.com: Some warning/error 
> messages are not prefixed with 'warning:'/'error:'
> http://code.google.com/p/lilypond/issues/detail?id=1008
> 
> When I implemented the loglevels and centralized all warning-handling in 
> warn.cc, I fixed most of those wrong warnings (the two mentioned here, for 
> example). Today, I checked again and fixed three still missing ones. Now, I 
> don't think there are any missing warnings any more.
> 

Just a heads up - in current master, my compilations now look like:

Processing `span-bar.ly'
Parsing...
Interpreting music... 
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Layout output to `span-bar.ps'...Converting to `./span-bar.pdf'...
Success: compilation successfully completed

(the Layout and Converting are now on the same line)

Is this a result of b551257a9d5d4bd1b57d32ac0cea4684260dfd83 ?

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

Re: Issue 1905 in lilypond: Add note to CG 9.3 'Compiling reg tests' to add --disable-optimising when using autogen.sh or configure

[m...@apollinemike.com]

On Sep 19, 2011, at 2:01 PM, lilyp...@googlecode.com wrote:

> 
> Comment #2 on issue 1905 by n.putt...@gmail.com: Add note to CG 9.3 
> 'Compiling reg tests' to add --disable-optimising when using autogen.sh or 
> configure
> http://code.google.com/p/lilypond/issues/detail?id=1905
> 
> Won't your patch break GUB builds?
> 

Indeed it will...
Perhaps create two new make options:

make unsafe-test-baseline

and

make unsafe-check

These would not have the fail-if-unoptimized check.
Then, one would need to make a change to GUB such that, when it runs the 
regtests, it uses the unsafe commands.

Does this seem like a good solution?

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

Re: Issue 1905 in lilypond: Add note to CG 9.3 'Compiling reg tests' to add --disable-optimising when using autogen.sh or configure

[m...@apollinemike.com]

On Sep 19, 2011, at 4:04 PM, Neil Puttock wrote:

> On 19 September 2011 13:05, m...@apollinemike.com  
> wrote:
> 
>> Perhaps create two new make options:
>> 
>> make unsafe-test-baseline
>> 
>> and
>> 
>> make unsafe-check
>> 
>> These would not have the fail-if-unoptimized check.
>> Then, one would need to make a change to GUB such that, when it runs the 
>> regtests, it uses the unsafe commands.
>> 
>> Does this seem like a good solution?
> 
> I'm probably not the person to ask.  I'd never use the unsafe-* versions.
> 
> Cheers,
> Neil
> 

Graham - how difficult would it be to change LilyPond's build in GUB such that 
it used different commands to run its regtests?
Also, it may be worth it to consider scrapping optimized binary altogether - 
it'd be good to test how much overhead the unoptimized version introduces with 
respect to the optimized version.

Cheers,
MS


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

Re: Issue 1905 in lilypond: Add note to CG 9.3 'Compiling reg tests' to add --disable-optimising when using autogen.sh or configure

[m...@apollinemike.com]

On Sep 19, 2011, at 5:22 PM, Neil Puttock wrote:

> On 19 September 2011 16:16, David Kastrup  wrote:
> 
>> The debug symbols should not affect code speed, and they are present in
>> the unoptimized build, anyway, unless you are talking about something
>> completely different from what I think you do.  I find it disturbing,
>> however, that our default build uses NDEBUG to disable assertions.
>> Under normal circumstances, assertions have negligible speed impact.  It
>> makes little sense to restrict their use explicitly to non-optimized
>> builds.  In particular since it makes it quite unlikely that one can
>> catch Heisenbugs with assertions: they often go away with significant
>> code changes, and switching optimization off most certainly _is_ a
>> significant change.
> 
> I didn't say that the debug symbols affect code speed.
> 
> The unoptimized binary is much slower, at least on my system.
> 
> Mike is suggesting we stop shipping optimized binaries.
> 

I've put up a new patch that checks for cyclic dependencies in the regtests - 
does this seem like a better approach?

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

Re: Issue 1912 in lilypond: Horizontal spacing depends on stem 'direction

[m...@apollinemike.com]

On Sep 22, 2011, at 9:25 AM, lilyp...@googlecode.com wrote:

> Status: Accepted
> Owner: 
> Labels: Type-Ugly
> 
> New issue 1912 by brownian.box: Horizontal spacing depends on stem 'direction
> http://code.google.com/p/lilypond/issues/detail?id=1912
> 
> Reported by Trevor Daniels,
> http://lists.gnu.org/archive/html/bug-lilypond/2011-09/msg00233.html :
> 
> %--8<-
> It seems the horizontal spacing is slightly dependent on the stem direction. 
> This can cause a score to mysteriously spread over an extra system when a 
> single note with stem down is changed to one with stem up, if the original 
> system exactly fitted the line width.
> 
> The following example demonstrates this by showing the slight difference in 
> the two line lengths.
> 
> \version "2.15.12"
> \score {
> \relative c'' {
>   \repeat unfold 6 { a4 a a a }
> }
> }
> 
> \score {
> \relative c'' {
>   \repeat unfold 6 { c4 c c c }
> }
> }
> %--8<-
> 

Is this a regression?  If so, do you know what the last version was that made 
the two lines equal?

Cheers,
MS


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

Re: Issue 1915 in lilypond: slurs don't avoid other voices

[m...@apollinemike.com]

On Sep 22, 2011, at 10:31 AM, lilyp...@googlecode.com wrote:

> Status: Accepted
> Owner: 
> Labels: Needs-evidence Type-Ugly
> 
> New issue 1915 by brownian.box: slurs don't avoid other voices
> http://code.google.com/p/lilypond/issues/detail?id=1915
> 
> Reported by -Eluze,
> http://lists.gnu.org/archive/html/bug-lilypond/2011-08/msg00789.html :
> 
> %--8<-
> slurs don't avoid other voices:
> 
> \version "2.15.12"
> \context Staff <<
> \new Voice { a'8( b') a'8( b') }
> \new Voice { \voiceTwo e'4 s}
> 
> %--8<-
> 
> 

I'm not sure what the desired output would be - the slur would be too snug if 
it were moved up.  Do you think it should be put above the beam?

Cheers,
MS


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

Re: Issue 1926 in lilypond: 2.15.12 processing speed problems

[m...@apollinemike.com]

On Sep 24, 2011, at 12:43 PM, lilyp...@googlecode.com wrote:

> Status: Accepted
> Owner: 
> Labels: Type-Critical Regression
> 
> New issue 1926 by philehol...@googlemail.com: 2.15.12 processing speed 
> problems
> http://code.google.com/p/lilypond/issues/detail?id=1926
> 
> On my system, 2.15.12 is _much_  slower than 2.15.10 for files of a fair 
> complexity.  The Mozart Horn regtest went from 14 seconds to 27 seconds.  A 
> 70 bar, 7 page piece by Parry I'm currently setting went from 23.3 seconds to 
> 49.3.  I've pasted below the worst increases in the regtests.  This will 
> probably be difficult to view, but may help debugging:
> 
> File  Old.TimeNew.Time
> midi-scales.ly3.136.89
> compound-time-signatures.ly   3.056.81
> paper-margins-line-width.ly   2.595.94
> page-turn-page-breaking-repeats.ly2.786.42
> paper-twosided-bcorr.ly   10.02   23.27
> page-turn-page-breaking-auto-first-page.ly3.027.16
> paper-default-margins-def.ly  3.338.14
> beam-auto.ly  5.6913.91
> paper-twosided.ly 9.8324.14

Here, on current master from my VirtualBox, paper-twosided.ly takes 8ish 
seconds with current master and 7ish seconds rewound to 
079a12b77ac95640595a6433761e7b46d5552af9 (the commit before the flag grobs).

paper-twosided.ly seems like the best test to tackle at first, as there are no 
flags & no beams, so the only thing from the stem/beam/flag work that could be 
slowing it down is the stem pure-height and/or height function (and their 
consorts of helper functions).  However, as I can't reproduce the large 
difference in compile times, it is difficult for me to start separating signal 
from noise in terms of what is actually taking longer.

I just read over the code in stem.cc for beamless stems and I don't see 
anything that could result in functions being over-called.  There are a few 
extra lookups in separate functions (for example, the beam object is looked-up 
more times), but I doubt this'd slow down the code a lot (I could be wrong - 
lemme know).

Are there any good profiling tools that'd help with this sorta thing?

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

Re: Issue 34 in lilypond: Grace synchronization

[m...@apollinemike.com]

On Jul 21, 2011, at 11:10 AM, lilyp...@googlecode.com wrote:

> 
> Comment #17 on issue 34 by reinhold...@gmail.com: Grace synchronization
> http://code.google.com/p/lilypond/issues/detail?id=34
> 
> Comment by Keith O'Hara on bug-lilypond:
> 
>> However, in my eyes we need to distinguish the events at each moment.
>> Basically, we have three different types of events:
> 
>> 1) events that should be processed at the very beginning of each moment
>> (before grace notes are handled)
>> 2) grace notes (i.e. notes that appear before the real content of the
>> moment), possibly also including some \set command, which should not mess
>> up things
>> 3) normal notes
> 
>> In other words, we need to find a way to process key/clef/barlines (in
>> particular all SetEvents) etc. before all grace notes. One approach might
>> be to assign a moment like 0G-inf to them, so they will be processed before
>> all grace notes.
> 
> I think that is a promising approach.  I looked through the code thinking 
> about
> this issue two days ago, and began to look for a way to default-initialize the
> grace_part_ of a Moment to something that would sort before any defined value
> of grace_part_.  I do not know enough Scheme to know if Rational grace_part_ =
> -1 / 0 is guaranteed to work as -inf.
> 

I'm not sure if I completely get how you want to represent this value in 
Scheme, but typing -1/0 into the command line in guile will get you a 
numerical-overflow error.

Cheers,
MS


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

Re: Issue 1921 in lilypond: Creates convert-ly rules for flag syntax changes

[m...@apollinemike.com]

On Sep 29, 2011, at 5:33 AM, lilyp...@googlecode.com wrote:

> Updates:
>   Labels: -Patch-countdown Patch-push
> 
> Comment #3 on issue 1921 by colinpkc...@gmail.com: Creates convert-ly rules 
> for flag syntax changes
> http://code.google.com/p/lilypond/issues/detail?id=1921
> 
> Counted down to 20110928
> 

Pushed as 9e781a447d4ea0dc072403b4c7f0b176f2edb2e2.

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

Re: Issue 1846 in lilypond: Improves horizontal spacing of axis groups that SpanBar grobs traverse

[m...@apollinemike.com]

On Sep 30, 2011, at 8:24 AM, lilyp...@googlecode.com wrote:

> Updates:
>   Status: Fixed
> 
> Comment #12 on issue 1846 by mts...@gmail.com: Improves horizontal spacing of 
> axis groups that SpanBar grobs traverse
> http://code.google.com/p/lilypond/issues/detail?id=1846
> 
> Fixed with 20670d51f8d97fd390210dd239b3b2427f071e7c.

Hey all,

I just reverted 20670d51f8d97fd390210dd239b3b2427f071e7c.  The reason that the 
span bars seemed off in the PDFs is because it was double printing the span bar 
lines.  Psychologically, I think it took my pushing the patch for this to dawn 
on me.

I will put the patch back on patch new with a new version after I figure out 
how to get this right.

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

Re: Add 6x9 Paper Size

[m...@apollinemike.com]

On Sep 30, 2011, at 7:43 PM, Peekay Ex wrote:

> hello
> 
> On Fri, Sep 30, 2011 at 6:39 PM, Jay Anderson  wrote:
>> 6 x 9 in. isn't currently available. I haven't found a standard name
>> for this size. Lulu calls it 'US Trade',
>> http://en.wikipedia.org/wiki/Book_size calls it 'octavo'. In any case
>> it seems to be a fairly common size that would be useful to add (and
>> custom sizes are clunky to add and maintain - is there a better way
>> besides modifying paper.scm?). My recommendation to add to paper.scm:
>> 
>> ("6x9" . (cons (* 6 in) (* 9 in)))
>> 
>> Thanks.
>> 
>> -Jay
> 
> Thanks. Added as
> 
> http://code.google.com/p/lilypond/issues/detail?id=1949
> 
> -- 
> --
> James


#(set! paper-alist (cons '("6x9" cons (* 6 in) (* 9 in)) paper-alist))
#(set-default-paper-size "6x9")

Is a workaround that you can use without modifying paper.scm.  But, of course, 
there's nothing wrong with modifying paper.scm!

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

Re: Issue 1926 in lilypond: 2.15.12 processing speed problems

[m...@apollinemike.com]

On Oct 1, 2011, at 11:47 AM, lilyp...@googlecode.com wrote:

> Updates:
>   Status: Accepted
>   Labels: -fixed_2_15_13
> 
> Comment #4 on issue 1926 by philehol...@googlemail.com: 2.15.12 processing 
> speed problems
> http://code.google.com/p/lilypond/issues/detail?id=1926
> 
> No.  On my Windows Vista box, for a fairly complex piece of music (Finale Act 
> I of The Gondoliers - about 500 bars, 30-odd pages), I get:
> 
> 2.12.3 - 545 seconds
> 2.15.9 - 205 sec
> 2.15.10 - 210 sec
> 2.15.12 - 335 sec (+60%)
> 2.15.13 - 341 sec
> 
> So we see that for complex music, the problem remains.  My experience of 
> running the regtests was that for simple music, 2.15.12 was OK to better; for 
> longer music much worse.  I'd suggest using the Mozart Horn regtest as a test 
> case/comparator that somewhat fulfills this requirement.

Confirmed.  I finally noticed the problem when I compiled a 30ish page new work 
on current master.

Phil - could you send me the source files?  I have a 2h train ride Monday 
evening that I can use to crunch Gilbert and Sullivan through various 
incarnations of 2.15 to find where the hike in compiling time crept in.

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

Re: Issue 1846 in lilypond: Improves horizontal spacing of axis groups that SpanBar grobs traverse

[m...@apollinemike.com]

On Sep 30, 2011, at 8:50 AM, m...@apollinemike.com wrote:

> On Sep 30, 2011, at 8:24 AM, lilyp...@googlecode.com wrote:
> 
>> Updates:
>>  Status: Fixed
>> 
>> Comment #12 on issue 1846 by mts...@gmail.com: Improves horizontal spacing 
>> of axis groups that SpanBar grobs traverse
>> http://code.google.com/p/lilypond/issues/detail?id=1846
>> 
>> Fixed with 20670d51f8d97fd390210dd239b3b2427f071e7c.
> 
> Hey all,
> 
> I just reverted 20670d51f8d97fd390210dd239b3b2427f071e7c.  The reason that 
> the span bars seemed off in the PDFs is because it was double printing the 
> span bar lines.  Psychologically, I think it took my pushing the patch for 
> this to dawn on me.
> 
> I will put the patch back on patch new with a new version after I figure out 
> how to get this right.
> 
> Cheers,
> MS
> 

OK, now pushed fo-realz after a clean make check and an elimination of the 
problem (I had written the same line twice in the code, so there were two 
barlines printed for every SpanBar...).

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

Re: Issue 1950 in lilypond: \mark after \stopStaff forces extension of staff symbol

[m...@apollinemike.com]

On Oct 2, 2011, at 7:27 PM, lilyp...@googlecode.com wrote:

> Status: Accepted
> Owner: 
> Labels: Type-Ugly
> 
> New issue 1950 by brownian.box: \mark after \stopStaff forces extension of 
> staff symbol
> http://code.google.com/p/lilypond/issues/detail?id=1950
> 
> \relative c'' {
>  c1
>  \stopStaff
>  s1
>  \startStaff
>  c1
>  \stopStaff
>  \mark \default
>  s1
> }
> 
> Quite similar to Issue 1506.
> 

This is the same problem as 1506.

I just sent off a piece where I used Neil's fix to this problem (posted on the 
1506 page) and it worked beautifully.  Neil is busy these days with various and 
sundry, but if it is OK to adopt a patch so that it can get into current master 
soon, I don't mind throwing it up on Rietveld and shepherding it.  Lemme know 
if that's cool w/ you, Neil.

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

Re: Issue 737 in lilypond: Enhancement: support for footnotes and/or endnotes.

[m...@apollinemike.com]

On Oct 3, 2011, at 10:10 AM, lilyp...@googlecode.com wrote:

> 
> Comment #10 on issue 737 by pkx1...@gmail.com: Enhancement: support for 
> footnotes and/or endnotes.
> http://code.google.com/p/lilypond/issues/detail?id=737
> 
> Just doc required I think
> 
> This is started (honest!) by myself
> 
> http://code.google.com/p/lilypond/issues/detail?id=1567
> 
> Mike if this is stopping a bounty, I apologize. I'll do my utmost to get the 
> first draft of all your work in the NR by the end of this week.
> 

It's not stopping it at all - I still have one patch to sort out before I'm 
comfortable asking people for €€.

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

Re: Issue 1791 in lilypond: footnote numbering is 'out of order' when using multiple staves in a system

[m...@apollinemike.com]

On Oct 4, 2011, at 8:49 AM, lilyp...@googlecode.com wrote:

> Updates:
>   Labels: -Patch-new Patch-needs_work
> 
> Comment #3 on issue 1791 by pkx1...@gmail.com: footnote numbering is 'out of 
> order' when using multiple staves in a system
> http://code.google.com/p/lilypond/issues/detail?id=1791
> 
> Passes make but fails make check. Cannot see where I just get
> 
> --snip--
> 
> job 0 terminated with signal: 11
> fatal error: Children (0) exited with errors.
> command failed: /home/jlowe/lilypond-git/build/out/bin/lilypond -I 
> /home/jlowe/lilypond-git/input/regression/ -I ./out-test -I 
> /home/jlowe/lilypond-git/input -I /home/jlowe/lilypond-git/Documentation -I 
> /home/jlowe/lily ...
> 
> etc
> 
> --snip-
> 

Should work like a charm now.

Sorry for taking your time on something that didn't work - I thought I was 
making an innocuous change that wasn't so innocuous.

I ran the regtests on this patch and it shows no difference from current master.

Cheers,
MS


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

Re: Issue 1591 in lilypond: doc: midi output is channel-voice

[m...@apollinemike.com]

On Oct 10, 2011, at 9:22 AM, lilyp...@googlecode.com wrote:

> 
> Comment #5 on issue 1591 by d...@gnu.org: doc: midi output is channel-voice
> http://code.google.com/p/lilypond/issues/detail?id=1591
> 
> More like "second stab at getting Percival mad".  Let me guess: you are using 
> the new git-cl to automagically post to both issue list and Rietveld 
> automatically?

Yup

> 
> The question is just where it gets the idea about this connection.
> 

Accidentally typed 1591 instead of 1951.

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

Re: Issue 1971 in lilypond: Slashed flags no longer work

[m...@apollinemike.com]

On Oct 16, 2011, at 12:06 PM, lilyp...@googlecode.com wrote:

> Status: Accepted
> Owner: 
> Labels: Type-Critical Regression
> 
> New issue 1971 by philehol...@gmail.com: Slashed flags no longer work
> http://code.google.com/p/lilypond/issues/detail?id=1971
> 
> The NR 
> (http://lilypond.org/doc/v2.15/Documentation/notation/special-rhythmic-concerns)says:
> 
> "The slash through the stem found in acciaccaturas can be applied in other 
> situations
> 
> \relative c'' {
>  \override Stem #'stroke-style = #"grace"
>  c8( d2) e8( f4)
> }"
> 

It's supposed to be :

\relative c'' {
 \override Flag #'stroke-style = #"grace"
 c8( d2) e8( f4)
}

Is there a way to run convert-ly on the docs to eliminate this sorta problem?

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

Re: Issue 1971 in lilypond: Slashed flags no longer work

[m...@apollinemike.com]

On Oct 16, 2011, at 10:07 PM, Graham Percival wrote:

> On Sun, Oct 16, 2011 at 12:13:27PM +0200, m...@apollinemike.com wrote:
>> 
>> Is there a way to run convert-ly on the docs to eliminate this sorta problem?
> 
> Yes.  By some incredible coincidence, it is discussed
> in CG 10.9.4 Automatically update documentation
> http://lilypond.org/doc/v2.15/Documentation/contributor/automatically-update-documentation
> which is part of CG 10.9 Adding or modifying features
> http://lilypond.org/doc/v2.15/Documentation/contributor/adding-or-modifying-features
> which is part of CG 10. Programming work
> http://lilypond.org/doc/v2.15/Documentation/contributor/programming-work
> 
> You should be familiar with all of those sections.

I think that by running convert-ly via the script in 10.9.4, duplicate Flag 
#'transparent statements will be issued (every time convert-ly sees a Stem 
#'transparent, it adds a Flag #'transparent for files created before the 
existence of a Flag grob).  I'll do some investigating tomorrow and propose a 
patch.

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

Re: Issue 1971 in lilypond: Slashed flags no longer work

[m...@apollinemike.com]

On Oct 16, 2011, at 12:06 PM, lilyp...@googlecode.com wrote:

> Status: Accepted
> Owner: 
> Labels: Type-Critical Regression
> 
> New issue 1971 by philehol...@gmail.com: Slashed flags no longer work
> http://code.google.com/p/lilypond/issues/detail?id=1971
> 
> The NR 
> (http://lilypond.org/doc/v2.15/Documentation/notation/special-rhythmic-concerns)says:
> 
> "The slash through the stem found in acciaccaturas can be applied in other 
> situations
> 
> \relative c'' {
>  \override Stem #'stroke-style = #"grace"
>  c8( d2) e8( f4)
> }"
> 
> However, between 2.15.7 and 15.9 the slash has disappeared.  Labelling this 
> as critical, even if it might have been intended, since if there is an 
> alternative we should document it in the appropriate place.
> 

Hey Phil,

I believe this problem can't be fixed, as all the files to which you're 
referring are on the LSR, which (I think) uses a pre-flag-grob version of 
LilyPond.  Thus, if they were changed on the LSR, they would run into compile 
problems.
I can, however, manually edit the docs (in spite of the fact that the files in 
question have comments saying that they should not be manually edited).

What would be nice is to have the LSR completely decoupled from the doc build 
so that this sorta thing didn't come up.  I have not followed the discussions 
on the list about the LSR as actively as I could have, so I'm sorry if I'm 
covering old turf!

Lemme know how to proceed and thanks for catching this.

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

Re: Issue 1971 in lilypond: Slashed flags no longer work

[m...@apollinemike.com]

On Oct 17, 2011, at 12:43 AM, Graham Percival wrote:

> On Sun, Oct 16, 2011 at 11:02:22PM +0200, m...@apollinemike.com wrote:
>> 
>> I think that by running convert-ly via the script in 10.9.4,
>> duplicate Flag #'transparent statements will be issued (every
>> time convert-ly sees a Stem #'transparent, it adds a Flag
>> #'transparent for files created before the existence of a Flag
>> grob).
> 
> ok, so you think there's a bug in convert-ly ?  This is not
> precisely shocking news; let's get a Tiny example and add it to
> the tracker, or...
> 

I think that there is an issue with file-touchability.  Certain snippets in the 
docs are not editable, and the convert-ly rules don't know how to handle this 
intelligently.

With respect to the current issue:

All Flag properties were changed in the docs save the files that have a comment 
saying "Do not change me" because they are part of the LSR.  There was also one 
issue with cary.ly that I just fixed.
All of these files that belong to the LSR are the ones that are causing the 
problem (i.e. the file in the bug report).

So, as I said in my e-mail to Phil, I'm not sure how to proceed w/ fixing this 
and how convert-ly would enter into the equation.

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

Re: Issue 1971 in lilypond: Slashed flags no longer work

[m...@apollinemike.com]

On Oct 17, 2011, at 9:09 AM, Neil Puttock wrote:

> On 17 Oct 2011 07:56, "Peekay Ex"  wrote:
> 
>> However, and this is for Phil: could we not simply 'deprecate' the
>> snippet(s) like we do with any that won't work (properly) in later
>> versions, and actually I think it was Mike that a week or so ago
>> pointed one out to me that was deprecated as of 2.14.x, because the
>> snippet said 'I am deprecated' in the compiled the docs. Then
>> eventually I just went back and removed the @snippet ref.
>> 
>> Sounds pretty standard stuff.
> 
> The CG's pretty clear on this.  If the snippets are still valid, the correct
> approach is to move them to snippets/new, with appropriate changes for new
> syntax.
> 
> Cheers,
> Neil
> 

Hey Neil,

Thank you for the info!
Could you let me know where this is in the CG?  I have a set of pages 
bookmarked that I use as a checklist - I'll add this to it.

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

Re: Issue 1971 in lilypond: Slashed flags no longer work

[m...@apollinemike.com]

On Oct 17, 2011, at 9:30 AM, Peekay Ex wrote:

> Mike
> 
> On Mon, Oct 17, 2011 at 8:12 AM, m...@apollinemike.com
>  wrote:
>> On Oct 17, 2011, at 9:09 AM, Neil Puttock wrote:
>> 
>>> On 17 Oct 2011 07:56, "Peekay Ex"  wrote:
>>> 
>>>> However, and this is for Phil: could we not simply 'deprecate' the
>>>> snippet(s) like we do with any that won't work (properly) in later
>>>> versions, and actually I think it was Mike that a week or so ago
>>>> pointed one out to me that was deprecated as of 2.14.x, because the
>>>> snippet said 'I am deprecated' in the compiled the docs. Then
>>>> eventually I just went back and removed the @snippet ref.
>>>> 
>>>> Sounds pretty standard stuff.
>>> 
>>> The CG's pretty clear on this.  If the snippets are still valid, the correct
>>> approach is to move them to snippets/new, with appropriate changes for new
>>> syntax.
>>> 
>>> Cheers,
>>> Neil
>>> 
>> 
>> Hey Neil,
>> 
>> Thank you for the info!
>> Could you let me know where this is in the CG?  I have a set of pages 
>> bookmarked that I use as a checklist - I'll add this to it.
> 
> http://lilypond.org/doc/v2.15/Documentation/contributor/adding-and-editing-snippets
> 

Thanks!
Would it be possible to put a link to this page somewhere between 10.9.3 and 
10.9.5?

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

Re: Issue 1971 in lilypond: Slashed flags no longer work

[m...@apollinemike.com]

On Oct 17, 2011, at 12:49 PM, Neil Puttock wrote:

> On 17 October 2011 11:41, Graham Percival  wrote:
>> On Mon, Oct 17, 2011 at 08:09:02AM +0100, Neil Puttock wrote:
>>> On 17 Oct 2011 07:56, "Peekay Ex"  wrote:
>>> 
 However, and this is for Phil: could we not simply 'deprecate' the
 snippet(s) like we do with any that won't work (properly) in later
 versions, and actually I think it was Mike that a week or so ago
 pointed one out to me that was deprecated as of 2.14.x, because the
 snippet said 'I am deprecated' in the compiled the docs. Then
 eventually I just went back and removed the @snippet ref.
 
 Sounds pretty standard stuff.
>>> 
>>> The CG's pretty clear on this.  If the snippets are still valid, the correct
>>> approach is to move them to snippets/new, with appropriate changes for new
>>> syntax.
>> 
>> If the snippets can be automatically converted by convert-ly, then
>> don't touch snippets/new/.  We run convert-ly for every lsr import
>> for precisely this reason.
> 
> Quite, but I understood from Mike that the convert rule doesn't work
> for these snippets.
> 
> Anyway, the changes are wrong, since he's copied all the texidocs and
> %begin verbatim comment into the new snippets.
> 
> Cheers,
> Neil

Crap, I missed the stuff about the texidocs and the %begin verbatim.

I'll fix it this afternoon.

Cheers,
MS


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

Re: Issue 1971 in lilypond: Slashed flags no longer work

[m...@apollinemike.com]

On Oct 17, 2011, at 12:49 PM, Neil Puttock wrote:

> On 17 October 2011 11:41, Graham Percival  wrote:
>> On Mon, Oct 17, 2011 at 08:09:02AM +0100, Neil Puttock wrote:
>>> On 17 Oct 2011 07:56, "Peekay Ex"  wrote:
>>> 
 However, and this is for Phil: could we not simply 'deprecate' the
 snippet(s) like we do with any that won't work (properly) in later
 versions, and actually I think it was Mike that a week or so ago
 pointed one out to me that was deprecated as of 2.14.x, because the
 snippet said 'I am deprecated' in the compiled the docs. Then
 eventually I just went back and removed the @snippet ref.
 
 Sounds pretty standard stuff.
>>> 
>>> The CG's pretty clear on this.  If the snippets are still valid, the correct
>>> approach is to move them to snippets/new, with appropriate changes for new
>>> syntax.
>> 
>> If the snippets can be automatically converted by convert-ly, then
>> don't touch snippets/new/.  We run convert-ly for every lsr import
>> for precisely this reason.
> 
> Quite, but I understood from Mike that the convert rule doesn't work
> for these snippets.
> 

No, it's not that - sorry for not being clear.  It's that I thought the LSR 
imports happened periodically (along with the convert-ly rules) and that they 
didn't need to be incorporated into patches.  The convert-ly rules should work 
perfectly on the file, but if they're run twice on the file (which was my 
concern - that I would run it once and then it'd be run again during the LSR 
import), then extra Flag #'transparent calls will be printed.

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

Re: Issue 1971 in lilypond: Slashed flags no longer work

[m...@apollinemike.com]

On Oct 17, 2011, at 1:12 PM, m...@apollinemike.com wrote:

> On Oct 17, 2011, at 12:49 PM, Neil Puttock wrote:
> 
>> On 17 October 2011 11:41, Graham Percival  wrote:
>>> On Mon, Oct 17, 2011 at 08:09:02AM +0100, Neil Puttock wrote:
>>>> On 17 Oct 2011 07:56, "Peekay Ex"  wrote:
>>>> 
>>>>> However, and this is for Phil: could we not simply 'deprecate' the
>>>>> snippet(s) like we do with any that won't work (properly) in later
>>>>> versions, and actually I think it was Mike that a week or so ago
>>>>> pointed one out to me that was deprecated as of 2.14.x, because the
>>>>> snippet said 'I am deprecated' in the compiled the docs. Then
>>>>> eventually I just went back and removed the @snippet ref.
>>>>> 
>>>>> Sounds pretty standard stuff.
>>>> 
>>>> The CG's pretty clear on this.  If the snippets are still valid, the 
>>>> correct
>>>> approach is to move them to snippets/new, with appropriate changes for new
>>>> syntax.
>>> 
>>> If the snippets can be automatically converted by convert-ly, then
>>> don't touch snippets/new/.  We run convert-ly for every lsr import
>>> for precisely this reason.
>> 
>> Quite, but I understood from Mike that the convert rule doesn't work
>> for these snippets.
>> 
> 
> No, it's not that - sorry for not being clear.  It's that I thought the LSR 
> imports happened periodically (along with the convert-ly rules) and that they 
> didn't need to be incorporated into patches.  The convert-ly rules should 
> work perfectly on the file, but if they're run twice on the file (which was 
> my concern - that I would run it once and then it'd be run again during the 
> LSR import), then extra Flag #'transparent calls will be printed.
> 

Now fixed in:
c5133c2f8447bd86a9b0569eda7120318ca1080c

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

Re: Issue 1567 in lilypond: Add documentation for footnotes

[m...@apollinemike.com]

On Oct 18, 2011, at 12:38 PM, lilyp...@googlecode.com wrote:

> 
> Comment #13 on issue 1567 by pkx1...@gmail.com: Add documentation for 
> footnotes
> http://code.google.com/p/lilypond/issues/detail?id=1567
> 
> I'm making headway into documenting the auto and (I prefer) manual
> footnote commands.
> 
> However, I'm coming across something I don't understand why it doesn't work.
> 
> @lilypond[verbatim,quote,ragged-right,papersize=a8]
> \book {
> \markup {
>   \bold \italic { Poco a poco }
>   \footnote
> \super 1
> \italic "1. Little by little"
> }
> \relative c' {
> a'4\f( b8)[ e] c4_ \markup { \italic { rit. }
>   \footnote
> \sub 2
> \italic "2. Slow down"
>   }
> dis?4
> \breathe
> }
> }
> @end lilypond
> 
> The first footnote works (I see the super 1 and the footnote itself)
> but the second I only see the \sub 2. No footnote "2. Slow down" is
> printed. I looked back at your explanation I pasted into
> http://code.google.com/p/lilypond/issues/detail?id=1567
> 
> and cannot see what the difference is apart from this being attached
> to note (as opposed to a grob).
> 
> What am I doing wrong?

Hey James,

Sorry for dragging my feet on responding to this - I saw it come down the pipe 
when you first sent it but I've been in music up to my ears and have let a 
couple things slip.

Footnotes in markups only work with top level markups.

For the second one, you'd have to do \footnoteGrob #'TextScript etc..

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

Re: Issue 1844 in lilypond: Changes variable names in include/beam-scoring-problem.hh and beam-quanting.cc

[m...@apollinemike.com]

On Oct 19, 2011, at 4:03 AM, lilyp...@googlecode.com wrote:

> 
> Comment #14 on issue 1844 by colinpkc...@gmail.com: Changes variable names in 
> include/beam-scoring-problem.hh and beam-quanting.cc
> http://code.google.com/p/lilypond/issues/detail?id=1844
> 
> Does this still need work, Mike? James had some concerns on Rietveld. The 
> patch has been on patch-push for over a week, so we should clarify the status.
> 
> 
> ___
> bug-lilypond mailing list
> bug-lilypond@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-lilypond

Sorry - it's been pushed.  Will mark as fixed now.

Cheers,
MS


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

Re: \override Beam #'consistent-slope = ##t should be default

[m...@apollinemike.com]

On Oct 21, 2011, at 6:15 PM, David Kastrup wrote:

> 
> commit 1d9a73b13ee576d28c0f41f5b243f2ebb1ff9fcf
> Author: Mike Solomon 
> Date:   Fri Oct 21 09:03:43 2011 +0200
> 
>Implements consistent beam slopes across line breaks.
> 
> says
> 
>To turn on this feature, use \override Beam #'consistent-slope = ##t.
> 
> I think that is a mistake: unbroken beams naturally have consistent
> slope.  So when breaking a beam across lines, Lilypond already gets to
> play with stem lengths to make the broken output strictly better than
> the unbroken output was.
> 
> The best output might conceivingly be achieved by very slightly relaxing
> slope consistency.  As long as we have no button for that, not relaxing
> it is a much saner visual choice than totally discarding it.
> 
> I would not even offer a settable property for this as long as the only
> options are on and off.
> 


Compile beam-feather-breaking.ly in input/regression with and without this 
property - I think that the visual output changes enough to merit the on/off 
existing in LilyPond, no?

Cheers,
MS


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

Re: \override Beam #'consistent-slope = ##t should be default

[m...@apollinemike.com]

On Oct 22, 2011, at 11:55 AM, David Kastrup wrote:

> "m...@apollinemike.com"  writes:
> 
>> On Oct 21, 2011, at 6:15 PM, David Kastrup wrote:
>> 
>>> 
>>> commit 1d9a73b13ee576d28c0f41f5b243f2ebb1ff9fcf
>>> Author: Mike Solomon 
>>> Date:   Fri Oct 21 09:03:43 2011 +0200
>>> 
>>>  Implements consistent beam slopes across line breaks.
>>> 
>>> says
>>> 
>>>  To turn on this feature, use \override Beam #'consistent-slope = ##t.
>>> 
>>> I think that is a mistake: unbroken beams naturally have consistent
>>> slope.  So when breaking a beam across lines, Lilypond already gets to
>>> play with stem lengths to make the broken output strictly better than
>>> the unbroken output was.
>>> 
>>> The best output might conceivingly be achieved by very slightly relaxing
>>> slope consistency.  As long as we have no button for that, not relaxing
>>> it is a much saner visual choice than totally discarding it.
>>> 
>>> I would not even offer a settable property for this as long as the only
>>> options are on and off.
>>> 
>> 
>> 
>> Compile beam-feather-breaking.ly in input/regression with and without
>> this property - I think that the visual output changes enough to merit
>> the on/off existing in LilyPond, no?
> 
> Apart from breaking the documentation, this patch does not really reach
> the finishing line.  First, the property actually is called
> consistent-broken-slope.  Second, it is quite obvious from the output
> that it does _not_ merely keep the slope consistent, but additionally
> the vertical position.

This is true.

> 
> Of course, this _does_ change the quality of the output.  The vertical
> positions of the broken beams should be kept together with a light
> spring at most.
> 
> If the vertical positions are tied together rigidly, the user gets the
> choice between two suboptimal extremes: detrimental overconsistency, or
> total non-consistency.
> 
> Picking the detrimental overconsistency only makes sense if by chance
> the beam slopes would be similar anyway.  Which is the case in
> beam-feather-breaking.ly.  But it should not be the task of the user to
> determine this and flip a switch accordingly.
> 

I see you raising two issues here:

1) Automating when broken slopes are kept consistent.  I agree that it'd be 
great if LilyPond could decide when this'll happen with respect to certain 
parameters, but I'm not sure what those parameters would be.  Based on my 
experience in the contemporary literature (I'm thinking of the 2nd Boulez 
Sonata), consistent slopes is always the case.  I think LilyPond's old output 
was not as much an aesthetic choice as a lack of an implemented feature.  Thus, 
I would be for getting rid of the property and making it the default, but I'd 
need more evidence showing that the default comes up nowhere in the literature.
2) As for the light spring, I think you're right (the Bartok 2nd string quartet 
on IMSLP, for example, has light differences between the cut points in broken 
beams), but I also think that:
 a)  The extreme that consistent-broken-slopes brings is closer to that which 
is found in the literature.
 b)  It will be easier to code the subtleties that are in the literature now 
that this feature is implemented.

Cheers,
MS

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


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

Re: Issue 1986 in lilypond: Patch: Fixes slope errors from incorrect X extents in Beam::print.

[m...@apollinemike.com]

On Oct 24, 2011, at 6:01 AM, lilyp...@googlecode.com wrote:

> Updates:
>   Labels: Patch-review
> 
> Comment #2 on issue 1986 by percival.music...@gmail.com: Patch: Fixes slope 
> errors from incorrect X extents in Beam::print.
> http://code.google.com/p/lilypond/issues/detail?id=1986#c2
> 
> Patchy the autobot says: LGTM.  Changed output in 
> beam-consistent-broken-slope.ly but I assume that's expected
> 

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

Re: \override Beam #'consistent-slope = ##t should be default

[m...@apollinemike.com]

errata: more note flat = more not flat
On Oct 25, 2011, at 10:06 AM, m...@apollinemike.com wrote:

> On Oct 25, 2011, at 5:32 AM, Keith OHara wrote:
> 
>> There are lots of broken beams in Scriabin's first prelude
>> <http://imslp.org/wiki/24_Preludes,_Op.11_(Scriabin,_Aleksandr)>
>> The original publisher makes no attempt at consistent slopes.
>> Peters Edition prints nearly-equal slopes across the line-breaks, but
>> lets the beam height 
>> 
>> There is a Lilypond version at 
>> <http://www.mutopiaproject.org/cgibin/piece-info.cgi?id=1779>
>> Applying consistent-broken-slope = #t (beware the error in this thread 
>> subject line) produces output with distractingly strange stem lengths.
>> 
>> The patch at <http://codereview.appspot.com/5293060>
>> seems to help.  The odd stem lengths, required to match the vertical
>> position of the beam across the line-break, are still distracting.
>> 
>> Consistent slopes seem to help readability somewhat.
>> 
> 
> Hey Keith,
> 
> Thanks for the suggestion!
> I've uploaded a new patch set that brings my work closer to the Peters.
> 
> A few thoughts:
> 
> 1) For hardcore contemporary music, I actually like the aesthetic of 
> completely consistent slopes.  I'll code a property for that once I've gotten 
> comments on the newest version of this patch.
> 
> 2) I get the sense from the Peters that the rule seems to be "the OKness of 
> slope modifications is directly proportional to the absolute value of the 
> slope."  That is, for flat slopes breaking across lines, a change in slope 
> seems very bad, whereas for slopes that are @ 20ish degrees, a change in 
> slope seems OK.  Although I don't know anything about human 
> psychology/cognition, my gut tells me that this corresponds to the way we 
> perceive slopes: if something goes from flat to not flat it sticks out, but 
> if something goes from not flat to more note flat it sticks out less.
> 
> 3) Aside from what I mention in (2), are there any other criteria that, in 
> your opinion, seem to govern slope breaking?  Could these criteria vary from 
> work to work, edition to edition, style to style?  Does Elaine Gould have 
> anything to say on the subject?  I can change the name of 
> consistent-broken-slope to slope-style (with styles like 
> 'hardcore-contemporary, 'peters-fin-de-siecle, 'break-without-unifying, 
> etc.).  But it'd be good to do this now before I have to start dealing with 
> convert-ly rules (ugggh :).
> 
> I know beam-quanting.cc pretty well now, so any changes to the scorer 
> wouldn't take me a long time.  What is most important is that we brainstorm 
> this thing correctly so that we can get as much right as possible with this 
> patch.
> 
> Cheers,
> MS
> ___
> bug-lilypond mailing list
> bug-lilypond@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-lilypond


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

Re: \override Beam #'consistent-slope = ##t should be default

[m...@apollinemike.com]

On Oct 25, 2011, at 10:06 AM, m...@apollinemike.com wrote:

> On Oct 25, 2011, at 5:32 AM, Keith OHara wrote:
> 
>> There are lots of broken beams in Scriabin's first prelude
>> <http://imslp.org/wiki/24_Preludes,_Op.11_(Scriabin,_Aleksandr)>
>> The original publisher makes no attempt at consistent slopes.
>> Peters Edition prints nearly-equal slopes across the line-breaks, but
>> lets the beam height 
>> 
>> There is a Lilypond version at 
>> <http://www.mutopiaproject.org/cgibin/piece-info.cgi?id=1779>
>> Applying consistent-broken-slope = #t (beware the error in this thread 
>> subject line) produces output with distractingly strange stem lengths.
>> 
>> The patch at <http://codereview.appspot.com/5293060>
>> seems to help.  The odd stem lengths, required to match the vertical
>> position of the beam across the line-break, are still distracting.
>> 
>> Consistent slopes seem to help readability somewhat.
>> 
> 
> Hey Keith,
> 
> Thanks for the suggestion!
> I've uploaded a new patch set that brings my work closer to the Peters.
> 
> A few thoughts:
> 
> 1) For hardcore contemporary music, I actually like the aesthetic of 
> completely consistent slopes.  I'll code a property for that once I've gotten 
> comments on the newest version of this patch.
> 
> 2) I get the sense from the Peters that the rule seems to be "the OKness of 
> slope modifications is directly proportional to the absolute value of the 
> slope."  That is, for flat slopes breaking across lines, a change in slope 
> seems very bad, whereas for slopes that are @ 20ish degrees, a change in 
> slope seems OK.  Although I don't know anything about human 
> psychology/cognition, my gut tells me that this corresponds to the way we 
> perceive slopes: if something goes from flat to not flat it sticks out, but 
> if something goes from not flat to more note flat it sticks out less.
> 
> 3) Aside from what I mention in (2), are there any other criteria that, in 
> your opinion, seem to govern slope breaking?  Could these criteria vary from 
> work to work, edition to edition, style to style?  Does Elaine Gould have 
> anything to say on the subject?  I can change the name of 
> consistent-broken-slope to slope-style (with styles like 
> 'hardcore-contemporary, 'peters-fin-de-siecle, 'break-without-unifying, 
> etc.).  But it'd be good to do this now before I have to start dealing with 
> convert-ly rules (ugggh :).
> 
> I know beam-quanting.cc pretty well now, so any changes to the scorer 
> wouldn't take me a long time.  What is most important is that we brainstorm 
> this thing correctly so that we can get as much right as possible with this 
> patch.
> 
> Cheers,
> MS

Hey all,

I have a new patch up at:

http://codereview.appspot.com/5293060

That addresses Keith's and David's concerns and (hopefully) gets broken slopes 
closer to the way that they appear in the late-Romantic and early-modern 
literature.

The patch still has some crud in it (notes to self, etc.) but is more or less 
stable.

The problem is that, when I run regtests on it, it slows my machine down to a 
crawl.  I am not sure if this is because I have a problem with my machine or if 
because I have some sorta memory leakage in the patch.

So, if someone could please run the regtests and let me know if they run in a 
timely fashion (or if they slow your machine down too), I'd appreciate it!

Cheers,
MS

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

Re: Problem with glissandi in 2.15.15

[m...@apollinemike.com]

On Oct 28, 2011, at 10:57 AM, Nick Payne wrote:

> I'm using glissandi to indicate slides in fingering. The following code 
> should give me a glissando between the fingering digits (it did in older 
> versions), but on 2.15.15 I get no glissando at all:
> 
> \version "2.15.15"
> 
> \relative c'' {
>\override Fingering #'staff-padding = #'()
>\once \override Glissando #'extra-offset = #'(0 . 1.4)
> 4\glissando 
> }
> 

You have to tell it not to end on the accidental.

\relative c'' {
   \override Fingering #'staff-padding = #'()
   \once \override Glissando #'extra-offset = #'(0 . 1.4)
   \once \override Glissando #'bound-details #'right #'end-on-accidental = ##f
4\glissando 
}

There are more accurate & automated ways of doing this, though.  If you create 
a Scheme engraver that acknowledges fingerings and glissandi and then override 
the Y positions to match up with these fingerings, you don't need to use the 
extra offset.  Check out scheme-engraver-instance.ly and scheme-engraver.ly in 
input/regression.

Cheers,
MS


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

Re: Issue 1981 in lilypond: Patch: Adds Scheme function for spring constructor.

[m...@apollinemike.com]

On Oct 28, 2011, at 2:11 PM, lilyp...@googlecode.com wrote:

> 
> Comment #8 on issue 1981 by d...@gnu.org: Patch: Adds Scheme function for 
> spring constructor.
> http://code.google.com/p/lilypond/issues/detail?id=1981
> 
> You forgot to rebase when pulling from dev/staging.  I took the liberty of 
> doing that and replacing dev/staging with the result.  So your commit now is
> 63f43c43a87be99477432e1f3156eac5870b775e
> and dev/staging should be pretty enough for fast-forwarding into master again.
> 

It's not that I forgot, it's that I have no clue what I'm doing with git when 
things venture outside of the insanely simple.
I did
git checkout dev/staging
git pull
git apply foo.diff
git commit -a -m "This is my commit message."
git push

Where should I do the rebase, and what should that line look like?

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

Re: Issue 1981 in lilypond: Patch: Adds Scheme function for spring constructor.

[m...@apollinemike.com]

On Oct 28, 2011, at 2:38 PM, David Kastrup wrote:

> "m...@apollinemike.com"  writes:
> 
>> On Oct 28, 2011, at 2:11 PM, lilyp...@googlecode.com wrote:
>> 
>>> 
>>> Comment #8 on issue 1981 by d...@gnu.org: Patch: Adds Scheme
>>> function for spring constructor.
>>> http://code.google.com/p/lilypond/issues/detail?id=1981
>>> 
>>> You forgot to rebase when pulling from dev/staging.  I took the
>>> liberty of doing that and replacing dev/staging with the result.  So
>>> your commit now is
>>> 63f43c43a87be99477432e1f3156eac5870b775e
>>> and dev/staging should be pretty enough for fast-forwarding into master 
>>> again.
>>> 
>> 
>> It's not that I forgot, it's that I have no clue what I'm doing with
>> git when things venture outside of the insanely simple.
>> I did
>> git checkout dev/staging
>> git pull
>> git apply foo.diff
>> git commit -a -m "This is my commit message."
>> git push
>> 
>> Where should I do the rebase, and what should that line look like?
> 
> In this case, you would have needed
> git pull -r
> which rebases your dev/staging on origin/dev/staging (since dev/staging
> is frequently reset, it does not make sense to keep its history
> according to your repository available).
> 
> If your old staging had stuff that was later removed (because of failing
> regtests or whatever), this stuff will be now in again.
> 
> So if you are not strictly at origin/dev/staging now, check that
> everything on top of that is yours and supposed to go in, otherwise do
> an appropriate hard reset.
> 
> Instead of applying a diff, you are better off doing git cherry-pick
> commit-id for getting the stuff into staging.
> 
> If you have a feature branch, it might be worth doing
> git fetch
> git rebase origin/dev/staging feature-branch
> [Check that everything looks hunky-dory]
> git push origin HEAD:refs/heads/dev/staging
> 
> If your feature branch has commits with non-compilable state in it
> (i.e., before running convert-ly), you want just a single merge commit
> to end up in staging:
> git fetch
> git rebase origin/dev/staging feature-branch
> git checkout origin/dev/staging
> git merge --no-ff feature-branch
> git push origin HEAD:refs/heads/dev/staging
> 
> Again: before pushing, most definitely use gitk or similar to check that
> the commit structure you are going to push makes sense: only nicely
> separated single commits, with the exceptions of merge commits bypassing
> the mainline if you want to split a feature into several commits with
> intermittently non-working working tree that should not go into the
> mainline in order not to disturb git bisect.
> 

Ok.  I followed your advice for a push I just made with in-notes.  Please let 
me know if this looks correct and sorry in advance if there are still any 
problems!

Cheers,
MS


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

Re: Issue 1981 in lilypond: Patch: Adds Scheme function for spring constructor.

[m...@apollinemike.com]

On Oct 28, 2011, at 3:06 PM, David Kastrup wrote:

> "m...@apollinemike.com"  writes:
> 
>> On Oct 28, 2011, at 2:38 PM, David Kastrup wrote:
>> 
>>> "m...@apollinemike.com"  writes:
>>> 
>>>> On Oct 28, 2011, at 2:11 PM, lilyp...@googlecode.com wrote:
>>>> 
>>>>> 
>>>>> Comment #8 on issue 1981 by d...@gnu.org: Patch: Adds Scheme
>>>>> function for spring constructor.
>>>>> http://code.google.com/p/lilypond/issues/detail?id=1981
>>>>> 
>>>>> You forgot to rebase when pulling from dev/staging.  I took the
>>>>> liberty of doing that and replacing dev/staging with the result.  So
>>>>> your commit now is
>>>>> 63f43c43a87be99477432e1f3156eac5870b775e
>>>>> and dev/staging should be pretty enough for fast-forwarding into
>>>>> master again.
>>>>> 
>>>> 
>>>> It's not that I forgot, it's that I have no clue what I'm doing with
>>>> git when things venture outside of the insanely simple.
>>>> I did
>>>> git checkout dev/staging
>>>> git pull
>>>> git apply foo.diff
>>>> git commit -a -m "This is my commit message."
>>>> git push
>>>> 
>>>> Where should I do the rebase, and what should that line look like?
>>> 
>>> In this case, you would have needed
>>> git pull -r
>>> which rebases your dev/staging on origin/dev/staging (since dev/staging
>>> is frequently reset, it does not make sense to keep its history
>>> according to your repository available).
>>> 
>>> If your old staging had stuff that was later removed (because of failing
>>> regtests or whatever), this stuff will be now in again.
>>> 
>>> So if you are not strictly at origin/dev/staging now, check that
>>> everything on top of that is yours and supposed to go in, otherwise do
>>> an appropriate hard reset.
>>> 
>>> Instead of applying a diff, you are better off doing git cherry-pick
>>> commit-id for getting the stuff into staging.
>>> 
>>> If you have a feature branch, it might be worth doing
>>> git fetch
>>> git rebase origin/dev/staging feature-branch
>>> [Check that everything looks hunky-dory]
>>> git push origin HEAD:refs/heads/dev/staging
>>> 
>>> If your feature branch has commits with non-compilable state in it
>>> (i.e., before running convert-ly), you want just a single merge commit
>>> to end up in staging:
>>> git fetch
>>> git rebase origin/dev/staging feature-branch
>>> git checkout origin/dev/staging
>>> git merge --no-ff feature-branch
>>> git push origin HEAD:refs/heads/dev/staging
>>> 
>>> Again: before pushing, most definitely use gitk or similar to check that
>>> the commit structure you are going to push makes sense: only nicely
>>> separated single commits, with the exceptions of merge commits bypassing
>>> the mainline if you want to split a feature into several commits with
>>> intermittently non-working working tree that should not go into the
>>> mainline in order not to disturb git bisect.
>>> 
>> 
>> Ok.  I followed your advice for a push I just made with in-notes.
>> Please let me know if this looks correct and sorry in advance if there
>> are still any problems!
> 
> input/regression/in-note.ly starts with \version "2.15.15", but VERSION
> is at 2.15.17 for the next release from staging.
> 
> You can checkout origin/dev/staging, fix the version (assuming that
> your commit is still last), do
> commit -C HEAD --amend input/regression/in-note.ly
> to meld this fix into your commit.
> 
> git push origin HEAD:refs/heads/dev/staging
> will now fail since you are not an ancestor of your original commit
> anymore.  Try it anyway.
> 
> git push original +HEAD:refs/heads/dev/staging
> would _overwrite_ dev/staging, but our repository is set up to not allow
> that (how stupid: for staging it would be really useful).
> 
> After double-checking with git-fetch that nobody left anything more in
> origin/dev/staging, you can to
> 
> git push origin :refs/heads/dev/staging
> git push origin HEAD:refs/heads/dev/staging
> 
> Note that the first line _deletes_ the staging branch.  The second
> rewrites it from scratch.
> 
> Better not fall asleep between the two commands, or you'll be unpopular.
> 

Sorry for the oversight.  Wouldn't it just be easier to commit a new commit 
with the change in version number?

Cheers,
MS


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

Re: Issue 1981 in lilypond: Patch: Adds Scheme function for spring constructor.

[m...@apollinemike.com]

On Oct 28, 2011, at 3:18 PM, David Kastrup wrote:

> "m...@apollinemike.com"  writes:
> 
>> Sorry for the oversight.  Wouldn't it just be easier to commit a new
>> commit with the change in version number?
> 
> Sure, that's certainly possible.  However, one of the points of the
> staging branch is that mistakes need not get into master.
> 
> To make an example for how to do corrections like that, I looked at your
> change in order to find something to complain about.  And the version
> string was the easiest target...
> 
> dev/staging is a moving target.  It should be kept in a state where
> fast-forwarding master to it is possible (because that's really what
> Patchy can do with good conscience after testing).
> 
> But from one moment to the next, it might stop being a proper descendant
> of a previous value of dev/staging, and contributors must be prepared to
> deal with that: rebasing their own work on top of an old dev/staging on
> the rewritten version of dev/staging.
> 

Worked like a charm!

Thanks for the tip.

Cheers,
MS


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

Re: Issue 1981 in lilypond: Patch: Adds Scheme function for spring constructor.

[m...@apollinemike.com]

On Oct 28, 2011, at 3:52 PM, David Kastrup wrote:

> "m...@apollinemike.com"  writes:
> 
>> On Oct 28, 2011, at 3:18 PM, David Kastrup wrote:
>> 
>>> "m...@apollinemike.com"  writes:
>>> 
>>>> Sorry for the oversight.  Wouldn't it just be easier to commit a new
>>>> commit with the change in version number?
>>> 
>>> Sure, that's certainly possible.  However, one of the points of the
>>> staging branch is that mistakes need not get into master.
>>> 
>>> To make an example for how to do corrections like that, I looked at your
>>> change in order to find something to complain about.  And the version
>>> string was the easiest target...
>>> 
>>> dev/staging is a moving target.  It should be kept in a state where
>>> fast-forwarding master to it is possible (because that's really what
>>> Patchy can do with good conscience after testing).
>>> 
>>> But from one moment to the next, it might stop being a proper descendant
>>> of a previous value of dev/staging, and contributors must be prepared to
>>> deal with that: rebasing their own work on top of an old dev/staging on
>>> the rewritten version of dev/staging.
>>> 
>> 
>> Worked like a charm!
>> 
>> Thanks for the tip.
> 
> And here is how I recovered after being in your previous version of
> dev/staging:
> 
> Your branch and 'origin/dev/staging' have diverged,
> and have 1 and 1 different commit(s) each, respectively.
> dak@lola:/usr/local/tmp/lilypond$ git rebase origin/dev/staging
> First, rewinding head to replay your work on top of it...
> Applying: Adds in-notes to LilyPond.
> Using index info to reconstruct a base tree...
> Falling back to patching base and 3-way merge...
> Auto-merging input/regression/in-note.ly
> CONFLICT (add/add): Merge conflict in input/regression/in-note.ly
> Failed to merge in the changes.
> Patch failed at 0001 Adds in-notes to LilyPond.
> 
> When you have resolved this problem run "git rebase --continue".
> If you would prefer to skip this patch, instead run "git rebase --skip".
> To restore the original branch and stop rebasing run "git rebase --abort".
> 
> dak@lola:/usr/local/tmp/lilypond$ git diff
> diff --cc input/regression/in-note.ly
> index 1ed0ecc,6e1b8b7..000
> --- a/input/regression/in-note.ly
> +++ b/input/regression/in-note.ly
> @@@ -1,4 -1,4 +1,8 @@@
> ++<<<<<<< HEAD
> +\version "2.15.17"
> ++===
> + \version "2.15.15"
> ++>>>>>>> Adds in-notes to LilyPond.
> 
>  \header {
>texidoc = "LilyPond does in-notes.  The positioning of these notes can
> dak@lola:/usr/local/tmp/lilypond$ git rebase --skip
> HEAD is now at 84ed591 Adds in-notes to LilyPond.
> 
> 
> Since rebasing replays the patches from _your_ branch on the upstream
> branch, skipping foreign patches that conflict with newer versions of
> themselves is the right thing to do.
> 
> Of course, you should also check the results of the rebase to make sure
> that you did not reintroduce foreign patches from your old staging
> branch into the current one.
> 
> It does make quite a bit of sense to do your own work in a feature
> branch based off origin/master rather than an own copy of staging, and
> just merge or rebase on a freshly fetched origin/dev/staging when you
> are ready for putting it out.
> 

+1.  This is what I used to do with origin/master as well.

Cheers,
MS


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

Re: Issue 1874 in lilypond: some stems are no longer transparent in the docs

[m...@apollinemike.com]

On Oct 29, 2011, at 7:19 PM, lilyp...@googlecode.com wrote:

> Updates:
>   Labels: -Priority-Medium
> 
> Comment #2 on issue 1874 by pkx1...@gmail.com: some stems are no longer 
> transparent in the docs
> http://code.google.com/p/lilypond/issues/detail?id=1874
> 
> Mike I don't know if your recent discussion and commits for convert-ly etc. 
> have resolved this or not?
> 
> James
> 
I believe so - I'll check in the next day or so and update the issue.  Don't 
hesitate to pester me if I forget!


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

Re: Issue 2029 in lilypond: Patch: Adds some info about pure propertiesto the CG.

[m...@apollinemike.com]

On Nov 8, 2011, at 8:00 AM, Trevor Daniels wrote:

> 
>> New issue 2029 by mts...@gmail.com: Patch: Adds some info about pure
>> properties to the CG.
>> http://code.google.com/p/lilypond/issues/detail?id=2029
>> 
>> Adds some info about pure properties to the CG.
>> 
>> http://codereview.appspot.com/5364048
> 
> Mike
> 
> Did you upload the right patch?  I don't see anything
> affecting the CG.
> 
> Trevor

Sorry, fixed!

Cheers,
MS

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

Re: Issue 1723 in lilypond: beam fails to extend over rest, intermittently

[m...@apollinemike.com]

On Nov 17, 2011, at 3:22 PM, lilyp...@googlecode.com wrote:

> 
> Comment #10 on issue 1723 by d...@gnu.org: beam fails to extend over rest, 
> intermittently
> http://code.google.com/p/lilypond/issues/detail?id=1723
> 
> Previous comment 9 was a wrong lead, just a case of obfuscate programming.  
> I'll likely commit some programming comments to save somebody else from 
> wracking his brain, but that's about it for that last hunch.  Search goes on.
> 
> 
> ___
> bug-lilypond mailing list
> bug-lilypond@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-lilypond

Hey all,

Using all of the suggestions proposed so far, I'm failing to reproduce the 
error in all but the occasional regtest.
This has uninitialized variable written all over it.  If someone can get me a 
surefire buggy file, I can likely figure this out.  The challenge is getting 
the consistently buggy file.

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

Re: Issue 2000 in lilypond: Patch: Fixes NoteColumn vs SpanBar collisions.

[m...@apollinemike.com]

On Nov 15, 2011, at 11:13 PM, lilyp...@googlecode.com wrote:

> Updates:
>   Labels: -Patch-countdown Patch-push
> 
> Comment #30 on issue 2000 by colinpkc...@gmail.com: Patch: Fixes NoteColumn 
> vs SpanBar collisions.
> http://code.google.com/p/lilypond/issues/detail?id=2000
> 
> Counted down to 2015
> 

Hey all,

I've posted the first installment of what will be pushed for this patch on 
Rietveld (http://codereview.appspot.com/5323062).  I'd like each installment 
(as described in my mail to devel on November 11, 2011 10:34:32 AM EST) to get 
counted down individually so that people have the time to review each step.

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

Re: Issue 2047 in lilypond: Patch: Add \accidentalStyle command

[m...@apollinemike.com]

On Nov 23, 2011, at 8:09 AM, lilyp...@googlecode.com wrote:

> 
> Comment #9 on issue 2047 by d...@gnu.org: Patch: Add \accidentalStyle command
> http://code.google.com/p/lilypond/issues/detail?id=2047
> 
> Tsk tsk tsk.  Currently working on the documention, and it is rather stupid 
> that we have \accidentalStyle "default" but $(set-accidental-style "default" 
> 'GrandStaff).  I lean towards allowing _only_ strings as accidentalStyle 
> (currently accidentalStyle #'default is working) and instead take an optional 
> symbol argument, like
> \accidentalStyle #'GrandStaff "default".  At the time the command is 
> executed, I can't use ly:context-find for reliably distinguishing context 
> symbols from others.
> 
> When I manage getting assignments into arguments, \accidentalStyle GrandStaff 
> = #'default would be nice, but I don't yet have a good workable plan for that.
> 
> People ok with reserving symbols for context specification, allowing only 
> strings for style spec?

I'm the last person to have the right to make any claims about how to do UI 
but, that said, here I go.  Currently, all style-related properties are symbols 
(Flag #'style, etc.).  Insofar as this is a context modification, I realize 
that the syntax has to be different, but it may be strange to users to remember 
this one exception.

Unfortunately, I can't think of a good workaround, but I figured I'd raise that 
issue.

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

Re: Issue 2051 in lilypond: Patch: Better pure heights for slurs

[m...@apollinemike.com]

On Nov 26, 2011, at 10:19 PM, Keith OHara wrote:

> On Sat, 26 Nov 2011 00:38:50 -0800,  wrote:
> 
>> Keith,
>> retested.
>> 
> Sorry to call you by the wrong name, James.  My eyes saw pkx166h and my brain 
> though "p h? no that's James" but my fingers were already typed Phil.
> 
> I still seems strange that \textLengthOn is failing for you in 
> 'string-number-around-slur.ly' after this patch, because the patch doesn't 
> touch text lengths.  But I will stop worrying because, Mike is likely to drop 
> this patch,

True that...it's a crappy patch.  The real problem, as you've pointed out, are 
the extents of Scripts.

I'll get on it w/in the next two-ish weeks.

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

Re: Issue 2051 in lilypond: Patch: Better pure heights for slurs

[m...@apollinemike.com]

On Nov 26, 2011, at 11:28 PM, m...@apollinemike.com wrote:

> On Nov 26, 2011, at 10:19 PM, Keith OHara wrote:
> 
>> On Sat, 26 Nov 2011 00:38:50 -0800,  wrote:
>> 
>>> Keith,
>>> retested.
>>> 
>> Sorry to call you by the wrong name, James.  My eyes saw pkx166h and my 
>> brain though "p h? no that's James" but my fingers were already typed Phil.
>> 
>> I still seems strange that \textLengthOn is failing for you in 
>> 'string-number-around-slur.ly' after this patch, because the patch doesn't 
>> touch text lengths.  But I will stop worrying because, Mike is likely to 
>> drop this patch,
> 
> True that...it's a crappy patch.  The real problem, as you've pointed out, 
> are the extents of Scripts.
> 
> I'll get on it w/in the next two-ish weeks.
> 

I revisited the patch and realized that it's crappiness was due to a 
miscalculation - I've reposted it, and I think it works well now.

Cheers,
MS


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

Re: Collision of hyphen and barline

[m...@apollinemike.com]

Le Dec 1, 2011 à 6:21 PM, Phil Holmes a écrit :

> "Christopher Schlosser"  wrote in message 
> news:loom.2030t213409-...@post.gmane.org...
>>> I'm not top posting.
>> 
>> %This is e.g. a problem for engraving a choral piece with barlines in 
>> mensural
>> style. Maybe this is a special case of bug #2061, but I wasn't sure.
>> 
>> 
>> \version "2.14.2"
>> 
>> \new StaffGroup <<
>> 
>> \new Staff { r1 r}
>>   %Collision of hyphen and barline
>> \new Lyrics \lyricmode { hel1 -- lo1 }
>> 
>> \new Staff { r1 r }
 
> 
> It's not 2061 - that was only introduced in 2.15.14.
> 
> That said, the normal way to set lyrics is with a ChoirStaff group, and if 
> you do that, there's no bar line for the hyphen to hit.  Have you considered 
> this?
> 

The same issue comes up with crescendos, beams, etc. that cross bar lines.  I 
usually do:

\once \override LyricHyphen #'whiteout = ##t

Cheers,
MS


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

Re: Issue 2067 in lilypond: Patch: Give \displayLilyMusic and \displayMusic optional port arguments.

[m...@apollinemike.com]

Le Dec 2, 2011 à 10:41 AM, lilyp...@googlecode.com a écrit :

> 
> So Mike: can you recheck your 5ac2664c2207e8dfa1734d786e5c7b214b275521 
> checkin using --no-optimize or whatever else it was we used to check for 
> undead objects?

I'm a bit short on time now, but I'll do my best to check it in the 
not-too-distant future.

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

Re: Issue 2083 in lilypond: \\break in alternative causes score to split

[m...@apollinemike.com]

Le Dec 7, 2011 à 1:07 PM, Eluze a écrit :

> this is described in 
> http://lilypond.org/doc/v2.15/Documentation/usage/common-errors#Common-errors
> 
> it points to the fact that there are "… two \relative blocks, which each
> implicitly create Staff and Voice blocks."
> 
> the following example creates a separate staff, too:
> 
> {
>   \relative c' c
>   \relative c' d
> }
> 
> if in your example you only use \music once everything looks OK!
> 
> Eluze

Gotchya...sorry for missing that!
Will mark as invalid.

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

Re: Issue 460 in lilypond: bar numbers for broken bars

[m...@apollinemike.com]

Le Dec 8, 2011 à 5:10 PM, lilyp...@googlecode.com a écrit :

> Updates:
>   Labels: Patch-needs_work
> 
> Comment #22 on issue 460 by lilypond...@gmail.com: bar numbers for broken bars
> http://code.google.com/p/lilypond/issues/detail?id=460#c22
> 
> Patchy the autobot says: tuplet-broken.ly goes from nothing to (2). Look, 
> this is supposed to catch *unintentional* problems. Are you testing these at 
> all yourself?

Yeah, I just misunderstood what was requested.
New patch set up.

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

Re: No flags printed with "2.15.20" using TabStaff with \tabFullNotation

[m...@apollinemike.com]

On Dec 17, 2011, at 4:39 PM, Thomas Morley wrote:

> Hi,
> 
> this doesn't print flags with "2.15.20", but it does with "2.14.2".
> 
> 
> \version "2.14.2"
> %\version "2.15.20"
> \new TabStaff { \tabFullNotation c8 }
> 
> 
> Cheers,
>  Harm

Thanks.

There is a patch up to fix this as 
http://code.google.com/p/lilypond/issues/detail?id=2116.

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

Re: Collision of hyphen and barline

[m...@apollinemike.com]

On Dec 25, 2011, at 1:48 PM, James wrote:

> Phil (mike)
> 
> On 2 December 2011 07:16, m...@apollinemike.com  wrote:
>> Le Dec 1, 2011 à 6:21 PM, Phil Holmes a écrit :
>> 
>>> "Christopher Schlosser"  wrote in message 
>>> news:loom.2030t213409-...@post.gmane.org...
>>>>> I'm not top posting.
>>>> 
>>>> %This is e.g. a problem for engraving a choral piece with barlines in 
>>>> mensural
>>>> style. Maybe this is a special case of bug #2061, but I wasn't sure.
>>>> 
>>>> 
>>>> \version "2.14.2"
>>>> 
>>>> \new StaffGroup <<
>>>> 
>>>> \new Staff { r1 r}
>>>>   %Collision of hyphen and barline
>>>> \new Lyrics \lyricmode { hel1 -- lo1 }
>>>> 
>>>> \new Staff { r1 r }
>>>>>> 
>>> 
>>> It's not 2061 - that was only introduced in 2.15.14.
>>> 
>>> That said, the normal way to set lyrics is with a ChoirStaff group, and if 
>>> you do that, there's no bar line for the hyphen to hit.  Have you 
>>> considered this?
>>> 
>> 
>> The same issue comes up with crescendos, beams, etc. that cross bar lines.  
>> I usually do:
>> 
>> \once \override LyricHyphen #'whiteout = ##t
>> 
>> Cheers,
>> MS
> 
> I used
> 
> \version "2.14.1"
> 
> \new StaffGroup <<
>  \new Staff { c''1 | c''1 }
>  \new Lyrics \lyricmode {
>\once \override LyricHyphen #'whiteout = ##t
>hell1 -- o1
>  }
>  \new Staff { R1 | R1 }
>>> 
> 
> and while it does technically white-out the lyric hyphen, it isn't
> _that_ clearer :) See attached.
> 
> Is there a way to increase the area around the lyric hyphen to add
> more white around the glyph without having to resort to boxes and
> layers?

Mm...no, it's pretty hard.  You'd have to override the stencil to add a white 
box underneath the hyphen and then make sure to adjust its position if it moves 
up or down because of its new vertical extent.  The white-out is applied 
directly to the stencil very late in the grob-making game, so fiddling with 
Y-extent doesn't cut it.

Cheers,
MS


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

Re: Segfault 2.15.23 Span_bar_stub_engraver

[m...@apollinemike.com]

On Dec 31, 2011, at 10:56 PM, Jay Anderson wrote:

> I've been unable to create a good small example so far. When I take
> out seemingly unrelated sections it compiles which makes it difficult
> to narrow down. Removing the "Span_bar_stub_engraver" from my
> PianoStaff fixes the segfault, but what won't work if I do this?
> 
> Below is at least the stack trace in case there is something obvious.
> This stack was made with a build using the latest on master this
> morning. Thanks for the help!
> 
> -Jay
> 
> #0  Scheme_hash_table::try_retrieve (this=0x0, k=0x7342f520,
>v=0x7fff8b78) at scm-hash.cc:97
> #1  0x0048e331 in Context::where_defined (this=0xd71ff0,
>sym=0x7342f520, value=0x7fff8b78) at context.cc:420
> #2  0x004953a7 in updated_grob_properties (tg=,
>sym=0x7342f520) at context-property.cc:264
> #3  0x006272fe in Span_bar_stub_engraver::process_acknowledged (
>this=0xce1d10) at span-bar-stub-engraver.cc:119
> #4  0x00685018 in invoke (this=)
>at ./include/translator-group.hh:46
> #5  Translator_group::precomputed_translator_foreach (this=,
>idx=) at translator-group.cc:325
> #6  0x004b1975 in Engraver_group::do_announces (this=0x109dd90)
>at engraver-group.cc:174
> #7  0x004b1942 in Engraver_group::do_announces (this=0xcc31a0)
>at engraver-group.cc:169
> #8  0x005ddcfd in one_time_step (this=0xcc31a0)
>at score-engraver.cc:152
> #9  Score_engraver::one_time_step_callback (self=0xcc31a0, ev=)
>at score-engraver.cc:145
> #10 0x0051c4cd in Listener::listen (this=,
>ev=) at listener.cc:44
> #11 0x004a05cf in Dispatcher::dispatch (this=0xc41260,
>sev=) at dispatcher.cc:152
> #12 0x0049ef8d in Dispatcher::broadcast (this=,
>ev=) at dispatcher.cc:178
> #13 0x0048e7ca in Context::internal_send_stream_event (this=0xf8c268,
>type=, origin=0x0, props=0x7fff9060) at context.cc:460
> #14 0x004d6cde in Global_context::run_iterator_on_me (this=0xf8c1e0,
>iter=0xdf2e30) at global-context.cc:169
> #15 0x004d8c4b in ly_interpret_music_expression (mus=,
>ctx=0x70d94d30) at global-context-scheme.cc:119
> #16 0x004d93d1 in ly_run_translator (mus=0x7fffef54c620,
>output_def=) at global-context-scheme.cc:146
> #17 0x005dcf00 in Score::book_rendering (this=0xaf4ef0,
>layoutbook=0xdb3150, default_def=0xc29f50) at score.cc:155
> #18 0x0045e324 in Book::process_score (this=,
>s=, output_paper_book=0xce27a0, layout=)
>at book.cc:236
> #19 0x0045e561 in Book::process (this=0xc241d0,
>default_paper=, default_layout=0xc29f50, parent_part=0x0)
>at book.cc:302
> #20 0x0045e71b in Book::process (this=,
>default_paper=, default_layout=)
>at book.cc:207
> #21 0x0045f013 in ly_book_process (book_smob=0x702766d0,
>default_paper=0x703c0aa0, default_layout=0x705b47a0,
>output=0x73568b60) at book-scheme.cc:76
> #22 0x77b2bdcf in scm_dapply () from /usr/lib/libguile.so.17
> #23 0x77b2d4cb in ?? () from /usr/lib/libguile.so.17
> #24 0x77b2be77 in scm_dapply () from /usr/lib/libguile.so.17
> #25 0x006adf6d in yyparse (parser=0x9dbda0) at parser.yy:592
> #26 0x006b5959 in Lily_parser::do_yyparse (this=)
>at parser.yy:3178
> #27 0x0050ed7b in Lily_parser::parse_file (this=0x9dbda0, init=...,
>name=, out_name=) at lily-parser.cc:124
> #28 0x00514b11 in ly_parse_file (name=)
>at lily-parser-scheme.cc:121
> #29 0x77b2d816 in ?? () from /usr/lib/libguile.so.17
> #30 0x77b2be77 in scm_dapply () from /usr/lib/libguile.so.17
> #31 0x77b84903 in scm_c_catch () from /usr/lib/libguile.so.17
> #32 0x77b84b0e in scm_catch_with_pre_unwind_handler ()
>   from /usr/lib/libguile.so.17
> #33 0x77b2bdcf in scm_dapply () from /usr/lib/libguile.so.17
> #34 0x77b2d4cb in ?? () from /usr/lib/libguile.so.17
> #35 0x77b2cb0c in ?? () from /usr/lib/libguile.so.17
> #36 0x77b2be77 in scm_dapply () from /usr/lib/libguile.so.17
> #37 0x721c9fd1 in scm_srfi1_for_each ()
>   from /usr/lib/libguile-srfi-srfi-1-v-3.so
> #38 0x77b2d6aa in ?? () from /usr/lib/libguile.so.17
> #39 0x77b2cb0c in ?? () from /usr/lib/libguile.so.17
> #40 0x77b2d343 in ?? () from /usr/lib/libguile.so.17
> #41 0x77b2be77 in scm_dapply () from /usr/lib/libguile.so.17
> #42 0x005268d2 in main_with_guile () at main.cc:440
> #43 0x77b475cf in ?? () from /usr/lib/libguile.so.17
> #44 0x77b1e16a in ?? () from /usr/lib/libguile.so.17
> #45 0x77b84903 in scm_c_catch () from /usr/lib/libguile.so.17
> #46 0x77b1e6f7 in scm_i_with_continuation_barrier ()
>   from /usr/lib/libguile.so.17
> #47 0x77b1e790 in scm_c_with_continuation_barrier ()
>   from /usr/lib/libguile.so.17
> #48 0x77b82db

Re: modern-straight-flag

[m...@apollinemike.com]

On Jan 2, 2012, at 1:55 PM, Karim Haddad wrote:

> 
> Hi,
> 
> I don't think this was reported. But in the latest dev version it appears
> that \override Stem #'flag = #modern-straight-flag is not working anymore
> ?
> version : 2.15.23-1
> MacosX 10.6.x
> 

Hey Karim,

It should be Flag #'stencil = #modern-straight-flag

Lemme know if there is a doc error in the devel version & I'll sort it out.

Also, you should be able to run convert-ly to get this property updated 
automatically.

Cheers,
MS


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

Re: Issue 1933 in lilypond: Lilypond-book requires msvcrt again

[m...@apollinemike.com]

On Jan 4, 2012, at 6:53 PM, Trevor Daniels wrote:

> Carl
> 
> Thanks for looking at this.  A month or so ago my laptop broke and I now have 
> a new one, with nominally the same OS (Windows Vista) but at a different 
> level.  I haven't tried lilypond-book since then, so I've just downloaded 
> 2.15.23 to try again.  I now get:
> 
> lilypond-book.py (GNU LilyPond) 2.15.23
> Reading C:/Users/Trevor/LilyPond-git/Documentation/notation/pitches.itely...
> Running texi2pdf on file c:\users\trevor\appdata\local\temp\tmpmpi_hh.texi to 
> detect default page settings.
> 
> Traceback (most recent call last):
> File "c:/program files/lilypond/usr/bin/lilypond-book.py", line 739, in ? 
> main ()
> File "c:/program files/lilypond/usr/bin/lilypond-book.py", line 722, in main 
> chunks = do_file (files[0])
> File "c:/program files/lilypond/usr/bin/lilypond-book.py", line 595, in 
> do_file
>   global_options.formatter.init_default_snippet_options (source)
> File "out/book_texinfo.py", line 279, in init_default_snippet_options
> File "out/book_texinfo.py", line 213, in get_texinfo_width_indent
> File "c:\Program Files\LilyPond\usr\lib\python2.4\subprocess.py", line 549, 
> in __init__
>   self.stdout = os.fdopen(c2pread, 'rU', bufsize)
> OSError: [Errno 22] Invalid argument
> Lilypond-book returned code 1
> 
> so something has changed since I reported the error last Sept.  I suspect 
> this check to detect default page settings is new - I don't recall seeing it 
> before.  So lilypond-book in 2.15.23 doesn't seem to get as far as entering 
> subprocess which is the first place msvcrt is called.
> 
> Trevor
> 

Hey Trevor,

Could you put a pretty print above this line in subprocess.py to the tune of :

print c2pread, bufsize

just to see what is being passed to it?

Cheers,
MS


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

Re: Issue 1948 in lilypond: Windows install clobbered system PATH

[m...@apollinemike.com]

On Jan 4, 2012, at 8:17 PM, Keith OHara wrote:

> On Tue, 03 Jan 2012 10:10:55 -0800,  wrote:
> 
>> Comment #13 on issue 1948 by PhilEHolmes: Windows install clobbered system
>> http://code.google.com/p/lilypond/issues/detail?id=1948
>> 
>> OK - it looks like there is nsis code designed to delete the extra entry in
>> the path statement, but it's not working AFAICS.  I need GUB to be running
>> to test this.
> 
> The only thing I see wrong is a trailing ';' in the search for the entry, 
> which character will not be the LilyPond entry is last in the list.
> 
> And then again a couple lines down when computing how many characters to 
> delete, and then if LilyPond was *not* last that could leave a pair of ";;" 
> one of which could be removed.
> 
> I thought it wisest to have the installer stop touching Windows paths at all, 
> but if you and Mike and others can take the time to do better, that' would be 
> better.
> 

I'll just make it clear that I have no clue what I'm doing - I'm just throwing 
out possible solutions.

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

Re: Issue 1933 in lilypond: Lilypond-book requires msvcrt again

[m...@apollinemike.com]

On Jan 4, 2012, at 7:15 PM, m...@apollinemike.com wrote:

> On Jan 4, 2012, at 6:53 PM, Trevor Daniels wrote:
> 
>> Carl
>> 
>> Thanks for looking at this.  A month or so ago my laptop broke and I now 
>> have a new one, with nominally the same OS (Windows Vista) but at a 
>> different level.  I haven't tried lilypond-book since then, so I've just 
>> downloaded 2.15.23 to try again.  I now get:
>> 
>> lilypond-book.py (GNU LilyPond) 2.15.23
>> Reading C:/Users/Trevor/LilyPond-git/Documentation/notation/pitches.itely...
>> Running texi2pdf on file c:\users\trevor\appdata\local\temp\tmpmpi_hh.texi 
>> to detect default page settings.
>> 
>> Traceback (most recent call last):
>> File "c:/program files/lilypond/usr/bin/lilypond-book.py", line 739, in ? 
>> main ()
>> File "c:/program files/lilypond/usr/bin/lilypond-book.py", line 722, in main 
>> chunks = do_file (files[0])
>> File "c:/program files/lilypond/usr/bin/lilypond-book.py", line 595, in 
>> do_file
>> global_options.formatter.init_default_snippet_options (source)
>> File "out/book_texinfo.py", line 279, in init_default_snippet_options
>> File "out/book_texinfo.py", line 213, in get_texinfo_width_indent
>> File "c:\Program Files\LilyPond\usr\lib\python2.4\subprocess.py", line 549, 
>> in __init__
>> self.stdout = os.fdopen(c2pread, 'rU', bufsize)
>> OSError: [Errno 22] Invalid argument
>> Lilypond-book returned code 1
>> 
>> so something has changed since I reported the error last Sept.  I suspect 
>> this check to detect default page settings is new - I don't recall seeing it 
>> before.  So lilypond-book in 2.15.23 doesn't seem to get as far as entering 
>> subprocess which is the first place msvcrt is called.
>> 
>> Trevor
>> 
> 
> Hey Trevor,
> 
> Could you put a pretty print above this line in subprocess.py to the tune of :
> 
> print c2pread, bufsize
> 
> just to see what is being passed to it?
> 
> Cheers,
> MS
> 

Question for Reinhold:

In 55aad8c485e14d29d78eddc0782a5e9901c6bf2c, you added a command to set LC_ALL. 
 This seems like POSIX-friendly syntax - are you sure it works on Windows?

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

Re: Issue 1933 in lilypond: Lilypond-book requires msvcrt again

[m...@apollinemike.com]

On Jan 6, 2012, at 10:49 PM, Trevor Daniels wrote:

> 
>> Comment #13 on issue 1933 by m...@apollinemike.com: Lilypond-book requires
>> msvcrt again
>> http://code.google.com/p/lilypond/issues/detail?id=1933
>> 
>> I think I may have found a one-stop-shopping solution to most of these 
>> problems:
>> 
>> http://python-mingw.donbennett.org:8081/mywiki/Installation
> 
> Mike
> 
> This seems to use a version of subprocess.py which works only under MinGW, 
> not in Windows command box.  And msvcrt seems not to be included anyway. Why 
> do you think this will solve the problem?
> 

Ah, ok, sorry.  I didn't understand that.  I had read the testimonials and it 
compiled clean, so I figured it was worth a try.
Back to the drawing board...

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

Re: Wrong placement of BreathingSign

[m...@apollinemike.com]

On Jan 9, 2012, at 1:20 PM, James wrote:

> hello,
> 
> On 9 January 2012 11:55, Thomas Morley  wrote:
>> With "2.14.2" and "2.15.2" the BreathingSign isn't positioned correct,
>> while using changed staff-size or (default) TabStaff.
>> 2.12.3-behaviour was accurate.
>> 
>> %\version "2.12.3"
>> \version "2.14.2"
>> %\version "2.15.20"
>> 
>> mel = { c'1 \breathe }
>> 
>> \score {
>>   <<
>>   \new Staff\with {
>>   fontSize = #-4
>>   \override StaffSymbol #'staff-space = #(magstep -4)
>>   \override StaffSymbol #'thickness = #(magstep -4)
>>   }
>>   \mel
>> 
>>   \new Staff
>>   \mel
>> 
>>   \new TabStaff
>>   \mel
 
>> }
>> 
> 
> Added as http://code.google.com/p/lilypond/issues/detail?id=2205
> 
> @devs
> 
> Not sure if this is a 'critical', as while it is a regression, it is
> the same in current stable as it is in current dev (i.e. it was 'ok'
> in 2.12 but never was, it seems in 2.14).
> 
> So someone else needs to make that judgement if this blocks release or
> not and change the tracker accordingly

My vote is for making it critical - I think a regression from any stable 
version is a critical regression.  I don't think it's worth making a 2.14.X 
that includes a fix, but the regression should block 2.16.

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

Re: Wrong placement of BreathingSign

[m...@apollinemike.com]

Will do.

Cheers,
MS

On Jan 9, 2012, at 1:33 PM, Neil Puttock wrote:

> On 9 January 2012 12:27, Neil Puttock  wrote:
> 
>> Hmm, I guess this is my fault.  We had a bug with Y-offset positioning
>> when using custom staves, so I revised the offset-callback.
>> 
>> Will try to check it out later.
> 
> Oops, really bad thinko in Breathing_sign::offset_callback.
> 
> Real inter = Staff_symbol::staff_space (me) / 2;
> 
> should obviously be
> 
> Real inter = Staff_symbol::staff_space (staff) / 2;
> 
> Sorry. :)
> 
> I can't push at the moment.  Can somebody else fix this please?
> 
> Cheers,
> Neil
> 
> ___
> bug-lilypond mailing list
> bug-lilypond@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-lilypond


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

Re: Issue 2229 in lilypond: Patch: Broadcast articulations not in EventChord

[m...@apollinemike.com]

On Jan 18, 2012, at 1:28 PM, lilyp...@googlecode.com wrote:

> Updates:
>   Status: Started
> 
> Comment #6 on issue 2229 by d...@gnu.org: Patch: Broadcast articulations not 
> in EventChord
> http://code.google.com/p/lilypond/issues/detail?id=2229
> 
> Hi Mike,
> let me see whether I get this right.  The iterator is the entity converting a 
> music event into a stream event and broadcasting the latter.

Yup

> So the rhythmic-iterator would be responsible for "wild" rhythmic music 
> events (that currently can't occur since the parser wraps everything into 
> EventChord)

Yup

> and would dismantle their articulations, create a stream event from the music 
> event not containing articulations, and broadcast this stream event as well 
> as the stream events created from articulations.
> 

Yup

> When the EventChord iterator gets an EventChord music event, it would cater 
> for converting the contained rhythmic music events into stream events 
> containing articulation stream events, and broadcast those.  The rhythmic 
> event iterator would never get to see any of that.
> 

Yup

> So correct me if I am wrong: if we applied your patch to the current 
> LilyPond, the Rhythmic event iterator should not get to see any action except 
> possibly on synthesized music (where naked rhythmic event chords would have 
> their articulations work like chord articulations rather than chord 
> constituent articulations).

Yup

> 
> If (after changing the parser not to put EventChord on unnecessarily) we at 
> one time decided that c-. should not be equivalent to -. but to , 
> then we would just need to change the rhythmic music iterator.
> 

Yup

> If I got the details right, this sounds like it would indeed be a cleaner 
> solution.  Is there actually anything missing from your patch for doing the 
> whole job of this issue?
> 

Not that I know of (you'd have to use the most recent version of the patch - I 
just threw it up).

> The one thing I worry about is that some other iterator might have first 
> rights on the music events.  As you can easily guess, I have no clue in this 
> area.

Not for now.  If anyone ever changes this, several regtests will explode.

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

Re: ERROR: Unable to find file "ice-9/boot-9.scm" in load path

[m...@apollinemike.com]

On Jan 21, 2012, at 1:47 PM, Damian leGassick wrote:

> 
> On 21 Jan 2012, at 12:08, Damian leGassick wrote:
> 
>> Hi
>> 
>> I've seen this before and a search through the list says it was fixed in 2.14
>> 
>> just upgraded to 2.15.26 and i get
>> 
>> GNU LilyPond 2.15.26
>> ERROR: In procedure primitive-load-path:
>> ERROR: Unable to find file "ice-9/boot-9.scm" in load path
>> 
>> is there a simple fix for this? I've tried adding the ice-9 folder to the 
>> PATH
>> 
>> echo $PATH gives:
>> 
>> /usr/local/git/bin:/usr/texbin:/usr/X11/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/local/bin:/Applications/LilyPond.app/Contents/Resources/bin:/Applications/LilyPond.app/Contents/Resources/share/guile/1.8/ice-9:/usr/texbin
>> 
> 
> Ok - I get that it's I it's a guile error message
> 
> I added export 
> GUILE_LOAD_PATH="/Applications/LilyPond.app/Contents/Resources/share/guile/1.8"
>  to my .bash_profile
> 
> guile now launches in the terminal without the error, but lilypond still won't
> 
> Damian (btw, Mac OSX10.6.8)

Damian,

I've cc'ed my response to the bug list - this should be opened up as an issue 
on the tracker.
What would help a lot is if you added things to your PATH variable until 
LilyPond started working and let us know what the key addition(s) proved to be.
Also, make sure to open a new terminal window every time you modify 
.bash_profile (I'm not assuming that you are not doing this, but I forget to do 
this all the time, so I figured it was worth saying).

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

Re: Feature request: cross-staff chords

[m...@apollinemike.com]

On Jan 31, 2012, at 9:14 PM, Francisco Vila wrote:

> 2012/1/31 Pavel Roskin :
>>> Various users have requested the same in the past.
>> 
>> I know.  Perhaps it's time to have an issue in the bug tracker.
> 
> Definitely.
> 
>> Once there is an issue in the tracker, it should be possible to attach
>> bounties to it.
> 
> I would add an amount to that, for I'm interested in the feature.

Hey all,

I have a patch that implements a barebones version of this that I haven't 
tinkered with for some time because of the issue of NoteCollision grobs.

NoteCollision grobs shift notes around so that they do not collide.  They would 
assumedly need to do this for cross-staff note heads as well.  However, this 
poses a multi-staff problem when there are cross staff chords, especially when 
one needs to take collisions w/ the stem into account.

Another problem that arises is where to place the beam.  Cross-staff stems can 
cut across beams, so there'd need to be beam related code as well.

All if it is doable but difficult.  If you can wait till the summer, it is 
provisionally on my summer-of-lily 2012 list.

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

Re: Issue 2293 in lilypond: Patch: Gets rid of oval stencil

[m...@apollinemike.com]

On Feb 6, 2012, at 12:24 PM, Werner LEMBERG wrote:

>> 
>> New issue 2293 by mts...@gmail.com: Patch: Gets rid of oval stencil
>> http://code.google.com/p/lilypond/issues/detail?id=2293
>> 
>> Gets rid of oval stencil
>> 
>> http://codereview.appspot.com/5630064
> 
> LGTM, together with the other ones.  I suggest to apply such
> straightforward, mainly cosmetic changes without creating issues.
> 
> 
>Werner
> 

Ok, though I'd appreciate a sanity-check LGTM from patchy before going forward. 
 I want to make sure that I am not killing off a stencil that is buried 
somewhere in the code base I haven't looked.

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

Re: Cross-staff-glissando doesn't work any more

[m...@apollinemike.com]

On Feb 7, 2012, at 2:33 AM, Thomas Morley wrote:

> With "2.15.24" the cross-staff-glissando doesn't work any more.
> 2.14.2-output was ok.
> 
> \version "2.15.24"
> 
> \new PianoStaff <<
> \new Staff = "right" {
>   e'''2\glissando
>   \change Staff = "left"
> 
>   a,,\glissando
>   \change Staff = "right"
>   b''8
> }
> \new Staff = "left" {
>   \clef bass
>   s1 s8
> }
>>> 
> 
> Harm

Thanks.
Reported as http://code.google.com/p/lilypond/issues/detail?id=2301.

Cheers,
MS


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

Re: Issue 2338 in lilypond: OS X LilyPad not working

[m...@apollinemike.com]

On Mar 1, 2012, at 3:12 PM, lilyp...@googlecode.com wrote:

> 
> Comment #28 on issue 2338 by colingh...@gmail.com: OS X LilyPad not working
> http://code.google.com/p/lilypond/issues/detail?id=2338
> 
> Right. I'll contact Christian and ask him to tar up his dev directory then.
> 
> Otherwise, is my outline of the work involved to get to a patch correct?
> 

Yup - the idea is that we want grahms fork of LilyPad to produce a reliable 
LilyPad from scratch.

I think it's worth it to do this to get 2.16 out.  Afterwards, we should do 
some brainstorming about better ways to package manage.  For example, brew has 
a lilypond OS X port of the stable version and jEdit can be used.  If these 
become the "Mac OS X" instructions on the webpage, people will actually get a 
better UI than if they download what we bundle.  It then becomes necessary that 
developer resources be spent on maintaining these packages, but it seems like 
this is a better (and more decentralized) use of our time than maintaining a 
GUI text editor.

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