funindexed words
Hello, while updating the translation of rhythms.itely I've found some @funindex lines introduced in 1cef4f15 by Ralph Palmer and committed by Carld Sorensen. I do not fully agree on including the English placeholders mentioned here: [rhythms.itely, line 1704] @example #(override-auto-beam-setting '(beam-limit beam-numerator beam-denominator time-signature-numerator time-signature-denominator) moment-numerator moment-denominator [context]) @end example I could be wrong, but beam-limit, beam-numerator etc etc are only there for explaining the arguments to the function, so they are not function names and can be translated both in the example and in the corresponding explanation. Affected lines are 1676, 1677, 1678, 1727, 1728, 1735 and 1736. -- Francisco Vila. Badajoz (Spain) www.paconet.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 'avoid-slur proposals
Neil Puttock wrote: > Adding avoid-phrasing-slur would mean duplicating all the slur > avoidance code just for the sake of a different name. What about making some sort of property "alias" (don't know if that's the right word). Such that if the parser (or interpreter or whatever) sees 'avoid-phrasing-slur, it will just operate on 'avoid-slur. Okay, maybe I'm out of my league here, and I don't want to waste your time. I guess from a programming point of view, it's a low priority and adding a explanation to the docstring may be more practical. > > \override PhrasingSlur #'avoid-slur = #'inside > > No. The acknowledged object (Slur) does the avoidance. IIUC, then by that logic, this shouldn't work (but it does): \override Staff.Clef #'avoid-slur = #'inside Perhaps I just need to accept that the current situation is awkward... > >> > 2. add a choice: 'ignore > >> Sounds like a good idea, and only requires one extra > >> line of code... > > > > Don't let me stop you! (: > > Why the sad face? I'm waiting for your patch to the IR > for 'avoid-slur. :) I don't know how to do that. I figured making suggestions was a better use of my time than learning how to submit patches because I don't know C++. But I guess you're referring to the documentation. The other thing is that adding code for 'ignore would have to be done at the same time as adding the docstring for 'avoid-slur. Or so I thought. I don't know, I guess I figured if you already knew how to do it, it would be a lot easier for you than for me. By the way, it's not a sad face, it's just looking left. - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 'avoid-slur proposals
2009/4/11 Mark Polesky :
>
> Neil Puttock wrote:
>> > Why does Slur have an 'avoid-slur property?
>> So they avoid phrasing slurs.
>>
>> \relative c' {
>> \override Slur #'avoid-slur = #'outside
>> c\( d( e) f\)
>> }
>
> Okay, but the semantics are contradictory. One could think
> of the command in your example in two different ways:
> Adjust the slur to keep the slur outside the phrasing-slur.
> -or-
> Adjust the slur to keep the phrasing-slur inside the slur.
You can see why avoid-slur is accompanied by `ugh'. ;)
It's the former meaning; you have to imagine avoid-slur actually means
avoid-(phrasing-)slur.
> Neither is reflected with the current syntax. Either of
> these (non-functioning) commands would be clearer:
> \override Slur #'avoid-phrasing-slur = #'outside
Adding avoid-phrasing-slur would mean duplicating all the slur
avoidance code just for the sake of a different name.
> \override PhrasingSlur #'avoid-slur = #'inside
No. The acknowledged object (Slur) does the avoidance. Since it's
fair to assume that phrasing slurs always encompass slurs, there's no
reason for the Slur_engraver to acknowledge phrasing slurs.
> As a kludge, we could add an exception clause to the
> docstring, but ideally that's the wrong solution IMO.
>
> Lastly, this construct is also semantically lacking:
> \override Staff.Clef #'avoid-slurs = ##f
> It's really the slur that's avoiding the clef. This
> would be more intuitive:
> \override Slur #'ignore-clefs = ##t(default would be #f)
> ...but that would be a terrible idea, because you'd want
> 'ignore-time-signatures, 'ignore-key-signatures, etc...
I agree it's not ideal, but it probably arises from the fact that the
avoid-slur infrastructure was already in place when the non-musical
avoidance code was added; I imagine it was much easier to rely on the
existing code to do the avoidance work, rather than implementing an
additional framework just for clefs, time signatures and key
signatures.
> Maybe something like this would be ideal:
> \override Slur #'avoid-list =
> #'(clef key-signature time-signature ...)
> Maybe not exactly that, but something like it? And then
> you could do the same thing for Tie andPhrasingSlur.
That list would get very long if it included the grobs which are
currently acknowledged. :) It would probably only work as a context
property, otherwise you couldn't be sure that avoidance code has
access to the grobs which need avoiding.
>> > 2. add a choice: 'ignore
>> Sounds like a good idea, and only requires one extra
>> line of code...
>
> Don't let me stop you! (:
Why the sad face? I'm waiting for your patch to the IR for 'avoid-slur. :)
>> > 4. implement 'avoid-ties and 'avoid-phrasing-slurs?
>> Judging by the number of `ugh' comments related to
>> avoid-slur in the source, extending the same behaviour
> < to ties is probably undesirable (though it would be
>> good if they avoided clefs and time signatures).
>
> Only if the user could choose.
Oh, definitely; you could imagine the typesetting horrors if the
avoidance were as broken as the current behaviour over line breaks.
Regards,
Neil
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reverting Beat Grouping Commands
On 4/13/09 10:49 AM, "Graham Percival" wrote: > On Mon, Apr 13, 2009 at 06:59:14AM -0600, Carl D. Sorensen wrote: >> >> On 4/13/09 2:44 AM, "Trevor Daniels" wrote: >> >>> \set #'autoBeamSetting #'(lengths 7 8) = >>> \makeAutoBeamSetting '(* . ( 4 3 ) >>> 16 . ( 3 5 6 )) >> >> You're missing paragraphs on this setting. It should rather be written as >> >> \makeAutoBeamSetting '((* . (4 3)) >>(16 . (3 5 6))) >> >> which means I've been missing a set of paragraphs in my examples too. > > ( > 'sup dawg, I > > herd u like > > paragraphs > > so I > > paragraph'd > > this > > parENTHESIS. > ) D'OH! I shouldn't write emails when I first wake up! I'm glad you knew what I meant, and not what I said! > > > >> Ahh -- I just thought that 8th notes are the longest notes with beams. So >> we could specify the * entries as eighths, and allow fractions > > I'm not totally certain about that. I mean, I'm not certain that > there aren't some wacky contemporary music pieces that change > this. > >> \makeAutoBeamSetting '((* . (1.5 4 7)) >> >> would then work properly. Eighth beams would end at 4/8 and 7/8; 16th and >> shorter would end at 3/16, 4/8, and 7/8. And we could avoid the whole cons >> cell entry, which I find rather difficult. >> >> I think I actually like this syntax quite well. Let the code take care of >> all the complexity, and let users have it easy. > > Speaking strictly from a user's point of view, why not keep the > \set beatGrouping = #'(3 3 2) > which automatically takes the denominator of the time signature? > ok, from a code standpoint you want beatGrouping to die, so what > about > \makeBeamGroupings #'(3 3 2) So then we could have \makeBeamGroupings #'(3 3 2) translate into an autoBeamSettings rule for the current time signature. I like that idea a lot! Thanks! > and then translate that into the other stuff? Then simple > beamings (I consider my irregular 8/8 time to be simple :) can > have a simple syntax, while people wanting exact control can do > those nested list funkiness. In their bases, of course. All their base are belonging to me. Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: should 'make web' take several attempts?
On Sat, Apr 11, 2009 at 05:29:09PM -0600, Carl D. Sorensen wrote: > > On 4/11/09 5:21 PM, "Andrew Hawryluk" wrote: > > > I am trying to build the docs, and I get "pdfetex exited with bad > > status, quitting" errors. However, each time I reattempt it, it seems > > to get further along before quitting. Does a full doc build from > > scratch require numerous build attempts, in a similar way that LaTeX > > must be run twice to get its cross-references correct? > > No, once should do it. To add to this: if you've modified the docs and they now require multiple runs, then you broke something. If this is your first time building the docs, then you're probably missing some requiement... hmm, maybe the utf-8 fonts? I always need to fumble around to find the right packages to install in Linux; I end up looking at the package suggestions in input/regression/utf-8.ly Every time, I make a mental note to update the INSTALL file to match whatever was in utf-8.ly, but I always forget before I actually do it. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reverting Beat Grouping Commands
On Mon, Apr 13, 2009 at 06:59:14AM -0600, Carl D. Sorensen wrote: > > On 4/13/09 2:44 AM, "Trevor Daniels" wrote: > > > \set #'autoBeamSetting #'(lengths 7 8) = > > \makeAutoBeamSetting '(* . ( 4 3 ) > > 16 . ( 3 5 6 )) > > You're missing paragraphs on this setting. It should rather be written as > > \makeAutoBeamSetting '((* . (4 3)) >(16 . (3 5 6))) > > which means I've been missing a set of paragraphs in my examples too. ( 'sup dawg, I herd u like paragraphs so I paragraph'd this parENTHESIS. ) > Ahh -- I just thought that 8th notes are the longest notes with beams. So > we could specify the * entries as eighths, and allow fractions I'm not totally certain about that. I mean, I'm not certain that there aren't some wacky contemporary music pieces that change this. > \makeAutoBeamSetting '((* . (1.5 4 7)) > > would then work properly. Eighth beams would end at 4/8 and 7/8; 16th and > shorter would end at 3/16, 4/8, and 7/8. And we could avoid the whole cons > cell entry, which I find rather difficult. > > I think I actually like this syntax quite well. Let the code take care of > all the complexity, and let users have it easy. Speaking strictly from a user's point of view, why not keep the \set beatGrouping = #'(3 3 2) which automatically takes the denominator of the time signature? ok, from a code standpoint you want beatGrouping to die, so what about \makeBeamGroupings #'(3 3 2) and then translate that into the other stuff? Then simple beamings (I consider my irregular 8/8 time to be simple :) can have a simple syntax, while people wanting exact control can do those nested list funkiness. In their bases, of course. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Move left-broken line-spanner check to callback.
On 2009/04/11 19:22:54, joeneeman wrote: I prefer the second one. OK, ly:spanner::kill-zero-spanned-time it is. I've added a convert rule just in case anybody's using ly:hairpin::after-line-breaking. http://codereview.appspot.com/32148 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reverting Beat Grouping Commands
On 4/13/09 2:44 AM, "Trevor Daniels" wrote: > > > Carl D. Sorensen wrote Monday, April 13, 2009 1:32 AM > >> On 4/12/09 6:14 AM, "Trevor Daniels" >> wrote: >> >>> I'm a bit concerned about dropping the easy >>> beatLength/beatGrouping >>> interface, which seems to be prefered by most users, and >>> replacing >>> it with a more complex one, but I don't have any suggestions >>> (which >>> work) to make at present. Might a special user interface be >>> preferable to \override and \revert? >> >> Instead of >> >> \set beatGrouping = #'(1 3 3) >> >> (which can be wrong, because it doesn't reference the time >> signature), it >> would be something like >> >> \override #'autoBeamSetting #'(end 7 8) = >> \makeAutoBeamSetting '(* . ((1 . 8) (4 . 8) (7 . 8))) > > Should this not be \set rather than \override, as > this is a context property? > According to LM 5.3.5, autoBeamSetting would not be a context property, because it doesn't change over time. (I think the definition of context property and grob property here is a bit confusing, and perhaps wrong). Also, according to LM 5.3.5, the main difference between \set and \override is that \override *adds* a new value to the front of the alist, while \set *replaces* the value with the one being set. Therefore, an \override can be \reverted, but a \set cannot. To me, changes to properties that affect the layout of music should always be revertable. That's why I chose \override rather than \set. >> I agree this is a bit more difficult to type, and may be more >> difficult to >> understand. But I think the advantages of >> >> A) Having the time signature explicitly included >> make this worthwhile. > > Absolutely > >> B) Being explicit about the grouping points >> make this worthwhile. > > Not so sure about this. > > \set #'autoBeamSetting #'(end 7 8) = > \makeAutoBeamSetting '(* . ((1 . 8) (4 . 8) (7 . 8))) > > could be written equivalently as > > \set #'autoBeamSetting #'(lengths 7 8) = > \makeAutoBeamSetting '(* . ( 1 3 3 )) I originally thought about this syntax, but elected not to use it because it would be difficult to capture the default behavior of 2 2, which is to break beams at the 1/4 note positions. \override #'autoBeamSetting #'(end 2 2) = \makeAutoBeamSetting '(* . ((1 . 4) (2 . 4) (3 . 4) (4 . 4)) I suppose it would be possible to write \override #'autoBeamSetting #'(end 2 2) = \makeAutoBeamSetting '(* . ( 0.5 0.5 0.5 0.5)) using the grouping notation. I don't think I'd want to use 'lengths as the symbol regardless. The symbol 'end is not used to show that the timing of the rule is specified in ending moments. Rather, it's used to show that this a rule for ending beams, as opposed to subdividing them. > > where the beat length is either dem if * or beam > duration if specified. makeAutoBeamSetting could > convert these to the equivalent 'end' form. > > Granted you could not write > > \set #'autoBeamSetting #'(end 7 8) = > \makeAutoBeamSetting '(* . ((3 . 16) (4 . 8) (7 . 8))) > > in the alternative syntax, so some flexibility would > be lost, but as this would affect only 16th and shorter > beams this would work: > > \set #'autoBeamSetting #'(lengths 7 8) = > \makeAutoBeamSetting '(* . ( 4 3 ) > 16 . ( 3 5 6 )) You're missing paragraphs on this setting. It should rather be written as \makeAutoBeamSetting '((* . (4 3)) (16 . (3 5 6))) which means I've been missing a set of paragraphs in my examples too. The problem with this setting is that if you want to have the rule apply to 32nd beams you need to explicitly include them: \makeAutoBeamSetting '((* . (4 3)) (16 . (3 5 6)) (32 . (6 10 12)) > > Hhm. Now I'm not sure which I prefer. This example > looks worse! And the grouping form can be specified > in an invalid way, meaning errors can be generated. > One advantage of the ending form is that pretty well > everything you can write is valid, as the final beam > will always end at the end of the bar even if this is > not specified. Only specifying moments beyond the end > of the bar would be erroneous. > > Perhaps on balance I prefer specifying end points > after all. I think the real problem is deciding whether or not we need both numerator and denominator in the moments. For example, we could specify ending numerators (instead of groups) in the setting above: \makeAutoBeamSetting '((* . (4 3)) (16 . (3 8 14)) (32 . (6 16 28)) This works fine for everything but the * rule, which has no denominator listed. Ahh -- I just thought that 8th notes are the longest notes with beams. So we could specify the * entries as eighths, and allow fractions \makeAutoBeamSetting '((* . (1.5 4 7)) would then work properly. Eighth beams would end at 4/8 and 7/8; 16th and shorter would end at 3/16, 4/8, and 7/8. And we could avoid the whole cons cell entry, which
Re: (de)cresendi syntax
> So, I took a look at the issue today and created a patch, which will now allow > all dynamic spanner starters to be implemented as postfix-operators. > > The short (<15 quite trivial lines!) patch is up for review at: > http://codereview.appspot.com/39047 > > Basically, my question for now is whether this the right approach. Call it a > proof-of-concept patch. > If so, we'll need to think about possible upgrade paths for the syntax changes > that are introduced by making all dynamic spanners postfix operators... > The patch also does not include the actual definitions of things like \dim, > \cresc, etc. Wonderful!!! Thanks a lot for this great job! Frédéric ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reverting Beat Grouping Commands
Carl D. Sorensen wrote Monday, April 13, 2009 1:32 AM On 4/12/09 6:14 AM, "Trevor Daniels" wrote: Carl Standardising on a single format for auto-beaming would be a major improvement, and this looks the right way to go. But at present the beatLength/beatGrouping values provide the default action in the event of no defined beam-ending rules. A catch-all default is needed, as we cannot provide explicit default rules for all the (infinite) time signatures. The catch-all default would be implemented in auto-beaming.scm. If there were no defined rule, then the denominator of the time signature would be used to end the beaming, just as it currently is. OK. As long as we provide default rules for compound time signatures that should be fine. I'm a bit concerned about dropping the easy beatLength/beatGrouping interface, which seems to be prefered by most users, and replacing it with a more complex one, but I don't have any suggestions (which work) to make at present. Might a special user interface be preferable to \override and \revert? Instead of \set beatGrouping = #'(1 3 3) (which can be wrong, because it doesn't reference the time signature), it would be something like \override #'autoBeamSetting #'(end 7 8) = \makeAutoBeamSetting '(* . ((1 . 8) (4 . 8) (7 . 8))) Should this not be \set rather than \override, as this is a context property? I agree this is a bit more difficult to type, and may be more difficult to understand. But I think the advantages of A) Having the time signature explicitly included make this worthwhile. Absolutely B) Being explicit about the grouping points make this worthwhile. Not so sure about this. \set #'autoBeamSetting #'(end 7 8) = \makeAutoBeamSetting '(* . ((1 . 8) (4 . 8) (7 . 8))) could be written equivalently as \set #'autoBeamSetting #'(lengths 7 8) = \makeAutoBeamSetting '(* . ( 1 3 3 )) where the beat length is either dem if * or beam duration if specified. makeAutoBeamSetting could convert these to the equivalent 'end' form. Granted you could not write \set #'autoBeamSetting #'(end 7 8) = \makeAutoBeamSetting '(* . ((3 . 16) (4 . 8) (7 . 8))) in the alternative syntax, so some flexibility would be lost, but as this would affect only 16th and shorter beams this would work: \set #'autoBeamSetting #'(lengths 7 8) = \makeAutoBeamSetting '(* . ( 4 3 ) 16 . ( 3 5 6 )) Hhm. Now I'm not sure which I prefer. This example looks worse! And the grouping form can be specified in an invalid way, meaning errors can be generated. One advantage of the ending form is that pretty well everything you can write is valid, as the final beam will always end at the end of the bar even if this is not specified. Only specifying moments beyond the end of the bar would be erroneous. Perhaps on balance I prefer specifying end points after all. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
