Re: GSoC 2016

[Urs Liska]

Am 27. Januar 2016 02:37:17 MEZ, schrieb Paul Morris <address@hidden>:
>> On Jan 26, 2016, at 5:24 AM, David Kastrup <address@hidden> wrote:
>> 
>>> So my question could be rephrased: Would it be acceptable to suggest
>a
>>> GSoC project if such an external library is *not* going to be
>included
>>> in LilyPond directly? With regard to the project I'm convinced that
>>> this would work out in the context/frame of a GSoC project.
>> 
>> I think so.  Now part of the GSoC idea (which has so far not worked
>very
>> convincingly for us) is to make a student build long-term ties into a
>> project.  For this to work, it would be a good idea if the student
>had
>> an actual long-term interest in scholarly editions rather than just
>some
>> programming project.
>
>Sounds good.  So ScholarLY can be added as a project to the ideas list
>with Urs as a mentor.  

I've already uploaded #4754.

>
>Did I understand correctly that something like a "CTAN for LilyPond”
>(CLAN) is already in the works and so wouldn’t be good for a GSoC
>project?

I understood that David had doubts about it even before I mentioned ongoing 
work.

>
>Just thinking aloud…  what about a project focused on improving the
>Edition Engraver and possibly integrating it into LilyPond?  Or is it
>better for it to also be one of these external packages / libraries?  

The "external" thing shouldn't be an issue. But we have just started 
re-implementing the edition-engraver from scratch, and I'm very much motivated 
to bring this as far as possible until May (when I'll present a related paper 
at the Music Encoding Conference).
So while this is a very good idea I hope there won't be "enough" left for a 
GSoC project.

>
>I assume that the MusicXML export/import would still be a valid project
>since there is more to do there, right?
>

Definitely. However, we should maybe make this somewhat more concrete.

>While we’re at it, one thing I’ve thought about is simplifying vertical
>spacing changes.  Basically something like this[1] but possibly
>integrated into LilyPond.  One idea is that alongside padding,
>minimum-distance, and basic-distance, there could be a property like
>“scaling”.  Then the properties padding, minimum-distance, and
>basic-distance would each be multiplied by “scaling” before being put
>into effect.  So you could do things like:
>
>\new Staff \with {
> \override VerticalAxisGroup.default-staff-staff-spacing.scaling = #1.2
>} { … }
>
>\paper {
>  system-system-spacing.scaling = #0.9
>}
>
>That gives the user one property to change to simply increase or
>decrease vertical spacing without having to look up default values (or
>guess) or have to decide whether to change padding, minimum-distance,
>or basic-distance or some combination of them.
>
>Thoughts on this idea in general?  And/or as a GSoC project?  (I’m not
>sure that it would be enough or well-suited for GSoC.)

In general I am very much in favor of everything that makes these spacing 
issues more accessible. But it sounds too small.

Best Urs
>
>[1]
>https://github.com/openlilylib/openlilylib/tree/master/notation-snippets/scale-vertical-spacing
>
>-Paul

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.