Re: 'measure-counter-stencil' not public?

Hi Harm, On Tue, Feb 17, 2015 at 5:09 PM, Thomas Morley wrote: > 2015-02-17 21:35 GMT+01:00 David Nalesnik : > > Hi Harm, > > > > On Tue, Feb 17, 2015 at 2:21 PM, Thomas Morley > > > wrote: > >> > >> Hi, > >> > >> is there

Re: 'measure-counter-stencil' not public?

Hi Harm, On Tue, Feb 17, 2015 at 2:21 PM, Thomas Morley wrote: > Hi, > > is there any reason the stencil-procedure for > 'measure-counter-stencil' isn't public? > It doesn't works with 'make-stencil-boxer' etc > Apparently, for no good reason! Do you want to change it? --David ___

Re: Make Grob::name accessible to Scheme (issue 203090043 by david.nales...@gmail.com)

On Mon, Feb 16, 2015 at 4:01 PM, Paul Morris wrote: > > On Feb 16, 2015, at 2:06 PM, David Nalesnik > wrote: > > > > In this case, KeySignature has both key-signature-interface and > key-cancellation-interface, but KeyCancellation only has > key-cancellation-inte

Re: Make Grob::name accessible to Scheme (issue 203090043 by david.nales...@gmail.com)

On Mon, Feb 16, 2015 at 1:30 PM, David Kastrup wrote: > David Nalesnik writes: > > > I suppose even better would be to come up with a way to automatically > > document public Scheme functions, but I wouldn't know how to do that > > at this point. > > Shouldn&#

Re: Make Grob::name accessible to Scheme (issue 203090043 by david.nales...@gmail.com)

On Mon, Feb 16, 2015 at 12:20 PM, David Kastrup wrote: > Paul Morris writes: > > > dak wrote > >> Paul Morris < > > > >> paul@ > > > >> > writes: > >>> Hmmm... would it be a good idea to also have a ly:grob-has-interface > >>> scheme > >>> function? > >> > >> How would it differ from the existin

Re: Make Grob::name accessible to Scheme (issue 203090043 by david.nales...@gmail.com)

On Mon, Feb 16, 2015 at 10:04 AM, Paul Morris wrote: P.S. FWIW, here's one marginal use case. I've been using grob names to > differentiate key signature grobs from key cancellation grobs, within a > custom engraver that acknowledges the key-signature-interface. I could add > a second engraver

Re: Make Grob::name accessible to Scheme (issue 203090043 by david.nales...@gmail.com)

On 2015/02/16 07:56:10, dak wrote: On 2015/02/15 19:54:19, david.nalesnik wrote: > Please review. Thanks! "Needing to determine the name of a grob" should actually rarely be necessary: the pervasive information connected to the functionality of a grob is rather its interfaces. That's the

Re: Add Scheme function to return column associated with Item. (issue 203910043 by david.nales...@gmail.com)

Harm, On Sun, Feb 15, 2015 at 2:42 PM, Thomas Morley wrote: > > Can't review C++, so I'll not post there. > There IS something you can help with, though. In the patch as it stands, I'm simply making Grob::name available through Scheme. It thus returns a string. (Grob::name actually converts

Re: Add Scheme function to return column associated with Item. (issue 203910043 by david.nales...@gmail.com)

On Sun, Feb 15, 2015 at 1:14 PM, David Nalesnik wrote: > > > Now, a function to get a grob's name would certainly be useful. I'm sick > to death of constantly recreating it or looking it up (as I bet you are)! > If there's a question of usefulness, I think we'

Make Grob::name accessible to Scheme (issue 203090043 by david.nales...@gmail.com)

Reviewers: , Message: Please review. Thanks! Description: Make Grob::name accessible to Scheme Needing to determine the name of a grob is extremely common to users of Scheme. Please review this at https://codereview.appspot.com/203090043/ Affected files (+11, -0 lines): M lily/grob-scheme.

Re: Add Scheme function to return column associated with Item. (issue 203910043 by david.nales...@gmail.com)

On Sun, Feb 15, 2015 at 12:34 PM, Thomas Morley wrote: > 2015-02-15 19:28 GMT+01:00 Thomas Morley : > > > Oops, definition for 'grob-name' is missing: > > #(define grob-name > (lambda (x) > (if (ly:grob? x) > (assq-ref (ly:grob-property x 'meta) 'name) > (ly:error "~a is n

