GSoC in contemporary notations

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

GSoC in contemporary notations

Tsz Kiu Pang
Hi all,

I am writing to express my interest in working on LilyPond as part of GNU
in the Google Summer of Code.

I was just looking at the project suggestions, and am interested in working
on contemporary notations. As a composer myself, I do find using Lilypond a
very steep learning curve, especially for contemporary music, where a lot
of workarounds are needed. I hope I can use this opportunity to create an
infrastructure for contemporary notations that will make composers' life
easier. I am also interested in creating a package that covers the style of
composers such as Iannis Xenakis or Elliott Carter.

I am just wondering if there are any suggestions in applying for GSoC and
writing a project proposal?

As for qualifications, I did my undergraduate in Music, majored in
Composition during my honours year, so I have good knowledge in
contemporary notation techniques and the capacity to research further if
required. I am currently a Master student in electrical engineering at the
University of Melbourne. I have only started programming last year but now
I am a tutor in programming/computing in C at the University. Though
scheme/guile is not my strong suit yet (I know the basic syntax and list
operations, but still struggling to count the parentheses), I am willing to
learn more and I believe I will have a good command in scheme/guile in a
few weeks.

Kind regards,
Tsz-Kiu
_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: GSoC in contemporary notations

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

Am 21.03.19 um 06:58 schrieb Tsz Kiu Pang:
> Hi all,
>
> I am writing to express my interest in working on LilyPond as part of GNU
> in the Google Summer of Code.
>
> 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.


> As a composer myself, I do find using Lilypond a
> very steep learning curve, especially for contemporary music, where a lot
> of workarounds are needed.


That's true, and one major issue with that (which a package would
address) is that so many things have to be done from scratch over and
over again, for each new project, or at least by each new user dealing
with them.


> I hope I can use this opportunity to create an
> infrastructure for contemporary notations that will make composers' life
> easier. I am also interested in creating a package that covers the style of
> composers such as Iannis Xenakis or Elliott Carter.


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.


>
> I am just wondering if there are any suggestions in applying for GSoC and
> writing a project proposal?


Basically you'd have to discuss a proposal on this list or in a somewhat
more private circle (although generally as much as possible
communication should be in public space) and find a way to show us your
qualification, potential and way of communication until April 9.  A bit
more on that below.


>
> As for qualifications, I did my undergraduate in Music, majored in
> Composition during my honours year, so I have good knowledge in
> contemporary notation techniques and the capacity to research further if
> required. I am currently a Master student in electrical engineering at the
> University of Melbourne. I have only started programming last year but now
> I am a tutor in programming/computing in C at the University. Though
> scheme/guile is not my strong suit yet (I know the basic syntax and list
> operations, but still struggling to count the parentheses), I am willing to
> learn more and I believe I will have a good command in scheme/guile in a
> few weeks.


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.

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.

###

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.

HTH
Urs

>
> Kind regards,
> Tsz-Kiu
> _______________________________________________
> lilypond-devel mailing list
> [hidden email]
> https://lists.gnu.org/mailman/listinfo/lilypond-devel
_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: GSoC in contemporary notations

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 <[hidden email]> 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 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 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?

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 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.

Regards,
Tsz Kiu


> _______________________________________________
> lilypond-devel mailing list
> [hidden email]
> https://lists.gnu.org/mailman/listinfo/lilypond-devel
>
_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: GSoC in contemporary notations

Urs Liska-3
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 <[hidden email]
> <mailto:[hidden email]>> 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
>     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 ...

>
>     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.


>
>     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 ;-)

Best
Urs


>
> Regards,
> Tsz Kiu
>
>     _______________________________________________
>     lilypond-devel mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.gnu.org/mailman/listinfo/lilypond-devel
>
_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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 <[hidden email]> 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
>>> [hidden email]
>>> https://lists.gnu.org/mailman/listinfo/lilypond-devel
>>>
>>
_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: GSoC in contemporary notations

Urs Liska-3
This is directed at the other devs, to (please) join the conversation

Am 01.04.19 um 08:30 schrieb Tsz Kiu Pang:

>
>>     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.
>

To make things clear for those who have not been following closely: What
Tsk Kiu is saying is that he expects being able to

  * commit 8-10 hours per week during the bonding period when he isn't
    officially required to spend specific working time yet. So these
    would be "additional"
  * commit only 8-10 hours during a three week period within the
    official project time
  * [and of course the actual situation during exams is not fully
    predictable]

What do you make of this?

Best
Urs

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: GSoC in contemporary notations

Tsz Kiu Pang
On Mon, 1 Apr 2019 at 18:04, Urs Liska <[hidden email]> wrote:

> This is directed at the other devs, to (please) join the conversation
> Am 01.04.19 um 08:30 schrieb Tsz Kiu Pang:
>
> 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.
>
>
> To make things clear for those who have not been following closely: What
> Tsk Kiu is saying is that he expects being able to
>
>    - commit 8-10 hours per week during the bonding period when he isn't
>    officially required to spend specific working time yet. So these would be
>    "additional"
>    - commit only 8-10 hours during a three week period within the
>    official project time
>    - [and of course the actual situation during exams is not fully
>    predictable]
>
> And not to mention that, from 29 July onward, I will only be able to
commit ~16 hours per week.
Though, I can commit ~38 hours per week during from 28th June to 29th July.
Unless this is still fine, I think it is probably a better idea for me to
apply next year when I can have a lighter study load.
And I must apologise to Urs for taking up your time in the past couple of
weeks.

>
>
> What do you make of this?
>
> Best
> Urs
>
_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: GSoC in contemporary notations

Tsz Kiu Pang
In reply to this post by Urs Liska-3
Hi Urs,

Whether or not I'll be suitable to participate in GSoC, I am keen to dive
into openlilylib.

On Thu, 21 Mar 2019 at 17:58, Urs Liska <[hidden email]> wrote:

>
> 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.
>

I was looking at the issues page on oll-core and there were a couple that
you opened two weeks ago.
Also, it seems like there is quite a number of TODOs in the codes (in
oll-core/scheme, oll-core/util, and oll-core/internal).
I am just wondering would these be "some small things" that I can do to the
oll package?

Kind regards,
Tsz Kiu

>
> HTH
> Urs
>
> >
> > Kind regards,
> > Tsz-Kiu
> > _______________________________________________
> > lilypond-devel mailing list
> > [hidden email]
> > https://lists.gnu.org/mailman/listinfo/lilypond-devel
> _______________________________________________
> lilypond-devel mailing list
> [hidden email]
> https://lists.gnu.org/mailman/listinfo/lilypond-devel
>
_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: GSoC in contemporary notations

Urs Liska-3
Hi Tsz Kiu,

Am 03.04.19 um 13:48 schrieb Tsz Kiu Pang:
> Hi Urs,
>
> Whether or not I'll be suitable to participate in GSoC, I am keen to
> dive into openlilylib.


That would be great!


>
> On Thu, 21 Mar 2019 at 17:58, Urs Liska <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>
>     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.
>
> I was looking at the issues page on oll-core and there were a couple
> that you opened two weeks ago.
> Also, it seems like there is quite a number of TODOs in the codes (in
> oll-core/scheme, oll-core/util, and oll-core/internal).
> I am just wondering would these be "some small things" that I can do
> to the oll package?


Most of the items on the issue tracker don't look like suitable
first-time tasks. But there are actually two issues you could have a
look at, both having to do with module loading. This may not be as
attractive as adding shiny new features, but I think it is a good way to
get a better understanding of how things are working in there.

https://github.com/openlilylib/oll-core/issues/43
https://github.com/openlilylib/oll-core/issues/39

43 is actually a "current" idea, but 39 is a limitation that really
should be removed - especially since just last week someone else
stumbled over the problem.

Both issues could be tackled by looking at the module handling code.

Handling metadata (issue 43) is done within \loadPackage, so you can
follow the procedure calls to see how that package.cnf file is processed
and metadata registered. \loadModule would then have to check not only
(as it currently does) whether the entry file is found on disk but also
(and before) whether the requested module is registered in the package's
metadata.

Preloading package/module options would basically work by integrating a
workaround. Currently options are set after a package or module has been
successfully loaded. This means that *while loading* the package or
module the user option is not available yet. Essentially using the \with
{} clause to set options is currently only a nice way to do the
package/module configuration for a user file, but user-provided options
can't be used to control the way the package/module is *loaded*. I see
two appraoches on how to solve the problem, and both are described in
the issue on Github. [Edit: Actually I think the approach I just thought
of and added as a comment there is the way to go]

Having thought of all this and doing some investigation *while* writing
this email I came to the conclusion that looking into issue 39 with the
approach described in
https://github.com/openlilylib/oll-core/issues/39#issuecomment-479813636 
should be a good idea to start with, both getting a good idea how things
work in oll-core and providing some very valuable improvement.

Best
Urs

>
> Kind regards,
> Tsz Kiu
>
>
>     HTH
>     Urs
>
>     >
>     > Kind regards,
>     > Tsz-Kiu
>     > _______________________________________________
>     > lilypond-devel mailing list
>     > [hidden email] <mailto:[hidden email]>
>     > https://lists.gnu.org/mailman/listinfo/lilypond-devel
>     _______________________________________________
>     lilypond-devel mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.gnu.org/mailman/listinfo/lilypond-devel
>
_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel