Re: Google SoC

[Jeffery Shivers]

On Wed, Mar 29, 2017 at 9:31 PM, Carl Sorensen  wrote:
>
> On 3/29/17 6:31 PM, "Winston, Charles R." 
> wrote:
>>
>>I also understand there is a period of "community bonding" for the GSoC.
>>I'd love to hear about that in more detail.
>
> After students are selected and before coding begins (from May 4 to May
> 30), students work to lay the foundation for their success.  This means
> they are involved in the development community, perhaps submitting bug
> fixes or documentation suggestions, reviewing code, and otherwise
> participating in the community.  But you don't need to wait until May 4 to
> start bonding with the LilyPond communityŠ

The GSoC website itself also has the comprehensive descriptions of
things in the timeline, rules, and other sections:
  https://summerofcode.withgoogle.com/how-it-works/#timeline

If you scroll to the bottom/footer, you'll find those and other helpful links.

Also, the last section at:
  http://lilypond.org/website/google-summer-of-code.html

-- 

Jeffery Shivers
 jefferyshivers.com
 soundcloud.com/jefferyshivers

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

Re: Allow 'staff-padding to work with MeasureCounter (issue 312580043 by david.nales...@gmail.com)

[Carl . D . Sorensen]

On 2017/03/29 23:28:40, david.nalesnik wrote:


This is a simple bugfix of something that should have worked since the
MeasureCounter was introduced in 2.17.something.  As such, I don't

think a

Changes entry is warranted.



I would propose simply that I fix that bug only, nothing else -- no

extra

snippet, no changes to the existing snippets (which are already dense

enough

with information).  So I am inclined to upload a patch just with the
scm/define-grobs.scm alterations.


I don't think it needs a Changes entry.

But there should be a regression test that shows the proper function of
the 'staff-padding property on MeasureCounter.  That way, if it were to
break again in the future, we would know it.

We don't need a documentation snippet, but we do need a regtest.



https://codereview.appspot.com/312580043/

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

Re: Google SoC

[Carl Sorensen]

On 3/29/17 6:31 PM, "Winston, Charles R." 
wrote:
>
>I am at this point trying to get familiar with some of the source code
>and reading the documentation. It would be great if you could tell me
>about LilyPond's current way of representing chords. Is there any data
>structure at all that represents a chord beyond
> simply the notes that make it up? In what modules in the code is this
>representation defined and used? And it would be great if you could point
>me toward helpful documentation for this, and for anything else you deem
>appropriate. I appreciate the help‹I'm
> new to LilyPond, and to open source projects in general, and am still
>trying to get a sense of everything.

Please look in the source.  There are four files in scm/ with chord in the
name, and 3 files in lily/ with chord in the name.

Also, you can look in the internals reference for EventChord and
NoteEvent.  The EventChord contains notes in its elements.  The EventChord
is iterated, which creates NoteEvents for each of the notes in the
elements of the EventChord.

Look in the internals reference under Contexts for ChordNames.  The
project doesn't directly involve this context, but it's part of the whole
chord processing system.  Also see the ChordName layout object.

In general, there's not much documentation.  You have to read the source.

>
>
>Also, I've been having trouble with joining the mailing lists. I've
>followed the instructions to subscribe and was told I would receive
>conformation instructions, but I haven't. I understand that the servers
>dealing with that are currently down, so please
> excuse the fact that I'm not able to communicate on those lists at the
>moment. I would appreciate any help you could give me in that regard‹is
>there another way to subscribe to the lists? I really want to dive right
>into the community.

The list moderator says there are no unmoderated requests.  You are
supposed to subscribe, then get an automatically-generated response email,
and respond to that email to activate your account.  Have you lost your
response email due to a spam filter?

BTW, list etiquette on LilyPond list asks that we not top post, and that
we quote only the relevant part of the email to use with inline quoting.
It would be a good idea to start practicing that, I think.


>
>I also understand there is a period of "community bonding" for the GSoC.
>I'd love to hear about that in more detail.

After students are selected and before coding begins (from May 4 to May
30), students work to lay the foundation for their success.  This means
they are involved in the development community, perhaps submitting bug
fixes or documentation suggestions, reviewing code, and otherwise
participating in the community.  But you don't need to wait until May 4 to
start bonding with the LilyPond communityŠ


>And finally, after I have the information about the chord representation
>and have studied the source code and documentation a little more
>thoroughly, it would be great if I could send you a draft of my proposal
>for you to look over and edit.


