Re: GSoC in contemporary notations

[Tsz Kiu Pang]

Hi Urs,
Thank you for your kind advice.

On Fri, 29 Mar 2019 at 00:03, Urs Liska <address@hidden> wrote:

> Hi Tsz Kiu,
>
> I don't know if you intentionally replied personally instead of to the
> list, and in general as much communication as possible should be kept
> public. But since the nature of what you're writing could be considered
> personal to some extent I'll reply in private as well.
>

Sorry that was a mistake, I will try to keep the communication public from
now on.

> Am 28.03.19 um 13:28 schrieb Tsz Kiu Pang:
>
> Hi Urs,
>
> Sorry for the late reply, has been swamped by school work in the past few
> days.
>
>
> OK. I'm in a hurry, so just some short comments where necessary.
>
>
>
> On Sat, 23 Mar 2019 at 10:22, Urs Liska <address@hidden> wrote:
>
>> 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 starting
>>> one for one specific composer (the one I had always thought of as a
>>> basis was Lachenmann, but Xenakis or Carter are equally valid choices),
>>> 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 https://scheme-book.ursliska.de
>>>     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. giving
>>>     a pretty slow-paced introduction)
>>>   * Understanding how Scheme is hooked into LilyPond (on a general level)
>>>   * (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 and
>>> 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
>> http://lilypond.org/doc/v2.19/Documentation/extending/index. 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 ...
>>
> I did not have time in the past few days to go through the official
> reference yet, but I did find your tutorial on scheme really helpful since
> it is given from a Lilypond perspective, rather than a general one.
>
>>
>> Just last week I've decided to start with a new openLilyLib package:
>>> https://github.com/openlilylib/grob-tools. The repository on Github is
>>> empty, and right now I only have one single uncommited function locally,
>>> 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 your
>>> 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.
>>
>>
>> This does sound good, a community effort on this project can probably let
> me focus on a more abstract level of things.
>
>>
>> What you should do now is:
>>>
>>>   * [of course dive more into Scheme]
>>>   * get an understanding of openLilyLib with
>>>     a) https://github.com/openlilylib/oll-core/wiki
>>>     b) the code in that repository
>>>     c) looking at how other openLilyLib packages are built within that
>>>     infrastructure
>>>   * Form an idea how a contemporary notation package could be approached
>>>     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 ;-)
>>
>
> I just have some concerns.
> Sorry I might have overestimated myself in the past week, but I realised I
> might not be able to commit for 30+ hours per week during May since I am in
> Australia, the exams are usually in May-early June.
>
>
> In general "full time" commitment is expected throughout the official
> coding period, and we can't make substantial exceptions. However, a) the
> coding period only begins May 27, the "bonding period" is explicitly not
> included in the full-time commitment. b) it is possible to circumvent the
> issue by starting earlier. I have no idea about your workload during and
> before exams, but if you should be accepted (which is announced May 6) and
> are able to do *some* work in May (not full-time) that would otherwise be
> part of your work in June that should be OK. When exactly would your exams
> be over? What would be your estimate for being able to do *something* in
> May?
>
> Although it is hard to predict exactly what would be my workload in the
next couple of months, I can say I would be able to commit 8-10 hours per
week once I've got accepted.
Though I have just realised I was mistaken before, that my exams is from
11th to 28th June. I can still commit 8 hours per week during that time.
However, considering that it is way into June, I am not sure whether that
will fit into the GSoC timeline.
Worst scenario is that, I might just try to apply for GSoC next year when I
have less study load.

Having said that, I am passionate about this project.
> I just want to check in what is the expectation from you guys in terms of
> commitment?
> I might reevaluate myself in these couple of days.
> Just in case, if I realise in these few days that I do not have the
> capacity for GSoC, would I still be able to contribute to this (or Lilypond
> dev in general) in anyway?
> I would definitely be keen to contribute to the Lilypond community within
> or outside GSoC.
>
>
> Of course that would be great. There's absolutely nothing that speaks
> against this.
>
Thank you for your support.

Kind regards,
Tsz Kiu

> Best
> Urs
>
>
> Best
>> Urs
>>
>>
>>
>> Regards,
>> Tsz Kiu
>>
>>
>>> _______________________________________________
>>> lilypond-devel mailing list
>>> address@hidden
>>> https://lists.gnu.org/mailman/listinfo/lilypond-devel
>>>
>>