date:20110107

On Thu, Jan 6, 2011 at 3:16 PM, Phil Holmes  wrote:
> Here's the file itself.

Good news, very good news, and bad news.

1. your patch is fine.
2. you're not crazy.  I've reproduced the error in lilydev with current git.
3. I haven't solved the problem yet.  Interestingly, there's
absolutely no problem with current git; I've compiled it a couple of
times (both from a clean checkout, and from a previously-compiled
state) on my normal machine.

The fact that ubuntu 10.04 native can compile git, but ubuntu 10.04
virtualized cannot, is not a good sign.  But at least I'm seeing the
same thing, so I can solve it.

Cheers,
- Graham

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

Re: german website problems

On Fri, Jan 7, 2011 at 4:59 AM, Graham Percival
 wrote:
> On Thu, Jan 06, 2011 at 07:25:48PM +0200, Till Paala wrote:
>> It appears strange to me to get suddenly this kind of errors when I
>> didn't do changes,
>
> I only check once every couple of months.  It might have broken
> last October (or even earlier).

Never mind, I found it while working on the lilydev doc compile problem.

It was broken by:
a7e8fad984c0450b3ae2818cfbccfdbba00a55e4
on 2010-12-29.  There was a @warning{} in
Documentation/de/included/helpus.itexi
which you did not close the }.

Fixing that one } cleaned up all the other errors as well.

Cheers,
- Graham

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

Re: Fix 1464 (segfault with R1 and metronome) (issue3858041)

2011-01-07 Thread percival . music . ca


Any other comments about this?  I'm aware of some discussion here about
get_parent:
http://lists.gnu.org/archive/html/lilypond-devel/2011-01/msg00057.html
http://lists.gnu.org/archive/html/lilypond-devel/2011-01/msg00055.html

is this a reason not to accept the patch as it currently stands?  As far
as I can tell, the patch is "good enough", and this would fix a Critical
issue, so my inclination would be to push it.

http://codereview.appspot.com/3858041/

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

Re: german website problems

2011-01-07 Thread Till Paala


Am 07.01.11 10:46, schrieb Graham Percival:

On Fri, Jan 7, 2011 at 4:59 AM, Graham Percival
  wrote:

On Thu, Jan 06, 2011 at 07:25:48PM +0200, Till Paala wrote:

It appears strange to me to get suddenly this kind of errors when I
didn't do changes,

I only check once every couple of months.  It might have broken
last October (or even earlier).

Never mind, I found it while working on the lilydev doc compile problem.

It was broken by:
a7e8fad984c0450b3ae2818cfbccfdbba00a55e4
on 2010-12-29.  There was a @warning{} in
Documentation/de/included/helpus.itexi
which you did not close the }.


Fixing that one } cleaned up all the other errors as well.

Cheers,
- Graham


Great, that saved me a lot of investigation work!

Thanks!
Till

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

Re: Correct convert-ly of page spacing (issue3793046)

2011-01-07 Thread k-ohara5a5a


New patch set is up.



you're changing the rules for the 2.13.10 conversion?
...  but I guess it makes sense in this case.


so that older files which have not yet been through convert-ly get the
affected variables converted to staff-spaces.

A couple reg-tests already got convert-ly-marked >2.13.10, so I update
them by hand in this patch.

http://codereview.appspot.com/3793046/

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

Re: mensural notation improvements (issue3797046)

> if it helps to confirm that you are right, I might add my own experience
> with mensural sources. Composers/writers seem to literally avoid dotted
> notes in ligatures except (a) at the end of the ligature, or (b) on top
> of the first note of an obliqua, or (c) both.  (a) and (b) are frequent,
> and there are numerous examples. There are some for (c), e.g. the Eton
> Choirbook that Pál quoted, or Apel, page 471.

yes; generally there's seldom need to dot a long note, regardless of
being in or outside a ligature.

> Sometimes, (d) a dotted first note of a non-obliqua ligature can be
> found with the dot on the right of the note. This is usually an
> ascending ligatura cum opposita proprietate (as in Pál's examples, or
> Apel, p. 181, or p. 138 for a semi-coloured one).

(btw in the Chigi example there's a dotted first breve in the penultimate
staff of the right side.)

> I have never seen this
> with a descending ligature, and I would be interested if you found an
> example.

seems to be a busy weekend, but I hope I can get to it.

> I don't know any sources that comply with Apel's dot-above rule, but
> then again, Apel probably saw more sources than I ever will...

or me, too.  and I learnt mensural notation solely from Apel.

> Sometimes I have been confused by a punctus divisionis placed in the
> middle above a ligature, but of course that's something different.

wow, I have never seen such a thing!  could you give an example?

p

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

Text at linebreaks

Another one of my noobie early questions was about long text markup being 
lost over the edge of the page when it was at the end of a line.  I was 
advised to check the learning manual and duly found section 4.6.5 where it 
advises that you can use:


\override PaperColumn #'keep-inside-line = ##t
\override NonMusicalPaperColumn #'keep-inside-line = ##t

to avoid this, at the penalty of performance.  I now have these 2 lines in 
my Lily source the whole time.  However, I've just tried compiling a 500 
bar, 30 page, 19 voice piece of music and compared the processor time with 
and without those lines.  485.6 seconds with them, 484.6 seconds with - a 
whole 0.2%.  So there's really no performance penalty to speak of.  I 
propose an enhancement to change the default and update the Learning manual 
since this will make Lily compile beautiful music with beautiful markup by 
default with no penalty.


--
Phil Holmes
Bug Squad




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

Re: Text at linebreaks

On Fri, Jan 07, 2011 at 09:48:09AM -, Phil Holmes wrote:
> to avoid this, at the penalty of performance.  I now have these 2
> lines in my Lily source the whole time.  However, I've just tried
> compiling a 500 bar, 30 page, 19 voice piece of music and compared
> the processor time with and without those lines. 485.6 seconds with
> them, 484.6 seconds with - a whole 0.2%.  So there's really no
> performance penalty to speak of.

How many markups and \mark do you have?  I mean, did you add a
whole bunch of them to the score?  Also, how long are they?  Were
they all short "espr." or did you have some
"this is an artifically long text script" in there?  I would
imagine that the latter would cause more problems for the musical
layout, and thus would impact performance more.

Cheers,
- Graham

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

Re: Text at linebreaks

- Original Message - 
From: "Graham Percival" 

To: "Phil Holmes" 
Cc: 
Sent: Friday, January 07, 2011 10:08 AM
Subject: Re: Text at linebreaks

On Fri, Jan 07, 2011 at 09:48:09AM -, Phil Holmes wrote:

to avoid this, at the penalty of performance.  I now have these 2
lines in my Lily source the whole time.  However, I've just tried
compiling a 500 bar, 30 page, 19 voice piece of music and compared
the processor time with and without those lines. 485.6 seconds with
them, 484.6 seconds with - a whole 0.2%.  So there's really no
performance penalty to speak of.

