[Top][All Lists]

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

Re: GSoC in contemporary notations

From: Urs Liska
Subject: Re: GSoC in contemporary notations
Date: Sat, 23 Mar 2019 00:22:22 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1

Hi Tzk Kiu,

Am 21.03.19 um 13:06 schrieb Tsz Kiu Pang:
Hi Urs,

Thank you for your reply, and thank you so much for asking about my name.

On Thu, 21 Mar 2019 at 17:58, Urs Liska <address@hidden <mailto:address@hidden>> wrote:

    Hi Tsz Kiu Pang (which of these names would you like to be called, or
    should I use all of them like I did?)

Tsz Kiu Pang is fine, though people usually call me Tsz Kiu, which is my first name.

    > I was just looking at the project suggestions, and am interested
    in working
    > on contemporary notations.

    This would be great. While all of our GSoC suggestions would be very
    welcome additions this one would maybe provide the most "visible" and
    spectacular addition, opening up LilyPond for a whole range of
    applications and therefore potential users.

I am glad to hear that my interests align with you guys.

    A specific composer's package would be a secondary package built
    on top
    of a general package, and I think it would be great to aim at
    one for one specific composer (the one I had always thought of as a
    basis was Lachenmann, but Xenakis or Carter are equally valid
    although it is not a requirement to achieve /comprehensive/
    coverage of
    a composer.

Yes, I agree that the secondary package would have to be build on top of a general package, and this is great since I hope this project can make contemporary notation accessible to LilyPond users in a general sense, but not just focusing on one or two composers.

The idea (as far as I have thought about it in the past) is to provide "building blocks" like functions that help create custom elements that behave like slurs ("lines" connecting two notes), elements that use paths to draw custom notation elements and more such basics. On top of that concrete commands should be built and organized maybe by repertoire or composer or whatever. But the building blocks should enable the creation of packages supporting something specific or the creation of a personal library of one's own notation repertoire.

    The Scheme/Guile part has three steps for you to consider:

      * "Counting parentheses" (i.e. the language basics)
        Depending on how far you've got
        might be a useful resource for you. It goes only that far but it
        specifically addresses a) the Scheme language from a dedicated
        LilyPond perspective and b) users counting parentheses (i.e.
        a pretty slow-paced introduction)
      * Understanding how Scheme is hooked into LilyPond (on a general
      * (Learning how openLilyLib ist structured)
      * Learning how to retrieve the relevant information about score
        elements and how to modify them in appropriate places.

    The last one is probably the hardest one since it is pretty opaque
    terribly documented. But it's the crucial one for a contemporary
    notation package - and it's the one where such a package will make it
    hugely easier for people to work with non-standard notation.

They all sound pretty hard, but your website seems like a great resource. I will definitely have a look at it. Regarding learning how Scheme is hooked into LilyPond, what is some other good resource for it, apart from your website?

The "official" reference is at However, one may find it somewhat hard to digest since obviously it is not always written with readers in mind who do not already know a lot about it ...

    Just last week I've decided to start with a new openLilyLib package: The repository on
    Github is
    empty, and right now I only have one single uncommited function
    but the idea is to create building blocks for recurring tasks like
    getting the exact position of objects relative to the staff or to
    another object, enumerating all NoteColumns included in a slur or
    similar things. This will be very much relevant for a contemporary
    notation package. One could either say that you should put much of
    results in that package, or we can try to make development of that
    package a community effort so that would take work from you,
    giving you
    the freedom to go further with the specific challenges.

Making the development as a community effort sounds great, though I cannot say for sure until I have a solid proposal.

What I mean is that to some extent that package could be developed by others ("the community"), relieving you from some of the work. However, I absolutely can't make any promise that this would work out with regard to the community dynamic.

    What you should do now is:

      * [of course dive more into Scheme]
      * get an understanding of openLilyLib with
        b) the code in that repository
        c) looking at how other openLilyLib packages are built within that
      * Form an idea how a contemporary notation package could be
        and discuss that with us
      * Find some small things you could do to openLilyLib package(s)
    to a)
        practice and b) give us an opportunity to assess your work. If we
        have some idea about your current familiarity with the matter
    we can
        find some suggestions for that.

Thank you for your concrete and useful suggestions.
I will definitely learn how to count parentheses and all that, and also try to familiarise myself with openLilyLib. Though if you do not mind, please except a lot of questions from me in these couple of weeks.

Please don't hesitate! The more you interact with us the more we will get to know you. It's also a good way to convince a community of the seriousness of your aspirations ;-)


Tsz Kiu

    lilypond-devel mailing list
    address@hidden <mailto:address@hidden>

reply via email to

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