Re: hel-arabic.ly
On Thu, 7 Mar 2024, 14:24 , wrote:
>
> \include "hel-arabic.ly"
> \relative {
> \key do \rast
>
Shouldn't this be
\key c \rast
?
c' d edb f | g a bdb c | eb a g f | edb d c
> }
>
> => rast1.png
>
>
> Hassan
>
Neil
>
Re: R\fermata: How to build a markup in C++?
On Tue, 16 Apr 2019 at 12:30, Malte Meyn wrote: > Thanks for the hint! I had already seen that (only then I realised that > \fermata already creates a MultiMeasureTextEvent and > MultiMeasureRestText grob that just has an 'articulation-type instead of > 'text property). But your hint made me look again at that place. Maybe I > could build the 'text from the 'articulation easier in Scheme than in > C++ (i. e. change the definition of script-to-mmrest-text so that it > gives ‘music’ a 'text property before calling make-music). Yeah. You should be able to check for an articulation-event and extract the type to build the markup. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: R\fermata: How to build a markup in C++?
Hi Malte, On Mon, 15 Apr 2019 at 10:55, Malte Meyn wrote: > Are there any other ideas how the R\fermata thing could be done? Check out scm/lily-syntax-constructors.scm, where there's a constructor for MM rests: http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=blob;f=scm/ly-syntax-constructors.scm;h=256a2ec08aefdf10bd543fe6f8b6b6b8caba8970;hb=HEAD#l199 Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: bounty for fixing issue 4044 (\addlyrics with custom contexts)
Hi Janek, On 1 August 2014 13:32, Janek Warchoł wrote: I'm putting a modest bounty on > https://code.google.com/p/lilypond/issues/detail?id=4044 - this > problem is a nuisance for my work on predefined instruments, so i'd > like to see it disappear. I remember looking at this a while ago. If I recall correctly it's too early for context information to be available to the syntax constructor - if you look in ly-syntax-constructors.scm there's a helper function which is supposed to find the first existing voice context so the constructor for \addlyrics doesn't have to create one from scratch. There's a comment there noting it doesn't work (it says `rarely works' but I'm pretty sure it never does). Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: X-aligning on Y-parent - ?? advice needed
On 5 April 2013 17:47, Janek Warchoł wrote: Regardless of it being a spanner, i've tried to find where > MultiMeasureRestText's (and MultiMeasureRestNumber's) Xparent is set, > but without sucsess. I thought that maybe it happens in line 240 of > paper-column-engraver, but apparently not. Spanner:set_bound () Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: alignment of unattached lyrics - opinions needed
On Mar 17, 2013 11:10 AM, "m...@mikesolomon.org"
wrote:
> In the stop_translation_timestep method of the lyric engraver, lyrics are
given note heads as parents. Could you send a minimal where the lyrics are
unassociated from note-heads?
\lyrics { do re mi }
If there's no associated voice the lyrics have no parent until the
Paper_column_engraver steps in.
Cheers,
Neil
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Allows slurs to break at barlines. (issue 7424049)
On Feb 28, 2013 8:37 PM, "m...@mikesolomon.org" wrote: > You're right, but I've opted for the breaking behavior in the most recent patch-set (\breakSlurHere). Otherwise, slurs wouldn't be able to span only one musical moment. Ok, so how about using an event of class break-span-event (like \breakDynamicSpan)? > We miss you! Come back! Thanks. :-) I can feel the itch returning, but really need to get a laptop first unless I can commandeer our new iMac when it arrives next month and work out how to do things iOS fashion. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Assertion failure
On Aug 28, 2012 12:14 PM, "m...@mikesolomon.org" wrote: > I'm a bit short on time but could someone do some snooping to try and figure out what the problematic commit is? I don't think there is one. I can't double check at the moment, but there's a dubious callback for BarNumber self-alignment-X in the main file which tries to set the property inside the callback. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Odd snippet
On 15 July 2012 22:22, Phil Holmes wrote: > Could someone have a look at http://lsr.dsi.unimi.it/LSR/Item?id=190 and say > what's wrong with it, please? It uses extra-offset to move the segno, so no space is reserved for it on the left hand side. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: add \shape (issue 6255056)
On 31 May 2012 18:40, wrote: > Thank you for reviewing this, Neil! You're welcome. :) LGTM. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: simultaneous rehersal marks, tempo indication, and text marks
On 27 February 2012 13:48, Graham Percival wrote:
> What would be involved in making a clean solution for this? I
> imagine that a separate TextMark engraver (just like the
> RehearsalMark engraver and MetronomeMark engravers) would do the
> trick, but that's a bunch of icky C++ code. Is there any way to
> use scheme to create a new engraver that behaves like an existing
> engraver (i.e. TextMark), but has its own data (so it doesn't
> merge the rehearsal mark event with the "text mark" event?)
Attached is a scheme engraver I hacked up a few years ago. It
naturally has a few limitations, particularly if you use multiple
\mark \default commands at the same timestep.
Cheers,
Neil
\version "2.15.8"
#(define (multi-mark-engraver ctx)
(let ((texts '())
(final-texts '())
(events '()))
`((start-translation-timestep
. ,(lambda (trans)
(set! final-texts '(
(listeners
(mark-event
. ,(lambda (trans ev)
(set! events (cons ev events)
(acknowledgers
(break-alignment-interface
. ,(lambda (trans grob source)
(for-each (lambda (mark)
(set! (ly:grob-parent mark X) grob))
texts
(process-music
. ,(lambda (trans)
(for-each
(lambda (ev)
(let* ((mark-grob
(ly:engraver-make-grob trans 'RehearsalMark ev))
(label (ly:event-property ev 'label))
(formatter (ly:context-property ctx 'markFormatter)))
(if (and (procedure? formatter)
(not (markup? label)))
(begin
(if (not (number? label))
(set! label
(ly:context-property ctx 'rehearsalMark)))
(if (and (integer? label)
(exact? label))
(set! (ly:context-property ctx 'rehearsalMark)
(1+ label)))
(if (number? label)
(set! label (apply formatter (list label ctx)))
(ly:warning "rehearsalMark must have integer value"
(if (markup? label)
(begin
(set! (ly:grob-property mark-grob 'text) label)
(let ((dir (ly:event-property ev 'direction)))
(and (ly:dir? dir)
(set! (ly:grob-property mark-grob 'direction)
dir
(ly:warning "mark label must be a markup object"))
(set! texts (cons mark-grob texts
(reverse events
(stop-translation-timestep
. ,(lambda (trans)
(if (pair? texts)
(let ((staves (ly:context-property ctx 'stavesFound))
(priority-index 0))
(for-each (lambda (grob)
(let ((my-priority (ly:grob-property grob 'outside-staff-priority 1500)))
(for-each (lambda (stave)
(ly:pointer-group-interface::add-grob grob 'side-support-elements
stave))
staves)
(set! (ly:grob-property grob 'outside-staff-priority) (+ my-priority priority-index))
(set! priority-index (1+ priority-index))
(set! final-texts (cons grob final-texts
(reverse texts))
(set! texts '())
(set! events '())
(finalize
. ,(lambda (trans)
(and (pair? final-texts)
(for-each (lambda (grob)
(set! (ly:grob-property grob 'break-visibility)
end-of-line-visible))
final-texts)))
\layout {
\context {
\Score
\remove "Mark_engraver"
\consists #multi-mark-engraver
}
}
markDown =
#(define-music-function (parser location text) (markup?)
(make-music 'MarkEvent
'direction DOWN
'label text))
\relative c' {
\mark "1"
\mark "2"
\mark "3"
\markDown "1"
\markDown "2"
\markDown "3"
c1
}
\relative c' {
c1
\mark \default
\mark "play violently"
d
}
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: This snippet needs a title
On 23 February 2012 17:04, Francisco Vila wrote: > I can fix this by my own if anybody does not provide me a title before. > Thanks. The title must be "Glissandi can skip grobs" to match the file name. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Gets vertical skylines from grob stencils (issue 5626052)
On 6 February 2012 16:59, wrote: > Should have added before: the most recent patch set is not bug free. Cyclic dependencies for TextScript Y-offset. But you've just fixed that by the look of it. ;) > I'm fixing all of the regtest issues, but what I need most from other > people who have a few minutes are benchmarks. L'Isle joyeuse: master: 0m30.432s patched: 0m46.997s Psalm 94 (Reubke): master: 1m31.692s patched: 2m0.817s Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: silly question: does make doc include running regtests?
2012/1/26 Janek Warchoł : > A potentially silly question: does make doc include running regtests? > (i don't mean regtest comparison, just compiling all the snippets) > I don't see anything about it in CG. Yes. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Glyphs for Kievan Notation (issue 4951062)
On 23 January 2012 01:02, wrote: > Regarding comments by Neil and Bertrand: > > I rewrote Stem::is_normal_stem the way Neil suggested. Looking at the > code in Stem.cc, it appears that both ways are being used to check the > style property. I don't know which is the more correct. Strictly speaking, Bertrand is more correct. But there's still no need to convert to a string. If we want to be paranoid about such comparisons, it would be better to use scm_is_eq () for comparing symbols. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Don't wrap EventChord around rhythmic events by default. (issue 5440084)
On 20 January 2012 17:32, David Kastrup wrote:
> n.putt...@gmail.com writes:
>
>> Hi David,
>>
>> Should I wait for a new patch or can I test using the latest one here?
>>
>> I've tried it out briefly on a real music example, and have a problem
>> with identifiers:
>>
>> foo = \mark \default
>>
>> \relative c' {
>> \foo
>> c1
>> }
>
> You have the newest. The problem is the definition of ly:event? (for
> recognizing postevents). It is currently (in lily/music-scheme.cc)
> defined as the equivalent of
> (define (ly:event? m)
> (and (ly:music? m)
> (ly:is-music-of-type? m 'event)
> (not (ly:is-music-of-type? m 'rhythmic-event
>
> That seemed to be more or less right. Apparently you found a "less
> right" case.
>
> Suggestions?
I can't think of anything better than adding another type such as
`command-event' to things like TempoChangeEvent and MarkEvent and
filtering that out too.
Cheers,
Neil
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Clickable examples in the docs
Hi, The clickable examples in the docs have stopped working. The links appear to be broken since they're missing the .ly suffix. Try the example on this page: http://lilypond.org/doc/v2.15/Documentation/learning/clickable-examples It goes to http://lilypond.org/doc/v2.15/Documentation/9e/lily-06377646 instead of http://lilypond.org/doc/v2.15/Documentation/9e/lily-06377646.ly I'm not sure how long it's been like this; I only noticed it when I looked at the changes page today. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Glyphs for Kievan Notation (issue 4951062)
On 12 January 2012 15:43, wrote: > Unfortunately, that doesn't seem to do anything. Unless I'm not > accessing the property correctly ... see the latest patch. You're trying to access style from the Stem instead of the NoteHead. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Glyphs for Kievan Notation (issue 4951062)
On 11 January 2012 17:13, wrote: > I've posted a potential solution to get rid of the "stems", but it's not > very elegant because it breaks the pattern. > > Perhaps someone else has a better idea. Add a check for kievan style in Stem::is_normal_stem (). Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: how to check clef type?
2012/1/8 Janek Warchoł : > ok, i think i understand what you said (that's a success :) ), but i > don't know what should i use instead of glyph-name callback - a hint > please? Write an offset callback instead? It should be safe to access glyph-name at that point. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: how to check clef type?
2012/1/8 Marc Hohl : > Are you sure the attached patch is up-to-date with your work? > I get a small change clef in the fifth line, see attachment. I get the same result as Janek. I think the problem is that the glyph-name callback checks break-status, thus shouldn't be called from the engraver (it's too early, then gets cached when accessed later in the print callback). Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: autoFootnote
On 8 January 2012 15:45, David Kastrup wrote:
> I am also replacing the flowery language "Use like @code{\\tweak}." and
> "Use like @code{\\once}." since neither makes any sense whatsoever: you
> don't use the first before a postevent,
What's a postevent these days then? If you want to tweak an
individual script or markup, you must place \tweak before that object.
{ c'4-\tweak #'color #red -"foo" -"bar" }
Cheers,
Neil
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: What's the deal with the LSR update?
On 1 January 2012 19:37, David Kastrup wrote: > Done, so let's see if this gets through to master, and if it does, you > might want to try the LSR updating procedure again. You need to remove the comment block at the top, the texidoc translations and `% begin verbatim' comments. These are all added automatically to the generated snippets. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make doc failure on fresh build tree
On 7 November 2011 19:32, Graham Percival wrote: > Failing either of these, I guess we're into git bisect time, which > of course sucks for doc-building if you're not Phil or James. I > know that Phil can build the docs, but hopefully James' computer > will fail in this same way? I've just finished building the docs without incident. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds Scheme function for spring constructor. (issue 5306050)
On 21 October 2011 12:39, wrote: > For me, this function is totally useless. If we want to check whether > they are equal, we use scm_equal_p, if we want to see whether they are > the same object, we use scm_eqv_p. > > Besides, I can't find any use for this function with git grep. I think Guile requires it. The documentation in lily/include/smobs.hh says all smobs should implement an equal_p () function. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Sketch for broken beams with consistent slopes (issue 4961041)
On 21 October 2011 07:50, Mike Solomon wrote: > Of this I am not sure. My gut says yes, but I don't know why the regtest > that skips quanting was added and the extent to which quantless-beams are > used by users. Never, I'd imagine. I certainly don't recall any users wanting to switch it off. I'm just thinking it would be better off being an internal property. I might have a few more comments once I've got Ubuntu running again. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Make accidental styles available as context mods. (issue 4819064)
On 20 October 2011 15:01, David Kastrup wrote: > I think the current state of dev/syntax should be committable. It has > no problems accepting context modifications. The function signature of > ((string? "Bottom") ly:context-mod?) should work just fine for accepting > an optional context string defaulting to "Bottom" and a mandatory > context modification. The default context would be "Staff". There's some code to switch to GrandStaff for the piano styles. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB
On 8 October 2011 17:41, Graham Percival wrote: > Yeah, that's the point of using one of the other commands; you can > specify the branch. There's also some way of specifying the > branch using the bin/gub method too... it'd be listed in > lilypond.make... but I don't have it written down handy. Heh, I couldn't work out any command which would do the same, so just hacked it instead. :) > It might be nice to determine the "recommended" command to build > the installer for a specific binary and a specific platform -- and > to easily support giving it a local repository -- but I'm not > offering to do that. Maybe since Phil is new to GUB, he'll be > energetic about fixing and documenting usage and bugs for the next > couple of weeks until gets jaded like us. :) Haha, can't we just kidnap Jan and get him to tell us? :) Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB
On 8 October 2011 16:23, Graham Percival wrote: > I /think/ it's this command you want: > > python bin/gib --platform=mingw > --branch=lilypond=git.sv.gnu.org--lilypond.git-master lilypond > > (all on one line) > > but it might be this one instead: > > bin/gub --platform=mingw > 'git://git.sv.gnu.org/lilypond-doc.git?branch=release/unstable' > > (again, all on one line) bin/gub mingw::lilypond-installer is what I use. I had to restore shallow cloning and hack specs/lilypond.py to get it to fetch changes from the local repository (otherwise it just builds master). Cheers, Neil PS I've just posted times on the tracker, since I always have an up-to-date mingw build to test changes. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Assertion failure on current master
On 1 October 2011 18:19, Peekay Ex wrote: > Neil what command do you run when you do a test-baseline so that I > might get something like you do? I don't. :) I couldn't work out which file was failing, so I did what I usually do: run all the regression tests until it crashes. The output I've posted is from debugging mozart-hrn-3.ly on its own via GDB. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Assertion failure on current master
On 1 October 2011 18:16, Graham Percival wrote:
> The problem is verified; I see exactly the same behaviour as Neil
> with 4f49b000d6e257724e311b406e2346b8388c1f0e
Here's a minimal snippet which fails:
\version "2.15.14"
\relative c' {
\times 2/3 { f8 e d }
}
Cheers,
Neil
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Assertion failure on current master
On 1 October 2011 18:04, m...@apollinemike.com wrote:
> A follow-up: I can't figure out how the error could come about.
> Interval::center should, in Tuplet_number::calc_y_offset, always be getting
> an interval for which it can find the center (it uses robust_scm2interval).
> Does anyone with more computer chops than I have have any intuition about
> this?
The interval it fails on is empty here:
(gdb) f 4
#4 0x006d8b2c in Tuplet_number::calc_y_offset
(smob=0x722bebe0) at tuplet-number.cc:83
83return scm_from_double (positions.center ());
(gdb) p positions
$1 = {> = {array_ = {4.158845306777426,
3.5388453067774259}}, }
I'll try to narrow it down by gutting the movement which has the
triplets. They all look pretty benign though.
Cheers,
Neil
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Assertion failure on current master
Hey guys, I can't complete test-baseline due to an assertion error running mozart-hrn-3.ly. Here's the backtrace: Drawing systems...lilypond: ../flower/include/interval.hh:226: T Interval_t::center() const [with T = double]: Assertion `!is_empty ()' failed. Program received signal SIGABRT, Aborted. (gdb) bt #0 0x7508fd05 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x75093ab6 in abort () at abort.c:92 #2 0x750887c5 in __assert_fail (assertion=0x70bd60 "!is_empty ()", file=, line=226, function=) at assert.c:81 #3 0x0041bf01 in Interval_t::center (this=0x7fff7310) at ../flower/include/interval.hh:226 #4 0x006d8b2c in Tuplet_number::calc_y_offset (smob=0x722bebe0) at tuplet-number.cc:83 #5 0x77926ae4 in scm_dapply () from /usr/lib/libguile.so.17 #6 0x004fc65f in Grob::try_callback_on_alist (this=0x108d150, alist=0x108d1b0, sym=0x72a6c080, proc=0x745ac530) at grob-property.cc:231 #7 0x004fc398 in Grob::internal_get_property (this=0x108d150, sym=0x72a6c080) at grob-property.cc:188 #8 0x00505efd in Grob::get_offset (this=0x108d150, a=Y_AXIS) at grob.cc:383 #9 0x00505a67 in Grob::relative_coordinate (this=0x108d150, refp=0x184dc00, a=Y_AXIS) at grob.cc:312 #10 0x005062a4 in Grob::extent (this=0x108d150, refp=0x184dc00, a=Y_AXIS) at grob.cc:427 #11 0x0043a1ad in add_boxes (me=0x108d150, x_common=0x18950a0, Looks like the new tuplet collision avoidance code. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: current master gives strange warning
On 26 Sep 2011 09:08, "m...@apollinemike.com" wrote: > > is anyone else getting: > > warning: identifier name is a keyword: `relative' Sounds like you've pulled the latest changes without rebuilding. You'll only get that message if the lexer hasn't been recompiled, since David's removed that token. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds StemTremolo to the note column's element list. (issue 5067041)
On 19 September 2011 19:48, m...@apollinemike.com wrote: > What I'd really like to know is why the spring ideal and minimum distances > are different just by virtue of its belonging to the array, but I have a > feeling the answer lies deep in the bowels of the horizontal spacing code and > I don't have time to get to the bottom of that in the foreseeable future. > For now, it seems like this is the right move to take. I'm afraid I disagree. Looking at the changes James has posted on the tracker, we now get undesirable extra space in some beamed tremolos, which looks strange. They shouldn't influence the spacing unless absolutely necessary. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: \slashedGrace vs \acciaccatura
On 25 September 2011 15:19, Phil Holmes wrote: > a) I believe the slashedGrace function is > to allow a slurred grace note inside a slur Nope. Reinhold recently added support for separate slurs on graces, so they work fine nested inside other slurs. b) I'm not convinced a tied grace note makes musical sense It's usually used to indicate a note/chord to be played early, at least in piano music when it's logistically impossible to sound on the beat without a third hand. :) I believe this is the usage which Reinhold was thinking of when he added the new command (see grace-slashed-no-slur.ly). Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.15.12 regtest problems
On 22 September 2011 17:38, Graham Percival wrote: > On Thu, Sep 22, 2011 at 02:46:38PM +0100, Phil Holmes wrote: >> There are 2 significant problems I've found with 2.15.12. > > Could we get issues for these? I should probably cancel the > release countdown. I can't verify either problem here. The missing fingering would've shown up in the regtest comparison, and running the snippet locally produces correct output. Master is faster on my system than 2.15.10 (both optimised and unoptimised), mainly due to the lack of cyclic redundancy error spamming. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Problem with make on a commit *after* Davids last '\pushAtTag' commit- 264022bd6ebfed3220c0272d2c4a1c8ef9db4028
On 22 September 2011 12:48, Phil Holmes wrote: > We probably need to learn how to use git bisect... It's David's most recent commit: 6c3445a0791831d450573cf583da36aecac5322c Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: bookOutputName broken
On 20 September 2011 21:50, Benkő Pál wrote:
> I don't know what to do, could you help me?
The attached patch works for me (haven't run make check on it though).
Cheers,
Neil
From f6f1ad62263b4dfb5f518da71891d3a0b30c89a3 Mon Sep 17 00:00:00 2001
From: Neil Puttock
Date: Tue, 20 Sep 2011 22:18:55 +0100
Subject: [PATCH] parser.yy: Allow embedded_scm inside \book & and \bookpart
---
lily/parser.yy |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/lily/parser.yy b/lily/parser.yy
index 02c99e2..df3067b 100644
--- a/lily/parser.yy
+++ b/lily/parser.yy
@@ -791,6 +791,7 @@ book_body:
| book_body lilypond_header {
$$->header_ = $2;
}
+ | book_body embedded_scm { }
| book_body error {
$$->paper_ = 0;
$$->scores_ = SCM_EOL;
@@ -843,6 +844,7 @@ bookpart_body:
| bookpart_body lilypond_header {
$$->header_ = $2;
}
+ | bookpart_body embedded_scm { }
| bookpart_body error {
$$->paper_ = 0;
$$->scores_ = SCM_EOL;
--
1.7.4.1
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Glyphs for Kievan Notation (issue 4951062)
2011/9/20 Neil Puttock : > I'm running make doc with the patch applied at the moment. Will > report any problems. There's nothing wrong with the patch as far as I can tell. Make doc completes successfully here. The only thing that's missing is an entry in Documentation/notation/notation-appendices.itely to show the glyphs. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Glyphs for Kievan Notation (issue 4951062)
2011/9/20 Janek Warchoł : > I'm not sure what is your opinion on this patch currently. Do you > agree to push it if it doesn't break make, make doc and regtests? Do > you agree with my comment no.7 > http://code.google.com/p/lilypond/issues/detail?id=1873#c7 ? Yes. I'm running make doc with the patch applied at the moment. Will report any problems. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Improves horizontal spacing of axis groups that SpanBar grobs traverse. (issue 4917046)
On 17 September 2011 15:45, Mike Solomon wrote: > The problem comes not from this patch but from the calculation of the > horizontal skylines for NonMusicalPaperColumns. Try adding: > > \override Score . NonMusicalPaperColumn #'stencil = #ly:separation-item::print > > To the beginning of SopranoMusic and then running LilyPond with > -ddebug-skylines. You'll see that in the first example, the downward stem > pushes the lyrics under the end point of the NonMusicalPaperColumn, whereas > this does not happen in the second example. > > Thus, the dependency is not stems (drop the soprano an octave and you'll see > that) but NonMusicalPaperColumn grobs. This isn't really a bug. NonMusicalPaperColumn has a default setting for skyline-vertical-padding which extends the skyline slightly. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes issue 1881 (cyclic dependency with beam calculations) (issue 5038042)
On 17 September 2011 12:16, m...@apollinemike.com wrote: > They should be applied separately - 5038042 fixes 1881, and 5057041 prunes > down bloated code. There is a chance that 5057041 is effected by 5038042 (I > haven't tested them together yet) though I doubt it. After their countdowns, > I'd push 5038042 first, rerun regtests on 5057041, and then either push > 5057041 or modify it if necessary. I wouldn't bother with a countdown for this patch. It's simple enough to apply immediately. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add support for custom ledger positions, using two new staff-symbol properties (issue 4974075)
On 16 September 2011 12:50, Peekay Ex wrote: > The CG doesn't mention this for reg test checking. Indeed, it only mentions this for debugging. > Is this something I should be doing now and if so does it matter where > this switch comes in the syntax? It's part of the configure process, so either ./autogen.sh --disable-optimising or (out-of-tree build with --noconfigure) ../configure --disable-optimising You'll have to do `make bin-clean' before reconfiguring to ensure the binary is built properly if you're not starting from scratch. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reg test check differences after last two commits this morning 17th Sept (by Joe)
On 17 September 2011 09:27, Peekay Ex wrote:
> I don't know if this is expected based on either/both commits but in
> the two reg tests the 'instrument names' have now disappeared.
Nope, it's a regression. I'm afraid Joe's fallen into the same trap I
did when I looked at issue #1598. We can't filter out non-spaceable
lines in the Instrument_name_engraver since it prevents them having
instrument names (or vocal names for lyrics).
\version "2.15.12"
\relative c' {
\set Staff.instrumentName = #"Music"
c d e f
}
\addlyrics {
\set vocalName = #"Lyrics"
foo bar baz
}
-> missing vocal name
Cheers,
Neil
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add support for custom ledger positions, using two new staff-symbol properties (issue 4974075)
On 15 September 2011 23:04, wrote: > On 2011/09/15 21:41:27, Neil Puttock wrote: > >> For some reason, your patch fails `make check' on my system. > > Neil, I've just applied this patch - after seeing your note - to the > latest 'git pull -r' and 'make ; make check' work fine on my system if > that helps? Did you build with --disable-optimising (you should be if you're doing regression checking)? Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add support for custom ledger positions, using two new staff-symbol properties (issue 4974075)
On 15 September 2011 14:43, wrote: > Done, typical beginner imperfections, thanks for pointing out. Thanks. :) For some reason, your patch fails `make check' on my system. I consistently get SIGABRT thrown soon after running: job 2 terminated with signal: 6 job 1 terminated with signal: 6 job 0 terminated with signal: 6 fatal error: Children (2 1 0) exited with errors. command failed: /home/neil/lilypond/out/bin/lilypond -I ./ -I ./out-test -I ../../input -I /home/neil/lilypond/Documentation -I /home/neil/lilypond/Documentation/snippets -I ../../input/regression/ -I /home/neil/lilypond/Documentation/included/ -I /home/neil/lilypond/mf/out/ -I /home/neil/lilypond/mf/out/ -I /home/neil/lilypond/Documentation/pictures -I /home/neil/lilypond/Documentation/pictures/./out-test -dbackend=eps --formats=ps -djob-count=3 -dseparate-log-files -dinclude-eps-fonts -dgs-load-lily-fonts --header=texidoc -I /home/neil/lilypond/Documentation/included/ -ddump-profile -dcheck-internal-types -ddump-signatures -danti-alias-factor=1 -I "/home/neil/lilypond/out/lybook-testdb" -I "/home/neil/lilypond/input/regression" -I "/home/neil/lilypond/input/regression" -I "/home/neil/lilypond/input/regression/out-test" -I "/home/neil/lilypond/input" -I "/home/neil/lilypond/Documentation" -I "/home/neil/lilypond/Documentation/snippets" -I "/home/neil/lilypond/input/regression" -I "/home/neil/lilypond/Documentation/included" -I "/home/neil/lilypond/mf/out" -I "/home/neil/lilypond/mf/out" -I "/home/neil/lilypond/Documentation/pictures" -I "/home/neil/lilypond/Documentation/pictures/out-test" --formats=eps -deps-box-padding=3.00 -dread-file-list -dno-strip-output-dir "/home/neil/lilypond/out/lybook-testdb/snippet-names--7968346798296354682.ly" Child returned 1 make[2]: *** [out-test/collated-files.texi] Error 1 rm out-test/weblinks.itexi make[2]: Leaving directory `/home/neil/lilypond/input/regression' make[1]: *** [local-test] Error 2 make[1]: Leaving directory `/home/neil/lilypond/input/regression' make: *** [test] Error 2 This is with an unoptimised binary (using --disable-optimising). Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 10: scheme indentation
On 15 Sep 2011 00:31, "Carl Sorensen" wrote: > > On 9/14/11 4:31 PM, "Graham Percival" wrote: > > > There's been no action on this for a few weeks. I'm starting to > > wonder if we should abandon this proposal and try bringing it back > > in a few months. > > Why? > > The only outstanding issue is that the else indentation is not the same as > Emacs, but Neil hasn't responded to the setting that he would like. I don't mind the else indentation, but there are a few other issues (I mentioned them briefly in another post). I'll post a more thorough review later. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: How to add measure counters?
On 12 September 2011 20:45, Reinhold Kainhofer wrote: > Exactly, that was my idea. My problem is that I can't do it like in the > percent repeat case, where we have percent-repeat-events (generated in the > iterator), which start at the right moment and have the correct length. In the > measure counter case everything is handled via context properties (or maybe a > start/stop event), so there is no music event at the start of each measure and > thus there is also no event from which I can obtain the length of one such > measure-spanner. > > So, to formulate the question a little more precisely: In the engraver, for > which events or grobs do I have to listen/acknowledge to get the left and the > right column for each bar? > > I can't listen to bar lines, since there might be mid-measure barlines, or no > barline at all (think longa or breve)... Can't you just use the same timing information the Multi_measure_rest_engraver uses? It knows the current moment and the length of each bar, so you only have to store columns (via currentCommandColumn) and create a new counter grob for each bar. You just need to set the bounds at the right time, bearing in mind that adjacent counters will need the same column but for opposite bound directions. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: How to add measure counters?
On 12 September 2011 20:03, Reinhold Kainhofer wrote: > Any idea how to implement this? Shouldn't it just be a spanner whose bounds are the left column and right column for each bar? Similar to a full-bar rest or percent repeat. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Working on Issue 1135
On 12 September 2011 13:47, Marc Hohl wrote: > I created a new directory, made a git repository from scratch, > changed the one line and did > > make all > make doc Hmm, in that case, I'm not sure why it doesn't work. I assume you changed the offending line to this: @funindex \\~a Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Working on Issue 1135
On 12 September 2011 13:49, David Kastrup wrote: > Not as long as I have not checked and pushed appropriate changes. I don't see how that's relevant. You've broken the way the argument list is documented for each function. That has no bearing on the way music functions are indexed. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Working on Issue 1135
On 12 September 2011 13:32, Marc Hohl wrote: > ok, but does that mean that issue 1135 can be closed? > As mentioned elsewhere, I replaced @findex by @funindex in > > scm/document-identifiers.scm > > but this seems to change nothing ... Did you ensure it's rebuilt properly? IIUC you need to touch something like notation.tely to regenerate it. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Working on Issue 1135
2011/9/12 Janek Warchoł : > 2011/9/12 Marc Hohl : >> Do I understand issue 1135 right - the scheme functions should get listed >> on out-www/offline-root/Documentation/internals/scheme-functions.html? >> >> Or am I searching on the wrong place? > > I'm not the one who can answer this question :( > I'm forwarding this to -devel. Nope, these are music functions. They're documented in the appendices to the Notation Reference via scm/document-identifiers.scm. scheme-functions.html documents the exported scheme functions defined in c/c++. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Cyclic redundancies with manual beaming
On 10 September 2011 14:59, Neil Puttock wrote: > Hi guys, > > This perfectly innocent looking snippet spits forth several errors > with current master: Of course, I mean cyclic dependencies. :) These are pretty serious. I haven't done `make check' for a few weeks and now I'm inundated with these errors, which makes it very difficult to see real changes. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: A few remarks concerning \relative
On 11 September 2011 16:02, David Kastrup wrote: > git grep '\\relative [^@a-z]' > > has a hit rate of close to 100%. Most of those are regression tests added after Mark's work. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: A few remarks concerning \relative
On 11 September 2011 15:22, Graham Percival wrote: > On Sun, Sep 11, 2011 at 03:58:32PM +0200, David Kastrup wrote: >> One could start by removing it from snippets and regtests. > > Yes, one could. Hmm, there shouldn't be any since Mark P removed them all a while ago. I suppose a few must have crept back in since then. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: hands off LSR and makelsr.py
On 10 September 2011 21:34, Graham Percival wrote: > Neil: is it ok to run makelsr.py locally? I think that > translators and some programmers need this, but if you're rather > deal with it yourself, that's fine. Local updates shouldn't pose any problems. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Cyclic redundancies with manual beaming
Hi guys,
This perfectly innocent looking snippet spits forth several errors
with current master:
\version "2.15.11"
\relative c' {
s2. c8[ c
c8 c]
}
/tmp/tmpJ8GqW5/document.ly:4:8: programming error: cyclic dependency:
calculation-in-progress encountered for #'quantized-positions (Beam)
s2. c8
[ c
/tmp/tmpJ8GqW5/document.ly:4:8: continuing, cross fingers
s2. c8
[ c
/tmp/tmpJ8GqW5/document.ly:4:8: programming error: cyclic dependency:
calculation-in-progress encountered for #'quantized-positions (Beam)
s2. c8
[ c
/tmp/tmpJ8GqW5/document.ly:4:8: continuing, cross fingers
s2. c8
[ c
/tmp/tmpJ8GqW5/document.ly:4:8: programming error: cyclic dependency:
calculation-in-progress encountered for #'quantized-positions (Beam)
s2. c8
[ c
/tmp/tmpJ8GqW5/document.ly:4:8: continuing, cross fingers
s2. c8
[ c
/tmp/tmpJ8GqW5/document.ly:4:8: programming error: cyclic dependency:
calculation-in-progress encountered for #'quantized-positions (Beam)
s2. c8
[ c
/tmp/tmpJ8GqW5/document.ly:4:8: continuing, cross fingers
s2. c8
[ c
I'll try to do a bisect later to narrow it down.
Uh oh, just noticed another one with stem Y-extent too (no manual beam
required here):
\version "2.15.11"
\relative c' {
\partial 16
c32 d
}
/tmp/tmp0lpVUz/document.ly:3:2: programming error: cyclic dependency:
calculation-in-progress encountered for #'Y-extent (Stem)
c32 d
/tmp/tmp0lpVUz/document.ly:3:2: continuing, cross fingers
c32 d
/tmp/tmp0lpVUz/document.ly:3:2: programming error: cyclic dependency:
calculation-in-progress encountered for #'quantized-positions (Beam)
c32 d
/tmp/tmp0lpVUz/document.ly:3:2: continuing, cross fingers
c32 d
Cheers,
Neil
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Make accidental styles available as context mods. (issue 4819064)
On 5 September 2011 20:10, David Kastrup wrote:
> I suggest trying the following Lilypond fragment out.
>
> #(define (make-accidental-mod style)
> "Make a context modification from accidental style @var{style}."
> (let ((style-settings '(1 2 3 4)))
> #{ \with { extraNatural = #(cadr $style-settings)
> autoAccidentals = #(caddr $style-settings)
> autoCautionaries = #(cadddr $style-settings) } #}))
> #(display (make-accidental-mod 'modern))
Heh, silly me. I was rather stupidly testing it with \set, which
naturally causes the parser to complain.
I suppose this means ly:make-context-mod is redundant then.
Cheers,
Neil
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Make accidental styles available as context mods. (issue 4819064)
On 5 September 2011 20:04, Reinhold Kainhofer wrote:
> Ah, I see. The problem is that the context mods are also used inside context
> definitions, like
>
> a=\with {
> \description "Some mod"
> ...
> }
> \context {\Score
> \description "context desc"
> \a
> }
>
> This is effectively the same as
>
> \context {\Score
> \description "context desc"
> \description "Some mod"
> ...
> }
>
> And the later description takes overwrites the context description.
Exactly.
> It's ugly that such a situation occurs, but I guess your approach is the
> easiest, short of renaming them to \contextDescription or so...
Yep, I thought the minor infelicity involved with (ab)using
\description would be preferable to adding another parser keyword.
Cheers,
Neil
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Make accidental styles available as context mods. (issue 4819064)
On 5 September 2011 17:29, wrote:
>
> http://codereview.appspot.com/4819064/diff/1/lily/context-mod-scheme.cc
> File lily/context-mod-scheme.cc (right):
>
> http://codereview.appspot.com/4819064/diff/1/lily/context-mod-scheme.cc#newcode45
> lily/context-mod-scheme.cc:45: LY_DEFINE (ly_make_context_mod,
> "ly:make-context-mod",
> Can you map this to #{ \with { ... } #} ?
Hmm, I don't think so, since a context modification isn't music.
> http://codereview.appspot.com/4819064/diff/1/ly/context-mods-init.ly
> File ly/context-mods-init.ly (right):
>
> http://codereview.appspot.com/4819064/diff/1/ly/context-mods-init.ly#newcode25
> ly/context-mods-init.ly:25: (ly:make-context-mod
> #{ \with { \set extraNatural #(second $style-settings)
> \set autoAccidentals #(third $style-settings)
> \set autoCautionaries #(fourth $style-settings) } #}
> No, I have not actually tested it, but with the recent changes to #{ #}
> something quite similar to this should actually work. Is there a reason
> you prepend the description in order to strip it again in parser.yy?
The \description keyword is used inside a context modification to set
the documentation string for the notation appendix. Since I've
replaced the existing ly:export versions of the default accidental
styles in engraver-init.ly with their context modification
equivalents, I don't want their \description settings to overshadow
the engraver documentation strings (also set via \description): so the
context modification strings are dropped.
Cheers,
Neil
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Make accidental styles available as context mods. (issue 4819064)
On 5 September 2011 17:29, wrote:
> It's hard for me to track all of this carefully, but I much prefer the
> context mod approach to the ly:export approach.
>
> LGTM
Thanks. :)
BTW, this doesn't bypass the existing ly:export version, since that's
still required for setting accidental styles in music. We could hack
the parser to allow music inside a context defintion, but that's
frowned upon seeing as we used to allow a similar construct inside
\midi {} for \tempo which was removed.
Cheers,
Neil
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Make accidental styles available as context mods. (issue 4819064)
On 5 September 2011 17:21, wrote: > LGTM. Thank you. :) > http://codereview.appspot.com/4819064/diff/1/lily/parser.yy > File lily/parser.yy (right): > > http://codereview.appspot.com/4819064/diff/1/lily/parser.yy#newcode670 > lily/parser.yy:670: continue; > What exactly is the reason for this hardcoded workaround? Somehow I > don't get your comment in the patch description... Since David has also queried this, I'll reply below. > http://codereview.appspot.com/4819064/diff/1/ly/context-mods-init.ly > File ly/context-mods-init.ly (right): > > http://codereview.appspot.com/4819064/diff/1/ly/context-mods-init.ly#newcode30 > ly/context-mods-init.ly:30: (cdr style-settings)) > I don't see any way around the lambda functions displayed for > make-accidental-style... It's rather unfortunate, since it really defeats the object of having documentation. I suppose the only alternative would be avoid currying and have several specific rule functions. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: please push patches
On 5 September 2011 17:15, James Lowe wrote: > Pass make and reg test > > ;) Hehe, I'm grateful as always for your testing work (and quite envious of your ninja PC, but can't justify an upgrade yet. :) Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: please push patches
On 4 September 2011 20:39, Graham Percival wrote: > Since Colin is off on holiday in the best place on earth (i.e. > Western Canada), I'll send the reminder. > > All the above people: you have patches that should be pushed. > http://code.google.com/p/lilypond/issues/list?can=2&q=label:patch&sort=patch > no particular rush; I just didn't want you to forget. Sorry, will try to sort out the fermata fix today or tomorrow. I have to say I'm disappointed nobody has commented on the `accidental styles as context modifications' patch. I really would like some feedback first. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 10: scheme indentation (probable decision)
On 24 August 2011 22:26, Graham Percival wrote: > No complaints from last time, with the possible exception of Neil > wanting a different behavior for (else...) I haven't had time to test it thoroughly since my last comments, but there are some other issues which will need fixing before we can apply it globally (e.g., handling of comments, several missing special cases). I hope to have time to do some more testing at the weekend, Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Creates pure closures (issue 4894052)
On 18 August 2011 13:44, Mike Solomon wrote: > What about pure-container ? It's all right, I suppose... but what about the unpure part? After all, the container's not just about the pure callback. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: oops! I've changed files in the `snippet' directory
On 18 August 2011 22:46, Reinhold Kainhofer wrote: > BTW, I managed to get the LSR-copy running on my machine: > http://lsr.kainhofer.at/LSR/ > > (the jail is set up but not yet used for compiling) > > HOWTO as usual at http://wiki.kainhofer.com/lilypond/lsr_setup Wow, that's awesome work, Reinhold. :) I've tried following the instructions, but can't get it to work properly. I think I've followed the instructions to the letter (apart from adding setcp.sh to the sh/ directory, since it's missing here: http://wiki.kainhofer.com/_media/lilypond/lsr/setcp.sh), but my jail refuses to mount when booting up and the LSR site isn't found when I type the URL into my browser. Any ideas? Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes heights and pure heights of stems. (issue 4898044)
On 15 August 2011 13:31, wrote: > Also, just a quick reply to let you know that the calc_stem_end and > calc_stem_begin methods are left in the code base for people who want to > override the Y-extent of the stem while conserving either the beginning > or end of the stem, ie: > > \override Stem #'Y-extent = #(lambda (grob) (let ((foo > (ly:stem::calc-stem-begin-position grob))) (cons foo (+ foo 10 That's every users who wants cross-staff stems for chords. Unless you can come up with a better interface for dealing with cross-staff stems, I'd rather you keep 'length for this case. BTW, I had a head-scratching moment with the above override until I realized that the begin/end-position callbacks return half-staff-space values. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: chaotic stems when querying direction property
On 14 August 2011 01:03, Ricardo Wurmus wrote: > So ly:glob-property has side effects because of the stem callback? > How can I make sure to get the final stem direction after all > dependent properties were calculated? > > I want to replace a note head with a triangle, but there is a gap > between note head a stem when the stem points upward. To correct this, I > modify the stem-attachment property of the note head. This correction > offset must be different when the stem points down. I'd override the default callback for stem-attachment. It should be safe to get the stem direction at this point since it's already been calculated and cached. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: script for auto-indenting .scm files.
On 13 August 2011 20:06, Carl Sorensen wrote: > De we have a standard for how much indentation we should have for each type > of compound expression? > > define > let > begin > > all get two, apparently. > > I see some sources that show that > > list > > gets one. > > Are you aware of a definitive statement I can follow? Not really; I'm just comparing it to Emacs* (which is by no means perfect; I've got several additions to my .emacs file for things like lambda* and parameterize). * http://cvs.savannah.gnu.org/viewvc/emacs/emacs/lisp/progmodes/scheme.el?view=markup > How did you do this? Did you do tab expansion on the file in an editor, > then run it through guileindent.scm? Yes (M-x untabify). > Once I've fixed all the issues you've raised and done some more > experimentation, I'll post a new patch. Great. I could've listed some more issues, but I think the majority of them are glaringly obvious in the diff. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: chaotic stems when querying direction property
On 13 August 2011 17:14, Ricardo Wurmus wrote: > I'm having a problem with a scheme engraver. Whenever I fetch the > direction property of a grob's stem object (or directly through a > listener on stem-event), the following warning is shown: > > warning: no viable initial configuration found: may not find good > beam slope > > The resulting score has a few notes with their stems pointing in the > wrong direction, so that the beams have a terribly ugly slope. As soon > as I remove the code to store the direction everything is fine again. > > I've attached a simple demo file where the chaotic stem directions can > be observed. All the code does is to save all grobs it encounters during > the acknowledge phase and then query the direction for each stored grob > during the processing phase. > > I'd be happy if you could explain to me why this happens. The stems of beamed notes have a dependency on beam direction, so if you try to get the direction of a stem which is part of a beam that hasn't been completed it can mess up the calculation (i.e., you end up with a disagreement between beam/stem directions in some cases). Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: script for auto-indenting .scm files.
On 12 August 2011 01:44, Carl Sorensen wrote:
> Yep. Here it is, along with the change to /usr/bin/env guile.
I had to change this to
/usr/bin/guile
to get the script to work:
/usr/bin/env: guile -s: No such file or directory
> I think I'm really going to like having this, if we can get all the bugs
> worked out..
I've just tested it on a few files, and there are several problems:
1) it introduces whitespace on blank lines
2) inside an `if', comments are counted, leading to incorrect
indentation for the subexpressions
3) subexpression inside `begin' are indented only one space
4) if a top-level form is erroneously indented (e.g.,
`set-music-properties!' in music-functions.scm), the rest of the file
also gets the same indentation
I've attached a diff which only shows the indentation changes (i.e.,
tab->space conversion is ignored).
Cheers,
Neil
diff --git a/scm/music-functions.scm b/scm/music-functions.scm
index 0266f63..6c27a86 100644
--- a/scm/music-functions.scm
+++ b/scm/music-functions.scm
@@ -68,7 +68,7 @@ First it recurses over the children, then the function is applied to
(define-public (music-filter pred? music)
"Filter out music expressions that do not satisfy @var{pred?}."
-
+
(define (inner-music-filter pred? music)
"Recursive function."
(let* ((es (ly:music-property music 'elements))
@@ -89,7 +89,7 @@ First it recurses over the children, then the function is applied to
(ly:music? e
(set! music '()))
music))
-
+
(set! music (inner-music-filter pred? music))
(if (ly:music? music)
music
@@ -98,7 +98,7 @@ First it recurses over the children, then the function is applied to
(define-public (display-music music)
"Display music, not done with @code{music-map} for clarity of
presentation."
-
+
(display music)
(display ": { ")
(let ((es (ly:music-property music 'elements))
@@ -110,8 +110,8 @@ presentation."
(display "}\n")))
(if (ly:music? e)
(begin
- (display "\nChild:")
- (display-music e
+ (display "\nChild:")
+ (display-music e
(display " }\n")
music)
@@ -135,7 +135,7 @@ For instance,
((and (not (string? arg)) (markup? arg)) ;; a markup
(inner-markup->make-markup arg))
(else ;; scheme arg
- (music->make-music arg
+(music->make-music arg
(define (inner-markup->make-markup mrkup)
(if (string? mrkup)
`(#:simple ,mrkup)
@@ -167,20 +167,20 @@ equivalent to @var{obj}, that is, for a music expression, a
(;; moment
(ly:moment? obj)
`(ly:make-moment ,(ly:moment-main-numerator obj)
- ,(ly:moment-main-denominator obj)
- ,(ly:moment-grace-numerator obj)
- ,(ly:moment-grace-denominator obj)))
+ ,(ly:moment-main-denominator obj)
+ ,(ly:moment-grace-numerator obj)
+ ,(ly:moment-grace-denominator obj)))
(;; note duration
(ly:duration? obj)
`(ly:make-duration ,(ly:duration-log obj)
-,(ly:duration-dot-count obj)
-,(car (ly:duration-factor obj))
-,(cdr (ly:duration-factor obj
+ ,(ly:duration-dot-count obj)
+ ,(car (ly:duration-factor obj))
+ ,(cdr (ly:duration-factor obj
(;; note pitch
(ly:pitch? obj)
`(ly:make-pitch ,(ly:pitch-octave obj)
- ,(ly:pitch-notename obj)
- ,(ly:pitch-alteration obj)))
+ ,(ly:pitch-notename obj)
+ ,(ly:pitch-alteration obj)))
(;; scheme procedure
(procedure? obj)
(or (procedure-name obj) obj))
@@ -196,7 +196,7 @@ equivalent to @var{obj}, that is, for a music expression, a
(;; a pair
(pair? obj)
`(cons ,(music->make-music (car obj))
-,(music->make-music (cdr obj
+ ,(music->make-music (cdr obj
(else
obj)))
@@ -223,8 +223,8 @@ Returns `obj'.
(parameterize ((*indent* 0)
(*previous-duration* (ly:make-duration 2))
(*force-duration* force-duration))
-(display (music->lily-string expr parser))
-(newline)))
+(display (music->lily-string expr parser))
+(newline)))
@@ -262,11 +262,11 @@ through MUSIC."
(if (ly:duration? dur)
dur
(loop (cdr elts
-
+
(let ((talts (if (< times (length alts))
(begin
- (ly:warning (_ "More alternatives than repeats. Junking excess alternatives"))
- (take alts times))
+(ly:warning
Re: Fixes note column skylines by adding stem tremolo to axis group. (issue4754054)
On 11 August 2011 12:34, m...@apollinemike.com wrote: > I figured out why it works - I figured I'd post this to the list in case > anyone else ever wants to mess around with pure properties. > > The StemTremolo is added to the paper column's element grob array via the > axis-group-engraver because it does not have an axis-group-parent-Y. I think you mean the VerticalAxisGroup's elements array. The StemTremolo is added to a PaperColumn's elements array (and gets the column as axis-group-parent-X) in the Paper_column_engraver. > Then, when horizontal spacing happens, its pure height function is passed > through for its print function (separation-item.cc). I think I understand: before you added the print-to-height conversion, the original height callback (ly:stem-tremolo::height) wasn't pure-relevant; this resulted in Item::pure_height () returning an empty extent, causing the StemTremolo to be left out of the skyline. This didn't matter unless the spacing was really tight. > I may write a "pure" tutorial for the contributor's guide. It has taken me a > long time to figure out how "pure" works in lilypond, and if other people are > as mystified as I was when I started trying to figure this stuff out, then I > think an addition to the CG would help. Sounds great. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: custom engraver in scheme: accessing nested Music object
On 10 August 2011 15:00, Ricardo Wurmus wrote: > Is there a way to change that order, or call the note-head-interface > function again at the very end for processing a grob? Acknowledger order depends on the order engravers are \consist-ed (the only exception is if you set must-be-last to #t) If you want to do useful things to the NoteHead, you should wait until all the acknowledging has finished, i.e., store the NoteHead grob and process the information in a process-acknowledged or stop-translation-timestep function. BTW, if you're prepared to wrap the notes in a chord (so you have access to 'articulations), you won't even need a scheme engraver (all the processing can take place in the NoteHead's stencil callback). Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Rewrite regtest mozart-hrn-3.ly (issue4811066)
On 9 August 2011 09:47, Phil Holmes wrote: > I said in a separate message that this isn't necessary. The link is > automatically converted to a clickable link. This only works reliably with Adobe Reader. Foxit produces an incorrect link: mutopia.org/It (it picks up the start of the next line) Neither okular nor evince produces a link. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 5: build system output (final)
On 9 August 2011 20:21, Reinhold Kainhofer wrote: > So having only 9 warnings in our codebase (four of which are in the > lexer/parser, which hardly anyone of us really understands!) is amazing. There are many more warnings (> 180) if you're compiling a 64-bit binary. They could be silenced via casting, but Han-Wen isn't in favour of that approach (http://codereview.appspot.com/1724041/): "* Why are all the casts there? Is this a 64 bit compiler thing? Lily compiles virutally without warnings over here (core duo, gcc 4.4.4). I think all the casting hinders readability, so I propose to not add casts unless necessary. If the warnings bother you, add a targeted -Wno-xxx option to the Makefile. I doubt that there are any cases where there is the risk of a real error." >> out/parser.cc:2392: warning: conversion to 'short int' from 'int' >> may alter its value >> /lily/lexer.ll:634: warning, rule cannot be matched >> /lily/lexer.ll:637: warning, rule cannot be matched >> /lily/lexer.ll:706: warning, -s option given but default rule can be >> matched > > Anyone here who knows more about the lexer and the parser? The parser.cc warning is from code generated by Bison. I'm not sure about the two `rule cannot be matched' warnings, though both lines have been there sice 1997 and removing them doesn't seem to cause any problems. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Line 722 of axis-group-interface.cc
On 8 August 2011 09:09, m...@apollinemike.com wrote:
> Question: on line 722 of axis-group-interface.cc, I see:
>
> while (i + 1 < elements.size ()
> && scm_eq_p (elements[i + 1]->get_property
> ("outside-staff-priority"), priority))
>
> Shouldn't this be:
>
> while (i + 1 < elements.size ()
> && to_boolean (scm_eq_p (elements[i + 1]->get_property
> ("outside-staff-priority"), priority)))
Good catch.
The Guile docs suggest using scm_eqv_p for this case:
"Numbers and characters are not equal to any other object, but the
problem is they're not necessarily eq? to themselves either."
Cheers,
Neil
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Should this be applied?
On 8 August 2011 12:43, David Kastrup wrote:
> I have no clue what start and end are
start and end are column ranks, i.e., an index to the position of a
particular column in a score. You can see them if you enable
debugging for columns:
\relative c' {
c1
}
\layout {
\context {
\Score
\override PaperColumn #'stencil = #ly:paper-column::print
\override NonMusicalPaperColumn #'stencil = #ly:paper-column::print
}
}
> and I have no clue what pure is.
https://secure.wikimedia.org/wikipedia/en/wiki/Pure_function
> But get_pure_property takes start and end as additional arguments over
> get_property, and so does pure_is_visible.
>
> So from a mere text-matching hand-waving likelihood point of view, the
> above change seems plausible.
>
> Is there anybody that could shed light on this?
The only effect I can see is that break-visiibility won't be cached.
There are no pure break-visibility callbacks so the start/end args
will never be applied.
Cheers,
Neil
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes issue 40. (issue4801083)
On 9 August 2011 07:41, wrote: > On 2011/08/09 05:08:56, hanwenn wrote: >> >> LGTM > >> note that image of the issue will also require a minimum distance > > setting, >> >> otherwise, the glissando will be shortened into a dot? > > Done. New patchset uploaded. This doesn't ensure the glissando's visible (and messes up two tablature regtests). Han-Wen probably means minimum-length (which requires a springs-and-rods setting); alternatively, you could set ragged-right = ##f. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: Added \compoundMeter function to NR (issue4837050)
On 7 August 2011 21:33, wrote: > Before I push this (and as Neil has just done an LSR update) do I still > need to run makelsr.py before applying this patch once it has been > approved? Nope. > I have removed one snippet from both dirs (snippets/new and snippets). Don't forget to remove the translated texidocs too. > I'll get someone to remove the snippet from the LSR too. I'd leave it until we actually have an update*, though I have already removed the `doc' tag to prevent the snippet reappearing with the next LSR update. * you could argue that we should leave it in case users aren't prepared to update to the latest stable version Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: NR 5.5.4 - Modifying ties and slurs
On 7 August 2011 21:58, James Lowe wrote: > I guess that opens a whole new vista of questions - i.e. along the lines of > how would I know that if its not documented in the IR How is it not documented? If I navigate to TieColumn, http://lilypond.org/doc/v2.15/Documentation/internals/tiecolumn there's a list of interfaces at the bottom, one of which is tie-column-interface. If I follow this link, there's a description of tie-configuration: http://lilypond.org/doc/v2.15/Documentation/internals/tie_002dcolumn_002dinterface > Is what I put instead, factually incorrect and needs 'reverting'? Well, we usually talk about properties belonging to a grob, so for consistency, it would be preferable to keep the original (particularly as the snippet in the LSR also has the same documentation). Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Deprecate \fermataMarkup for full-bar rests. (issue4672059)
On 7 August 2011 20:48, Reinhold Kainhofer wrote: > I wouldn't go that lowlevel. I rather thought about a scheme function that > prints a ly:warning and then returns the new definition (or calls the new > function). How would you prevent the deprecation warning from being issued when the identifier is created? Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Deprecate \fermataMarkup for full-bar rests. (issue4672059)
On 7 August 2011 20:21, wrote: > http://codereview.appspot.com/4672059/diff/1/ly/property-init.ly > File ly/property-init.ly (right): > > http://codereview.appspot.com/4672059/diff/1/ly/property-init.ly#newcode189 > ly/property-init.ly:189: fermataMarkup = \fermata > How about a wrapper to mark definitions/functions as deprecated, so they > print out a warning, but still work? That sounds great, though I'd be concerned about the overhead: surely every lookup via Lily_lexer::lookup_identifier () would need a deprecation check (probably using an object property). Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Deprecate \fermataMarkup for full-bar rests. (issue4672059)
On 7 August 2011 17:01, wrote: > Nice! LGTM. Thank you. > Will need some doc changes too. Indeed. I'll sort that out later (+ a regression test to exercise the code properly). > Should we deprecate \fermataMarkup? I think so. A convert rule would be reliable since it's just a substitution. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Doc: NR 5.5.4 - Modifying ties and slurs
Hi James,
There's nothing wrong with the following:
However, the @code{tie-configuration} property of
@code{TieColumn} can be overridden to set start line and direction
of ties as required.
'tie-configuration *is* a property of TieColumn, but one that happens
not to be set by default (that's why you don't see it in the
documentation for TieColumn).
Cheers,
Neil
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.15.8 Regtests
On 6 August 2011 15:31, David Kastrup wrote:
> I have a hard time counting the removal of a band aid for an artificial
> test case with undefined behavior (try finding a place in the user
> documentation that declares this kind of code as producing predictable
> results) as a regression because the original code did not fix the
> underlying problem, but merely masked it.
So how would you expect the following code to behave? It's the
snippet from the original bug report, which segfaulted in stem.cc.
\relative c' {
\time 2/4
\voiceOne
s16 [g s g ] s16 [g s g ] |
s16 [g s g ] \override Stem #'(details beamed-lengths) = #'(15 15)
s16 [g s g ] |
s16 [g s g ] s16 [g s g ] |
s16 [g s g ] \revert Stem #'(details beamed-lengths) s16 [g s g ] |
s16 [g s g ] s16 [g s g ] |
}
The regression test is deliberately artificial since it gives a clear
indication of failure, which this code doesn't (the segfault no longer
occurs due to checking the nested property is a pair before using
robust_list_ref). I don't think it's unreasonable to expect this code
to return 'beamed-lengths to the default value defined in
define-grobs.scm.
Cheers,
Neil
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: suspended whole notes - possibly a defect, please give your opinions
2011/8/4 Xavier Scheuer :
> That has been registered as issue #1774, isn't it?
> http://code.google.com/p/lilypond/issues/detail?id=1774
Not quite. Gould makes an exception for semibreves with adjacent
notes; in this case, they should be aligned as if they had stems:
\version "2.15.9"
\new Staff \relative c' {
\cadenzaOn
\set Staff.implicitTimeSignatureVisibility = #all-invisible
\set Staff.explicitClefVisibility = #all-invisible
\set Staff.instrumentName = #"LilyPond"
4 q1
4 q\breve
<<
{
4 q1
4 q1
}
\\
{
4 q1
4 q1
}
>>
}
\new Staff \relative c' {
\cadenzaOn
\set Staff.implicitTimeSignatureVisibility = #all-invisible
\set Staff.explicitClefVisibility = #all-invisible
\set Staff.instrumentName = #"Gould, p. 50"
4 q1
4 q\breve
<<
{
4 q1
4 q1
}
\\
{
4 q1
\once \override NoteColumn #'force-hshift = #1.4
4
\once \override NoteColumn #'force-hshift = #1.3
q1
}
>>
}
I can't see anything relevant in Stone; Read is a bit vague (but I
think he basically agrees with Gould on this).
Cheers,
Neil
<>___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 5: build system output (probable 2?)
On 29 July 2011 17:20, Graham Percival wrote:
> Could somebody get rid of these already? They're left-over from
> Valentin's note name changes from Dec 2010 or so;
They come from parsing string-tunings-init.ly.
> they were
> debugging messages which were supposed to be removed, but weren't
> completely removed.
No, parsing a string via ly:parser-parse-string (which is ultimately
what the hash-extend syntax for parsing .ly code inside scheme via #{
... #} uses) causes the lexer to set new input called `'. To
remove this, you'd probably have to have a flag set when parsing
strings (or included strings) to silence the verbose output.
Cheers,
Neil
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Give DynamicText horizontal space; issues 621 631 (issue4805054)
On 29 July 2011 22:44, wrote: > Just to be sure I understand, you'd prefer to require a manual tweak to > deal with the dynamic in the example snippet, rather than allow the > automatic behavior introduced with Keith's patch. The automatic behaviour is undesirable, since it introduces extra space before the dynamic to prevent the collision. You're unlikely to see this in engraved music. Ideally, the collision would be handled by shifting the dynamic automatically, taking into account any further dynamics which the initial one might collide with if moved (in that case, a whiteout would be more likely, but the shifting is preferred.) Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Current state of automatic footnotes. (issue4580041)
On 28 July 2011 15:57, wrote: > Many thanks to everyone for their help on this. > > Pushed as 233aad0ba9781e43424c4e77a859e42b660210e6. Hi Mike, can you look at my comments from a month ago please? I believe some of them are still relevant. Thanks, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: music function semantics
On 26 July 2011 22:41, David Kastrup wrote: > So the question basically is: which of those mechanisms is actually > being in use? Are there examples for existing music functions > interpreting a postevent or a chord constituent? \tweak would be the most common usage for both of these cases: c1-\tweak #'color #red -\fermata and < \tweak #'color #red c>1 Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: review process not working
On 26 July 2011 11:17, m...@apollinemike.com wrote: > This is my fault. I don't know why I missed it these warnings in the > side-by-side comparison, but I won't let this slip again. It isn't your fault. There were no warnings. It appears David's getting warnings from the more recent change to rest-ledger.ly (which must be architecture-specific; it compiles cleanly here before and after the change). Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: review process not working
On 26 July 2011 18:43, David Kastrup wrote: > Come on. I got pointed to this patch because _warnings_ occured. Don't > tell me "David is the only one who can see warnings". The patch is in > an area I have no clue about. _Anybody_ with reasonable C and Scheme > experience would have seen the same things I noted. I do not have reasonable C and Scheme experience. I started programming by accident (only to fix bugs on LilyPond; previously my programming experience amounted to nothing more than 'Hello World' in 68k assembler on an Amiga 500, and that's twenty years ago), so it's likely my LGTMs often miss things which may be considered basic errors to more experienced coders. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: \footnote 'bug' (or not?)
On 24 July 2011 19:51, m...@apollinemike.com wrote:
> On Jul 24, 2011, at 6:43 PM, James Lowe wrote:
>
>> Hello,
>>
>> From Neil P. explaining the finer points of footnote code, while looking at
>> my in-progress Doc patch for footnotes
>>
>> --snip--
>>
>> \footnote associates a single footnote with a particular event in the
>> music (usually a NoteEvent); in a certain sense it behaves like
>> \tweak, though I'd suggest to Mike that it actually be changed so its
>> behaviour is identical. Currently we have the situation where it's
>> awkward to add footnotes to individual scripts and fingerings:
>>
>> \relative c' {
>> < c-1-\footnote #'(1 . 2) "foo" "bar" >
>> }
>>
>
> This works as such because it is within a chord. \footnote is written to
> work like \tweak.
Please re-read my suggestion. \footnote doesn't work like tweak; if
it did, it would have music as the last argument, and apply the
FootnoteEvent to the following music. I suggested this precisely
since it's not possible to add a footnote to a specific post-event
(mainly fingerings and articulations). The documentation is at fault
here (it started with \balloon, since it implies it's similar to
\tweak).
>> -> doesn't apply footnote to fingering, still goes on notehead
>>
>> \relative c' {
>> c-1-\footnote #'(1 . 2) "foo" "bar"
>> }
>>
>
> Here, you'd need to do:
>
> \relative c' {
> \footnoteGrob #'Fingering #'(1 . 1) "foo" "bar" c-1
> }
>
> Because the fingering doesn't work like a tweak.
If \footnote behaved like \tweak, you'd do this:
c-\footnote #'(1 . 2) "foo" "bar" -1
Cheers,
Neil
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Makes parameters for hairpin rotation available in Scheme (issue4809051)
On 23 July 2011 15:48, wrote: > (a) is currently impossible to calculate in all circumstances, and (c) > would require a code dup. I think by making these available as > properties, the user can then use this data to fix the problem. In the > example given in Issue 36, I would personally rotate the stencil > downwards, and this patch would give me all the data necessary to create > an override for Beam #'rotation. This is too specific to hairpins. Most grobs collide with beams when they're cross-staff, so a more generic solution is required. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix for Issue 620. (issue4814041)
On 24 July 2011 09:55, m...@apollinemike.com wrote: > Why is it a bad thing to do it this way? Currently, the > Beam_collision_engraver implements dynamic filtering based on interface, and > I don't think there's a problem with that (it is the only way to make it > ignore certain grobs on the fly). I don't like the name. We already have `core interfaces'; they're grob-interface, item-interface and spanner-interface. > Creating a new interface would be OK but would make it harder to filter out > interfaces on the fly (people would have to override a grob's "meta" > property, which seems hard). Do you have a scenario whereby a user might want to override this? Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Produces better error messages when programmers forget to document a property. (issue4801045)
On 23 July 2011 23:05, wrote: > Can you give me an idea what his does and how to test this or what I am > going to see as someone who runs a lot of make/reg tests? If somebody forgets to document a new property (in scm/define-grob-properties.scm or scm/define-context-properties.scm) this will ensure the internals documentation generation aborts with a useful error message. If you want to test it, apply Mike's patch then try the following bad patch. It adds an undocumented grob property called `foo' to the accidental-interface. Cheers, Neil diff --git a/lily/accidental.cc b/lily/accidental.cc index bee99c6..3ad2ecf 100644 --- a/lily/accidental.cc +++ b/lily/accidental.cc @@ -230,6 +230,7 @@ ADD_INTERFACE (Accidental_interface, /* properties */ "alteration " "avoid-slur " + "foo " "forced " "glyph-name-alist " "hide-tied-accidental-after-break " ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: stable/2.14 still can't make doc
On 23 July 2011 04:07, Graham Percival wrote: > Presumably a different problem this time? > > I know that Carl is either flying to Korea, or just about to fly > to Korea, so could somebody else look into this? You should be > able to "make doc" on stable/2.14 from scratch. It doesn't work > in plain old git. I've just pushed a fix in staff.itely which gets me a clean build. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
