Re: tuplet number on cross-staff kneed-beam

2011-07-07 Thread Dmytro O. Redchuk
On Tue 05 Jul 2011, 23:22 David Nalesnik wrote:
 Hi, Colin --
 
 On 7/5/11, Colin Campbell c...@shaw.ca wrote:
 
  This will probably require an issue, David, but could you send the code
  you used to produce the 2.12.3 version, please?  I can't reproduce the
  previous stable example, in order to confirm the regression, because
  your Scheme-ing gives an error:
  LilyPond 2.12.3 [music.ly] starting (preview mode)...
  Processing `music.ly'
  Parsing...
  Interpreting music...
  Preprocessing graphical objects...
  Finding the ideal number of pages...
  Fitting music on 1 page...
  Drawing systems...music.ly:19:12: In procedure + in expression (+
  (ly:grob-property beam #) (/ # 2)):
  music.ly:19:12: Wrong type argument in position 1: ()
  LilyPond [music.ly] exited with return code 1.
 
 Oops -- yes, the error happened because 'thickness is now
 'beam-thickness.  I've attached the file I used for the 2.12.3 image.
 
 I've also attached a pared-down version of the file which should work
 in either release, as is.  It distills the problem a little more -- at
 the expense of centering the number directly on the beam . . .
 
 I hope that in some way this is useful :)
I've added this as 1745:
http://code.google.com/p/lilypond/issues/detail?id=1745

Thank you!

-- 
  Dmytro O. Redchuk
  Bug Squad
 Easy to use is easy to say.
   --Jeff Garbers

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond


Re: tuplet number on cross-staff kneed-beam

2011-07-07 Thread Dmytro O. Redchuk
On Thu 07 Jul 2011, 10:33 I wrote:
 On Tue 05 Jul 2011, 23:22 David Nalesnik wrote:
  I've also attached a pared-down version of the file which should work
  in either release, as is.  It distills the problem a little more -- at
  the expense of centering the number directly on the beam . . .
  
  I hope that in some way this is useful :)
 I've added this as 1745:
 http://code.google.com/p/lilypond/issues/detail?id=1745

For the record -- tuplet number placement is a subject of issue 696:
http://code.google.com/p/lilypond/issues/detail?id=696

-- 
  Dmytro O. Redchuk
  Bug Squad
 Easy to use is easy to say.
   --Jeff Garbers

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond


Re: tuplet number on cross-staff kneed-beam

2011-07-06 Thread David Nalesnik
Hi, again --

 I've also attached a pared-down version of the file which should work
 in either release, as is.  It distills the problem a little more -- at
 the expense of centering the number directly on the beam . . .


My last email included an image produced with 2.12.3.  Attached is the
output from 2.14.1.

Best,
David
attachment: tuplet-number-function-minimal.png___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond


Re: tuplet number on cross-staff kneed-beam

2011-07-06 Thread David Nalesnik
Hi, Colin --

On 7/5/11, Colin Campbell c...@shaw.ca wrote:

 This will probably require an issue, David, but could you send the code
 you used to produce the 2.12.3 version, please?  I can't reproduce the
 previous stable example, in order to confirm the regression, because
 your Scheme-ing gives an error:
 LilyPond 2.12.3 [music.ly] starting (preview mode)...
 Processing `music.ly'
 Parsing...
 Interpreting music...
 Preprocessing graphical objects...
 Finding the ideal number of pages...
 Fitting music on 1 page...
 Drawing systems...music.ly:19:12: In procedure + in expression (+
 (ly:grob-property beam #) (/ # 2)):
 music.ly:19:12: Wrong type argument in position 1: ()
 LilyPond [music.ly] exited with return code 1.

Oops -- yes, the error happened because 'thickness is now
'beam-thickness.  I've attached the file I used for the 2.12.3 image.

I've also attached a pared-down version of the file which should work
in either release, as is.  It distills the problem a little more -- at
the expense of centering the number directly on the beam . . .

I hope that in some way this is useful :)

Thank you for your help!

-David
\version 2.12.3

#(define (tuplet-number-to-beam tuplet-number)
  (let* ((tuplet-bracket (ly:grob-object tuplet-number 'bracket))
 (note-column (ly:grob-parent tuplet-number X))
 (stem (ly:grob-object note-column 'stem))
 (beam (ly:grob-object stem 'beam)))

 ;; Move (invisible) TupletBracket to beam, taking number with it
 (ly:grob-set-property! tuplet-bracket 'positions (ly:grob-property beam 'positions))

 ;; Number is now centered on beam.  Offset it based on width of beam and height
 ;; of tuplet number.
 (ly:grob-set-property! tuplet-number 'Y-offset
 (-
   (+
 (ly:grob-property beam 'thickness)
 (/ (interval-length (ly:grob::stencil-height tuplet-number)) 2))



\new PianoStaff 
  \new Staff = 1 {
s4
  }
  \new Staff = 2 {
\relative c {
  \clef bass
  \override TupletNumber #'after-line-breaking = #tuplet-number-to-beam
  \times 2/3 {
c8
\change Staff = 1
c''
\change Staff = 2
c,,
  }
}
  }



\version 2.12.3

#(define (tuplet-number-to-beam tuplet-number)
  (let* ((tuplet-bracket (ly:grob-object tuplet-number 'bracket))
 (note-column (ly:grob-parent tuplet-number X))
 (stem (ly:grob-object note-column 'stem))
 (beam (ly:grob-object stem 'beam)))

 ;; Move (invisible) TupletBracket to beam, taking number with it
 (ly:grob-set-property! tuplet-bracket 'positions (ly:grob-property beam 'positions


\new PianoStaff 
  \new Staff = 1 {
s4
  }
  \new Staff = 2 {
\relative c {
  \clef bass
  \override TupletNumber #'after-line-breaking = #tuplet-number-to-beam
  \times 2/3 {
c8
\change Staff = 1
c''
\change Staff = 2
c,,
  }
}
  }





tuplet-number-function-minimal.pdf
Description: Adobe PDF document
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond


Re: tuplet number on cross-staff kneed-beam

2011-07-05 Thread Valentin Villenave
On Mon, Jul 4, 2011 at 11:10 PM, David Nalesnik dnale...@umail.iu.edu wrote:
 Hello, all --

Greetings,

 First of all, I hope that I'm asking this question on the appropriate list!

Since you're demonstrating a regression, I'm forwarding your message
to our bug- list.

 I'm trying to simplify the workaround relating to tuplet-number
 position on kneed beams
 http://lsr.dsi.unimi.it/LSR/Snippet?id=646
 and I'm running into an unexpected problem.

 My reasoning is that, since the tuplet number is positioned according
 to the bracket, a logical first (certainly hacky!) step is to move the
 (invisible) bracket to the beam by setting the 'positions property of
 the bracket to that of the beam.  Then, the position of the number
 could be refined according to its height, the thickness of the beam,
 etc.

 This works as planned, except that in 2.14.1, the staves are pushed
 apart dramatically.  \override Beam #'collision-voice-only has no
 effect on the problem.  Manually setting Beam #'positions can be used
 to fix the problem, but that is obviously inconvenient.

 I've attached an .ly file with the function (stripped down to fit just
 this case), and several images of the output (one is produced with
 2.12.3, the other two with 2.14.1 -- one with an override of the Beam
 #'positions).  There doesn't appear to be any problem in 2.12.3.

 Is there anything I can do to fix this problem with the function?  Any
 help would be greatly appreciated!

Indeed, it's a problem I've been stumbling across as well. Several new
properties have been introduced with 2.14 (stretchability, etc.);
you may want to have a look at
http://lilypond.org/doc/v2.15/Documentation/notation/flexible-vertical-spacing-within-systems#within_002dsystem-spacing-properties

Whether the default behavior can/should be improved, is a question for
the Bug Squad :-)

Cheers,
Valentin.
attachment: function-current-stable.pngattachment: function-current-stable-positions-override.pngattachment: function-previous-stable.png\version 2.14.1

#(define (tuplet-number-to-beam tuplet-number)
  (let* ((tuplet-bracket (ly:grob-object tuplet-number 'bracket))
 (note-column (ly:grob-parent tuplet-number X))
 (stem (ly:grob-object note-column 'stem))
 (beam (ly:grob-object stem 'beam)))

 ;; Move (invisible) TupletBracket to beam, taking number with it
 (ly:grob-set-property! tuplet-bracket 'positions (ly:grob-property beam 'positions))

 ;; Number is now centered on beam.  Offset it based on width of beam and height
 ;; of tuplet number.
 (ly:grob-set-property! tuplet-number 'Y-offset
 (-
   (+
 (ly:grob-property beam 'beam-thickness)
 (/ (interval-length (ly:grob::stencil-height tuplet-number)) 2))



\new PianoStaff 
  \new Staff = 1 {
s4
  }
  \new Staff = 2 {
\relative c {
  \clef bass
  %% following line has no effect
  \override  Beam #'collision-voice-only = ##t
  %% following line improves situation
  %\override  Beam #'positions = #'(5 . 5)
  \override TupletNumber #'after-line-breaking = #tuplet-number-to-beam
  \times 2/3 {
c8
\change Staff = 1
c''
\change Staff = 2
c,,
  }
}
  }



___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond


Re: tuplet number on cross-staff kneed-beam

2011-07-05 Thread Colin Campbell

On 11-07-05 01:44 AM, Valentin Villenave wrote:

On Mon, Jul 4, 2011 at 11:10 PM, David Nalesnikdnale...@umail.iu.edu  wrote:

Hello, all --

Greetings,


First of all, I hope that I'm asking this question on the appropriate list!

Since you're demonstrating a regression, I'm forwarding your message
to our bug- list.


I'm trying to simplify the workaround relating to tuplet-number
position on kneed beams
http://lsr.dsi.unimi.it/LSR/Snippet?id=646
and I'm running into an unexpected problem.

My reasoning is that, since the tuplet number is positioned according
to the bracket, a logical first (certainly hacky!) step is to move the
(invisible) bracket to the beam by setting the 'positions property of
the bracket to that of the beam.  Then, the position of the number
could be refined according to its height, the thickness of the beam,
etc.

This works as planned, except that in 2.14.1, the staves are pushed
apart dramatically.  \override Beam #'collision-voice-only has no
effect on the problem.  Manually setting Beam #'positions can be used
to fix the problem, but that is obviously inconvenient.

I've attached an .ly file with the function (stripped down to fit just
this case), and several images of the output (one is produced with
2.12.3, the other two with 2.14.1 -- one with an override of the Beam
#'positions).  There doesn't appear to be any problem in 2.12.3.

Is there anything I can do to fix this problem with the function?  Any
help would be greatly appreciated!

Indeed, it's a problem I've been stumbling across as well. Several new
properties have been introduced with 2.14 (stretchability, etc.);
you may want to have a look at
http://lilypond.org/doc/v2.15/Documentation/notation/flexible-vertical-spacing-within-systems#within_002dsystem-spacing-properties

Whether the default behavior can/should be improved, is a question for
the Bug Squad :-)

Cheers,
Valentin.



This will probably require an issue, David, but could you send the code 
you used to produce the 2.12.3 version, please?  I can't reproduce the 
previous stable example, in order to confirm the regression, because 
your Scheme-ing gives an error:

LilyPond 2.12.3 [music.ly] starting (preview mode)...
Processing `music.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...music.ly:19:12: In procedure + in expression (+ 
(ly:grob-property beam #) (/ # 2)):

music.ly:19:12: Wrong type argument in position 1: ()
LilyPond [music.ly] exited with return code 1.


thanks, David

Colin Campbell
 Bug Squad

--
The human race has one really effective weapon, and that is laughter.
-- Mark Twain

 



___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond