On Jun 6, 2011, at 10:28 AM, Trevor Daniels wrote:
>
> m...@apollinemike.com wrote Monday, June 06, 2011 8:42 AM
>
>
>> On Sun, 5 Jun 2011 12:34:59 +0100, "Trevor Daniels"
>
>>> Shouldn't you be using the TupletNumber grob?
>>
>> Thanks for the suggestion!
>>
>> I just tried it with TupletNumber. I hadn't done that before because of
>> these lines in Tuplet_number::print :
>>
>> Spanner *tuplet = unsmob_spanner (me->get_object ("bracket"));
>>
>> if (!tuplet || !tuplet->is_live ())
>> {
>> me->suicide ();
>> return SCM_EOL;
>> }
>> SCM stc_scm = Text_interface::print (smob);
>> Stencil *stc = unsmob_stencil (stc_scm);
>>
>> stc->align_to (X_AXIS, CENTER);
>> stc->align_to (Y_AXIS, CENTER);
>>
>> SCM cpoints = tuplet->get_property ("control-points");
>
> I think these lines only apply when the tuplet bracket is present.
> When the triplet is beamed, as here, there is no bracket. That's
> why I suggested overriding TupletNumber.
>
>> These lines lead me to believe that the tuplet number's position is
>> dependent on the bracket's position (I could, of course, be wrong). In
>> general, there seems to be a problem w/ outside staff priority concerning
>> both TupletNumber and TupletBracket, as evidenced by the following bit of
>> code:
>>
>> \relative c'' {
>> \override Staff . TupletNumber #'outside-staff-priority = #500
>> \override Staff . Script #'outside-staff-priority = #0
>> \override Staff . TupletBracket #'outside-staff-priority = #50
>> << { \autoBeamOff\times 2/3 { bes8^\trill bes^\trill bes^\trill } } \\ {
>> \autoBeamOff\times 2/3 { c,8 c c } } >>
>> }
>
> Tuplet brackets and numbers are normally within-staff objects.
> There certainly are problems when they are included in the
> outside-staff objects by giving them an outside-staff-priority,
> as other properties such as 'direction then need to be specified
> as well. There may be more: tuplet brackets/numbers were not
> designed to work as outside-staff objects.
>
> The basic problem you have seems to be the collision of
> tuplet brackets/numbers with Script objects:
>
> \relative c'' {
> \times 2/3 {
> \stemUp
> bes8^\trill
> r
> bes^\trill
> }
> }
>
> If this were fixed you wouldn't need to mess with outside-staff
> objects, would you?
I am currently working off of a home-brewed branch of LilyPond that places
articulations on the inside of tuplet numbers. It uses the
Pointer_group_interface to make the tuplet bracket aware of scripts in
tuplet-engraver.cc and then factors the position of these scripts into the
vector `points' in tuplet-bracket.cc (initialized in line 550). However, it
seems like the collision-resolution should be modifiable such that
articulations can either be placed above or below a TupletNumber /
TupletBracket. The same goes for any outside staff grob (markups, dynamics,
etc.) - it should be possible to place them on the inside or on the outside of
TupletBrackets. I think this type of logic will help merge the tuplet bracket
and analysis bracket code.
Could all of this be cleared up if TupletBracket and TupletNumber were
redesigned to work as outside-staff grobs? Is there any disadvantage to doing
this?
Cheers,
MS
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