Re: Add Scheme function to return column associated with Item. (issue 203910043 by david.nales...@gmail.com)

Hi Harm, On Sun, Feb 15, 2015 at 12:28 PM, Thomas Morley wrote: > > > Some time ago I wrote a more generic code: > > #(define (look-up-for-parent name-symbol axis grob) > " > Return the parent of @var{grob}, specified by it's @var{name-symbol} in > axis @var{axis}. > If not found, look up for

Re: Add Scheme function to return column associated with Item. (issue 203910043 by david.nales...@gmail.com)

On Sun, Feb 15, 2015 at 7:58 AM, Urs Liska wrote: > Can't judge the code but the idea looks great :-) > > Thanks--I'm noticing that bits of code get reused on the lists, so there's a need. This will help tuck away some of the code gobbledygook that is so off-putting.. It occurs to me that it s

Add Scheme function to return column associated with Item. (issue 203910043 by david.nales...@gmail.com)

Reviewers: , Message: Please review. Description: Add Scheme function to return column associated with Item. The C++ function PaperColumn::get_column is used frequently, and it makes sense to have a Scheme function which performs the same task. An example of a practical application is the requ

Re: Allow independent adjustment of minimum length for spanner siblings (issue 201140043 by david.nales...@gmail.com)

https://codereview.appspot.com/201140043/diff/20001/lily/spanner.cc File lily/spanner.cc (right): https://codereview.appspot.com/201140043/diff/20001/lily/spanner.cc#newcode394 lily/spanner.cc:394: /* On 2015/02/06 21:47:11, lemzwerg wrote: Minor nit: Please use spaces, not tabs. Done. https

Re: Allow independent adjustment of minimum length for spanner siblings (issue 201140043 by david.nales...@gmail.com)

https://codereview.appspot.com/201140043/diff/20001/lily/spanner.cc File lily/spanner.cc (right): https://codereview.appspot.com/201140043/diff/20001/lily/spanner.cc#newcode404 lily/spanner.cc:404: Rod r; Perhaps we should call this rod something else to underscore that it's not the same rod as

Re: Allow independent adjustment of minimum length for spanner siblings (issue 201140043 by david.nales...@gmail.com)

https://codereview.appspot.com/201140043/diff/1/input/regression/minimum-length-after-break.ly File input/regression/minimum-length-after-break.ly (right): https://codereview.appspot.com/201140043/diff/1/input/regression/minimum-length-after-break.ly#newcode15 input/regression/minimum-length-aft

Re: Allow independent adjustment of minimum length for spanner siblings (issue 201140043 by david.nales...@gmail.com)

https://codereview.appspot.com/201140043/diff/1/input/regression/minimum-length-after-break.ly File input/regression/minimum-length-after-break.ly (right): https://codereview.appspot.com/201140043/diff/1/input/regression/minimum-length-after-break.ly#newcode15 input/regression/minimum-length-aft

Allow independent adjustment of minimum length for spanner siblings (issue 201140043 by david.nales...@gmail.com)

Reviewers: , Message: Please review. Description: Allow independent adjustment of minimum length for spanner siblings The property minimum-length affects both unbroken and broken spanners, making independent adjustment impossible. This patch adds a property, minimum-length-after-break, which,

Re: Issue 2535: Staccato on stem side alignment when other articulations are present (issue 196260043 by david.nales...@gmail.com)

https://codereview.appspot.com/196260043/diff/20001/input/regression/script-shift.ly File input/regression/script-shift.ly (right): https://codereview.appspot.com/196260043/diff/20001/input/regression/script-shift.ly#newcode6 input/regression/script-shift.ly:6: means centered on the stem.) On 20

Re: Issue 2535: Staccato on stem side alignment when other articulations are present (issue 196260043 by david.nales...@gmail.com)

On 2015/01/27 22:00:49, lemzwerg wrote: https://codereview.appspot.com/196260043/diff/20001/input/regression/script-shift.ly File input/regression/script-shift.ly (right): https://codereview.appspot.com/196260043/diff/20001/input/regression/script-shift.ly#newcode6 input/regression/script-sh

Re: Issue 2535: Staccato on stem side alignment when other articulations are present (issue 196260043 by david.nales...@gmail.com)

https://codereview.appspot.com/196260043/diff/20001/input/regression/script-shift.ly File input/regression/script-shift.ly (right): https://codereview.appspot.com/196260043/diff/20001/input/regression/script-shift.ly#newcode6 input/regression/script-shift.ly:6: means centered on the stem.) On 20

