Re: Calling all Londoners

[Phil Holmes]

- Original Message - 
From: 

To: "Devel Team" 
Sent: Thursday, February 09, 2012 5:54 PM
Subject: Calling all Londoners



Hey all,

On Monday, I'll be crossing the channel to the land where everything's 
called pudding and people drive on the wrong side of the road.  I'll be in 
London for a couple days for a gig.  Are any of you in the area?  If so, 
it'd be great to meet up for coffee!


Cheers,
MS



I'm about 90 minutes away, but could potentially get down if more people 
could make it, and the timing was good.


--
Phil Holmes



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

Re: google summer of code

[Phil Holmes]

- Original Message - 
From: "David Kastrup" 

To: 
Sent: Friday, February 10, 2012 5:44 AM
Subject: Re: google summer of code



Janek Warchoł  writes:


2012/2/9 Graham Percival :


Probably something like GSoC for "grace timing" would be overkill.
OTOH, if a student starts from a blank slate and mentoring is not
doing half the job already on its own, there might be less time left
after a _good_ solution has been implemented than one might think.


Sorry, i don't understand.  Do you think that grace timing is too
small or too big for GSoC?


It _sounds_ too small, but may turn out to be quite a number.
Basically, it requires a solid understanding of iterators, analyzing the
music events occuring in grace situations, designing iteration orders
useful for typesetting and MIDI replay, and making everything work with
them.  Iterators are not really the best documented corner of LilyPond.

--
David Kastrup



That might be another good avenue for a GSoC proposal - improving code 
documentation, which would therefore make it easier to get new contributors 
on board.


--
Phil Holmes



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

Re: google summer of code

[David Kastrup]

"Phil Holmes"  writes:

> - Original Message - 
> From: "David Kastrup" 
> To: 
> Sent: Friday, February 10, 2012 5:44 AM
> Subject: Re: google summer of code
>
>
>> Janek Warchoł  writes:
>>
>>> 2012/2/9 Graham Percival :

 Probably something like GSoC for "grace timing" would be overkill.
 OTOH, if a student starts from a blank slate and mentoring is not
 doing half the job already on its own, there might be less time left
 after a _good_ solution has been implemented than one might think.
>>>
>>> Sorry, i don't understand.  Do you think that grace timing is too
>>> small or too big for GSoC?
>>
>> It _sounds_ too small, but may turn out to be quite a number.
>> Basically, it requires a solid understanding of iterators, analyzing the
>> music events occuring in grace situations, designing iteration orders
>> useful for typesetting and MIDI replay, and making everything work with
>> them.  Iterators are not really the best documented corner of LilyPond.
>
> That might be another good avenue for a GSoC proposal - improving code
> documentation, which would therefore make it easier to get new
> contributors on board.

Well, code janitor training must be one of the least sexiest projects
imaginable.  Of course, companies will be battering down your door for
such a rare and ass-saving skill set.  The NIH-annihilator.

-- 
David Kastrup

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

Re: google summer of code

[Janek Warchoł]

2012/2/10 David Kastrup :
> Janek Warchoł  writes:
>> Sorry, i don't understand.  Do you think that grace timing is too
>> small or too big for GSoC?
>
> It _sounds_ too small, but may turn out to be quite a number.
> Basically, it requires a solid understanding of iterators, analyzing the
> music events occuring in grace situations, designing iteration orders
> useful for typesetting and MIDI replay, and making everything work with
> them.  Iterators are not really the best documented corner of LilyPond.

Thanks, now i better understand what's good for a GSoC idea.

2012/2/10 Phil Holmes :
> That might be another good avenue for a GSoC proposal - improving code
> documentation, which would therefore make it easier to get new contributors
> on board.

Unfortunately not. GSoC explicitly states that it must be about
writing code.  Documentation is explicitly excluded from GSoC.

2012/2/10 m...@apollinemike.com :
> It'd be great as well to see you work on your font-related projects
> such as different flag and accidental glyphs.  Also, I'm guessing
> that one does not need to devote 100% of one's GSoC time to writing
> lines of code.  LilyPond also needs lots of problems framed in terms
> of examples from the literature alongside the corresponding (possibly
> deficient) ly code.  You also do that really well

Thanks!
However i'm not sure if this qualifies for GSoC.  Sure, writing .ly
files is writing code :D but i don't think Google will like this.

> and it'd be great to have a formalized way of establishing goals via this 
> sort of research.

+1

cheers,
Janek

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

Re: google summer of code

[David Kastrup]

Janek Warchoł  writes:

> 2012/2/10 David Kastrup :
>> Janek Warchoł  writes:
>>> Sorry, i don't understand.  Do you think that grace timing is too
>>> small or too big for GSoC?
>>
>> It _sounds_ too small, but may turn out to be quite a number.
>> Basically, it requires a solid understanding of iterators, analyzing the
>> music events occuring in grace situations, designing iteration orders
>> useful for typesetting and MIDI replay, and making everything work with
>> them.  Iterators are not really the best documented corner of LilyPond.
>
> Thanks, now i better understand what's good for a GSoC idea.

