2014-08-02 9:05 GMT+02:00 Mark Polesky <markpole...@gmail.com>: > Janek Warchoł wrote: >> So, we can say that \magnifyStaff sets staff "size" to an >> absolute value - defined as the fraction of the default >> size - and not "relative" to the previous size. > > Not exactly. A magnifyStaff value is only relative to the > previous staff size the first time it's used in a given > staff. The value of "1" refers to the settings that are in > effect when magnifyStaff is first called. After that, then > yes, I suppose it's "absolute". But it's not precise to say > that it scales the "default" values, since it scales the > user's settings.
Ok, i see. >>> Subsequent calls to \magnifyStaff will first revert the >>> most recent layer of temporary overrides, but only if >>> the magnification value is different from last time. >> >> - do i understand correctly that this means that >> \magnifyStaff is aware of the previous magnification value >> used? > > Yes. I've added a new Staff context property > `magnifyStaffValue' to store that. What about naming it 'staffSize'? >> If so, would it be possible to make a "relative" version >> of \magnifyStaff, similarly to how we have relative and >> absolute markup commands (\large and \larger)? I think >> this could be useful. > > Hmm, sometimes I wonder if we're not wandering into levels > of esoterica here. At a minimum, we should provide the user > an easy way to do these two things: > 1) ossia staves > 2) small staves for non-piano instruments > in chamber music scores with piano > > This is now available; just throw magnifyStaff in a \with > block and you're done. Yes, that's indeed the basic use-case and it's handled nicely. > Then, to my great surprise, someone > requested the ability to change staff size mid-stream in a > Staff context: > http://lists.gnu.org/archive/html/lilypond-user/2014-06/msg00400.html > > So I made sure that magnifyStaff could do that: > ... > \magnifyStaff 0.75 > ... > \magnifyStaff 1 % revert back to initial size > ... > > Now with requests for absolute and relative versions, as > well as this: > > \temporary \magnifyStaff 1.3 > ... > \undo \magnifyStaff 1.3 > > ...I'm starting to wonder how much of this is really > necessary. Can anyone provide an actual use case to justify > accommodating either of these requests? I admit that i don't have an actual use case. I expect that crazy composers like Mike (hello Mike! :)) could want to make the staff progressively bigger and bigger each measure, for example as a fancy way of indicating global crescendo sustained over many measures. But that's just a speculation. > Also, to be honest, I don't really like the idea of the > \larger command, since it feels so arbitrary. I could do: > \largerStaff > \smallerStaff > > but I'm not wild about that idea. I suppose I could also > figure out a way to do: > \magnifyStaffAbsolute > \magnifyStaffRelative > > but that still seems silly to me. I don't think we have to provide mechanisms for both relative and absolute staff scaling right now. I just think that it's good to design the functionality (and name the functions) with such possibility in mind. > One thought I had was > putting the burden of reverting on the user, when wanting to > change from one non-default size to another, something like > this: > ... % size 1 > \magnifyStaff 0.75 % size 0.75 > ... > \resetStaffSize % size 1 > \magnifyStaff 2 % size 2 > ... > > Then if one really wanted a "relative" magnifyStaff, they > could do: > ... % size 1 > \magnifyStaff 0.75 % size 0.75 > ... > \magnifyStaff 2 % size 1.5 > ... > > But do you really think this is what users are going to > want? I agree that this wouldn't be most intuitive. I think that the way \magnifyStaff works now is very good. Changing staff size relatively would have to be another function, if we ever decide to support it. > I think I'm > leaning towards: > 1) keeping magnifyStaff as it is > 2) making magnifyMusic syntax like magnifyStaff > 3) changing magnifyMusic to magnifyVoice +1 best, Janek _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