Re: Issue 2535: Staccato on stem side alignment when other articulations are present (issue 196260043 by david.nales...@gmail.com)

On 2015/01/27 15:07:24, dak wrote: On 2015/01/27 14:37:27, david.nalesnik wrote: > What would this property be named? snap-to-column? shift-in-column? I suggest picking a name that starts in the same way as the existing property. toward-stem-shift-in-column would be unambiguous. Long, pe

Re: Issue 2535: Staccato on stem side alignment when other articulations are present (issue 196260043 by david.nales...@gmail.com)

Eek. Sorry for overquoting. https://codereview.appspot.com/196260043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Issue 2535: Staccato on stem side alignment when other articulations are present (issue 196260043 by david.nales...@gmail.com)

On 2015/01/27 08:50:36, dak wrote: On 2015/01/27 07:52:05, lemzwerg wrote: > On 2015/01/27 07:26:53, dak wrote: > > It seems to me like this number-pair consists of two settings that would > almost > > always be adjusted independently. Wouldn't it make more sense to make a > > separate prope

Re: Issue 2535: Staccato on stem side alignment when other articulations are present (issue 196260043 by david.nales...@gmail.com)

On 2015/01/27 07:32:24, dak wrote: Aaaand another thought: wouldn't it make more sense instead of having independent shifts for "with other articulations" and "without other articulations" when the articulation closest to the notehead is responsible for aligning the whole stack of articulations

Issue 2535: Staccato on stem side alignment when other articulations are present (issue 196260043 by david.nales...@gmail.com)

Reviewers: , Message: Please review. Description: Issue 2535: Staccato on stem side alignment when other articulations are present The default positioning of staccato dots in combination with other articulations is poor, because the dot is positioned midway between the center of the note head a

Re: Retrieving information about breaks

On Fri, Jan 23, 2015 at 11:52 AM, David Kastrup wrote: > Urs Liska writes: > > > > > But when > > > > (ly:grob-property grob 'non-musical) > > > > evaluates to #t then > > This is about the case where > > (ly:grob-property grob 'non-musical) evaluates to '(). > > > (eq? #t (ly:grob-property grob

Re: Retrieving information about breaks

Urs, On Fri, Jan 23, 2015 at 11:17 AM, Urs Liska wrote: > Hi David, > > thanks, that works great. > It did *not* write to a file, but that's not the issue here. > The main point is that it listens to implicit break events. > The only time it doesn't write to a file for me is when I don't save

Re: Retrieving information about breaks (was: Partial compilation (again))

e at which positions (in terms of barnumber and > measure-position) the final line breaks, page breaks and page turns have > been placed in LilyPond? > I'm sure this information has to be present at one point, but someone (I > think it may have been David Nalesnik) expressed the opini

Document 'scripts/add to relevant interfaces (issue 195190043 by david.nales...@gmail.com)

Reviewers: , Message: Please review. Description: Document 'scripts/add to relevant interfaces Please review this at https://codereview.appspot.com/195190043/ Affected files (+3, -1 lines): M lily/script-column.cc M lily/tuplet-bracket.cc M scm/define-grob-properties.scm Index: lily/sc

Missing spaces in lily/pure-from-neighbor-interface.cc (issue 192370043 by david.nales...@gmail.com)

Reviewers: , Message: small correction... Description: Missing spaces in lily/pure-from-neighbor-interface.cc Please review this at https://codereview.appspot.com/192370043/ Affected files (+2, -2 lines): M lily/pure-from-neighbor-interface.cc Index: lily/pure-from-neighbor-interface.cc di

doc fix for lily/stem-engraver.cc (issue 198820043 by david.nales...@gmail.com)

Reviewers: , Message: Please review. Description: doc fix for lily/stem-engraver.cc This engraver also creates Flag and StemStub grobs. Please review this at https://codereview.appspot.com/198820043/ Affected files (+3, -1 lines): M lily/stem-engraver.cc Index: lily/stem-engraver.cc diff

Issue 4238: Glissando overlaps dot (issue 194920043 by david.nales...@gmail.com)

Reviewers: , Message: Please review. Description: Issue 4238: Glissando overlaps dot Glissandi will now begin after augmentation dots by default. This behavior may be changed by overriding a new subproperty named 'start-at-dot, set by default to #t. Please review this at https://codereview.ap

