On Jan 12, 2013, at 2:47 AM, David Kastrup <d...@gnu.org> wrote: > Uh, if you have a _custom_ staff context for which you want particular > overrides, you just do > > \layout { > \context { > \Staff > \name "MyStaff" > \alias "Staff" > \override ... > \override ... > } > } > > at the bottom, and then in the music you use > > \new MyStaff { ... } > > and, of course, the overrides will be in every staff of that type, and > not anywhere else.
Right, I have been using this custom staff approach and it works great for "global" overrides that should _always_ happen on the custom staff. (I omitted those overrides in my previous tiny example to make it tiny, with a comment saying so, but in the process I may not have communicated clearly enough that I was trying to achieve something else.) My question now is about when say, a particular chord needs a manual ("non-global") override added _within_ the music (using \once), for it to look right on the custom staff (as a by-product of the global overrides of the custom staff). However, these same manual one-time overrides are not needed on a standard staff, and look wrong there. (For example, needing to move note heads to a different side of the stem to avoid collisions with other note heads on the custom staff, but not on the standard staff.) So once you've added these one-time overrides within the music you can only use the music for the custom staff and not a standard staff. (Unless... there's some way for a function that's called to do these one-time overrides to know whether its being called from the custom staff context or a standard staff context.) So this is a _really_ marginal use-case that fortunately has an easy workaround: I can just copy and paste the music into a 2nd variable and add the one-time overrides to the new copy, then use the two copies of the music with their respective staves. And/or write a "global" override function for the custom staff that's smart enough so that I do not need to do the one-time tweaks in the music at all. (Which is what I'm working on now.) Cheers, -Paul _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user