I've now had a chance to experiment further with this, and to try the suggestions you have made, which were very helpful.
For Dynamic-Text objects, the self-alignment-X = #-1 appears to align the left edge of the dynamic with the left edge of the note; self-alignment-X = #1 aligns the right edge of the dynamic with the right edge of the note. Presumably the default value of 0 aligns the centre of the dynamic mark with the centre of the note. None of this is terribly helpful if one wants consistent, sensible placing of dynamics! However, combining self-alignment-X = #-1 with a small negative value for X-offset gives the kind of result I want: that is, dynamic marks should have their left-edges consistently aligned very slightly to the left of the beginning (i.e. the left-edge) of the first note to which they apply. Using the two variables already mentioned, I can get a consistent, sensible placing for dynamics of different widths, such as "f" and "pppp". However, there is an irritating anomaly, which is that a dynamic in a Dynamics context is not placed in the same horizontal position as one attached to a note in a Staff context. I find that X-offset values of -1 in a Staff context and -0.3 in a Dynamics context produce similar (and, to me, satisfactory) results to each other. How weird is that! I also experimented with setting DynamicText.extra-spacing-width to '(0 . 0). With the default values of the other variables this is not a good solution to the problem of dynamic/bar-line collisions, because it produces an unwanted gap between the bar-line and the first note of the bar if the dynamic mark is a wide one. And with self-alignment-X = #-1 and a small value for X-offset these collisions are probably not going to arise very often, if at all. Thanks again for all your help. David On Tue, 2014-02-04 at 10:45 -0500, Hwaen Ch'uqi wrote: > Greetings David, > > > generally I prefer the left edge of dynamics to be related to the note > > position. But I should like it to be a little further to the left than > > the value of -1 gives. That is a bit of a problem, because the value > > required for a dynamic such as 'f' will be different from that needed by > > a wider marking such as 'ffff'. > > > > Is there perhaps a way of specifying where the left edge of the dynamic > > should be in relation to the note? For instance, I might like all > > dynamics to appear about half a note-head's width before the left edge > > of the note-head itself. It is going to get very tedious having > > continually to specify different self-alignment-X values when there are, > > say, alternating 'p' and 'mf' markings. > > Have you tried using decimal numbers with self-alignment-X, as in > numbers between -1 and 0? I am guessing that this will produce what > you want. If I understand things correctly, the self-alignment-X > property, at least in this instance, is calculating relative to the > note. The DynamicText entry of the Internals Reference (Section > 3.1.39) also give X-offset as another changeable property. It will > also move the dynamic text horizontally, though I am not clear what is > its X-parent. > > If you have not yet done it, I would highly recommend looking at > Chapter 4 (and especially sections 4.6 and 4.7) of the Learning > Manual, which will give you an invaluable introduction to tweaking the > output. In particular, you might be interested in 4.7.2 and 4.7.3, > where it is shown how you can minimize typing of tweaks by using > variables and stylesheets. > > > Also, considering that LilyPond is generally so good at avoiding > > collisions, I have been surprised to find that it seems to have no > > objection to printing dynamics and bar-lines on top of one another. Is > > there no way to tell it to avoid these collisions? I would have > > expected avoidance to be the default, with an override to allow > > collisions if that is what is wanted in a particular case. But the > > default appears to be that bar-lines and dynamics pay no regard for each > > other. > > Why the default is, I cannot say. But according to the same entry in > the IR, the extra-spacing-width property is set to #'(+inf.0 . -inf.0) > by default, which I believe means that, in LilyPond's calculations, > the object takes no horizontal space. Changing the elements within the > parentheses to actual numbers should force LilyPond to give it a > horizontal value and thus to place other objects with recognition of > that value. This is my understanding; if I am speaking amiss, please, > anyone, feel free to correct me. > > I hope this helps. > Hwaen Ch'uqi _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
