GSoC 2017 - Improve internal chord structure

[Diogo Canut]

Hello!

My name is Diogo Canut, a computer science student at Federal University of
Uberlandia. I am interested in improve internal chord structure project for
Google Summer of Code. I have a background with functional languages like
Haskell and Common Lisp. I already builded the lilypound source's from git
and currently I am reading the contributor's guide. Can someone help/guide
me in this journey?

Thanks all,
Diogo Canut
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Interested in GsoC 2017

[Adon Shapiro]

Hello,

I am interested in applying to Google Summer of Code and in
contributing to LilyPond this summer. Specifically, I'm intrigued by
improving internal chord structure as listed on the project ideas
page, and I was wondering if anyone could give me some advice as to
familiarizing myself with the project so I might write a more
effective project proposal. I would love to get involved with this and
any help would be greatly appreciated!

Thanks,
Adon Shapiro

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

Font loading (was: GSoC 2017)

[Urs Liska]

Am 11. März 2017 12:48:55 MEZ schrieb Werner LEMBERG :
>> Here's a caveat (but I'm not sure if that relates to the GSoC
>> project).  Some time ago I worked on a modified system to load the
>> notation font from system installed fonts too, which would
>> substantially reduce the amount of housekeeping when using
>> alternative notation fonts.  But I got stuck at a well-meant but
>> nasty behaviour of fontconfig that made it basically impossible:
>> fontconfig *always* returns a reference to a font.  This sounds good
>> but is a real problem with notation fonts.
>> 
>> The idea behind that behaviour is that when an application requests
>> a font it *needs* a font, and when a particular font isn't installed
>> in the system there has to be a fallback font.  The problem is that
>> with notation fonts it is totally unclear what an appropriate
>> replacement font is.  What I wanted (and what is necessary) would be
>> the information that a requested font (e.g. LilyJAZZ) isn't
>> available - then LilyPond could explicitly fall back to Emmentaler.
>> But instead fontconfig insists on giving back *something*, so when
>> LilyJAZZ isn't installed you may end up with a score trying to
>> typeset the noteheads with Comic Sans or Times New Roman.
>
>There is a solution to this problem, cf.
>
>https://lists.freedesktop.org/archives/fontconfig/2012-August/004252.html
>
>

Lpoks interesting. I'll see if I can make further sense of it.

Urs

> Werner

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

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

Re: GSoC 2017

[Werner LEMBERG]

> Here's a caveat (but I'm not sure if that relates to the GSoC
> project).  Some time ago I worked on a modified system to load the
> notation font from system installed fonts too, which would
> substantially reduce the amount of housekeeping when using
> alternative notation fonts.  But I got stuck at a well-meant but
> nasty behaviour of fontconfig that made it basically impossible:
> fontconfig *always* returns a reference to a font.  This sounds good
> but is a real problem with notation fonts.
> 
> The idea behind that behaviour is that when an application requests
> a font it *needs* a font, and when a particular font isn't installed
> in the system there has to be a fallback font.  The problem is that
> with notation fonts it is totally unclear what an appropriate
> replacement font is.  What I wanted (and what is necessary) would be
> the information that a requested font (e.g. LilyJAZZ) isn't
> available - then LilyPond could explicitly fall back to Emmentaler.
> But instead fontconfig insists on giving back *something*, so when
> LilyJAZZ isn't installed you may end up with a score trying to
> typeset the noteheads with Comic Sans or Times New Roman.

There is a solution to this problem, cf.

  https://lists.freedesktop.org/archives/fontconfig/2012-August/004252.html


 Werner

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

Re: GSoC 2017

[Urs Liska]

