Re: GSoC in contemporary notations

[Urs Liska]

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 > 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
> lilypond-devel@gnu.org 
> https://lists.gnu.org/mailman/listinfo/lilypond-devel
___
lilypond-devel mailing list
lilypond-devel@gnu.org 
https://lists.gnu.org/mailman/listinfo/lilypond-devel


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GSoC in contemporary notations

[Tsz Kiu Pang]

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  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
> > lilypond-devel@gnu.org
> > https://lists.gnu.org/mailman/listinfo/lilypond-devel
> ___
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-devel
>
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GSoC in contemporary notations

[Tsz Kiu Pang]

On Mon, 1 Apr 2019 at 18:04, Urs Liska  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
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GSoC in contemporary notations

[Urs Liska]

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
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

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

Re: GSoC in contemporary notations

[Urs Liska]

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

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  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
> lilypond-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-devel
>
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GSoC in contemporary notations

[Urs Liska]

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
  

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
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel