Re: Uses single algorithm for side-position spacing. (issue 6827072)

On 14 mars 2013, at 06:42, k-ohara5...@oco.net wrote: > issue 3242 > > > https://codereview.appspot.com/6827072/diff/38003/lily/axis-group-interface.cc > File lily/axis-group-interface.cc (right): > > https://codereview.appspot.com/6827072/diff/38003/lily/axis-group-interface.cc#newcode902 > l

Re: Uses single algorithm for side-position spacing. (issue 6827072)

issue 3242 https://codereview.appspot.com/6827072/diff/38003/lily/axis-group-interface.cc File lily/axis-group-interface.cc (right): https://codereview.appspot.com/6827072/diff/38003/lily/axis-group-interface.cc#newcode902 lily/axis-group-interface.cc:902: Skyline_pair skylines (inside_staff_sk

Re: Standardizes use of empty extents in pure heights and skylines. (issue 7310075)

On 2013/03/13 20:40:36, dak wrote: "Keith OHara" writes: > The C standard requires the variables to be equal after assignment. > C99 5.4.2.2: "Except for assignment and cast (which remove all extra > range and precision), the values of operations with floating ope

Re: API for getting various kinds of grobs

On Wed, Mar 13, 2013 at 4:33 PM, Janek Warchoł wrote: > > On Wed, Mar 13, 2013 at 12:27 AM, Joe Neeman wrote: > > The easiest way to define get_grob is to make 'align-to a list of > symbols, > > which you interpret as a path from the current grob to the grob you want > to > > align it to. For exa

Re: Standardizes use of empty extents in pure heights and skylines. (issue 7310075)

Hi, On Wed, Mar 13, 2013 at 10:44 AM, wrote: > > "m...@mikesolomon.org" writes: >> The concern before was a comment about numerical inaccuracy, but after >> having tested the patch, this seems not to be an issue. > > Like Keith pointed out, it could become one if more than one operation > is do

Re: API for getting various kinds of grobs

Hi Xavier, Joe, On Wed, Mar 13, 2013 at 12:05 AM, Xavier Scheuer wrote: > I'm not a developer, so my question might be stupid, but > > Can't you use existing "break-alignable-interface", > "break-aligned-interface" and "break-alignment-interface" and > *expand* a property like "break-align-symbol

Re: strange behaviour of relative_coordinate

On Wed, Mar 13, 2013 at 7:11 AM, Han-Wen Nienhuys wrote: > IIRC, the refp should be an ancestor of the grob you're asking for. > This means only one of > > obj->relative_coord(refp, X) > refp->relative_coord(obj, X) > > is valid. ok - i'll continue investigating code armed with that knowledge

PATCHES: Countdown for March 17th - 12:00 GMT

Hello, *Countdown – March 17th 2013 – 12:00 GMT* * * * * * * * * 3228 Documentation Aleksandr Andreev push Patch: Change \

Re: Adds Ferneyhough hairpins to LilyPond. (issue 7615043)

Hi Mike, sorry to be such an inch pincher. https://codereview.appspot.com/7615043/diff/23001/scm/output-lib.scm File scm/output-lib.scm (right): https://codereview.appspot.com/7615043/diff/23001/scm/output-lib.scm#newcode1061 scm/output-lib.scm:1061: (thick (* thick (layout-line-thickness grob

Re: Standardizes use of empty extents in pure heights and skylines. (issue 7310075)

"Keith OHara" writes: > On Wed, 13 Mar 2013 02:44:33 -0700, wrote: > >> If left and right have equal values to start with, C++ is still not >> required to have left and right receive the same value after >> >> left = left*factor + offset; >> right = right*factor + offset; > > The C standard requ

Re: Standardizes use of empty extents in pure heights and skylines. (issue 7310075)

On Wed, 13 Mar 2013 02:44:33 -0700, wrote: If left and right have equal values to start with, C++ is still not required to have left and right receive the same value after left = left*factor + offset; right = right*factor + offset; The C standard requires the variables to be equal after assi

Re: GUB usage

On 12 March 2013 19:46, Jan Nieuwenhuizen wrote: > Graham Percival writes: > >>> So now I need to patch the gcc sources because they have a small >>> bug that prevents building, and here I am puzzled about the >>> overall GUB architecture. Why is the patching logic spread out >>> between actual pa

Re: Harmonize point-and-click information for #xxx and $xxx (issue 7501046)

On Wed, Mar 13, 2013 at 4:56 PM, wrote: > On 2013/03/13 15:44:20, janek wrote: >> Ok, now i see what you mean. >> I think my problem was that, because of "however", i had thought that >> in the description you contrast some new behaviour with some other >> behaviour that existed already. As in "

Re: bar line interface / repat structure considerations

Hi Marc&all, On Wed, Mar 13, 2013 at 10:09 AM, Marc Hohl wrote: > make > sure you sit comfortable and have a nice cup of coffee, tea or whatever > around... these words actually reminded me that i had a tea waiting, and thanks to you it didn't get totally cold before i drank it :) > a) replace

Re: Harmonize point-and-click information for #xxx and $xxx (issue 7501046)

On 2013/03/13 15:44:20, janek wrote: On Wed, Mar 13, 2013 at 9:11 AM, wrote: > I don't get it. Seriously. All of $, #, and \ are lexical elements > combining with something following behind them (and all can take an > identifier) and producing an expression or a copy of i

Re: Harmonize point-and-click information for #xxx and $xxx (issue 7501046)

On Wed, Mar 13, 2013 at 9:11 AM, wrote: > I don't get it. Seriously. All of $, #, and \ are lexical elements > combining with something following behind them (and all can take an > identifier) and producing an expression or a copy of it. In the case > of music, this expression carries point-an

Re: bar line interface / repat structure considerations

Joram Berger writes: > Hi, > > I would like to add some thoughts to that: > > 1.) What I use (and what is probably the most frequent case) are: > a) \repeat {} and \alternative { {} {} } % repeats > b) \bar "||" % new section \divisio > c) \bar "|." % end of staff \finis > The first is syn

Re: API for getting various kinds of grobs

> What i would like: specify the reference grob in a property, for example > > \override LyricText #'align-to = #'Stem > > and then have one callback function that would be smart enough to find > appropriate grob to use and feed it to the method calculating > alignment. Hi Janek, I think this wo

Re: bar line interface / repat structure considerations

Hi, I would like to add some thoughts to that: 1.) What I use (and what is probably the most frequent case) are: a) \repeat {} and \alternative { {} {} } % repeats b) \bar "||" % new section c) \bar "|." % end of staff The first is syntactical the others are bar lines. Syntactical elements

Re: Adds Ferneyhough hairpins to LilyPond. (issue 7615043)

On 03/13/2013 12:22 AM, Janek Warchoł wrote: this reminds me of an idea i had that would probably play nicely with this: make it possible to manipulate hairpins' ends separately. The point would be that you could specify a vertical offset for one end and thus easily achieve a slanted hairpin (wit

Re: bar line interface / repat structure considerations

Am 13.03.2013 12:18, schrieb David Kastrup: Marc Hohl writes: Am 13.03.2013 10:27, schrieb David Kastrup: One reason I am skeptical about this particular suggestion is that more often than not (like the typical multi-stanza pop song with a separate ending), D.S.a.C is _intertwined_ with

Re: convert-ly rule

David Kastrup writes: > "m...@mikesolomon.org" writes: > >> On 13 mars 2013, at 11:56, David Kastrup wrote: >> >>> "m...@mikesolomon.org" writes: >>> Then that would mean that the tuplet bracket could never use side position interface and vice versa. >>> >>> Yes. The set of interf

Re: convert-ly rule

"m...@mikesolomon.org" writes: > On 13 mars 2013, at 11:56, David Kastrup wrote: > >> "m...@mikesolomon.org" writes: >> >>> Then that would mean that the tuplet bracket could never use side >>> position interface and vice versa. >> >> Yes. The set of interfaces is not user-changeable as far

Re: bar line interface / repat structure considerations

Marc Hohl writes: > Am 13.03.2013 10:27, schrieb David Kastrup: > >>One reason I am skeptical about this >> particular suggestion is that more often than not (like the typical >> multi-stanza pop song with a separate ending), D.S.a.C is _intertwined_ >> with a repeat volta. > LilyPond already

Re: convert-ly rule

On 13 mars 2013, at 11:56, David Kastrup wrote: > "m...@mikesolomon.org" writes: > >> On 13 mars 2013, at 11:00, David Kastrup wrote: >> >>> It might also be possible to let a callback check for the existing >>> grob interfaces in possible cases of contention and only use the >>> respective v

Re: convert-ly rule

"m...@mikesolomon.org" writes: > On 13 mars 2013, at 11:00, David Kastrup wrote: > >> It might also be possible to let a callback check for the existing >> grob interfaces in possible cases of contention and only use the >> respective value if the grob had the proper interface. >> >> So you'd h

Re: bar line interface / repat structure considerations

Am 13.03.2013 10:27, schrieb David Kastrup: Marc Hohl writes: Hello list, after some discussions on -user (partly emotional - sorry for that!) I promised to think about improving the bar line interface. Well, hereare some preliminary results. The mail got a bit long, so make sure you sit comf

Re: convert-ly rule

On 13 mars 2013, at 11:00, David Kastrup wrote: > "m...@mikesolomon.org" writes: > >> Hey all, >> >> I'm not too good at writing convert-ly rules. Is there a model I can >> use for replacing a property with another? Specifically, I'd like to >> write a patch changing: >> >> TupletBracket.st

Re: convert-ly rule

m...@mikesolomon.org wrote Wednesday, March 13, 2013 10:21 AM > On 13 mars 2013, at 10:51, David Kastrup wrote: > >> "m...@mikesolomon.org" writes: >> >>> Hey all, >>> >>> I'm not too good at writing convert-ly rules. Is there a model I can >>> use for replacing a property with another? S

Re: convert-ly rule

