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 pro
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 e
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 fa
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
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
> 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,
>
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
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 wit
- 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
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 performer
- 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 pa
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
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/
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 co
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-
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
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
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 R
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 woul
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 mail
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 standa
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
requir
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
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.
--
P
> 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/mailma
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 wro
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_in
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 me
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 L
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 th
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 compil
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
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: R
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 numbe
> 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 appl
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
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.
>
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 lis
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
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
li
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 = \m
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-horizont
> 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 overflo
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
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
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 musi
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 lo
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
s
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 horizon
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/270
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
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 larg
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:/
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
000
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
On 1/7/11 4:28 PM, "Carl Sorensen" wrote:
> 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).
>
> I was hoping tha
On Fri, 07 Jan 2011 15:50:40 -0800, Carl Sorensen wrote:
A default value of skyline-horizontal-padding of 1.2 gets
skyline-horizontal-padding.ly to work well.
An override to System 'skyline-horizontal-padding = #0 in
stem-length-estimation.ly gets it working well. Since we already have
overri
Looks fine, although I haven't actually tested it, but since it's not in
the core program I'm less concerned. Could you email me the git patch
and I'll push it?
http://codereview.appspot.com/3793046/
___
lilypond-devel mailing list
lilypond-devel@gnu.
I've done two regtest checks, and it all seems fine, so I've pushed it.
http://codereview.appspot.com/3858041/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
59 matches
Mail list logo