I'm happy to review a draft of your proposal.  However, best practices on
the GSOC list indicate that the best way to handle draft proposals is to
submit them to the development community for everybody to give feedback
on.  Alternatively, drafts can be submitted to GSOC, and a request to
review can be sent to the devel list, and all who are interested can
review.  It seems that GSOC likes to have the application period be quite
transparent just like the rest of development in open-source communities.
So if you're comfortable with that, I think that would be the best way to
proceed.

Thanks,

Carl


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

Re: Allow 'staff-padding to work with MeasureCounter (issue 312580043 by david.nales...@gmail.com)

[david . nalesnik]

On 2017/03/29 22:00:12, pkx166h wrote:

>
> Sorry, I mean the *first* snippet.  (The count that begins with two

could be

> pushed further from the staff possibly.)



Yes that is probably a good idea (if you could add something that

would normally

collide - would a slur/tie *over* one of the group of notes work? - to

give such

an 'excuse' to use the padding?


There won't be any collisions -- the numbers will automatically avoid
them.

{
  \startMeasureCount
  c''4( c-\accent-\staccato-\marcato g'' d)
  \stopMeasureCount
}

The only good excuse to use staff-padding would be in an example such as
in the snippet I provided with the patch: getting all numbers at the
same level where different content in one measure would ordinarily push
the number higher than the number in another measure.  But as Simon
points out, the usage of staff-padding for this purpose is already well
documented.  There's no need for a new snippet, and I see no convenient
way to slip staff-padding into one of the existing snippets without it
being an "unjustified" change.



Also we should have a changes.tely entry as well - use your original

snippet as

the example there to use the work you have already done.



This is a simple bugfix of something that should have worked since the
MeasureCounter was introduced in 2.17.something.  As such, I don't think
a Changes entry is warranted.

I would propose simply that I fix that bug only, nothing else -- no
extra snippet, no changes to the existing snippets (which are already
dense enough with information).  So I am inclined to upload a patch just
with the scm/define-grobs.scm alterations.



https://codereview.appspot.com/312580043/

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

Re: Improve internal chord structure

[Carl Sorensen]

On 3/29/17 2:13 PM, "David Kastrup"  wrote:

>Carl Sorensen  writes:
>
>> On 3/29/17 8:57 AM, "lilypond-devel on behalf of Renato Fabbri"
>> > renato.fab...@gmail.com> wrote:
>>
>>>Thanks for the feedback.
>>>Yes, I should be an enrolled student by May 4.
>>>
>>>Could you give me examples of what you consider an internal chord
>>>structure
>>>(semitone counting?)?
>> The internal chord structure is a Guile (scheme) list containing
>>pitches,
>> a duration, and events.
>
>I beg to differ.  The tangible representation we are working with is a
>list of note events.  When this list of note events is the result of
>chord entry, some additional information is put in to make identifying
>root/inversion possible.

I agree that your statement is more precise.  In my mind, this project is
about deciding what additional information is necessary to give us all the
semantics we would like to have to be able to properly deduce the
appropriate chord name, and how this additional information should be
stored.

>Other forms may be used for the internals of various chord
>naming/identifying routines, but they are an implementation detail.  The
>note events are the information bottleneck that every chord is passing
>through: if the information in there is not sufficient, it has to be
>amended and one has to see how to get the information best into there
>and out again.

If the information in the list of note events is not sufficient, we now
need to guess the semantics.  This GSOC project won't change that; we
aren't proposing to improve our ability to guess the semantics.

We eventually want to get to the point where when we parse something like
e:m7.5-, we don't just get the pitches, but we get the appropriate
semantic information to properly identify this chord in a rational chord
naming system.  So we'd want to capture the root, the quality, the
inversion, and whatever else needs to be captured.  Once we have that, we
can separate the pitch identification from the naming process.  It should
help separate things.

Thanks,

Carl


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

Re: Allow 'staff-padding to work with MeasureCounter (issue 312580043 by david.nales...@gmail.com)

[pkx166h]

Sorry, I mean the *first* snippet.  (The count that begins with two

could be

pushed further from the staff possibly.)


Yes that is probably a good idea (if you could add something that would
normally collide - would a slur/tie *over* one of the group of notes
work? - to give such an 'excuse' to use the padding?

Also we should have a changes.tely entry as well - use your original
snippet as the example there to use the work you have already done.

James

https://codereview.appspot.com/312580043/

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

Re: Improve internal chord structure

[David Kastrup]

Carl Sorensen  writes:

> On 3/29/17 8:57 AM, "lilypond-devel on behalf of Renato Fabbri"
>  renato.fab...@gmail.com> wrote:
>
>>Thanks for the feedback.
>>Yes, I should be an enrolled student by May 4.
>>
>>Could you give me examples of what you consider an internal chord
>>structure
>>(semitone counting?)?
> The internal chord structure is a Guile (scheme) list containing pitches,
> a duration, and events.

I beg to differ.  The tangible representation we are working with is a
list of note events.  When this list of note events is the result of
chord entry, some additional information is put in to make identifying
root/inversion possible.

Other forms may be used for the internals of various chord
naming/identifying routines, but they are an implementation detail.  The
note events are the information bottleneck that every chord is passing
through: if the information in there is not sufficient, it has to be
amended and one has to see how to get the information best into there
and out again.

>>And an internal representation (c2:min7 ?)?
> c2:min7 is an input syntax.
>
>>I am assuming that the output formating
>>is e.g. Cm7.
>
> Yes, that is correct.

Yup.

-- 
David Kastrup

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

Re: Improve internal chord structure

[Carl Sorensen]

On 3/29/17 8:57 AM, "lilypond-devel on behalf of Renato Fabbri"
 wrote:

>Thanks for the feedback.
>Yes, I should be an enrolled student by May 4.
>
>Could you give me examples of what you consider an internal chord
>structure
>(semitone counting?)?
The internal chord structure is a Guile (scheme) list containing pitches,
a duration, and events.

>And an internal representation (c2:min7 ?)?
c2:min7 is an input syntax.

>I am assuming that the output formating
>is e.g. Cm7.

Yes, that is correct.

Thanks,

Carl


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

not translating a node in a file

[Federico Bruni]

Hi translators

Continuous changes to Google Summer of Code node made me think about 
removing the translation, because maintaining the translation is too 
cumbersome and it's not worth (as any GSoC candidate should speak 
english).
The problem is that I do not want to throw away all the community 
italian file, of course.


The documentation seems to suggest that something like this:

"""
@node Google Summer of Code
@unnumberedsec Google Summer of Code
@translationof Google Summer of Code

@untranslated
"""

should load the text from the original english file into the localized 
page.

Ok, probably it's just my imagination. I've found it here:
http://lilypond.org/doc/v2.19/Documentation/contributor/documentation-translation-details#translating-the-web-site-and-other-texinfo-documentation

When I run "make website" after applying above change I get a 404 error 
when I try to open the italian GSoC page.

So the italian node is not created.
It's a bug or I'm missing something? (see patch attached if you want to 
try it out)


An alternative might be moving the GSoC page in an includable file (in 
Documentation/included/), so we can easily include the english text in 
a localized website.


Thanks for any suggestion
Federico


>From 96aea960ce9db88f4b0645200d3205c027ac4e63 Mon Sep 17 00:00:00 2001
From: Federico Bruni 
Date: Wed, 29 Mar 2017 18:44:10 +0200
Subject: [PATCH] leave GSoC page in English

---
 Documentation/it/web/community.itexi | 202 +--
 1 file changed, 1 insertion(+), 201 deletions(-)

diff --git a/Documentation/it/web/community.itexi b/Documentation/it/web/community.itexi
index 7c6aeca..7c3b72e 100644
--- a/Documentation/it/web/community.itexi
+++ b/Documentation/it/web/community.itexi
@@ -879,207 +879,7 @@ manuali sono reperibili su @url{http://lilypond.org}}
 @unnumberedsec Google Summer of Code
 @translationof Google Summer of Code
 
-@divClass{column-center-top}
-@subheading Che cos'è il Google Summer of Code?
-
-@uref{https://developers.google.com/open-source/gsoc/, GSoC} è un programma
-internazionale che offre agli studenti degli stipendi per scrivere codice per
-progetti di software libero e open source durante l'estate.  È un'ottima
-opportunità per gli studenti per fare esperienza con lo sviluppo software
-in un progetto vero e per dare un contributo da cui tutti potranno trarre
-vantaggio.  Attrae nuovi collaboratori e stimola gli studenti che già
-partecipano allo sviluppo di LilyPond ad impegnarsi di più in esso.  LilyPond
-partecipa a GSoC sotto l'egida del @uref{http://www.gnu.org/, progetto GNU}.
-
-Abbiamo avuto partecipanti al GSoC nel 2012, 2015 e 2016 e invitiamo gli
-studenti a fare domanda per le prossime estati.
-
-Se hai dubbi o desideri presentare domanda, invia un'email alla nostra
-mailing list degli sviluppatori (vedi @ref{Contact}).
-
-@divEnd
-
-@divClass{column-center-middle-color2}
-@subheading Elenco di idee di progetti
-
-Ecco un elenco di progetti suggeriti per il GSoC o per chiunque sia interessato
-a aiutare a migliorare LilyPond. (Ultimo aggiornamento: Novembre 2016)
-
-La disponibilità di mentori varia da progetto a progetto e di anno in anno.
-Invia un'email alla nostra mailing list degli sviluppatori (vedi @ref{Contact})
-e ti aiuteremo a trovare un mentore per un progetto che sia adatto ai tuoi
-interessi e capacità.
-
-Se hai idee per un progetto GSoC che non è elencato qui sotto, puoi inviarci
-un'email per discuterne.  Ci sono molte aree in cui LilyPond può essere
-migliorato e il nostro team di sviluppo è sempre disponibile a aiutare
-coloro che desiderino affrontare un progetto come quelli di seguito elencati.
-
-Una lista completa di tutti i problemi da risolvere si trova
-@uref{http://sourceforge.net/p/testlilyissues/issues/, qui}.
-
-@divEnd
-
-@divClass{column-center-middle-color3}
-@subheading Migliorare la struttura interna degli accordi
-
-La rappresentazione interna degli accordi in LilyPond non è abbastanza potente
-da comprendere la nomenclatura degli accordi jazz.  Attualmente l'accordo ha
-una radice, un basso e un'inversione.  Sarebbe auspicabile poter gestire
-accordi @qq{impilati} o bicordi, minori/maggiori, etc.  Per poter far questo,
-deve essere sviluppata una rappresentazione interna capace di catturare
-l'essenza di accordi complessi.  Una volta che questa rappresentazione
-interna viene sviluppata, c'è un'ulteriore vantaggio: sarà più semplice
-migliorare la formattazione dei nomi degli accordi.
-
-@strong{Difficoltà:} Facile/media
-@strong{Requisiti:} Scheme (Guile), ma il livello necessario può essere
-facilmente imparato
-@strong{Consigliato:} Teoria e nomenclatura degli accordi
-@strong{Mentore:} Carl Sorensen
-
-@divEnd
-
-@divClass{column-center-middle-color3}
-@subheading Aggiungere varianti dei glifi dei tipi di carattere
-
-@divClass{keep-bullets}
-@itemize
-
-@item
-Aggiungere varianti @q{sulla} linea del rigo e @q{tra} le linee dei righi.
-

Re: Improve internal chord structure

[Renato Fabbri]

Thanks for the feedback.
Yes, I should be an enrolled student by May 4.

Could you give me examples of what you consider an internal chord structure
(semitone counting?)?
And an internal representation (c2:min7 ?)?
I am assuming that the output formating
is e.g. Cm7.
PS. I am referring explicitly to the text of the GSoC project idea.

Em 29 de mar de 2017 09:11, "Urs Liska"  escreveu:

Hi Renato,


Am 29.03.2017 um 13:54 schrieb Carl Sorensen:
> Congratulations on your dissertation completion.  That's a big step!  If
> you're interested in the project, we'd be delighted to have you apply.

just to add to this:
You are *not* too late until you miss the GSoC deadline. Of course, the
later you start, the less chance you have to discuss and improve your
suggestion, so you should go straight ahead now.

Just one question: I assume you will still be an enrolled student by May 4?

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

Re: Allow 'staff-padding to work with MeasureCounter (issue 312580043 by david.nales...@gmail.com)

[david . nalesnik]

On 2017/03/29 12:40:32, david.nalesnik wrote:

On 2017/03/29 11:08:17, simon.albrecht wrote:
> I’m not sure if a doc snippet is really necessary.  Using

staff-padding is

> explained in
>


and

>


,


> IIRC we want to be careful about extending the NR, don’t we?



I have no particular attachment to the snippet, so if it's redundant

I'll remove

it.



> so maybe a verbal remark in the section on Measure counts with a

link there

> might suffice.



Besides its IR page, MeasureCounter is documented right now through

two

snippets:



http://lilypond.org/doc/v2.19/Documentation/snippets/repeats#repeats-numbering-groups-of-measures


http://lilypond.org/doc/v2.19/Documentation/snippets/repeats#repeats-centered-measure-numbers


I could amend the second snippet to use staff-padding?  Other than

that, I don't

see a convenient way to mention it.


Sorry, I mean the *first* snippet.  (The count that begins with two
could be pushed further from the staff possibly.)


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

Re: Allow 'staff-padding to work with MeasureCounter (issue 312580043 by david.nales...@gmail.com)

[david . nalesnik]

On 2017/03/29 11:08:17, simon.albrecht wrote:

I’m not sure if a doc snippet is really necessary.  Using

staff-padding is

explained in


and

,


IIRC we want to be careful about extending the NR, don’t we?


I have no particular attachment to the snippet, so if it's redundant
I'll remove it.


so maybe a verbal remark in the section on Measure counts with a link

there

might suffice.


Besides its IR page, MeasureCounter is documented right now through two
snippets:

http://lilypond.org/doc/v2.19/Documentation/snippets/repeats#repeats-numbering-groups-of-measures

http://lilypond.org/doc/v2.19/Documentation/snippets/repeats#repeats-centered-measure-numbers

I could amend the second snippet to use staff-padding?  Other than that,
I don't see a convenient way to mention it.


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

Re: Improve internal chord structure

[Urs Liska]

Hi Renato,


Am 29.03.2017 um 13:54 schrieb Carl Sorensen:
> Congratulations on your dissertation completion.  That's a big step!  If
> you're interested in the project, we'd be delighted to have you apply.

just to add to this:
You are *not* too late until you miss the GSoC deadline. Of course, the
later you start, the less chance you have to discuss and improve your
suggestion, so you should go straight ahead now.

Just one question: I assume you will still be an enrolled student by May 4?

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: Improve internal chord structure

[Carl Sorensen]

Dear Renato,

>
>have you already made some systematization of the chords?
>There is a list here:
>https://en.wikipedia.org/wiki/List_of_chords
>and I got myself interested in
>analyzing the context in which the chord is incident to have the
>"ability to capture the essence of complex chords",
>as stated in the GSoC ideas page.

The list of chords is interesting.  I can't speak for all of the
users/developers, but personally I don't think I would be interested in
using the names of the chords that are on the left hand side of that
table.  I'm less interested in having a unique name for each chord, and
more interested in having a structure that supports chord characteristics
(such as the quality which is listed in the table).

>I also have some interests in symmetry which
>might help with representing symmetric scale chords
>such as derived from Messiaen's modes of limited transposition.
>Might chords not from the 12 tones system
>or in other temperaments be of interest?

I suppose that there could be some interest in chords that are not in
standard temperaments, but I don't think that is the focus of interest for
this project.  I don't believe we are trying to expand the range of chords
that LilyPond can capture with this project as much as we are trying to
improve the semantics of what we already have.

That being said, I don't believe there would be any problem with adding
non-standard chords in addition to improving the semantics.

>
>I understand it might be late for coping with GSoC, but if you find it
>suitable,
>I might apply.
>My apologies for not making this contact earlier, but I handed my
>doctorate
>dissertation a few days ago and could not concentrate as needed until now.
>Some info about my research and software development efforts are gathered
>here:
>https://pastebin.com/iNNuN4fy
>Anyway, this topic might be of use for the LilyPond community as a whole
>and for
>developments outside GSoC.

Congratulations on your dissertation completion.  That's a big step!  If
you're interested in the project, we'd be delighted to have you apply.

Thanks,

Carl Sorensen



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

Improve internal chord structure

[Renato Fabbri]

Dear developers,

have you already made some systematization of the chords?
There is a list here:
https://en.wikipedia.org/wiki/List_of_chords
and I got myself interested in
analyzing the context in which the chord is incident to have the
"ability to capture the essence of complex chords",
as stated in the GSoC ideas page.
I also have some interests in symmetry which
might help with representing symmetric scale chords
such as derived from Messiaen's modes of limited transposition.
Might chords not from the 12 tones system
or in other temperaments be of interest?

I understand it might be late for coping with GSoC, but if you find it
suitable,
I might apply.
My apologies for not making this contact earlier, but I handed my doctorate
dissertation a few days ago and could not concentrate as needed until now.
Some info about my research and software development efforts are gathered
here:
https://pastebin.com/iNNuN4fy
Anyway, this topic might be of use for the LilyPond community as a whole
and for
developments outside GSoC.

Best Regards,
Renato Fabbri


-- 
GNU/Linux User #479299
labmacambira.sourceforge.net
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Allow 'staff-padding to work with MeasureCounter (issue 312580043 by david.nales...@gmail.com)

[simon . albrecht]

I’m not sure if a doc snippet is really necessary.  Using staff-padding
is explained in

and
,
so maybe a verbal remark in the section on Measure counts with a link
there might suffice.  IIRC we want to be careful about extending the NR,
don’t we?

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