On 13 mars 2013, at 10:51, David Kastrup wrote: > "m...@mikesolomon.org" writes: > >> Hey all, >> >> I'm not too good at writing convert-ly rules. Is there a model I can >> use for replacing a property with another? Specifically, I'd like to >> write a patch changing: >> >> TupletBracket.st

Re: convert-ly rule

"m...@mikesolomon.org" writes: > Hey all, > > I'm not too good at writing convert-ly rules. Is there a model I can > use for replacing a property with another? Specifically, I'd like to > write a patch changing: > > TupletBracket.staff-padding > > to: > > TupletBracket.bracket-staff-padding > >

Re: convert-ly rule

"m...@mikesolomon.org" writes: > Hey all, > > I'm not too good at writing convert-ly rules. Is there a model I can > use for replacing a property with another? Specifically, I'd like to > write a patch changing: > > TupletBracket.staff-padding > > to: > > TupletBracket.bracket-staff-padding > >

Re: convert-ly rule

David Kastrup writes: > "m...@mikesolomon.org" writes: > >> Hey all, >> >> I'm not too good at writing convert-ly rules. Is there a model I can >> use for replacing a property with another? Specifically, I'd like to >> write a patch changing: >> >> TupletBracket.staff-padding >> >> to: >> >> T

Re: Standardizes use of empty extents in pure heights and skylines. (issue 7310075)

Just sent this to developer list only, so here a copy for the record: "m...@mikesolomon.org" writes: The concern before was a comment about numerical inaccuracy, but after having tested the patch, this seems not to be an issue. Like Keith pointed out, it could become one if more than one ope

Re: convert-ly rule

"m...@mikesolomon.org" writes: > Hey all, > > I'm not too good at writing convert-ly rules. Is there a model I can > use for replacing a property with another? Specifically, I'd like to > write a patch changing: > > TupletBracket.staff-padding > > to: > > TupletBracket.bracket-staff-padding > >

Re: Standardizes use of empty extents in pure heights and skylines. (issue 7310075)

"m...@mikesolomon.org" writes: > The concern before was a comment about numerical inaccuracy, but after > having tested the patch, this seems not to be an issue. Like Keith pointed out, it could become one if more than one operation is done before storing the result, and/or there are different c

convert-ly rule

Hey all, I'm not too good at writing convert-ly rules. Is there a model I can use for replacing a property with another? Specifically, I'd like to write a patch changing: TupletBracket.staff-padding to: TupletBracket.bracket-staff-padding as one cannot currently use the side position inter

Re: bar line interface / repat structure considerations

Marc Hohl writes: > Hello list, > > after some discussions on -user (partly emotional - sorry for that!) > I promised to think about improving the bar line interface. Well, > hereare some preliminary results. The mail got a bit long, so make > sure you sit comfortable and have a nice cup of coffe

Re: Standardizes use of empty extents in pure heights and skylines. (issue 7310075)

On 12 mars 2013, at 23:44, janek.lilyp...@gmail.com wrote: > Hi Mike, > > i've read changes in code and i don't quite get what this change is for. > What makes it possible that we can now accept boxes that are narrower > than epsilon? What can we achieve with that and why? > > I'm sorry for ask

Re: bar line interface / repat structure considerations

Am 13.03.2013 10:09, schrieb Marc Hohl: [...] a) replace the current mechanism by a command (define-bar-line ( :prebreak :postbreak :span-bar :prebreak-span :postbreak-span )) where :prebreak, :postbreak, :spanbar, :prebreak-span and :postbreak-span arguments are optional,and we define (in

bar line interface / repat structure considerations

Hello list, after some discussions on -user (partly emotional - sorry for that!) I promised to think about improving the bar line interface. Well, hereare some preliminary results. The mail got a bit long, so make sure you sit comfortable and have a nice cup of coffee, tea or whatever around...

Re: Adds Ferneyhough hairpins to LilyPond. (issue 7615043)

On 13 mars 2013, at 00:02, janek.lilyp...@gmail.com wrote: > Nice hairpins! > > Janek > > > https://codereview.appspot.com/7615043/diff/23001/input/regression/ferneyhough-hairpins.ly > File input/regression/ferneyhough-hairpins.ly (right): > > https://codereview.appspot.com/7615043/diff/23001/

Re: Harmonize point-and-click information for #xxx and $xxx (issue 7501046)

On 2013/03/13 07:03:16, janek wrote: On Wed, Mar 13, 2013 at 7:06 AM, wrote: > On 2013/03/12 22:12:34, janek wrote: >> >> As usual, i have a dumb question about the commit message. >> What is the relation of \xxx to #xxx and $xxx? >> I can't quite grok the commit message :/

Re: Harmonize point-and-click information for #xxx and $xxx (issue 7501046)

On Wed, Mar 13, 2013 at 7:06 AM, wrote: > On 2013/03/12 22:12:34, janek wrote: >> >> As usual, i have a dumb question about the commit message. >> What is the relation of \xxx to #xxx and $xxx? >> I can't quite grok the commit message :/ > > Uh, \xxx is something starting with a backslash, $xxx i