Re: Vertical position of rests on a custom staff
To conclude the saga... Thanks to David Kastrup's tip my function can now automatically position all rests and their dots where they need to be, no matter what voice they are in. Once again LilyPond can handle just about anything. See attached file. I'm now curious about the difference between using ly:grob-property-data and ly:grob-property. The docs say: Function: ly:grob-property grob sym val Return the value for property sym of grob. If no value is found, return val or '() if val is not specified. Function: ly:grob-property-data grob sym Return the value for property sym of grob, but do not process callbacks. http://www.lilypond.org/doc/v2.16/Documentation/internals/scheme-functions I assume this means that if a property is set to a function rather than a static value, then ly:grob-property would process the function to return a value, but ly:grob-property-data would not. Is that right? Thanks again, -Paul Morris restShifter.ly Description: Binary data ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Vertical position of rests on a custom staff
Paul Morris p...@paulwmorris.com writes: To conclude the saga... Thanks to David Kastrup's tip my function can now automatically position all rests and their dots where they need to be, no matter what voice they are in. Once again LilyPond can handle just about anything. See attached file. I'm now curious about the difference between using ly:grob-property-data and ly:grob-property. The docs say: Function: ly:grob-property grob sym val Return the value for property sym of grob. If no value is found, return val or '() if val is not specified. Function: ly:grob-property-data grob sym Return the value for property sym of grob, but do not process callbacks. http://www.lilypond.org/doc/v2.16/Documentation/internals/scheme-functions I assume this means that if a property is set to a function rather than a static value, then ly:grob-property would process the function to return a value, but ly:grob-property-data would not. Is that right? Yes. For things like stem directions, there may be a default callback which makes the decision about whether to put the stem upwards or downwards, and calling this fallback might trigger other typesetting decisions prematurely. Also, one does not get to see whether the ultimate direction decision was due to \voiceOne or such a tie-breaking callback. This may or may not be the case for rest direction, but because I was too lazy to double-check, I went for ly:grob-property-data. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Vertical position of rests on a custom staff
dak wrote Yes. For things like stem directions, there may be a default callback which makes the decision about whether to put the stem upwards or downwards, and calling this fallback might trigger other typesetting decisions prematurely. Also, one does not get to see whether the ultimate direction decision was due to \voiceOne or such a tie-breaking callback. This may or may not be the case for rest direction, but because I was too lazy to double-check, I went for ly:grob-property-data. Ok, good to know. It sounds like if ly:grob-property-data works for a given case, then it's the safer choice of the two. Thanks for the explanation. -Paul Morris -- View this message in context: http://lilypond.1069038.n5.nabble.com/Vertical-position-of-rests-on-a-custom-staff-tp146537p146669.html Sent from the User mailing list archive at Nabble.com. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Vertical position of rests on a custom staff
Paul Morris p...@paulwmorris.com writes: dak wrote Yes. For things like stem directions, there may be a default callback which makes the decision about whether to put the stem upwards or downwards, and calling this fallback might trigger other typesetting decisions prematurely. Also, one does not get to see whether the ultimate direction decision was due to \voiceOne or such a tie-breaking callback. This may or may not be the case for rest direction, but because I was too lazy to double-check, I went for ly:grob-property-data. Ok, good to know. It sounds like if ly:grob-property-data works for a given case, then it's the safer choice of the two. Thanks for the explanation. Well, depends on what kind of data one tries testing for. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Vertical position of rests on a custom staff
Hi Pierre, I tried your suggestion:
restmusic = \relative f {
\override Rest #'Y-offset = #0
\cadenzaOn
...
}
But it put the whole and half rests on a ledger line in the middle of the
custom staff, which was not really what I wanted.
I tried to figure out a way to globally override the rest positioning for
different voices on the same staff -- something like this:
http://www.lilypond.org/doc/v2.16/Documentation/notation/changing-context-default-settings#changing-all-contexts-of-the-same-type
But it doesn't look like it's possible to specify, at the level of a custom
staff context, that the rests in the 1st voice on this type of staff get
positioned here, and those in the 2nd voice get positioned there, etc.
So I revised my function so it would let you manually turn off/on the custom
rest positions when you have more than one voice on a staff (see attached
files).
After getting that working I checked to see if anything changed between v. 2.16
to 2.17.19 And I'm really glad to say that in 2.17.19 the positioning of the
rests was almost exactly what I wanted by default! The only ones that needed
re-positioning were the rarer ones that were longer than a whole rest. Also
the dots on about half of the rests also still needed re-positioning.
If I'd known this before I probably wouldn't have gone to the trouble of
writing my function. It seems like overkill now. (A good reason to start
using or at least testing with the dev version sooner in the future.) At any
rate, big thanks to all those working on improving LilyPond with each new
version.
I revised my function for use with 2.17.19 -- see attached. While it would be
nice if you didn't have to manually turn the overrides on and off when there
are more than one voice on a staff, at least now this is only needed for rests
that are longer than a whole rest, which do not occur that often.
-Paul Morris
shiftRests2.pdf
Description: Adobe PDF document
shiftRests2.ly
Description: Binary data
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Vertical position of rests on a custom staff
Paul Morris p...@paulwmorris.com writes: I am working on adjusting the vertical position of rests on a custom staff and have run into a problem. I basically want the rests to be positioned as they are on the standard staff, but in my custom staff there is no center line so the rests become oriented to the next line above that (except for whole rests which stay the same). See the attached files. I wrote an override function that moves the rests down to where I want them. Half rests move down further, and I had to adjust the position of the dots for dotted rests as well. So far so good. The problem I ran into is that when the music includes \voiceOne and \voiceTwo, the rests appear in the right place by default, and my adjustment then puts them in the wrong place. You can see this on the right hand side of the PDF. Any thoughts on how to work around this? Make your function do different things depending on the value of (ly:grob-property-data 'direction grob) This will be +1 or -1 for \voiceOne and \voiceTwo (or their equivalents), and something else (0 or a function) when in \oneVoice mode. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Vertical position of rests on a custom staff
Paul Morris p...@paulwmorris.com writes: After getting that working I checked to see if anything changed between v. 2.16 to 2.17.19 And I'm really glad to say that in 2.17.19 the positioning of the rests was almost exactly what I wanted by default! The only ones that needed re-positioning were the rarer ones that were longer than a whole rest. Also the dots on about half of the rests also still needed re-positioning. Could you elaborate? -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Vertical position of rests on a custom staff
David Kastrup wrote Make your function do different things depending on the value of (ly:grob-property-data 'direction grob) This will be +1 or -1 for \voiceOne and \voiceTwo (or their equivalents), and something else (0 or a function) when in \oneVoice mode. Thank you! This will do the trick. -Paul Morris -- View this message in context: http://lilypond.1069038.n5.nabble.com/Vertical-position-of-rests-on-a-custom-staff-tp146537p146634.html Sent from the User mailing list archive at Nabble.com. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Vertical position of rests on a custom staff
The only ones that needed re-positioning were the rarer ones that were longer than a whole rest. Also the dots on about half of the rests also still needed re-positioning. Could you elaborate? See the attached files. This one makes it clearer than the previous one. The red rests and blue dots are the ones my function has moved. The 3 longest rests are lower on the custom staff than I wanted, so my function moves them up to where they usually are on the standard staff, but then the dots became centered vertically on the longest two rests. So my function moves those dots up where they usually appear. Dots were also centered vertically on quarter, 8th, and 16th rests on the custom staff, so my function moves them up to their usual position. I also show some staves with different line patterns where the Y-offset of the rests is manually set to 0. Sometimes the dots are centered on the rests, and sometimes they are in their usual position (half a staff space higher). This is odd since the dot position apparently depends on the staff line pattern. I suppose that the dots might be centered by default on the rest and then be shifted up to avoid a line through the middle of the rest. (However, on one of the staves they appear in their usual position even though there is no line to avoid.) -Paul Morris shiftRests3.pdf Description: Adobe PDF document shiftRests3.ly Description: Binary data ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Vertical position of rests on a custom staff
Hello everyone, I am working on adjusting the vertical position of rests on a custom staff and have run into a problem. I basically want the rests to be positioned as they are on the standard staff, but in my custom staff there is no center line so the rests become oriented to the next line above that (except for whole rests which stay the same). See the attached files. I wrote an override function that moves the rests down to where I want them. Half rests move down further, and I had to adjust the position of the dots for dotted rests as well. So far so good. The problem I ran into is that when the music includes \voiceOne and \voiceTwo, the rests appear in the right place by default, and my adjustment then puts them in the wrong place. You can see this on the right hand side of the PDF. Any thoughts on how to work around this? I'm away from email for a day or two, but wanted to go ahead and send this while I was working on it. -Paul Morris adjustRests.pdf Description: Adobe PDF document adjustRests.ly Description: Binary data ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Vertical position of rests on a custom staff
2013/6/1 Paul Morris p...@paulwmorris.com
Hello everyone,
I am working on adjusting the vertical position of rests on a custom staff
and have run into a problem. I basically want the rests to be positioned
as they are on the standard staff, but in my custom staff there is no
center line so the rests become oriented to the next line above that
(except for whole rests which stay the same). See the attached files.
I wrote an override function that moves the rests down to where I want
them. Half rests move down further, and I had to adjust the position of
the dots for dotted rests as well.
So far so good. The problem I ran into is that when the music includes
\voiceOne and \voiceTwo, the rests appear in the right place by default,
and my adjustment then puts them in the wrong place. You can see this on
the right hand side of the PDF.
Any thoughts on how to work around this? I'm away from email for a day or
two, but wanted to go ahead and send this while I was working on it.
Hi Paul,
try this :
restmusic = \relative f {
\override Rest #'Y-offset = #0
\cadenzaOn
...
}
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