Update docstring in lily/note-head-line-engraver.cc (issue 194900043 by david.nales...@gmail.com)

Reviewers: , Message: Please review. Description: Update docstring in lily/note-head-line-engraver.cc As of commit 06dbc712c654888708b9feabbd0affe9ff2e4902 (May 27, 2003), this file is not involved in the creation of Glissando grobs. Please review this at https://codereview.appspot.com/1949000

Re: ly:line-interface::print should read ly:line-spanner::print in NR (issue 186650043 by thomasmorle...@gmail.com)

LGTM. https://codereview.appspot.com/186650043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: git fetch returns fatal error

On Sat, Jan 3, 2015 at 4:13 PM, Thomas Morley wrote: > Hi, > > after some months without own computer I've a new one and lilydevel > working. > Good to hear it! -David ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailma

Doc: Issue 4221: Corrections to example of 'positions property (issue 186920043 by tdanielsmu...@googlemail.com)

LGTM https://codereview.appspot.com/186920043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Cello fingering indications

On Thu, Nov 27, 2014 at 3:24 AM, David Kastrup wrote: > > add-event seems to be a frequent enough use case to figure out a nice > global name for it and provide it in LilyPond proper. > I agree. --David ___ lilypond-devel mailing list lilypond-devel@g

Use number-pair-list? with 'control-points (issue 159450043 by david.nales...@gmail.com)

Reviewers: , Message: Please review. Description: Use number-pair-list? with 'control-points The predicate number-pair-list? is a better fit than list?. Please review this at https://codereview.appspot.com/159450043/ Affected files (+1, -1 lines): M scm/define-grob-properties.scm Index: s

Improvements to measure counter (issue 156380043 by david.nales...@gmail.com)

Reviewers: , Message: Please review. Description: Improvements to measure counter Improvements to measure counter This patch adds no new functionality to the measure counter, but there are improvements to the code. The stencil callback has been shortened, as there is no need to search for c

non-existent procedure-with-setter in input/regression/scheme-text-spanner.ly (issue 157100043 by david.nales...@gmail.com)

Reviewers: , Message: Please review. Description: No procedure-with-setter is provided for ly:spanner-set-bound! in scm/music-functions.scm. This patch removes the faulty usage in input/regression/scheme-text-spanner.ly. Please review this at https://codereview.appspot.com/157100043/ Affecte

Re: indclude notnames bn, etc., in English (issue 133840043 by k-ohara5...@oco.net)

I think this will be helpful to users of English note entry, and why not take advantage of the duplication for "c", "d", and the like in scm/define-note-names.scm? The only difficulty might be that a user might confuse "cn" with an explicit accidental. Say, if he/she used it for C in C major. P

Re: some working grob properties are unlisted?

On Sat, Jul 26, 2014 at 8:25 AM, David Nalesnik wrote: > > > I think we should also add font-interface, as InstrumentName responds to > font-shape, for example. > > Already included :) ___ lilypond-devel mailing list lilypond-d

Re: some working grob properties are unlisted?

On Fri, Jul 25, 2014 at 6:33 PM, Mark Polesky wrote: > David Nalesnik wrote: > >> I noticed that the 'baseline-skip property works with the > >> InstrumentName grob, which confuses me, because in the IR > >> entry for IntsrumentName, none of the supported i

Re: some working grob properties are unlisted?

On Fri, Jul 25, 2014 at 4:27 PM, David Nalesnik wrote: > > > Personally, I've long wondered whether interfaces serve any purpose other > than for acknowledging grobs in engravers. > > (well, and in generating documentation...) ___

Re: some working grob properties are unlisted?

On Fri, Jul 25, 2014 at 4:27 PM, David Nalesnik wrote: > > > \version "2.19.10" > > #(define (pr grob) >(let* ((layout (ly:grob-layout grob)) > (defs (ly:output-def-lookup layout 'text-font-defaults)) > (props (ly:grob-ali

Re: some working grob properties are unlisted?

Hi Mark, On Tue, Jul 22, 2014 at 4:09 PM, Mark Polesky wrote: > I noticed that the 'baseline-skip property works with the > InstrumentName grob, which confuses me, because in the IR > entry for IntsrumentName, none of the supported interfaces > listed at the bottom provide the 'baseline-skip pro

Re: Allow specifying different alignment for grob and its parent (issue 118950043 by janek.lilyp...@gmail.com)