Am 06.03.2017 um 23:46 schrieb tisimst:
> On Mon, Mar 6, 2017 at 3:34 PM, Urs Liska [via Lilypond] <
> ml-node+s1069038n200802...@n5.nabble.com> wrote:
>
>> Of course it is good to have optical sizes - even if the vast majority
>> of LilyPond users may not even be aware of it. And it's not depending on
>> the number of different sizes in a score but already on a single staff
>> size. If you want to engrave a pocket score requiring very small staves
>> it's obviously better to have optical sizes that aren't simply scaled
>> down.
>> So we should definitely use the optical sizes equally when font handling
>> is done by SMuFL, but (as you say) should be prepared that more or less
>> any other font won't have it. (None of your fonts have it, Abraham,
>> isn't it?).
>
> At the moment, that's correct. I'm hoping to change this sometime this
> year, though, time permitting. The root of this idea though is, how to
> handle fonts that only have a single size and those that have multiple
> sizes?
>
I think this should be manageable. If we have proper access to the fonts
(see the other part of my previous post) we can rather easily redirect
non-existent files for optical sizes to the default "medium" size.

Urs

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

Re: GSoC 2017

[tisimst]

On Mon, Mar 6, 2017 at 3:34 PM, Urs Liska [via Lilypond] <
ml-node+s1069038n200802...@n5.nabble.com> wrote:

> Of course it is good to have optical sizes - even if the vast majority
> of LilyPond users may not even be aware of it. And it's not depending on
> the number of different sizes in a score but already on a single staff
> size. If you want to engrave a pocket score requiring very small staves
> it's obviously better to have optical sizes that aren't simply scaled
> down.
> So we should definitely use the optical sizes equally when font handling
> is done by SMuFL, but (as you say) should be prepared that more or less
> any other font won't have it. (None of your fonts have it, Abraham,
> isn't it?).


At the moment, that's correct. I'm hoping to change this sometime this
year, though, time permitting. The root of this idea though is, how to
handle fonts that only have a single size and those that have multiple
sizes?




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/GSoC-2017-tp200631p200805.html
Sent from the Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GSoC 2017

[Urs Liska]

lear what an appropriate replacement
font is. What I wanted (and what is necessary) would be the information
that a requested font (e.g. LilyJAZZ) isn't available - then LilyPond
could explicitly fall back to Emmentaler. But instead fontconfig insists
on giving back *something*, so when LilyJAZZ isn't installed you may end
up with a score trying to typeset the noteheads with Comic Sans or Times
New Roman.

I think the implication for GSoC is: If we don't find a solution to fix
this issue (maybe fontconfig has been updated in the meantime, or we can
convince the developers to do something about it) we will probably have
to load the SMuFL fonts from the LilyPond installation directory just
like we do now.

Best
Urs

>
> Those are just some thoughts to keep the conversation going.
>
> Best,
> Abraham
>
> [1] https://w3c.github.io/smufl/gitbook/
>
>
>
>
> --
> View this message in context: 
> http://lilypond.1069038.n5.nabble.com/GSoC-2017-tp200631p200794.html
> Sent from the Dev mailing list archive at Nabble.com.
> ___
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-devel

-- 
u...@openlilylib.org
https://openlilylib.org
http://lilypondblog.org


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

Re: GSoC 2017

[Werner LEMBERG]

> 3. IIUC, this was just a set of overrides and callback functions
>picking up the correct symbols from a smufl font, doing the
>mapping by glyph name.

