Am 27. Januar 2016 02:37:17 MEZ, schrieb Paul Morris <p...@paulwmorris.com>:
>> On Jan 26, 2016, at 5:24 AM, David Kastrup <d...@gnu.org> 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.
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