On Wed, Jul 23, 2014 at 9:45 AM, wrote: > > > P.S. Can you suggest an application of self-alignment-Y? > > Forget that--I see an application in NR 5.5.1. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypo

Re: Allow specifying different alignment for grob and its parent (issue 118950043 by janek.lilyp...@gmail.com)

Do you think a regtest would be appropriate? LGTM. A natural extension of self-alignment capabilities. P.S. Can you suggest an application of self-alignment-Y? https://codereview.appspot.com/118950043/ ___ lilypond-devel mailing list lilypond-devel@

Re: Issue 4015: Add \magnifyStaff. (issue 117830043 by markpole...@gmail.com)

On Fri, Jul 18, 2014 at 2:00 AM, Marc Hohl wrote: > > > \rescale...? > > \scale.. would be better, but my favorite is still \magnify... --David ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Issue 4015: Add \magnifyStaff. (issue 117830043 by markpole...@gmail.com)

The changes look good to me, but I'm getting a property type-check warning for `thin-kern.' https://codereview.appspot.com/117830043/diff/80001/ly/music-functions-init.ly File ly/music-functions-init.ly (right): https://codereview.appspot.com/117830043/diff/80001/ly/music-functions-init.ly#newc

Re: Issue 4015: Add \magnifyStaff. (issue 117830043 by markpole...@gmail.com)

Hi Mark, On Thu, Jul 17, 2014 at 2:34 PM, wrote: > > > While I have your attention, there was some discussion on the mailing > list about changing \magnifyMusic and \magnifyStaff to \resizeMusic and > \resizeStaff. Any opinion? > > Hmm. To be honest, I rather like \magnifyMusic and \magnifySta

Re: Issue 4015: Add \magnifyStaff. (issue 117830043 by markpole...@gmail.com)

Looks well coded and well commented. I have some observations/questions about the regtests, but otherwise LGTM. https://codereview.appspot.com/117830043/diff/60001/input/regression/magnifyStaff-bar-lines.ly File input/regression/magnifyStaff-bar-lines.ly (right): https://codereview.appspot.com

Fix doc string of ly:pitch-diff (issue 104640043 by d...@gnu.org)

LGTM. https://codereview.appspot.com/104640043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel

Issue 3992: Fix dodecaphonic-no-repeat (issue 110570043 by david.nales...@gmail.com)

Reviewers: , Message: Please review. Thanks. Description: Issue 3992: Fix dodecaphonic-no-repeat Incorporate renaming of localKeySignature to localAlterations. The function dodecaphonic-no-repeat-rule now considers alterations. Improvement to code comments. Improve code formatting. Please

Re: typo/oversight in align-interface.cc and page-layout-problem.cc (issue 115770043 by thomasmorle...@gmail.com)

LGTM. https://codereview.appspot.com/115770043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: difference between \column and \left-column?

Hi Harm, On Sat, Jul 12, 2014 at 6:49 AM, Thomas Morley wrote: > Hi, > > I'm working on some markup-commands. > > Currently we have the two markup-commands \column and \left-column. > Whats the difference in usage between them? > If there isn't any, why not get rid of one of them. > > \markup {

Re: Issue 2245: always align dynamics and lyrics on "main" notehead (issue 108270044 by janek.lilyp...@gmail.com)

https://codereview.appspot.com/108270044/diff/40001/scm/define-grobs.scm File scm/define-grobs.scm (right): https://codereview.appspot.com/108270044/diff/40001/scm/define-grobs.scm#newcode87 scm/define-grobs.scm:87: (X-extent . ,ly:accidental-interface::width) The old code is used as an example

Re: Doc: NR - 1.2.5 - Bar Numbers - added snippet (issue 106320046 by pkx1...@gmail.com)

https://codereview.appspot.com/106320046/diff/1/Documentation/snippets/new/printing-bar-numbers-with-changing-regular-intervals.ly File Documentation/snippets/new/printing-bar-numbers-with-changing-regular-intervals.ly (right): https://codereview.appspot.com/106320046/diff/1/Documentation/snippe

Re: Changes.tely updated - 2.19.x up to June 2014 (issue 108130043 by pkx1...@gmail.com)

On 2014/06/30 22:00:15, J_lowe wrote: Thanks https://codereview.appspot.com/108130043/diff/70001/Documentation/changes.tely File Documentation/changes.tely (right): https://codereview.appspot.com/108130043/diff/70001/Documentation/changes.tely#newcode141 Documentation/changes.tely:141: A

Re: Changes.tely updated - 2.19.x up to June 2014 (issue 108130043 by pkx1...@gmail.com)

https://codereview.appspot.com/108130043/diff/70001/Documentation/changes.tely File Documentation/changes.tely (right): https://codereview.appspot.com/108130043/diff/70001/Documentation/changes.tely#newcode141 Documentation/changes.tely:141: A new markup command @code{\justify-line} has been add

Re: questions about inconsistencies in Slur and PhrasingSlur

Hi Mark, On Fri, Jun 6, 2014 at 1:32 AM, Mark Polesky wrote: > 1) Slur has a default line-thickness property, so why doesn't PhrasingSlur? > > 2) If Slur.thickness = 1.2, why does PhrasingSlur.thickness = 1.1? > > Are these oversights? Based on my understanding of classical engraving, > regula