How many markups and \mark do you have?  I mean, did you add a
whole bunch of them to the score?  Also, how long are they?  Were
they all short "espr." or did you have some
"this is an artifically long text script" in there?  I would
imagine that the latter would cause more problems for the musical
layout, and thus would impact performance more.

Cheers,
- Graham

It was just a normal score - the Finale of Act I of The Gondoliers.  And 
this is part of the point - it may be that you can construct a test file 
that would impact performance more, but why bother?  On a normal score with 
performers names, tempo indications, etc., as textual markings, there's 
essentially no performance hit.  However, the annoyance of the text flowing 
over the end of a line plus the research to fix it plus the recompile taking 
500 times longer than the actual hit means this should be changed.  We don't 
allow notes to collide as a matter of course to save time, with a note in 
the Learning manual that you can move all the notes.  Why do we allow 
something worse to happen with text?

--
Phil Holmes

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

Re: Text at linebreaks

On Fri, Jan 07, 2011 at 10:53:41AM -, Phil Holmes wrote:
> It was just a normal score - the Finale of Act I of The Gondoliers.
> And this is part of the point - it may be that you can construct a
> test file that would impact performance more, but why bother?  On a
> normal score with performers names, tempo indications, etc., as
> textual markings, there's essentially no performance hit.

Ok, good point.  Perhaps the various changes since 2005 have
either improved the text placement, or require more processing
such that the text placement doesn't cause a significant
difference in performance.

This might be a good time for somebody to figure out other
time-saving methods -- I know that there's something you can do
with the page breaking to improve performance, but AFAIK it's
never trickled its way into the "speeding up performance" part of
Learning.

I'd quite like to go with a "default good output; optional poor
output but faster processing" policy.

Cheers,
- Graham

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

Re: Text at linebreaks

- Original Message - 
From: "Graham Percival" 

To: "Phil Holmes" 
Cc: 
Sent: Friday, January 07, 2011 11:01 AM
Subject: Re: Text at linebreaks

On Fri, Jan 07, 2011 at 10:53:41AM -, Phil Holmes wrote:

It was just a normal score - the Finale of Act I of The Gondoliers.
And this is part of the point - it may be that you can construct a
test file that would impact performance more, but why bother?  On a
normal score with performers names, tempo indications, etc., as
textual markings, there's essentially no performance hit.

Ok, good point.  Perhaps the various changes since 2005 have
either improved the text placement, or require more processing
such that the text placement doesn't cause a significant
difference in performance.

This might be a good time for somebody to figure out other
time-saving methods -- I know that there's something you can do
with the page breaking to improve performance, but AFAIK it's
never trickled its way into the "speeding up performance" part of
Learning.

I'd quite like to go with a "default good output; optional poor
output but faster processing" policy.

Cheers,
- Graham

http://code.google.com/p/lilypond/issues/detail?id=1470

See the performance results there.  9% hit when every other line has 
over-flowing text.

--
Phil Holmes

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

Re: mensural notation improvements (issue3797046)

2011-01-07 Thread Robert Memering

Am 07.01.2011 10:17, schrieb Benkő Pál:
>> Sometimes I have been confused by a punctus divisionis placed in the
>> middle above a ligature, but of course that's something different.
> 
> wow, I have never seen such a thing!  could you give an example?

The only one I could find quickly is from Apel's facsimiles again: p.
192, 5th staff, quaternaria. (And, similarly, the binaria LB at the end
of the line)

Best regards,
Robert

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

Re: Text at linebreaks

2011-01-07 Thread Trevor Daniels



Graham Percival wrote Friday, January 07, 2011 11:01 AM



I'd quite like to go with a "default good output; optional poor
output but faster processing" policy.


+1

Trevor



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

RE: Can't compile docs

Hello,

From: lilypond-devel-bounces+james.lowe=datacore@gnu.org 
[lilypond-devel-bounces+james.lowe=datacore@gnu.org] on behalf of Graham 
Percival [gra...@percival-music.ca]
Sent: 07 January 2011 08:38
To: Phil Holmes
Cc: Lily devel
Subject: Re: Can't compile docs

On Thu, Jan 6, 2011 at 3:16 PM, Phil Holmes  wrote:
> Here's the file itself.

Good news, very good news, and bad news.

1. your patch is fine.
2. you're not crazy.  I've reproduced the error in lilydev with current git.
3. I haven't solved the problem yet.  Interestingly, there's
absolutely no problem with current git; I've compiled it a couple of
times (both from a clean checkout, and from a previously-compiled
state) on my normal machine.

The fact that ubuntu 10.04 native can compile git, but ubuntu 10.04
virtualized cannot, is not a good sign.  But at least I'm seeing the
same thing, so I can solve it.

-

I noticed yesterday that the Update Manager for LilyDev reported some 
fixes/updates for git-core and gitk.

One thing that does come to mind here and that is resources of the VM/VM Host.

I seem to remember that in some odd cases I would get 'read/write' errors on a 
directory while building docs. I also know that some linux distributions will 
go into read-only mode when IO is 'too much' for the kernel or the resources (I 
use the term loosely) are high - I see this often in my job, although I don't 
support linux I have to touch most different OSs daily in some shape or form 
and get feedback from many users.

So knowing that, I simply upped my RAM allocation of my VM by another GB and 
did another make; make-doc (not even a make clean) and things worked and I 
haven't had such problems since.

I realise this is anecdotal, but as I also know our doc build process is shall 
we say, highly-strung so often I will try some 'turn it off and turn it on 
again' method before I ask for help.

Also Phil if you haven't realised already you can sometimes make use of 
Snapshots with Virtual Box, once I get a clean doc build I take a snapshot and 
then I know I always have a last known good that I can roll back too and 
reapply a patch or edit to see if it was my mistake or something else.

Just my tuppence
James

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

make loses $(src-dir) part of $

Highly odd make behaviour here.  We seem to have a problem when
running "make doc" inside virtualbox lilydev.  Nobody (including
myself) has seen this problem in their normal lilypond development,
but I can reproduce it occasionally inside lilydev.

I've modified the top of my
  make/doc-i18n-root-rules.make
to be:
$(outdir)/%.texi: $(src-dir)/%.texi
echo "zzz"
echo $(src-dir)
cp -p $< $@

(I added the echos)

