[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GSoC 2016

From: Urs Liska
Subject: Re: GSoC 2016
Date: Wed, 27 Jan 2016 07:10:49 +0100
User-agent: K-9 Mail for Android

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
>>> GSoC project if such an external library is *not* going to be
>>> 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
>> 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
>> an actual long-term interest in scholarly editions rather than just
>> 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

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

>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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]