I think this helps already a lot – such a mapping has to be
implemented anyway, at least in `convert-ly'.


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

Re: GSoC 2017

[Urs Liska]

Am 06.03.2017 um 23:16 schrieb tisimst:
> On Mon, Mar 6, 2017 at 2:34 PM, Noeck [via Lilypond] <
> ml-node+s1069038n200797...@n5.nabble.com> wrote:
>
>> 3. IIUC, this was just a set of overrides and callback functions picking
>> up the correct symbols from a smufl font, doing the mapping by glyph
>> name. So pretty much all you could do without touching lilypond directly.
>> I guess for the GSoC the approach would be quite different and I hope
>> Abraham can point into the right direction.
>>
> Personally, I think there's not much more that can be done with what is
> already in OLL, but I don't think that's what we want done anyway. Full
> SMuFL integration would be a more substantial improvement, IMHO.

Indeed. We want to make that OLL approach obsolete by not only
"supporting" SMuFL natively but by switching completely to *using* it as
LilyPond's notation font encoding.

Urs

>
> Best,
> Abraham
>
>
>
>
> --
> View this message in context: 
> http://lilypond.1069038.n5.nabble.com/GSoC-2017-tp200631p200799.html
> Sent from the Dev mailing list archive at Nabble.com.
> ___
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-devel

-- 
u...@openlilylib.org
https://openlilylib.org
http://lilypondblog.org


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

Re: GSoC 2017

[tisimst]

On Mon, Mar 6, 2017 at 2:34 PM, Noeck [via Lilypond] <
ml-node+s1069038n200797...@n5.nabble.com> wrote:

> 1. Nathan was coding this, I just included this into oll and wrote the
> post.


Correct.


> 2. I guess it still works.
>

Yep. Mostly without problems, but it does have its limitations.


> 3. IIUC, this was just a set of overrides and callback functions picking
> up the correct symbols from a smufl font, doing the mapping by glyph
> name. So pretty much all you could do without touching lilypond directly.
> I guess for the GSoC the approach would be quite different and I hope
> Abraham can point into the right direction.
>

Personally, I think there's not much more that can be done with what is
already in OLL, but I don't think that's what we want done anyway. Full
SMuFL integration would be a more substantial improvement, IMHO.

Best,
Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/GSoC-2017-tp200631p200799.html
Sent from the Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GSoC 2017

[Noeck]

Hi,

Am 06.03.2017 um 09:41 schrieb Urs Liska:
>>   http://lilypondblog.org/2014/01/smufl-fonts-in-lilypond/
>>
>> I don't know whether this is still up to date.
> Oh, me neither.
> Joram?

1. Nathan was coding this, I just included this into oll and wrote the post.
2. I guess it still works.
3. IIUC, this was just a set of overrides and callback functions picking
up the correct symbols from a smufl font, doing the mapping by glyph
name. So pretty much all you could do without touching lilypond directly.
I guess for the GSoC the approach would be quite different and I hope
Abraham can point into the right direction.

Cheers,
Joram

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

Re: GSoC 2017

[tisimst]

On Mon, Mar 6, 2017 at 1:42 AM, ul [via Lilypond] <
ml-node+s1069038n200762...@n5.nabble.com> wrote:

>
>
> Am 06.03.2017 um 07:44 schrieb Werner LEMBERG:
> >>> Not yet :-)  I can only second what Urs said.
> >> I think we (i.e. Abraham and you) should give Matthew some more
> >> concrete pointers on where to start investigating.
> > Can you send him our e-mail conversation regarding this topic?
> > Currently, I'm abroad, not having time to do that by myself.
>
> I'll see what is there - probably it's at least partially in German.
>
> >
> >>> BTW, where are the current instructions to install a font compliant
> >>> to the SMuFL layout?
> >> What context are you talking about here?
> > This context:
> >
> >   http://lilypondblog.org/2014/01/smufl-fonts-in-lilypond/
> >
> > I don't know whether this is still up to date.
>
> Oh, me neither.
> Joram?
>

While I think this background info is helpful, I don't believe it's really
relevant beyond seeing which SMuFL glyphs are being substituted for the
LilyPond ones.

Here's what I see needing to happen to make SMuFL _really_ work with
LilyPond:

1. Full revamp of LilyPond's glyph naming scheme so it coincides with SMuFL
glyph names. The Metafont files would need to be adjusted for this.
2. Refactor LilyPond's glyph metadata subtables into the external SMuFL
font metadata file (thankfully there are many similarities here...)
3. Refactoring everywhere a glyph or the embedded metadata (LILY, LILC,
LILF subtables) is called (thankfully, they are all called by name and not
code point so they're easy to search for) to use the SMuFL glyph names.
4. Provide a mechanism to load a _single_ 3rd-party font file since I think
most SMuFL font designers will not take the effort to create optically
sized ones like Emmentaler. Now, SMuFL does include a dedicated set of
codepoints for the case where the user has a smaller staff next to the
normal sized one so the smaller staff's glyphs _are_ optically sized, but
no application that I know of (including Dorico) utilizes this at yet. It's
not a bad approach since an engraver isn't likely to have more than two
staff sizes in the same score, but I'm not sure it's the _right_ approach.
I like LilyPond's idea of this better.
5. (Optional) Create the "_Text.otf" version of the font files. They are
intended to make including music glyphs in text easier, but I don't see any
reason LilyPond would need to create these files.

>> For LilyPond there *are* of course no such instructions yet, and
> >> otherwise you can install them like regular fonts, it's then up to
> >> the notation application to properly use it.
> > Well, yes.  But music fonts are handled specially in lilypond...
>

They are, but SMuFL is similar enough that it should be a fairly
straightforward transition. I have to believe that Daniel Spreadbury
borrowed a lot of ideas from the LilyPond handles fonts. The nice thing
about SMuFL is that there are dedicated locations on all operating systems
(Mac, Win, Linux) where the files are expected to be located, as explained
in the SMuFL gitbook[1], so there should be no problem pointing to them.
SMuFL fonts are installed in the system font folder just like any normal
text font.

Those are just some thoughts to keep the conversation going.

Best,
Abraham

[1] https://w3c.github.io/smufl/gitbook/




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/GSoC-2017-tp200631p200794.html
Sent from the Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Obsolete GSoC page (was: GSoC 2017)

[Federico Bruni]

Il giorno lun 6 mar 2017 alle 7:20, Urs Liska  ha 
scritto:



Am 06.03.2017 um 05:02 schrieb Werner LEMBERG:
 PS: If I do a google search for `lilypond gsoc', the first hit is 