Don't get me wrong: it is probably quite enough work for getting someone
started.  I'm just not sure whether it will be easy to sell it off.  The
largest part of the work would realistically consist in digging oneself
into sparsely documented areas, just in order to be able to come up with
a good plan and implementation that would, if you discounted all dead
corners, take two days to do.

It seems a bit like visiting a term of art classes in order to make a
convincing sketch at its end.  The real deal is not the sketch, but the
ability to do so.  And if all you are going to do is that one sketch,
the exercise seems a bit pointless.

But of course, if you want to turn sketches into a living, having
someone pay what it takes to do the first sketch is going to be a _big_
help.

-- 
David Kastrup


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

Re: google summer of code

[Janek Warchoł]

2012/2/10 David Kastrup :
> Don't get me wrong: it is probably quite enough work for getting someone
> started.  I'm just not sure whether it will be easy to sell it off.  The
> largest part of the work would realistically consist in digging oneself
> into sparsely documented areas, just in order to be able to come up with
> a good plan and implementation that would, if you discounted all dead
> corners, take two days to do.
>
> It seems a bit like visiting a term of art classes in order to make a
> convincing sketch at its end.  The real deal is not the sketch, but the
> ability to do so.  And if all you are going to do is that one sketch,
> the exercise seems a bit pointless.
>
> But of course, if you want to turn sketches into a living, having
> someone pay what it takes to do the first sketch is going to be a _big_
> help.

Of course.

Janek

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

Re: Gets vertical skylines from grob stencils (issue 5626052)

[Han-Wen Nienhuys]

Just a very quick look: I notice you're creating affine transform
matrices in Scheme. IMO, this seems an excellent candidate to
implement in C++ and expose through bindings, as the C++ matrices will
be better packed in memory, and should probably only be manipulated by
operations involving multiple floating point ops (add, multiply, etc.)

On Thu, Feb 9, 2012 at 9:24 PM, m...@apollinemike.com
 wrote:
>
-- 
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen

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

Re: Gets vertical skylines from grob stencils (issue 5626052)

[David Kastrup]

Han-Wen Nienhuys  writes:

> Just a very quick look: I notice you're creating affine transform
> matrices in Scheme. IMO, this seems an excellent candidate to
> implement in C++ and expose through bindings, as the C++ matrices will
> be better packed in memory, and should probably only be manipulated by
> operations involving multiple floating point ops (add, multiply, etc.)

Stupid question: wasn't Cairo a dependency of LilyPond?  It should offer
affine transforms as a builtin entity anyway, and it is conceivable that
using those will play together smoothly with other rendering operations.

-- 
David Kastrup


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

Re: Gets vertical skylines from grob stencils (issue 5626052)

[David Kastrup]

David Kastrup  writes:

> Han-Wen Nienhuys  writes:
>
>> Just a very quick look: I notice you're creating affine transform
>> matrices in Scheme. IMO, this seems an excellent candidate to
>> implement in C++ and expose through bindings, as the C++ matrices will
>> be better packed in memory, and should probably only be manipulated by
>> operations involving multiple floating point ops (add, multiply, etc.)
>
> Stupid question: wasn't Cairo a dependency of LilyPond?  It should
> offer affine transforms as a builtin entity anyway, and it is
> conceivable that using those will play together smoothly with other
> rendering operations.

Cancel that: I was confusing this with Pango.

-- 
David Kastrup


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

Re: Gets vertical skylines from grob stencils (issue 5626052)

[David Kastrup]

David Kastrup  writes:

> David Kastrup  writes:
>
>> Han-Wen Nienhuys  writes:
>>
>>> Just a very quick look: I notice you're creating affine transform
>>> matrices in Scheme. IMO, this seems an excellent candidate to
>>> implement in C++ and expose through bindings, as the C++ matrices will
>>> be better packed in memory, and should probably only be manipulated by
>>> operations involving multiple floating point ops (add, multiply, etc.)
>>
>> Stupid question: wasn't Cairo a dependency of LilyPond?  It should
>> offer affine transforms as a builtin entity anyway, and it is
>> conceivable that using those will play together smoothly with other
>> rendering operations.
>
> Cancel that: I was confusing this with Pango.

Well, uncancel the idea in itself: seems like it applies to Pango as
well:

http://developer.gnome.org/pango/stable/pango-Glyph-Storage.html#PangoMatrix>

-- 
David Kastrup


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

Re: Gets vertical skylines from grob stencils (issue 5626052)

[m...@apollinemike.com]

On Feb 10, 2012, at 1:16 PM, Han-Wen Nienhuys wrote:

