Contemporary notation (Re: GSoC projects list)

[Urs Liska]

One thing I'm missing about our projects list is actual *notation*
projects. Currently (i.e. when the current wave of purges has been
completed) there is no project that adds to or improves LilyPond's
notation. All projects are important items, but maybe this isn't really
attractive to students.

I have one suggestion for which I could be a mentor, but I would really
prefer to act as *secondary* advisor only, with someone else being the
primary mentor: creating a library for contemporary notation. Obviously
it would be an openLilyLib project again, and I'm not feeling 100%
comfortable with that, but I'm sure it would be attractive for potential
students, and it would also add some prominently visible new features to
LilyPond.

LilyPond's programmability and especially the provision to make enhanced
features available through (more or less) easy-to-use commands is one of
the major features I've been lobbying with over the recent years. And
with regard to contemporary notation this feature outweighs (IMO) the
fact that creating non-standard notation is more complicated than by
using arbitrary drawing tools.

openLilyLib is a suitable framework to build such a contemporary
notation package and making it easily accessible. What I'm thinking of
is not a flat collection of notation elements but rather a hierarchy of
building blocks that can be used to easily build concrete notation elements.

Feedback for that? Any of the more proficient composers out there
willing to join?

Urs

Am 06.02.2017 um 00:24 schrieb Urs Liska:
>
> Hi all,
>
> I'm somewhat worried about LilyPond's GSoC project proposals list.
> Right now I'm purging the web page
> (http://lilypond.org/google-summer-of-code.html) from projects without
> mentors, and I have the feeling when this process is completed we're
> left with an unsatisfactory state.
>
> From the 9 projects that are listed at the time of writing this post
> four are right now scheduled for removal:
>
>   * Grace notes
>   * Improving default beam positioning
>   * Improving compilation behaviour
>   * Improve Slurs and Ties
>
> A fifth project, MusicXML export, is still unclear.
>
> So essentially per now we will have only 4/5 projects left:
>
>   * Improving internal chord structure
>   * Adopting SMuFL
>   * Adding glyph variants
>   * openLilyLib testing and documentation
>
> I find this list quite disappointing, and I'm afraid it won't be
> terribly attractive to potential students. So I strongly encourage
> anybody to suggest further projects, preferably together with a pledge
> to mentor them.
>
> Best
> Urs
>
>
> -- 
> address@hidden
> https://openlilylib.org
> http://lilypondblog.org

-- 
address@hidden
https://openlilylib.org
http://lilypondblog.org