the

 old

   http://lilypond.org/gsoc.html

 and only the second hit is the current

   http://lilypond.org/google-summer-of-code.html

 Any chance to fix this quickly, for example, to copy the latter 
to

 the former?


I'm very surprised and didn't even know such a page exists!

~/git/lilypond/source$ git grep gsoc
Documentation/es/web/community.itexi:@uref{https://developers.google.com/open-source/gsoc/, 
GSoC} es un
Documentation/es/web/news.itexi:@uref{http://www.google-melange.com/gsoc/homepage/google/gsoc2012, 
El

Documentation/fr/web/community.itexi:@uref{https://developers.google.com/open-source/gsoc/resources/manual,
Documentation/it/web/community.itexi:@uref{https://developers.google.com/open-source/gsoc/, 
GSoC} è un programma
Documentation/ja/web/community.itexi:@uref{https://developers.google.com/open-source/gsoc/, 
GSoC} is a global

Documentation/web/community.itexi:@uref{https://developers.google.com/open-source/gsoc/resources/manual,
Documentation/web/news.itexi:@uref{http://www.google-melange.com/gsoc/homepage/google/gsoc2012,
Documentation/zh/web/news-front.itexi:@uref{http://www.google-melange.com/gsoc/homepage/google/gsoc2012,


This indicates that the GSoC page's translation hasn't been properly
updated for a number of languages, but it doesn't really show how a
gsoc.html should have been triggered.



IIRC there's a page for every @node, so:

$ git grep -i "@node gsoc"
Documentation/ca/web/community.itexi:@node GSoC 2012
Documentation/zh/web/community.itexi:@node GSoC 2012

seems to confirm your hypothesis that the website sync didn't work 
properly.




Is it possible that the HTML file is a leftover that simply hasn't 
been
removed when uploading the updated site (how is that actually done)? 
If

so, I suggest to use a permanent redirect instead of copying over the
content.

Anyway, this should (urgently) be looked at by someone familiar with 
the

website build process.





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

Re: GSoC 2017

[Urs Liska]

Am 06.03.2017 um 07:44 schrieb Werner LEMBERG:
>>> Not yet :-)  I can only second what Urs said.
>> I think we (i.e. Abraham and you) should give Matthew some more
>> concrete pointers on where to start investigating.
> Can you send him our e-mail conversation regarding this topic?
> Currently, I'm abroad, not having time to do that by myself.

I'll see what is there - probably it's at least partially in German.

>
>>> BTW, where are the current instructions to install a font compliant
>>> to the SMuFL layout?
>> What context are you talking about here?
> This context:
>
>   http://lilypondblog.org/2014/01/smufl-fonts-in-lilypond/
>
> I don't know whether this is still up to date.

Oh, me neither.
Joram?

Best
Urs

>> For LilyPond there *are* of course no such instructions yet, and
>> otherwise you can install them like regular fonts, it's then up to
>> the notation application to properly use it.
> Well, yes.  But music fonts are handled specially in lilypond...
>
>
> Werner

-- 
u...@openlilylib.org
https://openlilylib.org
http://lilypondblog.org


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

Re: GSoC 2017

[Werner LEMBERG]

>> Not yet :-)  I can only second what Urs said.
> 
> I think we (i.e. Abraham and you) should give Matthew some more
> concrete pointers on where to start investigating.

Can you send him our e-mail conversation regarding this topic?
Currently, I'm abroad, not having time to do that by myself.

>> BTW, where are the current instructions to install a font compliant
>> to the SMuFL layout?
> 
> What context are you talking about here?

This context:

  http://lilypondblog.org/2014/01/smufl-fonts-in-lilypond/

I don't know whether this is still up to date.

> For LilyPond there *are* of course no such instructions yet, and
> otherwise you can install them like regular fonts, it's then up to
> the notation application to properly use it.

Well, yes.  But music fonts are handled specially in lilypond...


Werner

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

Re: GSoC 2017

[Urs Liska]

Hi Matthew,


Am 06.03.2017 um 05:02 schrieb Werner LEMBERG:
>
>> The first thing will be to get an idea about what happens when
>> LilyPond uses glyphs from the notation font.  How does it locate the
>> font, how does it identify the glyph to choose?  And on the other
>> side, how is the notation font created during LilyPond's build
>> process?  I think this is what you'll want to go for first, as a
>> basis to shape a project description.
>>
>> I assume that Werner Lemberg and Abraham Lee will have to say some
>> more on the technical parts of this project
> Not yet :-)  I can only second what Urs said.

I think we (i.e. Abraham and you) should give Matthew some more concrete
pointers on where to start investigating.


>
> BTW, where are the current instructions to install a font compliant to
> the SMuFL layout?

What context are you talking about here?
For LilyPond there *are* of course no such instructions yet, and
otherwise you can install them like regular fonts, it's then up to the
notation application to properly use it.

Urs

-- 
u...@openlilylib.org
https://openlilylib.org
http://lilypondblog.org


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

Obsolete GSoC page (was: GSoC 2017)

[Urs Liska]

Am 06.03.2017 um 05:02 schrieb Werner LEMBERG:
> PS: If I do a google search for `lilypond gsoc', the first hit is the
> old
>
>   http://lilypond.org/gsoc.html
>
> and only the second hit is the current
>
>   http://lilypond.org/google-summer-of-code.html
>
> Any chance to fix this quickly, for example, to copy the latter to
> the former?

I'm very surprised and didn't even know such a page exists!

~/git/lilypond/source$ git grep gsoc
Documentation/es/web/community.itexi:@uref{https://developers.google.com/open-source/gsoc/,
 GSoC} es un
Documentation/es/web/news.itexi:@uref{http://www.google-melange.com/gsoc/homepage/google/gsoc2012,
 El
Documentation/fr/web/community.itexi:@uref{https://developers.google.com/open-source/gsoc/resources/manual,
Documentation/it/web/community.itexi:@uref{https://developers.google.com/open-source/gsoc/,
 GSoC} è un programma
Documentation/ja/web/community.itexi:@uref{https://developers.google.com/open-source/gsoc/,
 GSoC} is a global
Documentation/web/community.itexi:@uref{https://developers.google.com/open-source/gsoc/resources/manual,
Documentation/web/news.itexi:@uref{http://www.google-melange.com/gsoc/homepage/google/gsoc2012,
Documentation/zh/web/news-front.itexi:@uref{http://www.google-melange.com/gsoc/homepage/google/gsoc2012,


This indicates that the GSoC page's translation hasn't been properly
updated for a number of languages, but it doesn't really show how a
gsoc.html should have been triggered.

Is it possible that the HTML file is a leftover that simply hasn't been
removed when uploading the updated site (how is that actually done)? If
so, I suggest to use a permanent redirect instead of copying over the
content.

Anyway, this should (urgently) be looked at by someone familiar with the
website build process.

Urs

-- 
u...@openlilylib.org
https://openlilylib.org
http://lilypondblog.org


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

Re: GSoC 2017

[Werner LEMBERG]

>> I also would appreciate any help defining this project so I can
>> write an effective proposal.  I am new to LillyPond development, but
>> I have used the program many years ago.

s/LillyPond/LilyPond/

> The first thing will be to get an idea about what happens when
> LilyPond uses glyphs from the notation font.  How does it locate the
> font, how does it identify the glyph to choose?  And on the other
> side, how is the notation font created during LilyPond's build
> process?  I think this is what you'll want to go for first, as a
> basis to shape a project description.
> 
> I assume that Werner Lemberg and Abraham Lee will have to say some
> more on the technical parts of this project

Not yet :-)  I can only second what Urs said.

BTW, where are the current instructions to install a font compliant to
the SMuFL layout?


Werner


PS: If I do a google search for `lilypond gsoc', the first hit is the
old

  http://lilypond.org/gsoc.html

and only the second hit is the current

  http://lilypond.org/google-summer-of-code.html

Any chance to fix this quickly, for example, to copy the latter to
the former?

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

GSoC 2017

[Matthew Sedam]

Hello everyone!

My name is Matthew Sedam, and I am interested in LillyPond for Google
Summer of Code 2017. I am particularly interested in the "Adopt the SMuFL
music font encoding standard" idea. I would like to know what progress, if
any, has been done on this project. I also would appreciate any help
defining this project so I can write an effective proposal. I am new to
LillyPond development, but I have used the program many years ago.

Any help would be appreciated! I am really excited about working on
LillyPond!

Thank you,

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

GSoC 2017

[Urs Liska]

Dear LilyPond community,

I'm happy to inform you that both LilyPond (as part of GNU) and
Frescobaldi have been accepted as mentoring organizations for Google
Summer of Code 2017 :-)

This means we have the chance to get up to four (realistically) students
to work on improving LilyPond and Frescobaldi full-time over the summer
for three months, which is of course a great thing.

The project ideas for LilyPond can be found at
http://lilypond.org/google-summer-of-code.html, those for Frescobaldi at
https://github.com/wbsoft/frescobaldi/wiki/Google-Summer-of-Code.

If you are a full-time enrolled student and think you could apply for
such a project please go ahead. Full information about the program,
including the program rules can be found at
https://summerofcode.withgoogle.com/

If you don't think you want to apply for whatever reason please think
about where you can spread this information so it gets to the inbox of
potential students.

Best wishes for this year's program
Urs


-- 
u...@openlilylib.org
https://openlilylib.org
http://lilypondblog.org


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