> Just a very quick look: I notice you're creating affine transform
> matrices in Scheme. IMO, this seems an excellent candidate to
> implement in C++ and expose through bindings, as the C++ matrices will
> be better packed in memory, and should probably only be manipulated by
> operations involving multiple floating point ops (add, multiply, etc.)
> 

Hey Han-Wen,

The most recent patch up on dev/skylines-cached is all in C++.  It actually 
sometimes runs faster than current master - it's incredible how much C++ speeds 
stuff up!

Cheers,
MS


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

Re: Gets vertical skylines from grob stencils (issue 5626052)

[m...@apollinemike.com]

On Feb 10, 2012, at 1:51 PM, David Kastrup wrote:

> David Kastrup  writes:
> 
>> David Kastrup  writes:
>> 
>>> Han-Wen Nienhuys  writes:
>>> 
 Just a very quick look: I notice you're creating affine transform
 matrices in Scheme. IMO, this seems an excellent candidate to
 implement in C++ and expose through bindings, as the C++ matrices will
 be better packed in memory, and should probably only be manipulated by
 operations involving multiple floating point ops (add, multiply, etc.)
>>> 
>>> Stupid question: wasn't Cairo a dependency of LilyPond?  It should
>>> offer affine transforms as a builtin entity anyway, and it is
>>> conceivable that using those will play together smoothly with other
>>> rendering operations.
>> 
>> Cancel that: I was confusing this with Pango.
> 
> Well, uncancel the idea in itself: seems like it applies to Pango as
> well:
> 

I've implemented all of the affine transformations in stencil-integral.cc.  
They're pretty simple, but they work and are fast.

Cheers,
MS


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

Re: Gets vertical skylines from grob stencils (issue 5626052)

[David Kastrup]

"m...@apollinemike.com"  writes:

> On Feb 10, 2012, at 1:51 PM, David Kastrup wrote:
>
>> David Kastrup  writes:
>> 
>>> David Kastrup  writes:
>>> 
 Han-Wen Nienhuys  writes:
 
> Just a very quick look: I notice you're creating affine transform
> matrices in Scheme. IMO, this seems an excellent candidate to
> implement in C++ and expose through bindings, as the C++ matrices will
> be better packed in memory, and should probably only be manipulated by
> operations involving multiple floating point ops (add, multiply, etc.)
 
 Stupid question: wasn't Cairo a dependency of LilyPond?  It should
 offer affine transforms as a builtin entity anyway, and it is
 conceivable that using those will play together smoothly with other
 rendering operations.
>>> 
>>> Cancel that: I was confusing this with Pango.
>> 
>> Well, uncancel the idea in itself: seems like it applies to Pango as
>> well:
>
> I've implemented all of the affine transformations in
> stencil-integral.cc.  They're pretty simple, but they work and are
> fast.

No disrespect intended, but if we do our text stencilling in Pango
anyway, it seems like we don't buy us any advantages by maintaining our
own code for transformations, possibly needing to convert them into the
Pango form when passing them on.  I immediately agree that it is a
nuisance to first do the work of coding this, then do the work of
replacing it again, then check that the replacement also works.  It
would have been nicer if I had thought of this earlier.

But things like using SSE instruction sets for transforms have a place
in Pango (where it is a fundamental operation) but would not be a
reasonable fit of code complexity in LilyPond.  It may be a naive
assumption without looking at the respective code, but I would at least
hope that we can rely on the Pango stuff being in reasonable shape, and
if it isn't, have people care about bug reports without needing to
invest too much work of our own.

-- 
David Kastrup


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

guile1-config

[Werner LEMBERG]

Folks,


openSuSE is now packaging guile 1 and guile 2 separately, and the
former comes with a `guile1-config' script, and the binary is called
`guile1'.

Given that lilypond doesn't work reliably with guile 2 yet (at least I
got a segfault during `make all') it might be a good thing to make it
work for the above configuration also...

Attached is a very primitive patch which works for me.


Werner
diff --git a/stepmake/aclocal.m4 b/stepmake/aclocal.m4
index c60521e..b92ddf8 100644
--- a/stepmake/aclocal.m4
+++ b/stepmake/aclocal.m4
@@ -536,6 +536,10 @@ AC_DEFUN(STEPMAKE_GETTEXT, [
 
 AC_DEFUN(STEPMAKE_GUILE, [
 STEPMAKE_PATH_PROG(GUILE, guile, $1)
+if test "$GUILE" = "- echo guile not found"; then
+  GUILE=
+  STEPMAKE_PATH_PROG(GUILE, guile1, $1)
+fi
 ])
 
 
@@ -577,7 +581,7 @@ AC_DEFUN(STEPMAKE_GUILE_DEVEL, [
 test -n "$target_alias" && target_guile_config=$target_alias-guile-config
 test -n "$host_alias" && host_guile_config=$host_alias-guile-config
 AC_MSG_CHECKING([for guile-config])
-for guile_config in $GUILE_CONFIG $target_guile_config $host_guile_config $build_guile_config guile-config; do
+for guile_config in $GUILE_CONFIG $target_guile_config $host_guile_config $build_guile_config guile-config guile1-config; do
 	AC_MSG_RESULT([$guile_config])
 	if ! $guile_config --version > /dev/null 2>&1 ; then
 	AC_MSG_WARN([cannot execute $guile_config])
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: guile1-config

[David Kastrup]

Werner LEMBERG  writes:

> Folks,
>
>
> openSuSE is now packaging guile 1 and guile 2 separately, and the
> former comes with a `guile1-config' script, and the binary is called
> `guile1'.
>
> Given that lilypond doesn't work reliably with guile 2 yet (at least I
> got a segfault during `make all') it might be a good thing to make it
> work for the above configuration also...
>
> Attached is a very primitive patch which works for me.