My build log now contains:
...
echo "zzz"
zzz
echo /home/lily/lilypond-git/Documentation/es
/home/lily/lilypond-git/Documentation/es
cp -p /home/lily/lilypond-git/Documentation/es/web.texi out-www/web.texi
...
echo "zzz"
zzz
echo /home/lily/lilypond-git/Documentation/fr
/home/lily/lilypond-git/Documentation/fr
cp -p web.texi out-www/web.texi
cp: cannot stat `web.texi': No such file or directory


note that the second cp does *not* include the $(src-dir) portion.

I'm baffled.  I can't see any important difference in the
de/GNUmakefile fr/GNUmakefile es/GNUmakefile... but looking at this
rule, I can't see how any difference in those files would make any
difference.  Something weird is happening between $(src-dir) and $<

Any thoughts?

Cheers,
- Graham

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

Re: make loses $(src-dir) part of $

On Fri, Jan 7, 2011 at 12:24 PM, Graham Percival
 wrote:
> Highly odd make behaviour here.  We seem to have a problem when

Forgot to mention:
- running "make doc", i.e. no -j options.
- system has a single virtualized CPU
- 3.6 gigs free out of 7.5 gigs
- I just tried a new build, and it completed fr/ and it/ with no
problems.  (i.e. the missing directory is no longer missing)
- I wasn't watching memory usage when it died, but at the moment it's
under 40% of 1024 megs.

Cheers,
- Graham

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

RE: Black mensural notation

hello,


From: lilypond-devel-bounces+james.lowe=datacore@gnu.org 
[lilypond-devel-bounces+james.lowe=datacore@gnu.org] on behalf of James 
Lowe [james.l...@datacore.com]
Sent: 07 January 2011 13:03
To: Lukas Pietsch; lilypond-devel@gnu.org
Subject: RE: Black mensural notation

Lukas (although for some reason I am getting bounces from your email address so 
I hope you are reading this on the lists)!
---

Is anyone else getting


10.mx.freenet.de rejected your message to the following e-mail addresses:

Lukas Pietsch (lukas.piet...@freenet.de)

10.mx.freenet.de gave this error:
inconsistent or no DNS PTR record for 173.221.96.141 (see RFC 1912 2.1)


...

--

after replying to Lukas' email? I hope Lukas can see these messages otherwise.

James

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

RE: Black mensural notation

2011-01-07 Thread Lukas Pietsch

On Fri, 2011-01-07 at 13:08 +, James Lowe wrote:

>  
> I ran this with 2.13.45 and it compiles with some warnings (see
> attached zip of log file).
>  
> However, this is wonderful stuff!
>  
> Also your PDF is very informative and it would be nice to incorporate
> this into our own Notation Reference at some point, if at all possible
> - I can help with that if you need to.
>  
> James
> 

Thanks a lot! As for the warnings, I too was getting the "cannot align
on self: empty element" ones, and found no way of getting rid of them.
Maybe it's something to do with Lilypond not liking the way I removed
the standard stems and flags, because it seems to be trying to align
something with something else that isn't there, for each notehead it has
to process. The "cannot find property type-check for `beatLength'" and
`beatGrouping' warnings seem to be new. Were these properties recently
renamed or something? They seemed to be a standard part of how bars were
defined in the version I had.

As for how to proceed from here, I'm not quite sure, since "my" system
now stands rather outside the normal architecture and its development
process, and since consolidating it further would probably duplicate
some of the work Pál has been doing on the white notation. Probably the
most elegant thing would be if it was possible to merge some of the
logic of my ligature processing (with the plicas, pes shapes and
currentes) into the standard ligature engraver Pál has been improving?
But for that, I'd need somebody to help me with integrating the black
glyph primitives into the standard font system and make them accessible
from the normal engravers. I can't say I've really understood much of
that architecture yet.

Lukas

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

Re: Black mensural notation




On 1/7/11 7:00 AM, "Lukas Pietsch"  wrote:

> On Fri, 2011-01-07 at 13:08 +, James Lowe wrote:
> 
>> 
>> I ran this with 2.13.45 and it compiles with some warnings (see
>> attached zip of log file).
>> 
>> However, this is wonderful stuff!
>> 
>> Also your PDF is very informative and it would be nice to incorporate
>> this into our own Notation Reference at some point, if at all possible
>> - I can help with that if you need to.
>> 
>> James
>> 
> 
> Thanks a lot! As for the warnings, I too was getting the "cannot align
> on self: empty element" ones, and found no way of getting rid of them.
> Maybe it's something to do with Lilypond not liking the way I removed
> the standard stems and flags, because it seems to be trying to align
> something with something else that isn't there, for each notehead it has
> to process. The "cannot find property type-check for `beatLength'" and
> `beatGrouping' warnings seem to be new. Were these properties recently
> renamed or something? They seemed to be a standard part of how bars were
> defined in the version I had.

beatLength and beatGrouping have gone away in 2.13.  They are replaced
(mostly) by baseMoment and beatStructure.


> 
> As for how to proceed from here, I'm not quite sure, since "my" system
> now stands rather outside the normal architecture and its development
> process, and since consolidating it further would probably duplicate
> some of the work Pál has been doing on the white notation. Probably the
> most elegant thing would be if it was possible to merge some of the
> logic of my ligature processing (with the plicas, pes shapes and
> currentes) into the standard ligature engraver Pál has been improving?
> But for that, I'd need somebody to help me with integrating the black
> glyph primitives into the standard font system and make them accessible
> from the normal engravers. I can't say I've really understood much of
> that architecture yet.

I'd be happy to help you integrate the glyph primitives into the
standard font.  I'm not sure how much help I can be in the process of
integrating the glyph primitives into ligatures.

Thanks,

Carl


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

Re: Black mensural notation

2011-01-07 Thread Karl Hammar

James Lowe:
...
> Lukas (although for some reason I am getting bounces from your email address 
> so I hope you are reading this on the lists)!

Lukas cannot do anything about this except changing mail provider.

The mailing list should be fine.

You can do something by making sure the sending mailserver ip-number
and dns name points back to each other, ask your mail- and dnsadmin.

> Is anyone else getting
> 
> 
> 10.mx.freenet.de rejected your message to the following e-mail addresses:
> 
> Lukas Pietsch (lukas.piet...@freenet.de)
> 
> 10.mx.freenet.de gave this error:
> inconsistent or no DNS PTR record for 173.221.96.141 (see RFC 1912 2.1)

 Yes, freenet.de only accepts mail from mail-servers with a valid 
 reverse pointer.

 If I like to find out who 172.221.96.141 is, I can do:

$ host -t ptr 173.221.96.141
141.96.221.173.in-addr.arpa domain name pointer cas-ftl1.datacore.com.
$

 But cas-ftl1.datacore.com doesn't poin back to the same number:

$ host cas-ftl1.datacore.com.
cas-ftl1.datacore.com has address 205.237.192.88
$

Regards,
/Karl Hammar

---
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57



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

Re: Black mensural notation

2011-01-07 Thread Lukas Pietsch

On Fri, 2011-01-07 at 07:10 -0700, Carl Sorensen wrote:
> > 
> > Thanks a lot! As for the warnings, I too was getting the "cannot align
> > on self: empty element" ones, and found no way of getting rid of them.
> > Maybe it's something to do with Lilypond not liking the way I removed
> > the standard stems and flags, because it seems to be trying to align
> > something with something else that isn't there, for each notehead it has
> > to process. The "cannot find property type-check for `beatLength'" and
> > `beatGrouping' warnings seem to be new. Were these properties recently
> > renamed or something? They seemed to be a standard part of how bars were
> > defined in the version I had.
> 
> beatLength and beatGrouping have gone away in 2.13.  They are replaced
> (mostly) by baseMoment and beatStructure.
> 
Ah, I see. Which means maintaining a scheme function that redefines bar
structures in a way that is compatible with all current versions might
be rather difficult? (Okay, bar structures may not be of the highest
priority for making the thing work, because for most purposes they
should remain invisible anyway, but currently I think there's still
something about the horizontal spacing that is sensitive to where the
assumed underlying bar lines are.)

> > 
> > As for how to proceed from here, I'm not quite sure, since "my" system
> > now stands rather outside the normal architecture and its development
> > process, and since consolidating it further would probably duplicate
> > some of the work Pál has been doing on the white notation. Probably the
> > most elegant thing would be if it was possible to merge some of the
> > logic of my ligature processing (with the plicas, pes shapes and
> > currentes) into the standard ligature engraver Pál has been improving?
> > But for that, I'd need somebody to help me with integrating the black
> > glyph primitives into the standard font system and make them accessible
> > from the normal engravers. I can't say I've really understood much of
> > that architecture yet.
> 
> I'd be happy to help you integrate the glyph primitives into the
> standard font.  I'm not sure how much help I can be in the process of
> integrating the glyph primitives into ligatures.
> 
Great! I'm not sure when I might find time for again working
substantially on this, but perhaps you could start by giving me some
pointers about what input format we'd need to define those glyphs? I
currently have Postscript and SVG representations of them.

Lukas



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

Re: Fix Issue 1290 (issue3832046)

2011-01-07 Thread Carl . D . Sorensen


I've added comments about the need for the horizontal-padding in the
distance call to be used with System grobs, and I've moved the
skyline-horizontal-padding from an override to a default value for the
System grob.

I think this should make everything work right out of the box now,
without
requiring overrides.

Any further comments?

Thanks,

Carl


http://codereview.appspot.com/3832046/

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

Re: Black mensural notation

hi all,

> As for how to proceed from here, I'm not quite sure, since "my" system
> now stands rather outside the normal architecture and its development
> process, and since consolidating it further would probably duplicate
> some of the work Pál has been doing on the white notation. Probably the
> most elegant thing would be if it was possible to merge some of the
> logic of my ligature processing (with the plicas, pes shapes and
> currentes) into the standard ligature engraver Pál has been improving?
> But for that, I'd need somebody to help me with integrating the black
> glyph primitives into the standard font system and make them accessible
> from the normal engravers. I can't say I've really understood much of
> that architecture yet.

I will work on the ligature stuff, but I'm quite slow;
regarding other shapes, I have to look very thoroughly
through the existing gregorian support and your stuff.
What I like best are the Ars subtilior flags; however,
that is a part which confuses me quite a bit.  In particular,
what I've added as coloratio / black mensural notation
support is really just the heads, the flagging must be
hacked around as I wrote in
http://lists.gnu.org/archive/html/lilypond-devel/2010-11/msg00212.html

regards,
p

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

[Patch] Fix for Issue 879

I believe the attached patch fixes issue 879.  Don't think it's a big deal, 
but it was flagged as a frog task so I thought I'd contribute.  I have run 
my own regtest checker against the regtests and there were no differences. 
Please could someone with git access check and push if it's OK.


--
Phil Holmes
Bug Squad



0001-Fix-for-879.patch
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Potential fix for issue 37

2011-01-07 Thread Werner LEMBERG


> I'm not exactly sure what the desired output would be for issue 37,
> but my code assumes that if there are collision problems, flat beams
> look best.

+1


Werner

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

Re: Fix Issue 1290 (issue3832046)

2011-01-07 Thread joeneeman



http://codereview.appspot.com/3832046/diff/2001/lily/skyline.cc
File lily/skyline.cc (right):

http://codereview.appspot.com/3832046/diff/2001/lily/skyline.cc#newcode396
lily/skyline.cc:396: if ((i->slope_ == 0) && !isinf (i->y_intercept_) &&
i->y_intercept_ >= 0)
On 2011/01/03 03:48:09, Carl wrote:

On 2011/01/02 05:19:58, joeneeman wrote:
> Why restrict to y_intercept_ < 0?
  Because if I have a y intercept that is less than zero, and create a

box with

that y intercept, the padded skyline comes out with all zero heights.

I don't

know why it works that way, but it does.


That's very strange. Do you have an example file that triggers this
behaviour?


I tried several things to get it to behave differently, but was

unsuccessful.

And I don't think that a negative skyline will ever be limiting in

inter-system

spacing, so I didn't feel that it was a problem.


Probably not, but I still feel that it's bad to have methods with
strange corner cases. At the very least, there should be a comment
explaining that the distance function will throw away any constraints
with negative height.

http://codereview.appspot.com/3832046/diff/27001/lily/skyline.cc#newcode391
lily/skyline.cc:391: {
I still don't understand why this function is so complicated. Does this
not work?

Real start = -infinity_f;
vector boxes;
list::const_iterator end = src.buildings_.end ();
for (list::const_iterator i = src.buildings_.begin (); i !=
end; sta
 rt=i->end_, i++)
  if ((i->slope_ == 0) && !isinf (i->y_intercept_))
boxes.push_back (Box (Interval (start, i->end_),
  Interval (-infinity_f, i->y_intercept_)));

buildings_ = internal_build_skyline (&boxes, horizon_padding, X_AXIS,
UP);
sky_ = src.sky_;

By the way, the above code (and your version also) will break if we
every switch to using more accurate outlines for grobs (ie. more
accurate than bounding boxes) because it could be throwing away
interesting things when it discards non-horizontal segments.

http://codereview.appspot.com/3832046/diff/27001/lily/skyline.cc#newcode419
lily/skyline.cc:419: Axis vert_axis = other_axis (horizon_axis);
This should have X_AXIS instead of "a", because you put the horizon axis
into the X_AXIS of your boxes.

http://codereview.appspot.com/3832046/

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

Re: Fix Issue 1290 (issue3832046)




On 1/7/11 9:47 AM, "joenee...@gmail.com"  wrote:

> 
> 
> http://codereview.appspot.com/3832046/diff/2001/lily/skyline.cc
> File lily/skyline.cc (right):
> 
> http://codereview.appspot.com/3832046/diff/2001/lily/skyline.cc#newcode396
> lily/skyline.cc:396: if ((i->slope_ == 0) && !isinf (i->y_intercept_) &&
> i->y_intercept_ >= 0)
> On 2011/01/03 03:48:09, Carl wrote:
>> On 2011/01/02 05:19:58, joeneeman wrote:
>>> Why restrict to y_intercept_ < 0?
>>   Because if I have a y intercept that is less than zero, and create a
> box with
>> that y intercept, the padded skyline comes out with all zero heights.
> I don't
>> know why it works that way, but it does.
> 
> That's very strange. Do you have an example file that triggers this
> behaviour?

The regression test file in the patch triggers this behavior.

> 
>> I tried several things to get it to behave differently, but was
> unsuccessful.
>> And I don't think that a negative skyline will ever be limiting in
> inter-system
>> spacing, so I didn't feel that it was a problem.
> 
> Probably not, but I still feel that it's bad to have methods with
> strange corner cases. At the very least, there should be a comment
> explaining that the distance function will throw away any constraints
> with negative height.
> 
> http://codereview.appspot.com/3832046/diff/27001/lily/skyline.cc#newcode391
> lily/skyline.cc:391: {
> I still don't understand why this function is so complicated. Does this
> not work?
> 
> Real start = -infinity_f;
> vector boxes;
> list::const_iterator end = src.buildings_.end ();
> for (list::const_iterator i = src.buildings_.begin (); i !=
> end; sta
>   rt=i->end_, i++)
>if ((i->slope_ == 0) && !isinf (i->y_intercept_))
>  boxes.push_back (Box (Interval (start, i->end_),
>Interval (-infinity_f, i->y_intercept_)));
> 
> buildings_ = internal_build_skyline (&boxes, horizon_padding, X_AXIS,
> UP);
> sky_ = src.sky_;

I will try this.  I have not yet tried it. I'll get back to you on the
results.

> 
> By the way, the above code (and your version also) will break if we
> every switch to using more accurate outlines for grobs (ie. more
> accurate than bounding boxes) because it could be throwing away
> interesting things when it discards non-horizontal segments.

That is true, but at that point we will not be using Boxes to define
skylines.

> 
> http://codereview.appspot.com/3832046/diff/27001/lily/skyline.cc#newcode419
> lily/skyline.cc:419: Axis vert_axis = other_axis (horizon_axis);
> This should have X_AXIS instead of "a", because you put the horizon axis
> into the X_AXIS of your boxes.

I'll fix this.  Thanks for the comments.

Thanks,

Carl


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

Re: Potential fix for issue 37

2011-01-07 Thread David Kastrup

Werner LEMBERG  writes:

>> I'm not exactly sure what the desired output would be for issue 37,
>> but my code assumes that if there are collision problems, flat beams
>> look best.
>
> +1

Don't agree: the beams usually give an impression of the overall pitch
tendency.  Flat beams over a rising melody line look strange and dead.
So I think it would be good if they usually kept their natural angle,
just with uniformly longer stems.

Of course, a flat beam is still better than a collision.

-- 
David Kastrup

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

RE: Potential fix for issue 37

From: lilypond-devel-bounces+james.lowe=datacore@gnu.org 
[lilypond-devel-bounces+james.lowe=datacore@gnu.org] on behalf of David 
Kastrup [...@gnu.org]
Sent: 07 January 2011 17:15
To: lilypond-devel@gnu.org
Subject: Re: Potential fix for issue 37

Werner LEMBERG  writes:

>> I'm not exactly sure what the desired output would be for issue 37,
>> but my code assumes that if there are collision problems, flat beams
>> look best.
>
> +1

Don't agree: the beams usually give an impression of the overall pitch
tendency.  Flat beams over a rising melody line look strange and dead.
So I think it would be good if they usually kept their natural angle,
just with uniformly longer stems.

Of course, a flat beam is still better than a collision.

---

So do you agree or not?

;)

James

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

Re: Potential fix for issue 37

On 7 January 2011 16:14,   wrote:
> I'm not exactly sure what the desired output would be for issue 37, but my 
> code assumes that if there are collision problems, flat beams look best.
>
> Lemme know what you think!

Looks interesting, though you need to do a regression test check to
make sure there are no side-effects.

\relative c' {
  c8 d e f
}

This crashes, since the following line

+  if (scm_to_bool (me->get_object ("collides")))

returns a `Wrong type' error for the default case (since 'collides
will return '()).  Use to_boolean () instead (and get_property
()/set_property ()).

