Re: Reverting Beat Grouping Commands
Neil Puttock wrote Sunday, April 26, 2009 4:31 PM 2009/4/26 Trevor Daniels : Just to recap, the advantage of \override over \set is that previously overridden values can be recovered by \revert because they are pushed onto a stack, whereas \unset simply restores the original default value. Is that right? Yes. The problem with context properties is there's nowhere to store the previous value My knowledge of the internals is not sufficient to judge whether this is feasible or even possible, but is this [i.e. implementing a stack fo context properties] an alternative approach worth considering? I'm sure it's possible, but it's way beyond my capabilities. That means this is infeasible as a solution. So we are left with two approaches: a) Implement a pseudo-grob so we can use \override and \revert. This would work, as Carl has demonstrated, but it muddies the distinction between context and layout properties. b) Implement special functions (as now) to change the auto-beaming rules, so a pseudo-grob is not required It would, in any case, be desirable to simplify the syntax of the user interface, so some special functions at least will be provided. For example, Graham suggested: so what about \makeBeamGroupings #'(3 3 2) and Carl replied: 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! So maybe we should implement all the user interface with special functions along these lines, perhaps using \makeAutoBeamRule \revertAutoBeamRule (I'd prefer push and pop rather than make and revert, but maybe that's going too far) and later \makeAutoSubdivideRule \revertAutoSubdivideRule Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Date in the footer and Headers/Footers/Titles
Kieren MacMillan wrote: Then I suggest Titles, Headings, Headers, Footers or something similar to avoid the nasty `/'. Headings (Titles) and Margin Text (Headers and Footers) 3.2. Titles Headings and Front-Matter 3.2.1 Titles Headings and Front-Matter score "book", Score Titles, subtitles etc. etc, also one-off things like tag-lines> 3.2.2 Custom Titles and Section Headings the oddHeaderMarkup, evenHeaderMarkup, oddFooterMarkup, evenFooterMarkup and related properties in \page.> Current definition of \header (in NR 3.1.3 File Structure) A \header block. This sets the global header block. This is the block containing the definitions for book-wide settings, like composer, title, etc. I propose renaming this to \front-matter, since most of the stuff mentioned in this quote from the NR describes things that appear at the start of a typical score, and the term header implies something this block doesn't actually do (header as in headers and footers). I suppose another possibility for the name might be \headings, if people want something similar to existing syntax. The current \header behaves differently depending on whether it's at top level or in a \score, when it only processes the title and opus properties. Maybe it would be a good idea to give it a separate name, (\score-headings, \section-headings ?) and add some validation to make sure it is used inside a \score block? Cheers, Ian ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Date in the footer and Headers/Footers/Titles
Ian Hulin wrote: Kieren MacMillan wrote: Then I suggest Titles, Headings, Headers, Footers or something similar to avoid the nasty `/'. Headings (Titles) and Margin Text (Headers and Footers) 3.2. Titles Headings and Front-Matter 3.2.1 Titles Headings and Front-Matter score "book", Score Titles, subtitles etc. etc, also one-off things like tag-lines> 3.2.2 Custom Titles and Section Headings the oddHeaderMarkup, evenHeaderMarkup, oddFooterMarkup, evenFooterMarkup and related properties in \page.> Sorry - hit the send button too soon - this should read 3.2.3 Headers and Footers the appearance each page in the score> Current definition of \header (in NR 3.1.3 File Structure) A \header block. This sets the global header block. This is the block containing the definitions for book-wide settings, like composer, title, etc. I propose renaming this to \front-matter, since most of the stuff mentioned in this quote from the NR describes things that appear at the start of a typical score, and the term header implies something this block doesn't actually do (header as in headers and footers). I suppose another possibility for the name might be \headings, if people want something similar to existing syntax. The current \header behaves differently depending on whether it's at top level or in a \score, when it only processes the title and opus properties. Maybe it would be a good idea to give it a separate name, (\score-headings, \section-headings ?) and add some validation to make sure it is used inside a \score block? Cheers, Ian Hulin ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: recent beaming change?
Thanks Trevor and Patrick for the explanation! It sounds like the new
system will make a lot more sense, and if it beaming 4 eighth notes /
quavers together is the only exceptional case not covered by the new
system, then that exception is probably best added after they have got
their final version working. In the mean time, I will just finalize
this short project with LP 2.12.
Cheers,
Andrew
On Sun, Apr 26, 2009 at 8:31 AM, Trevor Daniels wrote:
>
> Patrick McCarty wrote Re: recent beaming change?
>
>
>>> On Sat, Apr 25, 2009 at 8:31 AM, Andrew Hawryluk
>>> wrote:
My latest LilyPond build (2.13.1, 24 Apr 2009) produces different
beaming than my last build.
e.g. {c''8 c'' c'' c''}
used to produce |_|_|_|
and now it gives me |_| |_|
Was this intentional?
>>>
>>> Yes, this was changed recently. The reasons are listed here:
>>>
>>> http://lists.gnu.org/archive/html/bug-lilypond/2009-03/msg00126.html
>>>
>>> I don't know if the plans to revise the auto-beaming code (being
>>> discussed by Carl, Trevor, and Neil) will address this issue.
>>> Clearly, it would be better to allow for this "special case", since
>>>
>>> |_|_|_|
>>>
>>> is much more common than
>>>
>>> |_| |_|
>>
>> Oops. I should elaborate a little more about this.
>>
>> The first beaming pattern used to be the default in certain cases
>> (e.g. 4/4 time on beats 1 and 3), and this beaming pattern can still
>> be used by modifying beatLength, as Trevor described.
>>
>> But it is reasonable to expect users to use "\set beatLength =
>> #(ly:make-moment 1 2)" if they want the first beaming pattern, which
>> is more common?
>
> I can only repeat what I said in the thread referenced above, namely
> that the new default permits the correct beaming of
>
> \relative c'' {
> a16 a a8 a a
> a8 a16 a a8 a
> a8 a a16 a a8
> a8 a a a16 a % beaming is different
> }
>
> Also, it seems easier to set beatLength to go from 2 to 4 beamed
> quavers than to revert auto-beaming rules if you wanted 2 rather
> than 4 beamed quavers. Lily can't do both by default, and I think
> the new behaviour makes the better compromise. I tried to reduce
> the number of auto-beaming rules to minimise the need to revert
> them. But I'm quite happy to change the beaming rules back if a
> majority of users prefer the old default.
>
> That said, Carl is still hoping to unify the behaviour which would
> make overrides to the beaming behaviour far more rational.
>
> Trevor
>
>
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