That patch looks like it would stop working the moment you also install
Guile 2.

-- 
David Kastrup


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

Re: guile1-config

[Werner LEMBERG]

>> Attached is a very primitive patch which works for me.
> 
> That patch looks like it would stop working the moment you also
> install Guile 2.

I don't think so, but admittedly I haven't tested it.  The patch is
bad, I know; it's just to tell people what I have done to compile
lilypond with the `guile1' package from openSuSE factory.


Werner

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

Re: Thinking about putting together a grant to support development on LilyPond

[Brent Annable]

Just an idea: how about a Kickstarter  project?
Or has this already been considered?

Brent.

On 9 February 2012 12:08, Han-Wen Nienhuys  wrote:

> On Wed, Feb 8, 2012 at 12:29 PM, Carl Sorensen  wrote:
> > I've been thinking about the problem of sustaining LilyPond development
> > long-term (and specifically the problem of obtaining enough money to
> > support David K as long as he's interested).
> >
> > As I've thought about it, going after a grant seems the most logical
> thing
> > to do.  So I looked into the National Endowment for the Arts and the
> > National Endowment for the Humanities.  NEA has nothing that looks
> > interesting, unfortunately.  However, NEH has two initiatives that seem
> > interesting.  One is concerned with preservation; the other is concerned
> > with improve digital access to collected materials.
> >
> > Guidelines for the preservation grant (which will probably be due in
> July)
> > are shown here:
> >
> > http://www.neh.gov/grants/guidelines/HCRR.html
> >
> >
> > Guidelines for the digital humanities grants are shown here:
> >
> > http://www.neh.gov/grants/guidelines/digitalhumanitiesstartup.html
>
> Some comments:
>
> I have tried getting grants from different EU and national bodies with
> various partner institutions (including the one where Graham now
> works, IIRC). My impression is that you need people (preferably many)
> with lots of academic clout that can sign off on the proposal, since
> LilyPond itself has little formal recognition. Also, for EU research
> grants specifically, they were focused a lot on partnerships with and
> things that helped small and medium enterprises, and we couldn't
> invent a story around that.
>
> As for these grants specifically: you will need to invent something
> outrageously new involving LilyPond (now in its 14th year of
> existence), to qualify for the "startup" grant; the collections
> initiative looks like a better fit.
>
> > A) Development of ly2xml
> > B) Development of a lilypond scoring standard for the project, so that
> > scholars would know how to compare scores.
> > C) Development of score_ocr2ly, which would take a score pdf and turn it
> > into .ly files matching the lilypond scoring standard
>
> Heh.  This is a known problem, and the OCR part is very, very
> difficult. It also has nothing to do with lilypond.
>
> > So I'd like to ask the developers (and the users):  Does this seem
> > interesting to you?  Is this something that is worth trying to put
> > together?  Is anybody interested in contributing to a grant proposal?
>
> I'd be happy to provide any references or recommendations for the
> LilyPond project as a whole.
>
> > If there seems to be enough interest, I'll visit with the music librarian
> > at BYU, and see if there is any institutional interest.
>
> I'd talk with someone from the local music/humanities department that
> has experience with writing grants and the funding body.  Of course,
> if you got grants in the past, that might be less necessary.
>
> --
> Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
>
> ___
> lilypond-user mailing list
> lilypond-u...@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user
>
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Gets vertical skylines from grob stencils (issue 5626052)

[mike]

On Feb 10, 2012, at 3:05 PM, David Kastrup wrote:

> "m...@apollinemike.com"  writes:
> 
>> On Feb 10, 2012, at 1:51 PM, David Kastrup wrote:
>> 
>>> David Kastrup  writes:
>>> 
 David Kastrup  writes:
 
> Han-Wen Nienhuys  writes:
> 
>> Just a very quick look: I notice you're creating affine transform
>> matrices in Scheme. IMO, this seems an excellent candidate to
>> implement in C++ and expose through bindings, as the C++ matrices will
>> be better packed in memory, and should probably only be manipulated by
>> operations involving multiple floating point ops (add, multiply, etc.)
> 
> Stupid question: wasn't Cairo a dependency of LilyPond?  It should
> offer affine transforms as a builtin entity anyway, and it is
> conceivable that using those will play together smoothly with other
> rendering operations.
 
 Cancel that: I was confusing this with Pango.
>>> 
>>> Well, uncancel the idea in itself: seems like it applies to Pango as
>>> well:
>> 
>> I've implemented all of the affine transformations in
>> stencil-integral.cc.  They're pretty simple, but they work and are
>> fast.
> 
> No disrespect intended, but if we do our text stencilling in Pango
> anyway,

The affine transformation code handles all stencils, including paths, shapes, 
arcs, named-glyphs (which use open type fonts), etc..

> it seems like we don't buy us any advantages by maintaining our
> own code for transformations, possibly needing to convert them into the
> Pango form when passing them on.

They do not currently do this.  I am of course open to using pango for these 
transformations if it can do them reliably for generic matrices (i.e. something 
not wedded to text) and you're sure that their API is stable.  However, for the 
purposes of this patch, they are very simple and straightforward (copied 
straight out of the svg specification) and they get the job done.  Check out 
line 120 of stencil-integral.cc.  That's the extent of the complexity.

> I immediately agree that it is a
> nuisance to first do the work of coding this, then do the work of
> replacing it again, then check that the replacement also works.  It
> would have been nicer if I had thought of this earlier.
> 

There is absolutely no problem at all - I would much rather use a stable and 
robust library if it's available.  However, the operations are so minimal and 
simple that the thought didn't even occur to me not to implement them myself 
(it's taking me longer to write this e-mail than it took me to write the code). 
 If you think that Pango can do the job of what's in stencil-integrate.cc, 
lemme know.  I don't see anything in the library that seems designed for this, 
but I of course could have missed something.

> But things like using SSE instruction sets for transforms have a place
> in Pango (where it is a fundamental operation) but would not be a
> reasonable fit of code complexity in LilyPond.  It may be a naive
> assumption without looking at the respective code, but I would at least
> hope that we can rely on the Pango stuff being in reasonable shape, and
> if it isn't, have people care about bug reports without needing to
> invest too much work of our own.

This paragraph is a bit over my head, but again, if you think I can sub in 
Pango for my affine transformations, lemme know where it is in pango & I'll get 
to it!

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

Re: Gets vertical skylines from grob stencils (issue 5626052)

[David Kastrup]

m...@apollinemike.com writes:

>
>> I immediately agree that it is a
>> nuisance to first do the work of coding this, then do the work of
>> replacing it again, then check that the replacement also works.  It
>> would have been nicer if I had thought of this earlier.
>> 
>
> There is absolutely no problem at all - I would much rather use a
> stable and robust library if it's available.  However, the operations
> are so minimal and simple that the thought didn't even occur to me not
> to implement them myself (it's taking me longer to write this e-mail
> than it took me to write the code).  If you think that Pango can do
> the job of what's in stencil-integrate.cc, lemme know.  I don't see
> anything in the library that seems designed for this, but I of course
> could have missed something.

Look in pango-matrix.h for the transforms.

I skimmed over the actual code, and at the current point of time it is
nothing particularly optimized: it almost looks like a copy of your code
right now.  I'd still prefer a wrapper for that (it's not inconceivable
that we might want to pass these into Pango rendering at one time, and
not having to copy anything would be an advantage) to our own code.

-- 
David Kastrup

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

Re: Gets vertical skylines from grob stencils (issue 5626052)

[m...@apollinemike.com]

On Feb 10, 2012, at 5:55 PM, David Kastrup wrote:

> m...@apollinemike.com writes:
> 
>> 
>>> I immediately agree that it is a
>>> nuisance to first do the work of coding this, then do the work of
>>> replacing it again, then check that the replacement also works.  It
>>> would have been nicer if I had thought of this earlier.
>>> 
>> 
>> There is absolutely no problem at all - I would much rather use a
>> stable and robust library if it's available.  However, the operations
>> are so minimal and simple that the thought didn't even occur to me not
>> to implement them myself (it's taking me longer to write this e-mail
>> than it took me to write the code).  If you think that Pango can do
>> the job of what's in stencil-integrate.cc, lemme know.  I don't see
>> anything in the library that seems designed for this, but I of course
>> could have missed something.
> 
> Look in pango-matrix.h for the transforms.
> 
> I skimmed over the actual code, and at the current point of time it is
> nothing particularly optimized: it almost looks like a copy of your code
> right now.  I'd still prefer a wrapper for that (it's not inconceivable
> that we might want to pass these into Pango rendering at one time, and
> not having to copy anything would be an advantage) to our own code.
> 

The problem is that the Pango API does not allow multiplication between two 
arbitrary matrices.  I like the openness of the one I've created, and if we 
lock ourselves into using Pango, then we close off this openness (for example, 
if we ever want to implement skewX or skewY it'd be difficult whereas w/ my 
affine transformation functions it is a one-liner).

I do see what you're saying, though, about eventually using Pango matrices.  If 
it's all right w/ everyone, I'd rather keep this version for now and use Pango 
if necessary later down the line.

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

Re: Gets vertical skylines from grob stencils (issue 5626052)

[David Kastrup]

"m...@apollinemike.com"  writes:

> The problem is that the Pango API does not allow multiplication
> between two arbitrary matrices.

Hm?  What's wrong with pango_matrix_concat ?

> I like the openness of the one I've created, and if we lock ourselves
> into using Pango, then we close off this openness (for example, if we
> ever want to implement skewX or skewY it'd be difficult

Hm?  Why?

> whereas w/ my affine transformation functions it is a one-liner).

-- 
David Kastrup

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

Announce discontinuation of MacOSX support for versions 10.4 and older (issue 2271) (issue 5653057)

[graham]

I have mixed feelings about this patch.  Given that adding osx 10.4 ppc
support is a two-line patch -- smaller than this one! -- it feels a bit
weird to move ahead with this.  However, there is clearly no desire to
actually create that two-line patch, so I guess that removing support is
the thing to do.

As well as changes.itely, the website macosx download page needs to be
modified.


http://codereview.appspot.com/5653057/diff/1/Documentation/changes.tely
File Documentation/changes.tely (right):

http://codereview.appspot.com/5653057/diff/1/Documentation/changes.tely#newcode285
Documentation/changes.tely:285: lack of interest and resources, support
for versions 10.4 and older has
Make this a new @item, at the top of the list.  The way it is right now,
it looks as though Christian was the person to discontinue osx 10.4
support, which is extremely misleading.  He told us how to fix it.

http://codereview.appspot.com/5653057/

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

Re: Announce discontinuation of MacOSX support for versions 10.4 and older (issue 2271) (issue 5653057)

[David Kastrup]

gra...@percival-music.ca writes:

> I have mixed feelings about this patch.  Given that adding osx 10.4 ppc
> support is a two-line patch -- smaller than this one! -- it feels a bit
> weird to move ahead with this.  However, there is clearly no desire to
> actually create that two-line patch, so I guess that removing support is
> the thing to do.

I have no clue at all about the actual work involved, but it sounded to
me like it also involved considerable effort in compiling, testing and
uploading things, and then wait for feedback.  If we claim something to
be supported, it is not enough to say "we think it may work".

If that two-line patch possibly causes us to have to reiterate several
times before OSX 10.7 gets working again, it is quite more expensive
than "2 lines" sounds like.  If there is no such risk, one can do the
patch, declare the platform "unsupported", and go on without testing.

Again: I don't have a clue about the involved work.  But if it isn't
happening, there is no point in never releasing something for those
platforms which we _do_ actively support.

-- 
David Kastrup

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

Re: Announce discontinuation of MacOSX support for versions 10.4 and older (issue 2271) (issue 5653057)

[Graham Percival]

On Fri, Feb 10, 2012 at 08:16:53PM +0100, David Kastrup wrote:
> gra...@percival-music.ca writes:
> 
> > However, there is clearly no desire to
> > actually create that two-line patch, so I guess that removing support is
> > the thing to do.
>
> Again: I don't have a clue about the involved work.  But if it isn't
> happening, there is no point in never releasing something for those
> platforms which we _do_ actively support.

Agreed; if you fix the other comments in my review, I'll give it a
LGTM.  I'm just giving one more chance to somebody to care about
this.

- Graham

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

Re: Announce discontinuation of MacOSX support for versions 10.4 and older (issue 2271) (issue 5653057)

[David Kastrup]

Graham Percival  writes:

> On Fri, Feb 10, 2012 at 08:16:53PM +0100, David Kastrup wrote:
>> gra...@percival-music.ca writes:
>> 
>> > However, there is clearly no desire to
>> > actually create that two-line patch, so I guess that removing support is
>> > the thing to do.
>>
>> Again: I don't have a clue about the involved work.  But if it isn't
>> happening, there is no point in never releasing something for those
>> platforms which we _do_ actively support.
>
> Agreed; if you fix the other comments in my review, I'll give it a
> LGTM.  I'm just giving one more chance to somebody to care about
> this.

Sure thing.  When this will be going on countdown, I was also going to
copy it to the user list.  I also plan on mentioning it in the next
LilyPond Report (no idea about when I'll be working seriously on that,
hopefully soon), whether before or after 2.16 has been released.  But as
long as no users are seriously worrying about OSX 10.4 (and the only one
actually offering a bounty was not doing this out of personal need, but
because of sympathy with possibly mythical legacy users), there does not
seem much of a point to expend the work, even if it is just few hours,
for caring.

-- 
David Kastrup


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

Re: Gets vertical skylines from grob stencils (issue 5626052)

[m...@apollinemike.com]

On Feb 10, 2012, at 7:35 PM, David Kastrup wrote:

> "m...@apollinemike.com"  writes:
> 
>> The problem is that the Pango API does not allow multiplication
>> between two arbitrary matrices.
> 
> Hm?  What's wrong with pango_matrix_concat ?


Missed that.
New dev/skylines-cached up that uses pango affine transforms.

Cheers,
MS

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

Re: Announce discontinuation of MacOSX support for versions 10.4 and older (issue 2271) (issue 5653057)

[Carl Sorensen]

On 2/10/12 12:52 PM, "David Kastrup"  wrote:

>Graham Percival  writes:
>
>> On Fri, Feb 10, 2012 at 08:16:53PM +0100, David Kastrup wrote:
>>> gra...@percival-music.ca writes:
>>> 
>>> > However, there is clearly no desire to
>>> > actually create that two-line patch, so I guess that removing
>>>support is
>>> > the thing to do.
>>>
>>> Again: I don't have a clue about the involved work.  But if it isn't
>>> happening, there is no point in never releasing something for those
>>> platforms which we _do_ actively support.
>>
>> Agreed; if you fix the other comments in my review, I'll give it a
>> LGTM.  I'm just giving one more chance to somebody to care about
>> this.
>
>Sure thing.  When this will be going on countdown, I was also going to
>copy it to the user list.  I also plan on mentioning it in the next
>LilyPond Report (no idea about when I'll be working seriously on that,
>hopefully soon), whether before or after 2.16 has been released.  But as
>long as no users are seriously worrying about OSX 10.4 (and the only one
>actually offering a bounty was not doing this out of personal need, but
>because of sympathy with possibly mythical legacy users), there does not
>seem much of a point to expend the work, even if it is just few hours,
>for caring.

I will take a stab at the two-line patch tomorrow.

Thanks,

Carl






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


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

Dubious recommendation about ragged-last-bottom in spacing.itely

[Pavel Roskin]

Hello!

There is a strange suggestion in Documentation/notation/spacing.itely:


@item ragged-last-bottom
@funindex ragged-last-bottom

If set to false, systems will spread vertically down the last
page.  Pieces that amply fill two pages or more should have this
set to true.


I believe the opposite should be suggested.  Large scores should set
ragged-last-bottom to false.  For a large score, it's easy to fill a
whole number of pages without much distortion.  Doing so increases
readability of the piece without increasing the number of the page
turns.

I checked some scores on imslp.org, and I don't see many "ragged
bottoms" at the end of many serious works.

I suggest changing "true" to "false".  I believe it was meant that way
by the author of the text.

-- 
Regards,
Pavel Roskin

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

Re: Glyphs for Kievan Notation (issue 4951062)

[janek . lilypond]

This was pushed as 18dda6b2f5fbea91a174b60eb22bbb73591b9b64
Thanks, Aleksandr and all reviewers!
Janek

http://codereview.appspot.com/4951062/

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

Re: google summer of code

[Janek Warchoł]

2012/2/9 Graham Percival :
> Does anybody feel like submitting a proposal to google summer of
> code?  IIRC students must be registered at a school, so this isn't
> something that would help any senior developer, but it's still
> $5500 for any student that ends up working on lilypond over the
> summer, plus $500 for the organization.
>
> http://www.google-melange.com/gsoc/homepage/google/gsoc2012

> [some discussion]

So, are there any reasons not to do it?  In particular, do you think
we might have problems with availability of mentors?
If there are no objections, i'll start a separate thread in which
we'll discuss what should be on our "ideas list".

cheers,
Janek

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

Re: Dubious recommendation about ragged-last-bottom in spacing.itely

[Janek Warchoł]

2012/2/10 Pavel Roskin :
> Hello!
>
> There is a strange suggestion in Documentation/notation/spacing.itely:
>
> 
> @item ragged-last-bottom
> @funindex ragged-last-bottom
>
> If set to false, systems will spread vertically down the last
> page.  Pieces that amply fill two pages or more should have this
> set to true.
> 
>
> I believe the opposite should be suggested.  Large scores should set
> ragged-last-bottom to false.  For a large score, it's easy to fill a
> whole number of pages without much distortion.  Doing so increases
> readability of the piece without increasing the number of the page
> turns.
>
> I checked some scores on imslp.org, and I don't see many "ragged
> bottoms" at the end of many serious works.
>
> I suggest changing "true" to "false".  I believe it was meant that way
> by the author of the text.

+1

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

some comments and complaints on the code (issue 5651069)

[janek . lilypond]

Reviewers: milimetr88,

Message:
Hi,

together with Luke (milimet...@gmail.com) we're preparing a fix for
http://code.google.com/p/lilypond/issues/detail?id=1546

We had a really hard time on Wednesday trying to understand how the
current code works; after 4 hours of reading we have some grasp now.  In
order not to loose this knowledge, we decided to add it as comments -
it'd be good if you confirmed we understood things correctly.
We also added some questions - if you can answer them, it would be
great!

Description:
some comments and complaints on the code

direction.hh: added a #define loop for_UP_and_DOWN()
  for iterating through: {UP, DOWN}
minor changes in note-collision.cc, some comments etc.

Please review this at http://codereview.appspot.com/5651069/

Affected files:
  M flower/include/direction.hh
  M lily/accidental-placement.cc
  M lily/grob.cc
  M lily/include/grob-interface.hh
  M lily/include/note-collision.hh
  M lily/include/note-column.hh
  M lily/include/staff-symbol-referencer.hh
  M lily/note-collision.cc



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

Re: some comments and complaints on the code (issue 5651069)

[Carl . D . Sorensen]

Thanks for taking this on, Janek.

I don't know what the response will be to for_UP_and_DOWN(d).  The last
time somebody proposed a change, it was resisted because the do{}
flip(d)!=UP idiom seemed simple enough to be acceptable.

But I think the new idiom is more readable, and if there are no
performance issues with it, I'd be in favor of it.

I have some specific comments below about spacing, comment format, and
comment placement.  In general, I think it's a good idea for you to add
comments.  I'm not sure it's a good idea to add TODO about missing
comments (but it might be).  I'm really hesitant to have you add
comments that say "please add a comment", since it's not clear to whom
the please is directed.

Thanks,

Carl



http://codereview.appspot.com/5651069/diff/1/lily/include/note-column.hh
File lily/include/note-column.hh (right):

http://codereview.appspot.com/5651069/diff/1/lily/include/note-column.hh#newcode39
lily/include/note-column.hh:39: /**
IMO, this comment belongs in the definition, not the declaration

http://codereview.appspot.com/5651069/diff/1/lily/include/staff-symbol-referencer.hh
File lily/include/staff-symbol-referencer.hh (right):

http://codereview.appspot.com/5651069/diff/1/lily/include/staff-symbol-referencer.hh#newcode53
lily/include/staff-symbol-referencer.hh:53: /**
Again, comment in the definition, not the declaration

http://codereview.appspot.com/5651069/diff/1/lily/note-collision.cc
File lily/note-collision.cc (right):

http://codereview.appspot.com/5651069/diff/1/lily/note-collision.cc#newcode369
lily/note-collision.cc:369: ->set_property ("direction", scm_from_int
(dir));
I think the indentation in the old code is correct.  The -> should be
indented, since it's not the start of a statement.

But if this spacing is what's produced by fixcc.py, then we should keep
it.

http://codereview.appspot.com/5651069/diff/1/lily/note-collision.cc#newcode377
lily/note-collision.cc:377: /**
I don't like the double * following the /.  Is this a standard anywhere
else in lilypond?

http://codereview.appspot.com/5651069/diff/1/lily/note-collision.cc#newcode552
lily/note-collision.cc:552: for_UP_and_DOWN (d) // please, make a
comment to this loop (better than the above one...)
To whom is the "please" directed?  Is there anybody who is better than
you right now to comment the loop?

http://codereview.appspot.com/5651069/diff/1/lily/note-collision.cc#newcode588
lily/note-collision.cc:588: {
I don't know that we have a specification for this, or if it can be
handled by fixcc.py, but for consistency with the way we indent braces
with loops and if, the braces should be indented two spaces, IMO.

http://codereview.appspot.com/5651069/

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

Re: some comments and complaints on the code (issue 5651069)

[joeneeman]

http://codereview.appspot.com/5651069/diff/1/lily/accidental-placement.cc
File lily/accidental-placement.cc (right):

http://codereview.appspot.com/5651069/diff/1/lily/accidental-placement.cc#newcode211
lily/accidental-placement.cc:211: * @return A vector of
Accidental_placement_entrys
Please don't just comment on the type (unless it's SCM in which case you
can say which scheme type it is).

http://codereview.appspot.com/5651069/

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

git repository for osx-lilypond

[Carl Sorensen]

I'm trying to see if it's possible to keep support for OSX 10.4, and at
the same time, have the proper version of lilypond shown in the About box.

In order to try to track this down, I'd like to have a git history to see
how things have changed.

According to issue 980, they're hosted at
github.com/pnorcks/lilypad-macos, but that repo was last updated 2 years
ago.

There's also a mirror at http://repo.or.cz/w/lilypad-macos.git, but that
also has its last update 2 years ago.

The place where GUB gets its lilypad editor is

http://lilypond.org/download/gub-sources/osx-lilypad-universal/


This has tar.gz files; 0.5 is from August 2011 and 0.6 is from December
2011.   But there is no git repo there.

I thought maybe it was on Jan's github account, https://github.com/janneke/

But that has only gub, schikkers-list, yodl, and mpp.

Google searches have turned up nothing.

Can anybody tell me where I might find an up-to-date repository?

Thanks,

Carl


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