Issue 3933: Use \tempo in Real music example (issue 104740043)

LGTM. https://codereview.appspot.com/104740043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Reposition voiced rests (Issue 3902) (issue 101720045)

On 2014/05/27 14:27:07, email_philholmes.net wrote: - Original Message - From: To: ; ; ; ; Cc

Re: Reposition voiced rests (Issue 3902) (issue 101720045)

https://codereview.appspot.com/101720045/diff/1/lily/rest.cc File lily/rest.cc (right): https://codereview.appspot.com/101720045/diff/1/lily/rest.cc#newcode138 lily/rest.cc:138: To be consistent with your change above, shouldn't this be: return neutral + 2 * dir; https://codereview.appspot.c

Re: Fix calculation of X-extent of AccidentalPlacement. (issue 94980043)

Hi Karol, On Sat, May 3, 2014 at 5:23 PM, karol wrote: > > Hi David. Does your patch fix issue 612? > > Sorry--unfortunately not. -David ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel

Fix calculation of X-extent of AccidentalPlacement. (issue 94980043)

Reviewers: , Message: Please review. Thanks! Description: Fix calculation of X-extent of AccidentalPlacement. Previously, the offsets used for staggered placement of accidentals were not included in the calculation of the width of AccidentalPlacement grobs. Please review this at https://coder

Re: using \offset with Slur.positions

Hi, On Tue, Apr 8, 2014 at 7:53 PM, Paul Morris wrote: Looks like this can be simplified as follows. Cheers, -Paul > > \version "2.19.2" > > offsetPositions = > \override Slur.positions = > #(lambda (grob) >(cons > (cdar (ly:slur::calc-control-points grob)) > (cdar (reverse (ly:slu

Re: using \offset with Slur.positions

On Tue, Apr 8, 2014 at 7:12 AM, David Nalesnik wrote: > Hi Werner, > > > The reason this won't work is that there is no value or procedure to be > found in define-grobs.scm for Slur.positions to use for a default to offset > against. Could such a procedure be offered? >

Re: using \offset with Slur.positions

Hi Werner, On Tue, Apr 8, 2014 at 12:27 AM, Werner LEMBERG wrote: > > [2.19.4] > > > Folks, > > > it seems that \offset can't be applied to `Slur.positions'. Doing > > \relative c' { > \once \offset positions #'(5 . 5) Slur > c'2( c) > } > > I get > > Warnung: the property 'positio

Re: Tuplet brackets should reliably not follow kneed beams. (issue 84730043)

On 2014/04/07 04:16:52, Devon Schudy wrote: Fix inaccurate test description. LGTM. https://codereview.appspot.com/84730043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Tuplet brackets should reliably not follow kneed beams. (issue 84730043)

On Mon, Apr 7, 2014 at 2:32 AM, David Kastrup wrote: > > > When using the following test code with the latest patch (I think), it > would appear that TupletBracket directions are ignored with invisible > brackets. Is this intentional? > > Yes, this was intentional. If the number is to be put ne

Tuplet brackets should reliably not follow kneed beams. (issue 84730043)

https://codereview.appspot.com/84730043/diff/1/input/regression/tuplet-number-kneed-beam-horizontal-fit.ly File input/regression/tuplet-number-kneed-beam-horizontal-fit.ly (right): https://codereview.appspot.com/84730043/diff/1/input/regression/tuplet-number-kneed-beam-horizontal-fit.ly#newcode1

Bad positioning of tuplet numbers on kneed beams with Beam.positions override. (issue 81330046)

