Hi Carl, from what I read in the documentation
http://lilypond.org/doc/v2.19/Documentation/learning/moving-objects ... there are two ways to place items like the OctaveBracket. 1) The first method is to use properties like "padding" (therefore: staff-padding, outstide-staff-padding etc.). The advantages of making changes to this type of property are (according to the doc) that "other objects will be moved automatically if necessary to make room " 2) The second method is the "extra-offset" method. It, according to the doc, should be used "when all else fails", and has this disadvantage: "correct values for the repositioning have to be worked out, often by trial and error, for every object individually" Now, from what I understand, I can use both methods 1 and 2 with a dynamic object, for example. I get method 1) with: DynamicText.X-offset + DynamicLineSpanner.Y-offset; and I get method 2) with DynamicText.extra-offset. All this system, which is very clear, does not work with OttavaBracket. In fact, with OttavaBracket I can only use method 2) If I want to use the method 1) with OttavaBracket I have the staff-padding, outside-staff-padding, staff-position, Y-offset properties: but, * for OttavaBracket *, all these require starting from a minimum offset that is unknown. Therefore I cannot use any of the above properties. Also note that there are differences between 2.18 and 2.19 for the behavior of the same properties. And, whithin the same version, they differ if I use "\offset" or "\override" commands. Finally, note that (apparentily) a workaround could be to reset outside-staff-padding property ( ---> = 0) and see this default before applying the *wanted* outside-staff-padding offset. I hope that with this description the problem I have identified is clearer. This is why I believe it's a bug. I suspect it depends on the fact that OttavaBracket is designed to be closely coupled to the staff (in fact I have to specify Staff.OttavaBracket), and this can cause similar inconveniences. HTH, Paolo On Mon, Jan 13, 2020 at 4:16 AM Carl Sorensen <c_soren...@byu.edu> wrote: > > > > > *From: *Paolo Prete <paolopr...@gmail.com> > *Date: *Sunday, January 12, 2020 at 7:31 PM > *To: *Aaron Hill <lilyp...@hillvisions.com> > *Cc: *lilypond-user <lilypond-user@gnu.org> > *Subject: *Re: Shift up OttavaBracket > > > > As said in the first post staff-padding seems to have the same problem of > Y-offset: > > > > http://lilybin.com/njdr3x/1 > > > > outside-staff-padding does the job only if reset; see: > > > > http://lilybin.com/yb5u35/4 > > > > Then I would consider this a bug. At least one property of OttavaBracket > should behave like extra-offset concerning the starting offset. > > > > I disagree with this statement. You are trying to mix automatic placement > with manual placement, but then get the benefits of manual placement. This > is inconsistent with the basic design of LilyPond. > > > > Notes we can offset, because they have standard positions determined based > on their pitches and their rhythmic position. The other items move to > avoid collisions based on penalties. This is the fundamental operation > mode of lilypond. > > > > It appears that what you are asking is to calculate a position based on > penalties, then add an offset, then run through the collision-avoidance > algorithm again, which will then move things around based on penalties. > Then you need to add an offset again from the automatically-calculated > position, and you end up with an infinite loop. > > > > Extra-offset is provided to allow you to specify an exact amount of > shift. But when you do so, you are responsible for managing collisions. > > > > If you want to move things around during automatic placement, the > appropriate lilypond way to do it is to change the parameters that lead to > spacing (e.g. padding, priority, etc.). But you still get the automatic > placement. > > > > I think you are trying to misuse LilyPond, and I don’t agree that it > should be rewritten to support manual placement. But I would not object to > somebody allowing such functionality, as long as it didn’t break the > existing functionality. IMO, the reason I use and contribute to LilyPond > is because it does such a good job of handling things automatically. > > > > Thanks, > > > > Carl > > >
