Re: Charles Winston's GSoC code: Chord Semantics (issue 337870043 by chazwi...@gmail.com)
On 2018/11/10 05:44:23, pwm wrote:
https://codereview.appspot.com/337870043/diff/40001/Documentation/notation/chords.itely#newcode679
Documentation/notation/chords.itely:679: represent the structure of
the chord.
When entered in node mode,
typo: "note mode"
Done.
https://codereview.appspot.com/337870043/diff/40001/input/regression/chord-name-exceptions.ly#newcode4
input/regression/chord-name-exceptions.ly:4: texidoc = "The property
@code{chordNameExceptions} can used
'can be used' (This was carried over, but might as well fix while
we're here.)
Done
https://codereview.appspot.com/337870043/diff/40001/input/regression/chord-name-exceptions.ly#newcode29
input/regression/chord-name-exceptions.ly:29: chExceptions = #(append
(chordmode->exception-entry chordVar markupVar) chExceptions)
Hmm, chExceptions is used in its own definition here? Does that work?
This is
not making sense to me.
chExceptions is previously defined to be a couple of new chords
prepended to ignatzekExceptions, so it can be used this way.
https://codereview.appspot.com/337870043/diff/40001/input/regression/chord-semantics-lowercase-root.ly#newcode14
input/regression/chord-semantics-lowercase-root.ly:14:
Whitespace on unnecessary blank line.
Done
https://codereview.appspot.com/337870043/diff/40001/input/regression/chord-semantics-name-exceptions.ly#newcode5
input/regression/chord-semantics-name-exceptions.ly:5: texidoc = "The
property
@code{chordSemanticsNameExceptions} can used
can be used
Done
https://codereview.appspot.com/337870043/diff/40001/input/regression/chord-semantics-power-chord.ly#newcode12
input/regression/chord-semantics-power-chord.ly:12:
Whitespace on unneeded blank line.
Done
https://codereview.appspot.com/337870043/diff/40001/scm/chord-entry.scm#newcode23
scm/chord-entry.scm:23:
Unnecessary new line.
Done
https://codereview.appspot.com/337870043/diff/40001/scm/chord-entry.scm#newcode75
scm/chord-entry.scm:75: chord-semantics))
It's hard to read this code because of the way it's formatted. Would
be better
with more line-breaks to keep the lines from being too long and the
indentation
from going so far to the right and wrapping around to the next line
(in narrow
views like this code review one). Similar comment for other places in
this file
like this.
Done
https://codereview.appspot.com/337870043/diff/40001/scm/chord-entry.scm#newcode238
scm/chord-entry.scm:238: 'chord-semantics chord-semantics))
Hmm, so there's a single 'chord-semantics property under a
'ChordSemanticsEvent
? Seems like we could avoid that extra step of nesting and just have
the
subproperties of 'chord-semantics under 'ChordSemanticsEvent ? And
that would
be more like NoteEvent and other events. Or maybe I'm missing
something?
We could do that, but it would pollute the global namespace with all the
properties
that are part of 'chord-semantics and are only used for chord semantics.
By putting them
in a single property, we avoid polluting the namespace. Similar to the
way we do fret-diagram-details.
https://codereview.appspot.com/337870043/diff/40001/scm/chord-entry.scm#newcode243
scm/chord-entry.scm:243: (ly:pitch-octave (entry-pitch
original-inv-pitch
Would be more clear and consistent if original-inv-pitch were renamed
to
original-inv-entry or similar.
Why? Not to be argumentative, but I wonder what about this name is more
clear and consistent, in your opinion?
https://codereview.appspot.com/337870043/diff/40001/scm/chord-entry.scm#newcode267
scm/chord-entry.scm:267: (append (if bass (write-me "base3: " bass)
(list
(make-note-ev bass 'bass #t)) '())
This write-me looks like a debugging statement that was left in?
Done
https://codereview.appspot.com/337870043/diff/40001/scm/chord-entry.scm#newcode272
scm/chord-entry.scm:272: (bass (make-elements (cons (make-note-ev bass
'bass
(cons #t #t))
Hmm, this (cons #t #t) looks like it could be related to one of the
regression
test failures that James posted about?
Will look more later.
https://codereview.appspot.com/337870043/diff/40001/scm/chord-entry.scm#newcode306
scm/chord-entry.scm:306: (assoc-ref semantics-list key))
This is defined twice, see line 292 above.
Done
https://codereview.appspot.com/337870043/diff/40001/scm/chord-entry.scm#newcode399
scm/chord-entry.scm:399: ((= alteration FLAT) (set! quality 'dim)
Instead of all of these (set! quality ...) why not just let the result
of this
cond be assigned to 'quality' and add an 'else' 'maj at the end?
Basically:
(quality (cond ((= alteration SHARP) 'aug) ...))
I think it's because for some intervals, you set a zero alteration as
perfect, while
for others, the zero alteration is 'maj. So it doesn't drop easily into
an else, I think.
https://codereview.appspot.com/337870043/diff/40001/scm/chord-entry.scm#newcode411
scm/chord-entry.scm:411: (if (= step-number 7) (set! quality 'min))
Defining quality using cond or case would be a
Re: Charles Winston's GSoC code: Chord Semantics (issue 337870043 by chazwi...@gmail.com)
On 2018/11/10 19:44:47, pwm wrote: Hi Charles, Today I built and ran 'make check' with your patch applied to current master. I was able to get it to pass 'make check' by making the following two changes. 1. In `chord-entry.scm` line 267, remove `(write-me "base3: " bass)`. 2. In that same file, line 100, remove the parens to change `(chord-semantics)` to just `chord-semantics`. The first change fixed this error (but note the type check warning): input/regression/chord-names-languages.ly' ~~~ Parsing... Renaming input to: `/home/james/lilypond-git/input/regression/chord-names-languages.ly' warning: type check for `bass' failed; value `(#t . #t)' must be of type `boolean' /home/james/lilypond-git/build/out/share/lilypond/current/scm/chord-entry.scm:267:59: In procedure memoization in expression (if ba ss (write-me "base3: " bass) ...): /home/james/lilypond-git/build/out/share/lilypond/current/scm/chord-entry.scm:267:59: In file "/home/james/lilypond-git/build/out/s hare/lilypond/current/scm/chord-entry.scm", line 266: Missing or extra expression in (if bass (write-me "base3: " bass) (list (make -note-ev bass (quote bass) #t)) (quote ())). ~~~ And the second change fixed this error: input/regression/chord-name-entry.ly ~~~ $ /home/dev/lilypond-git/build/out/bin/lilypond input/regression/chord-name-entry.ly GNU LilyPond 2.21.0 Processing `input/regression/chord-name-entry.ly' Parsing.../home/dev/lilypond-git/build/out/share/lilypond/current/scm/chord-entry.scm:100:35: In expression (chord-semantics): /home/dev/lilypond-git/build/out/share/lilypond/current/scm/chord-entry.scm:100:35: Wrong type to apply: ((modifier . #f) (root . #) (extension . 7) (additions) (removals) (bass . #f)) ~~~ So if you have a chance to upload a new patch set with those two changes, that should get things moving forward with the code review process. Cheers, -Paul Thanks for figuring this out. I'm now working on make check, and will post a new patch shortly (I hope). https://codereview.appspot.com/337870043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: NR: Add many function index entries. (issue 564590043 by lemzw...@googlemail.com)
Reviewers: Valentin Villenave, Message: \addInstrumentDefinition is deprecated; see commit a7c014b60702e96bbc376892249b495bc10b8662. I've just removed the last documentation remnants. Description: NR: Add many function index entries. Also clean up some minor typos. Also add minor documentation improvements. Please review this at https://codereview.appspot.com/564590043/ Affected files (+138, -23 lines): M Documentation/notation/ancient.itely M Documentation/notation/changing-defaults.itely M Documentation/notation/chords.itely M Documentation/notation/expressive.itely M Documentation/notation/fretted-strings.itely M Documentation/notation/input.itely M Documentation/notation/percussion.itely M Documentation/notation/pitches.itely M Documentation/notation/rhythms.itely M Documentation/notation/simultaneous.itely M Documentation/notation/spacing.itely M Documentation/notation/staff.itely M Documentation/notation/vocal.itely M Documentation/notation/world.itely ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Documentation: no \layout in markup-nested scores (issue 548590043 by v.villen...@gmail.com)
LGTM https://codereview.appspot.com/548590043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GSoC in contemporary notations
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
NR: Add many function index entries. (issue 564590043 by lemzw...@googlemail.com)
Hi Werner, that’s a very nice patch done in a quite methodical way. I just have a question: https://codereview.appspot.com/564590043/diff/546570043/Documentation/notation/staff.itely File Documentation/notation/staff.itely (left): https://codereview.appspot.com/564590043/diff/546570043/Documentation/notation/staff.itely#oldcode1487 Documentation/notation/staff.itely:1487: I’m not familiar with the state of instrumentCues; why did this sentence need to be removed? (Just out of curiosity; I’m not implying it didn’t.) https://codereview.appspot.com/564590043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GSoC in contemporary notations
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
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