Cheers,
Neil

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

Re: Black mensural notation

On 7 January 2011 02:50, Andrew Hawryluk  wrote:
> I tried running it on a current development snapshot this week, but it
> didn't have enough memory to run nicely and bogged down my computer
> with swap traffic (I've got 2 MB here). I gave up on it before it
> finished. Does it take long to compile the PDF on your system?

I had to do the same (2 GB here. ;)  Before aborting, swap memory had
shot up to 2.5 GB.

It seems the \ligature function's causing the excessive memory usage.

Cheers,
Neil

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

Re: Black mensural notation

2011-01-07 Thread Lukas Pietsch

On Fri, 2011-01-07 at 17:50 +, Neil Puttock wrote:
> On 7 January 2011 02:50, Andrew Hawryluk  wrote:
> > I tried running it on a current development snapshot this week, but it
> > didn't have enough memory to run nicely and bogged down my computer
> > with swap traffic (I've got 2 MB here). I gave up on it before it
> > finished. Does it take long to compile the PDF on your system?
> 
> I had to do the same (2 GB here. ;)  Before aborting, swap memory had
> shot up to 2.5 GB.
> 
> It seems the \ligature function's causing the excessive memory usage.
> 

Dang. :-( 

And of course I understand far too little about the internals to have
any idea of what could be causing this. I don't see anything like an
exaggerated memory footprint when I run it on my system (2.12.3 on
Ubuntu Linux 10.04). For mensuraltest.ly, my system monitor shows a
memory usage of max. about 180 MiB, and it takes about 7 seconds to run.

Lukas

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

RE: Black mensural notation

Hello,

From: lilypond-devel-bounces+james.lowe=datacore@gnu.org 
[lilypond-devel-bounces+james.lowe=datacore@gnu.org] on behalf of Lukas 
Pietsch [lukas.piet...@freenet.de]
Sent: 07 January 2011 18:21
To: Neil Puttock
Cc: lilypond-devel@gnu.org
Subject: Re: Black mensural notation

On Fri, 2011-01-07 at 17:50 +, Neil Puttock wrote:
> On 7 January 2011 02:50, Andrew Hawryluk  wrote:
> > I tried running it on a current development snapshot this week, but it
> > didn't have enough memory to run nicely and bogged down my computer
> > with swap traffic (I've got 2 MB here). I gave up on it before it
> > finished. Does it take long to compile the PDF on your system?
>
> I had to do the same (2 GB here. ;)  Before aborting, swap memory had
> shot up to 2.5 GB.
>
> It seems the \ligature function's causing the excessive memory usage.
>

Dang. :-(

And of course I understand far too little about the internals to have
any idea of what could be causing this. I don't see anything like an
exaggerated memory footprint when I run it on my system (2.12.3 on
Ubuntu Linux 10.04). For mensuraltest.ly, my system monitor shows a
memory usage of max. about 180 MiB, and it takes about 7 seconds to run.

---

I ran it on Windows 2.13.44 (not 45 as I first said) and it took a few seconds 
to complile and roughly 150Mb.

James

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

Re: Black mensural notation

On 7 January 2011 18:40, James Lowe  wrote:

> I ran it on Windows 2.13.44 (not 45 as I first said) and it took a few 
> seconds to complile and roughly 150Mb.

Windows 2.13.44 also works fine here, though I can't say the same for 2.13.45:

Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 or 2 pages...
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
terminate called after throwing an instance of 'std::bad_alloc'
  what():  St9bad_alloc

Cheers,
Neil

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

Re: Black mensural notation

> Windows 2.13.44 also works fine here, though I can't say the same for 2.13.45:
>
> Preprocessing graphical objects...
> Finding the ideal number of pages...
> Fitting music on 1 or 2 pages...
> This application has requested the Runtime to terminate it in an unusual way.
> Please contact the application's support team for more information.
> terminate called after throwing an instance of 'std::bad_alloc'
>  what():  St9bad_alloc

it may be related to Joe's recent patch 777066 about page
breaking. I can't compile my larger scores, it stops at the
same message and memory usage goes to the skies.  I wanted
to investigate it a bit more, but if anybody beats me...

p

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

Re: Black mensural notation

On 7 January 2011 20:27, Benkő Pál  wrote:

> it may be related to Joe's recent patch 777066 about page
> breaking. I can't compile my larger scores, it stops at the
> same message and memory usage goes to the skies.  I wanted
> to investigate it a bit more, but if anybody beats me...

I'm looking at it at the moment. :)

Cheers,
Neil

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

Re: Issue 1268 in lilypond: [PATCH] span-bar problem

hi Joe,

>> > need to be careful about what happens when bar-size is set.
>> > Currently, your patch will break (for example) input/regression/drums.ly
>> > because it ignores bar-size.
>>
>> well, I think extent shouldn't be computed from size
>> as it loses information, but the other way round.
>
> That's true, but we currently allow users to override bar-size (for example
> in percussion parts). With your current patch, if the user overrides
> bar-size, then Bar_line::calc_bar_size and Bar_line::calc_bar_extent will
> give conflicting results (I was wrong earlier when I said that this would
> affect the printed bar line, but I still think it's bad for the functions to
> conflict).

certainly.  btw, I think the span bar code looks like this
to allow putting percussion staves into StaffGroup's.

>> AFAICS the intent of the span bar code is to draw lines
>> not between staves but from line to line, and my patch
>> reverts this.
>> of course there's no difference in general, but there is
>> if bar lines are to have different extent than that of
>> their staff; and there is a further difference whether
>> the bar is shorter or longer than the staff: if longer,
>> there may be no point in using span bars at all; if
>> shorter, then perhaps span bars are better placed just
>> between staves (see spantest5.ly).
>
> I don't think the current intention is documented anywhere. If you want to
> fix a policy now, that's ok with me.
>
>> I still don't know exactly how should spantest3 behave
>> (spantest5 makes me feel it works acceptably), neither
>> what should happen if different bar types are connected
>> (see spantest4.ly - I hope this is farthest from a real
>> world case of all my tests).
>>
>> >>> I removed the center setting code and that
>> >>> (with my patch still active) made my example perfect;
>> >>> however, the attached complementary test (with bar
>> >>> lines only within staff, not between them) failed,
>> >>> but it's perfect with current center setting
>> >>> (independently whether my original patch is active or not).
>>
>> >> Since Bar_line::compound_barline is used in both BarLine and SpanBar,
>> >> you
>> >> will need to find some solution that works for both cases. It won't be
>> >> as
>> >> simple as just enabling or disabling the centering code.
>>
>> I moved the centering code from compound_barline to print,
>> and this way all regtests are OK and all my spantests are
>> good or at least acceptable.
>
> Thanks, this patch looks good. Just a couple of things I'd like to see:
>
> - a comment explaining the positioning of span-bars (ie. between bar-lines
> or between staves?)

I'm thinking about a bit more: take the union of bar-extent and staff extent,
and draw the span bar outside those.  Then mensurstrich layout can be achieved
by setting bar-size to 0 (or rather, setting bar-extent to '( 0 . 0 )), which
is perhaps less hackish than the current method of hiding the bar.

> - agreement between bar-size and bar-extent. There are two solutions I can
> see, but feel free to invent your own:
>    - deprecate the bar-size property and use bar-extent from now on. This
> will require a convert-ly rule.

I think this is a must, to avoid setting incompatible size and extent.

>    - unset bar-size by default (in scm/define-grob-properties.scm). In
> calc_bar_extent, check to see if bar-size is set. If it is, use it.
> Otherwise, use the staff extent
>
> Here are a couple other suggestions that I think would improve the code. I'd
> be happy to commit your patch without them because they reflect problems
> with the existing code rather than problems with your patch. But if you have
> time, it would be nice :)
> - Shouldn't Bar_line::print use bar-extent rather than bar-size? That seems
> more natural.

me too, and getting rid of bar-extent makes this a must, too.

> - The centering issue regarding compound_barline still seems strange.
> Wouldn't it be nicer if compound_barline took Real bottom and Real top (or
> maybe Interval) parameters (instead of Real h) and drew a bar line whose
> Y-extent stretched from bottom to top? That seems like a more intuitive API
> to me (and unlike the current one, it's self-documenting).

Good idea!  I have to figure out the centering issues and how to convert
SCM to Interval, but this is a nice way.

I hope I can find some time to do it; thanks for the hints,
p

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

stringTunings documentation

Hi Carl,

The docstring for stringTunings is incorrect following the changes you've made:

"The tablature strings tuning.  It is a list of the pitch (in
semitones) of each string (starting with the lower one."

Cheers,
Neil

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

Re: Black mensural notation

On 7 January 2011 20:33, Neil Puttock  wrote:
> On 7 January 2011 20:27, Benkő Pál  wrote:
>
>> it may be related to Joe's recent patch 777066 about page
>> breaking. I can't compile my larger scores, it stops at the
>> same message and memory usage goes to the skies.  I wanted
>> to investigate it a bit more, but if anybody beats me...
>
> I'm looking at it at the moment. :)

This seems to work (at least, the regtests are OK and it doesn't
appear to break the interaction between page-count and
systems-per-page):

diff --git a/lily/page-breaking.cc b/lily/page-breaking.cc
index e6a5740..af41363 100644
--- a/lily/page-breaking.cc
+++ b/lily/page-breaking.cc
@@ -712,7 +712,7 @@ Page_breaking::system_count_bounds
(vector const &chunks,
   assert (chunks.size () >= 2);

   Line_division ret;
-  ret.resize (chunks.size () - 1, 0);
+  ret.resize (chunks.size () - 1, 1);

   for (vsize i = 0; i + 1 < chunks.size (); i++)
 {
@@ -812,7 +812,7 @@ Page_breaking::set_to_ideal_line_configuration
(vsize start, vsize end)
  div.push_back (line_breaking_[sys].best_solution (start, end).size 
());
}
   else
-   div.push_back (0);
+   div.push_back (1);

   system_count_ += div.back ();
 }
@@ -849,7 +849,7 @@ Page_breaking::cache_line_details (vsize
configuration_index)
}
  else
{
- assert (div[i] == 0);
+ assert (div[i] == 1);
  uncompressed_line_details_.push_back (system_specs_[sys].prob_
? Line_details 
(system_specs_[sys].prob_, book_->paper_)
: Line_details ());

I don't know why, though. :)

Cheers,
Neil

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

Re: Fix Issue 1290 (issue3832046)

2011-01-07 Thread n . puttock


Hi Carl,

Do we have to set a default for skyline-horizontal-padding?  It has a
detrimental effect on some of the regtests (particularly
stem-length-estimation.ly).

Cheers,
Neil

http://codereview.appspot.com/3832046/

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

Re: [PATCH] Allow \markuplines to be assigned to a variable

On 4 January 2011 14:33, Reinhold Kainhofer  wrote:

> mmm = \markup "blah"
> \markup \mmm     % works
> \mmm             % doesn't work

This is a special case since \markup "blah" returns a string rather
than a markup (using simple_string ()).  It works if you wrap the
string in braces:

mmm = \markup  { "blah" }

\mmm

If you want something similar for \markuplines, all you need is a
similar rule to the one for MARKUP_IDENTIFIER in full_markup:

full_markup_list:
MARKUPLINES_IDENTIFIER {
$$ = $1;
}
| MARKUPLINES
{ PARSER->lexer_->push_markup_state (); }
markup_list {
$$ = $3;
PARSER->lexer_->pop_state ();
}
;

Cheers,
Neil

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

Re: Fix Issue 1290 (issue3832046)

2011-01-07 Thread n . puttock



http://codereview.appspot.com/3832046/diff/27001/input/regression/skyline-horizontal-padding.ly
File input/regression/skyline-horizontal-padding.ly (right):

http://codereview.appspot.com/3832046/diff/27001/input/regression/skyline-horizontal-padding.ly#newcode12
input/regression/skyline-horizontal-padding.ly:12: \score {
needs a \book { } block to prevent lilypond-book hijacking the
system-system spacing

http://codereview.appspot.com/3832046/

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

Re: Black mensural notation

> This seems to work (at least, the regtests are OK and it doesn't
> appear to break the interaction between page-count and
> systems-per-page):
[...]
> I don't know why, though. :)

it works for me in the sense that there's no memory problem,
but doesn't work in the sense that now I get an overflow message.

p

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

Re: stringTunings documentation

On 1/7/11 2:34 PM, "Neil Puttock"  wrote:

> Hi Carl,
> 
> The docstring for stringTunings is incorrect following the changes you've
> made:
> 
> "The tablature strings tuning.  It is a list of the pitch (in
> semitones) of each string (starting with the lower one."

Thanks, Neil.  I've changed it to "It is a list of the pitches of each
string (starting with the lowest-numbered one)."

Thanks,

Carl

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

Re: Black mensural notation

On 7 January 2011 14:00, Lukas Pietsch  wrote:

> Thanks a lot! As for the warnings, I too was getting the "cannot align
> on self: empty element" ones, and found no way of getting rid of them.

They're caused by the following lines:

  \override Score.BarLine #'stencil = #empty-stencil
  \override Score.BarNumber #'stencil = #empty-stencil

You can replace the first override with the following:

\set Score.defaultBarType = #"empty"

If you don't want bar numbers, you'd be better off removing the
Bar_number_engraver.

\clavis #'g #3 c'\breve^"where's the g clef?!" c'\breve

It doesn't get printed since nothing changes to trigger a new clef:
you're using a dummy clef with an override, so you'll only get a new
one to show if you change clefGlyph or clefPosition.

Here's a crude hack which also changes clefGlyph to ensure the G clef appears:

 (make-music; dummy setting
   'PropertySet
   'symbol 'clefGlyph
   'value (ly:format "clefs.~a" (string-upcase
(symbol->string type

Cheers,
Neil

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

Re: Potential issue 39 fix w/ patch

2011-01-07 Thread Keith OHara

 Original Message 
> From: "Mike Solomon" 
> Sent: Thursday, January 06, 2011 10:03 AM
>

Mike,
 The patch moves 8th notes unnecessarily.
 The patch breaks the collision resolution of dotted notes.
 If you have to move the notehead, you're moving it the wrong direction.  

Test music attached.  I notice that LilyPond moves an undotted upstem note 
to the left, away from a dotted note, but usually the first priority is to 
keep simultaneous noteheads as close as possible.  For perspective, I 
included a couple collisions LilyPond has never tried to resolve 
automatically. (The last one is allowed intentionally, surprisingly, see 
code comments regarding the boolean 'touch'; there might be a very good 
reason, or it might have been a mental slip. Either way, the LearningManual 
has a "real music example" to teach users how to resolve what LilyPond 
cannot.)

So I suggest 
1) lengthening the stem, selectively, based on duration_log and the 
appropriate collision-sense booleans; or
2) treating notes with big flags as if the were dotted, because the 
dangling flag creates a conceptually similar situation.

Later I'll post the image of desired output, or better desires if we have 
any, on issue 39.



39.ly
Description: Binary data


test.preview.png
Description: Binary data


desire.preview.png
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Potential fix for issue 37

2011-01-07 Thread Jan Warchoł

2011/1/7 

> I'm not exactly sure what the desired output would be for issue 37, but my
> code assumes that if there are collision problems, flat beams look best.
>
> Lemme know what you think!


Judging by my very own personal taste i'd say that when notes are not on the
same staffline it would look better if the beams were slanted; i'd also
prefer slightly smaller vertical gap between upper beams and noteheads (now
it's something like 1 staff space, i'd go for 0.5 staff space). And it would
be great if beams covered stafflines like in regular situations.
But this is my personal opinion and of course the new output is far better
than the old one, so keep up the good work!

cheers,
Janek
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Fix Issue 1290 (issue3832046)

On 1/7/11 2:41 PM, "n.putt...@gmail.com"  wrote:

> Hi Carl,
> 
> Do we have to set a default for skyline-horizontal-padding?  It has a
> detrimental effect on some of the regtests (particularly
> stem-length-estimation.ly).

Well, no, we don't.  However, the original bug says that we're crowding
stuff too closely together.  If we don't change the default, we aren't
really solving the original request unless we also do the Documentation.

I was hoping that by setting the default, we'd get good spacing and we
wouldn't need the override.

I see three possibilities:

1) Change the default value for System skyline-horizontal-padding to see if
we can make both regtests succeed.

2) Eliminate the default value for System skyline-horizontal-padding, and
use an override in skyline-horizontal-padding.ly (and document it more
clearly).

3) Leave the default value as it is, and \override it to zero in
stem-length-estimation.ly.

I think I prefer option 1, followed by 3, followed by 2.

Thanks,

Carl

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

Re: Fix Issue 1290 (issue3832046)

2011-01-07 Thread k-ohara5a5a



http://codereview.appspot.com/3832046/diff/27001/scm/define-grobs.scm
File scm/define-grobs.scm (right):

http://codereview.appspot.com/3832046/diff/27001/scm/define-grobs.scm#newcode1940
scm/define-grobs.scm:1940: (skyline-horizontal-padding . 2)
too big for a default.  I suggest 0.5.

A horizontal space of _4-times_ this value is maintained between
potential interleavers, because the diagonal starts one padding a way
from the grob, the vertical is two paddings away, and grobs from each
system are padded.

I realize that a value of 1.5 or greater is required to affect your
regression test, but an \override in the score would make a more useful
regression test anyway.

The only musical example I have seen where I would want the padding is
the regtest les-nereides.ly, which greatly improved with
horizontal-padding 0.5.

http://codereview.appspot.com/3832046/

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

Re: Fix Issue 1290 (issue3832046)

2011-01-07 Thread Carl . D . Sorensen

Thanks for the feedback. I've responded to each of the suggestions
you've given me.

Carl

http://codereview.appspot.com/3832046/diff/27001/input/regression/skyline-horizontal-padding.ly
File input/regression/skyline-horizontal-padding.ly (right):

http://codereview.appspot.com/3832046/diff/27001/input/regression/skyline-horizontal-padding.ly#newcode12
input/regression/skyline-horizontal-padding.ly:12: \score {
On 2011/01/07 21:59:41, Neil Puttock wrote:

needs a \book { } block to prevent lilypond-book hijacking the

system-system

spacing

Done.

http://codereview.appspot.com/3832046/diff/27001/lily/skyline.cc
File lily/skyline.cc (right):

http://codereview.appspot.com/3832046/diff/27001/lily/skyline.cc#newcode391
lily/skyline.cc:391: {
It worked, once I changed boxes from a vector to a list.

Thanks for the insight!

http://codereview.appspot.com/3832046/diff/27001/lily/skyline.cc#newcode419
lily/skyline.cc:419: Skyline padded_skyline = Skyline (boxes,
horizon_padding, a, UP);
On 2011/01/07 16:47:27, joeneeman wrote:

This should have X_AXIS instead of "a", because you put the horizon

axis into

the X_AXIS of your boxes.

Done.

http://codereview.appspot.com/3832046/diff/27001/scm/define-grobs.scm
File scm/define-grobs.scm (right):

http://codereview.appspot.com/3832046/diff/27001/scm/define-grobs.scm#newcode1940
scm/define-grobs.scm:1940: (skyline-horizontal-padding . 2)
On 2011/01/07 23:53:34, Keith wrote:

too big for a default. I suggest 0.5.

A horizontal space of _4-times_ this value is maintained between

potential

interleavers, because the diagonal starts one padding a way from the

grob, the

vertical is two paddings away, and grobs from each system are padded.

I realize that a value of 1.5 or greater is required to affect your

regression

test, but an \override in the score would make a more useful

regression test

anyway.

The only musical example I have seen where I would want the padding is

the

regtest les-nereides.ly, which greatly improved with

horizontal-padding 0.5.

Done. 0.5 also works fine with stem-length-estimation.ly.

http://codereview.appspot.com/3832046/

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

Re: Fix Issue 1290 (issue3832046)

2011-01-07 Thread Carl . D . Sorensen


On 2011/01/07 21:41:51, Neil Puttock wrote:

Hi Carl,



Do we have to set a default for skyline-horizontal-padding?  It has a
detrimental effect on some of the regtests (particularly
stem-length-estimation.ly).


I've set the default to 0.5, in accordance with Keith's suggestions.  It
leaves stem-length-estimation.ly alone now.


http://codereview.appspot.com/3832046/

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

Re: Fix Issue 1290 (issue3832046)

2011-01-07 Thread Keith OHara

 Original Message 
> From: "Carl Sorensen" 
> Sent: Friday, January 07, 2011 3:28 PM

> 
> I was hoping that by setting the default, we'd get good spacing and we
> wouldn't need the override.
> 

I hadn't seen this exchange when I commented on the define-grobs.scm; 
sorry.

The large horizontal padding of 2.0 told Lily that the upper loops of the 
treble clefs were intolerably close to the whole notes, in 
stem-length-estimation.ly.   The stem length test passes with 0.5.

The bug report test and your reg-test are rather extreme examples, with 
very tall and narrow protrusions.  It seems fine to have an extreme example 
for your reg-test, though, and to include an override that adjusts the very 
feature being tested.

For docs, my suggestion for define-grop-properties.scm earlier in this the 
thread might do the trick by putting text in the correct places in the 
Internals Reference.
-keith


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

Re: Issue 1268 in lilypond: [PATCH] span-bar problem

2011-01-07 Thread Joe Neeman

On Sat, Jan 8, 2011 at 4:13 AM, Benkő Pál  wrote:

>
> Good idea!  I have to figure out the centering issues and how to convert
> SCM to Interval, but this is a nice way.
>

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

Re: Potential fix for issue 37

2011-01-07 Thread Mike Solomon

Kinda meh, but it gets the job done!  I've included three patches, including the original.The second preserves the flat beams but gets rid of the crashing lily, whereas the third implements some bendiness.Cheers,MS

0003-Second-pass-on-potential-fix-for-issue-37.patch
Description: Binary data


0002-Fixes-crashing-problem.patch
Description: Binary data


0001-Potential-fix-for-issue-37.patch
Description: Binary data
On Jan 7, 2011, at 6:11 PM, Jan Warchoł wrote:2011/1/7  



I'm not exactly sure what the desired output would be for issue 37, but my code assumes that if there are collision problems, flat beams look best.

Lemme know what you think!Judging by my very own personal taste i'd say that when notes are not on the same staffline it would look better if the beams were slanted; i'd also prefer slightly smaller vertical gap between upper beams and noteheads (now it's something like 1 staff space, i'd go for 0.5 staff space). And it would be great if beams covered stafflines like in regular situations.



But this is my personal opinion and of course the new output is far better than the old one, so keep up the good work!cheers,Janek
___lilypond-devel mailing listlilypond-devel@gnu.orghttp://lists.gnu.org/mailman/listinfo/lilypond-devel___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: [Patch] Fix for Issue 879




On 1/7/11 8:28 AM, "Phil Holmes"  wrote:

> I believe the attached patch fixes issue 879.  Don't think it's a big deal,
> but it was flagged as a frog task so I thought I'd contribute.  I have run
> my own regtest checker against the regtests and there were no differences.
> Please could someone with git access check and push if it's OK.

Thanks, Phil.   Pushed.

Carl

> 
> --
> Phil Holmes
> Bug Squad
> 


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

Re: Fix Issue 1290 (issue3832046)