Reviewers: , Message: Please review. Thanks! Description: Bad positioning of tuplet numbers on kneed beams with Beam.positions override. Previously, when Beam.positions was overridden, tuplet numbers on kneed beams would automatically be placed according to the bracket instead of against the b

Re: Inconsistent tuplet-number-kneed-beam-horizontal-fit.ly results?

Hi Devon, On Fri, Mar 28, 2014 at 3:47 PM, Devon Schudy wrote: > I'm getting unpredictable output from > input/regression/tuplet-number-kneed-beam-horizontal-fit.ly. > > Sometimes the second tuplet number is in bracket position below the > staff, and sometimes it overlaps the beam. When I run th

Re: access to all remote branches

Hi again, On Tue, Mar 11, 2014 at 5:39 PM, David Nalesnik wrote: [...] > Could it be something I need to change in a config file? > <http://user.name> > Yes, that was exactly it... Just found this link: http://lists.gnu.org/archive/html/lilypond-devel/2012-02/msg00165.html I

Re: access to all remote branches

al_working > > master > > remotes/origin/master > > you may have cloned only the master branch. try > git fetch --all > Now I remember having used that command before. Unfortunately, when I try it now I still get the three branches. Could it be something I need to change in

access to all remote branches

Hi, I've had to reinstall LilyDev, and I'm no longer able to see all of the remote branches. When I run git branch -a I simply see: dev/local_working master remotes/origin/master Previously I saw branches from the entire history of the project. Unfortunately, I'm drawing a blank HOW I set th

Issue 3860: Add command \justify-line (issue 66980043)

Reviewers: , Message: Please review. Thanks! Description: Issue 3860: Add command \justify-line The command \fill-line spaces words taking word length into account such that the following distances are equal: outside edge of outside markup to center of adjoining markup; center to center of nei

Re: Improve positioning of tuplet numbers for kneed beams. (issue 58610044)

On 2014/02/09 21:23:29, janek wrote: this ROCKS! :) What about "more than 1 tuplet per beam group" and "nested tuplets"? My head explodes every time i see these examples! The "more than 1 tuplet per beam group" is actually covered by the French beaming example. I could include the neste

Re: Improve positioning of tuplet numbers for kneed beams. (issue 58610044)

Reviewers: janek, Message: On 2014/02/06 21:44:26, janek wrote: Why are there so few test cases in the regtests? I saw that you have loads of *excellent* examples, and i think that at least half of them is worth being added - don't be shy about it! Here's five more :) Description: Impr

Re: Shape of individual ties in chords

On Thu, Jan 23, 2014 at 8:01 AM, David Nalesnik wrote: > >> >>> >> There's also the attached file (which comes from >> http://www.mail-archive.com/lilypond-devel@gnu.org/msg47432/shape-tie-columns.ly) >> which will work with broken ties. >> >>

Re: Shape of individual ties in chords

Hi again, On Thu, Jan 23, 2014 at 8:01 AM, David Nalesnik wrote: > Hi, > > > On Wed, Jan 22, 2014 at 4:55 PM, Thomas Morley > wrote: > > >> Below some coding just to show that it can be done. >> It's a very first sketch, several issues are present (p.e. l

Re: Shape of individual ties in chords

