Re: anonymous functions in define-grobs.scm

On Fri, 22 Nov 2013 22:12:28 -0800, David Kastrup wrote: "Keith OHara" writes: Near the top of 'define-grobs.scm' it says WARNING: don't use anonymous functions for initialization. and I am wondering why. My personal guess is that anonymous functions look like garbage and/or don't pr

Re: Support articulations, slurs and breaths in MIDI (issue 26470047)

On 2013/11/23 07:25:31, benko.pal wrote: > I would need, however, an appropriate new name for the property, and the best I > can think of now is 'strength'. 'attack'? 'velocity'. There is nothing to be gained by inventing different names from the MIDI terminology but confusion. https://c

Re: Support articulations, slurs and breaths in MIDI (issue 26470047)

I would need, however, an appropriate new name for the property, and the best I can think of now is 'strength'. 'attack'? https://codereview.appspot.com/26470047/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/

Re: anonymous functions in define-grobs.scm

"Keith OHara" writes: > Near the top of 'define-grobs.scm' it says > WARNING: don't use anonymous functions for initialization. > and I am wondering why. > > I suspected it was to avoid storing a function body in every instance of the > type of grob that might have an anonymous function as

Re: Support articulations, slurs and breaths in MIDI (issue 26470047)

Looks good, as far as I have time to review. I might propose a follow-up patch, to clarify in define-music-properties.scm that the 'volume' property affects the "note-on-velocity", as it should to represent an accent, rather than the "channel volume" of the channel. People who care about the mid

anonymous functions in define-grobs.scm

Near the top of 'define-grobs.scm' it says WARNING: don't use anonymous functions for initialization. and I am wondering why. I suspected it was to avoid storing a function body in every instance of the type of grob that might have an anonymous function as one of its default properties. Bu

Re: tracking down a crash

On Fri, 22 Nov 2013 01:32:19 -0800, David Kastrup wrote: Argh. How about this one (should likely apply using git am): That clears the crash, resolves the problem with extra barlines, and leaves no similar problems in my test case so far as I can see. __

Re: Make make-relative able to deal with music rather than just pitches (issue 30890043)

Reviewers: J_lowe, Message: On 2013/11/22 17:01:25, J_lowe wrote: https://codereview.appspot.com/30890043/diff/1/input/regression/make-relative-music.ly File input/regression/make-relative-music.ly (right): https://codereview.appspot.com/30890043/diff/1/input/regression/make-relative-music.l

Make make-relative able to deal with music rather than just pitches (issue 30890043)

https://codereview.appspot.com/30890043/diff/1/input/regression/make-relative-music.ly File input/regression/make-relative-music.ly (right): https://codereview.appspot.com/30890043/diff/1/input/regression/make-relative-music.ly#newcode8 input/regression/make-relative-music.ly:8: well inside and

Re: tracking down a crash

David Kastrup writes: > "Keith E OHara" writes: > >> On Wed, 20 Nov 2013 23:48:47 -0800, David Kastrup wrote: >> >>> So one suspicion would be that iter_ points to a non-operative >>> iterator. Maybe set it to zero in >> >>> Sequential_iterator::do_quit () >> >> That change, on master, did not

Patches: Countdown for November 25th - 06:00 GMT

Hello, *Countdown – November 25th – 06:00 GMT* 3668

Re: tracking down a crash

"Keith E OHara" writes: > On Wed, 20 Nov 2013 23:48:47 -0800, David Kastrup wrote: > >> So one suspicion would be that iter_ points to a non-operative >> iterator. Maybe set it to zero in > >> Sequential_iterator::do_quit () > > That change, on master, did not clear the crash. Argh. How about