Hi, On Wed, Jan 22, 2014 at 4:55 PM, Thomas Morley wrote: > Below some coding just to show that it can be done. > It's a very first sketch, several issues are present (p.e. linebreak) > Might be a starting point, though. > > There's also the attached file (which comes from http://www.mail-archi

Re: possible tuplet bug?

On Wed, Dec 25, 2013 at 12:58 PM, David Nalesnik wrote: > David, > > On Wed, Dec 25, 2013 at 12:56 PM, David Kastrup wrote: > > So even if you don't want to propose a "formal" commit, using "git diff" >> in order to produce a properly readable pa

Re: possible tuplet bug?

David, On Wed, Dec 25, 2013 at 12:56 PM, David Kastrup wrote: > David Nalesnik writes: > > > > > I hesitate to submit a formal patch because I haven't worked with C++ in > > LilyPond before, > > Formal or not, trying to figure out what you changed fro

Re: possible tuplet bug?

Hi again, On Wed, Dec 25, 2013 at 12:41 PM, David Nalesnik wrote: > > > The following snippet demonstrates the problem (see attached image): > > And here's the image of the default... <>___ lilypond-devel mailing list li

possible tuplet bug?

Hi, I just noticed something fishy about the interaction of Tuplet.connect-to-neighbor and Tuplet.break-overshoot. The property 'break-overshoot is meant to apply to broken spanners, but here it is having an effect on unbroken "connected" tuplet brackets. (Break-overshoot is described as "How muc

Re: LyricHyphen hara-kiri

Kieren, On Sat, Dec 21, 2013 at 3:26 PM, Kieren MacMillan < kieren_macmil...@sympatico.ca> wrote: > I think [to begin with] there are two separate issues to consider here: > > 1. In m.28, it’s clear that “foo bar” has not become one Pango string, > which it apparently has on the downbeat of m.2

Re: LyricHyphen hara-kiri

Kieren, On Sat, Dec 21, 2013 at 2:30 PM, David Nalesnik wrote: > Kieren, > > On Sat, Dec 21, 2013 at 2:18 PM, Kieren MacMillan < > kieren_macmil...@sympatico.ca> wrote: > > >> >> Clearly, there’s a gap in several measures, right? >> > > Yup.

Re: LyricHyphen hara-kiri

Kieren, On Sat, Dec 21, 2013 at 2:18 PM, Kieren MacMillan < kieren_macmil...@sympatico.ca> wrote: > > Clearly, there’s a gap in several measures, right? > Yup. > > However, now that I look at the output again, there are no gaps to be > found — i.e., it apparently works as advertised/expected/

Re: LyricHyphen hara-kiri

Hi Kieren, On Sat, Dec 21, 2013 at 1:19 PM, Kieren MacMillan < kieren_macmil...@sympatico.ca> wrote: > Hello all, > > I’ve been asking around to see if anyone can work on Lyric bounties (e.g., > GSoC stuff, plus other features). > > This one — LyricHyphen hara-kiri — was one that Mike S. suggest

WAS: SostenutoPedalLineSpanner and texts

Hi, This question came in reference to a workaround given for repeating texts on a broken pedal line: On Fri, Dec 20, 2013 at 1:42 AM, Simon Bailey wrote: > >> Could this be adapted to solve this problem: >> http://lists.gnu.org/archive/html/lilypond-user/2013-12/msg00839.html ? >> I'd be willin

Re: branching

Hi, On Tue, Dec 10, 2013 at 2:46 PM, Carl Peterson wrote: > On Tue, Dec 10, 2013 at 3:21 PM, Mike Solomon wrote: > >> >> The only hassle for me, which I did not run up against when I started >> with the project, is David’s way of communicating. I’m not claiming this >> is all on him, but I’m als

Re: Some audicious hand-engraved slurs compared to LilyPond

On Tue, Dec 3, 2013 at 7:32 AM, Joseph Rushton Wakeling < joseph.wakel...@webdrake.net> wrote: > On 03/12/13 14:25, David Nalesnik wrote: > >> The problem is that the position of the tuplet number is tied to the >> placement >> of the tuplet bracket, whether it i

Re: Some audicious hand-engraved slurs compared to LilyPond

Joseph, On Tue, Dec 3, 2013 at 7:20 AM, Joseph Rushton Wakeling < joseph.wakel...@webdrake.net> wrote: > > > The tuplet number placement is bizarre. There's no reason why it > shouldn't be close to the beams. > > The problem is that the position of the tuplet number is tied to the placement of t

Re: Some audicious hand-engraved slurs compared to LilyPond

Hi David, On Tue, Dec 3, 2013 at 6:17 AM, David Kastrup wrote: > David Kastrup writes: > > > Here is a scan from a Peters edition of Grieg with somewhat flamboyantly > > executed slurs (I am almost sure that the engraver had felt some grim > > satisfaction when doing those). > > > > > > And th

Re: The dot's position is correct?

Hi Jefferson, On Thu, Nov 7, 2013 at 5:59 AM, Jefferson dos Santos Felix < jsfe...@gmail.com> wrote: > I have a doubt if it's a bug or not. > > The problem occours in the following cut: > > \version "2.17.95" > { > <<{c''4.}\\{c'}>> > 4. > } > > This produce diferent dot positions to same no

push status

Hello, The time has come when I have another patch to push to staging, I can't do this myself, and I don't like to inconvenience others by asking them to do it for me. May I request that I be given push status? Thanks, David ___ lilypond-devel mailin

<    1   2   3   4   5   >