Re: thoughts on changing \magnifyMusic, please comment
markpolesky wrote > But before I start recoding the thing, I would like to know if > there's any good reason to retain the current \magnifyMusic > interface. Hi Mark, I can't think of any. It seems like all benefits and no drawbacks to me. Good idea to make these more consistent! Cheers, -Paul -- View this message in context: http://lilypond.1069038.n5.nabble.com/thoughts-on-changing-magnifyMusic-please-comment-tp164783p164797.html Sent from the Dev mailing list archive at Nabble.com. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: thoughts on changing \magnifyMusic, please comment
Mark Polesky writes: > I'm wondering whether I should do either of these: > 1) rename \magnifyMusic to \magnifyVoice > 2) change the \magnifyMusic interface to match \magnifyStaff > > Regarding #2, currently \magnifyStaff can be used in a > Staff's \with block, but \magnifyMusic *can't* be used in a > Voice's \with block. \magnifyStaff settings are reverted by > issuing `\magnifyStaff 1', Does that mean that magnifyStaff would not refer to the previous value of properties? Because if it did, \magnifyStaff 1 would seem like a noop. If it doesn't, it might be mapped to a sequence of overrides. If that would be the case, it would mean that you could use \temporary \magnifyStaff 1.3 ... \undo \magnifyStaff 1.3 and indeed \magnifyMusic could then be implemented in such a manner if it is still desired, though its size would not be relative to the current size. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: thoughts on changing \magnifyMusic, please comment
David Kastrup wrote: > Does that mean that magnifyStaff would not refer to the > previous value of properties? Because if it did, > \magnifyStaff 1 would seem like a noop. The first time magnifyStaff is called, it scales everything as it is, so if the user does this: %% default 'thick-thickness is 6 \override Staff.BarLine.thick-thickness = 4 %% first use of \magnifyStaff \magnifyStaff 0.5 then the new 'thick-thickness will be 2 (and not 3). Internally, the value of 'thick-thickness will have been changed to `2' with ly:context-pushpop-property, which does the equivalent of a \temporary \override. 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. So unless the user changed settings mid-stream, we're left with the user's original settings, which are then scaled anew, using the new magnification value (but only if the the magnification value is different from last time), and so on. Any mid-stream user overrides should be done with \temporary and should be reverted before changing staff sizes again. I should discuss this in the docs. I chose the above-mentioned design because I feel that this: \magnifyStaff 0.75 ... \magnifyStaff 1 % reset to original size is more intuitive than this: \magnifyStaff 0.75 ... \magnifyStaff 1.33 % reset to original size Also, this way I can add a command \resetStaffSize which would just be syntactic sugar for `\magnifyStaff 1', if anyone desires. > If it doesn't, it might be mapped to a sequence of > overrides. If that would be the case, it would mean that > you could use > > \temporary \magnifyStaff 1.3 > ... > \undo \magnifyStaff 1.3 > > and indeed \magnifyMusic could then be implemented in such > a manner if it is still desired, though its size would not > be relative to the current size. As it is currently designed, that's not possible, since \magnifyStaff relies on applyContext, and we get: warning: Cannot make ApplyContext revertible If the current design is unacceptable, please let me know soon so I can alter it. Hopefully it's good as it stands. Thanks for your comments, Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: thoughts on changing \magnifyMusic, please comment
Hi, better late than never ;-) 2014-07-22 22:31 GMT+02:00 Mark Polesky : > I'm wondering whether I should do either of these: > 1) rename \magnifyMusic to \magnifyVoice > 2) change the \magnifyMusic interface to match \magnifyStaff +1 for both. 2014-07-23 22:26 GMT+02:00 Mark Polesky : > 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. So unless > the user changed settings mid-stream, we're left with the > user's original settings, which are then scaled anew, using > the new magnification value (but only if the the > magnification value is different from last time), and so on. > > I chose the above-mentioned design because I feel that this: > > \magnifyStaff 0.75 > ... > \magnifyStaff 1 % reset to original size > > is more intuitive than this: > > \magnifyStaff 0.75 > ... > \magnifyStaff 1.33 % reset to original size 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. I think that in that case the command should have a slightly different name - maybe \staffSize or \staffMagnification? To me, magnifyStaff sounds like "take the current size of the staff and magnify it". > Also, this way I can add a command \resetStaffSize which > would just be syntactic sugar for `\magnifyStaff 1', if > anyone desires. Sounds worthwhile. BTW, you wrote that 2014-07-23 22:26 GMT+02:00 Mark Polesky : > 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? 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. In general, your work on setting notation size looks very nice. I've been missing such functionality for a long time :) best, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: thoughts on changing \magnifyMusic, please comment
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. >> 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. > 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. 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? 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. 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? To me the extra reset command seems needlessly cumbersome, and the "relative" magnification seems so non-intuitive, I find it hard to believe that anyone needs a relative function here, so I just built the reset into the function itself. And besides, isn't this already so esoteric (multiple mid-stream staff size changes?), what tiny minority are we catering to by even worrying about it? Sorry if I'm ranting; my questions are sincere, and I'm happy to take further discussion on the matter. I think I'm leaning towards: 1) keeping magnifyStaff as it is 2) making magnifyMusic syntax like magnifyStaff 3) changing magnifyMusic to magnifyVoice > In general, your work on setting notation size looks > very nice. I've been missing such functionality for a > long time :) Well, validation is always nice. :) Thanks! Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: thoughts on changing \magnifyMusic, please comment
2014-08-02 9:05 GMT+02:00 Mark Polesky : > 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
Re: thoughts on changing \magnifyMusic, please comment
Mark Polesky writes: > 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. Sigh. That's not as much a user interface as it is a nightmare. It's sort of hand-waving. > But do you really think this is what users are going to > want? To me the extra reset command seems needlessly > cumbersome, and the "relative" magnification seems so > non-intuitive, I find it hard to believe that anyone needs a > relative function here, so I just built the reset into the > function itself. And besides, isn't this already so > esoteric (multiple mid-stream staff size changes?), what > tiny minority are we catering to by even worrying about it? > > Sorry if I'm ranting; my questions are sincere, and I'm > happy to take further discussion on the matter. I think I'm > leaning towards: > 1) keeping magnifyStaff as it is > 2) making magnifyMusic syntax like magnifyStaff > 3) changing magnifyMusic to magnifyVoice The takeout may be that several commands doing a clear-defined job may be warranted. Personally, I am most uncomfortable with the "be relative to current settings once" idea: that seems like a total nightmare in situations using quotes or similar. The question is where we could access a reasonably "default" setting that relative references could be based on. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: thoughts on changing \magnifyMusic, please comment
Am 02.08.2014 11:35, schrieb Janek Warchoł: 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. > I don't have concrete examples either, but I can think of two practical use cases: Temporarily changing staff size may be useful in pedagogical sheets. And you could make it useful when writing "dialogue" like parts, i.e. when two or more instruments or singers sing/play alternatingly. Then it may be helpful for sight-reading when your own part is on maginfied parts of the staff. Urs -- Urs Liska www.openlilylib.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: thoughts on changing \magnifyMusic, please comment
David Kastrup wrote: > Personally, I am most uncomfortable with the "be relative > to current settings once" idea: that seems like a total > nightmare in situations using quotes or similar. The > question is where we could access a reasonably "default" > setting that relative references could be based on. Okay, then I propose a completely new design, which will be a near total rewrite of the code, but it looks like it will be more elegant. Pardon the quasi-code. `\magnifyStaff mag' will do these overrides: for each shrinkable prop S, S = (* S (/ mag old-mag)) for each unshrinkable prop U, U = (if (< mag 1) (if (< old-mag 1) U (/ U old-mag)) (if (< old-mag 1) (* U mag)) (* U (/ mag old-mag))) \magnifyStaffRelative relative-mag = \magnifyStaff #(* old-mag relative-mag) \resetStaffSize = \magnifyStaff 1 The "default" setting, corresponding to size "1", will be equivalent to the size of the staff when magnifyStaff is first called. However, unlike before, the user won't be locked in to the initial "default". To change defaults mid-stream, the user would now be able to do: ... \magnifyStaff 0.75 ... \resetStaffSize [change defaults here] \magnifyStaff 0.75 ... Does this design look better? If you're curious and you want to try to understand the crux of the confusion in all of this, read below. ___ Whether the mag value is interpreted as relative or absolute, magnifyStaff simply requires a consistent default size to refer to, if for no other reason than to prevent staff lines and the like from getting thinner than the default. It makes sense to me that, at least initially, the default size should be the size of the staff when magnifyStaff is first used. Note that \magnifyStaffRelative will *NOT* be precisely "relative to the current settings" every time, as demonstrated by the following example: ... % staff-space:1.00, staff-line:1.00 \magStaffRelative 0.75 % staff-space:0.75, staff-line:1.00 \magStaffRelative 2 % staff-space:1.50, staff-line:1.50 The call with value 0.75 won't scale staff lines below 1.00, because they're not supposed to get smaller than the "default". Accordingly, the call with value 2 won't scale everything relative to the current settings, because if it did then the staff lines would be too thick. If we allow the function to be consistently "relative to the current settings" each time, then we get staff lines that are too thin when reducing size. And if we say, "don't ever let staff lines reduce from the current size", then we get this: ... % staff-space:1.00, staff-line:1.00 \magStaffRelative 1.50 % staff-space:1.50, staff-line:1.50 \magStaffRelative 0.5 % staff-space:0.75, staff-line:1.50 Here, the staff lines, which should be back at 1.00, are stuck at 1.50: too thick. As I see it, the only way around this is to store some abstraction of an absolute "1" value, and to keep track of the relationship between the current staff size and that absolute value. Okay, hopefully I've stated the issue clearly. Sorry this is so confusing. I'm just trying to do it right. Let me know if you have more questions/concerns. Best, Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: thoughts on changing \magnifyMusic, please comment
Mark Polesky writes: > David Kastrup wrote: >> Personally, I am most uncomfortable with the "be relative >> to current settings once" idea: that seems like a total >> nightmare in situations using quotes or similar. The >> question is where we could access a reasonably "default" >> setting that relative references could be based on. > > Okay, then I propose a completely new design, which will be > a near total rewrite of the code, but it looks like it will > be more elegant. Pardon the quasi-code. > > `\magnifyStaff mag' will do these overrides: > for each shrinkable prop S, >S = (* S (/ mag old-mag)) > for each unshrinkable prop U, >U = >(if (< mag 1) > (if (< old-mag 1) > U > (/ U old-mag)) > (if (< old-mag 1) >(* U mag)) >(* U (/ mag old-mag))) This assumes access to old-mag. It also assumes that floating point arithmetic is perfect and has no accumulative errors. So I don't see that this approach will fly. > It makes sense to me that, at least initially, the > default size should be the size of the staff when > magnifyStaff is first used. I repeat: that seems like a total nightmare in situations using quotes or similar. The question is where we could access a reasonably "default" setting that relative references could be based on. Perhaps the easiest way out would be to have a staff-size relative setting in analogy to the current font-size setting. It would have to be factored in "at the last moment" just like font-size is and should cater for ossia staves and similar reasonably gracefully. Apropos gracefully: maybe it might be worth checking how grace-settings et al work and take a hint from them. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: thoughts on changing \magnifyMusic, please comment
David Kastrup wrote: >> `\magnifyStaff mag' will do these overrides: >> for each shrinkable prop S, >>S = (* S (/ mag old-mag)) >> for each unshrinkable prop U, >>U = >>(if (< mag 1) >> (if (< old-mag 1) >> U >> (/ U old-mag)) >> (if (< old-mag 1) >>(* U mag)) >>(* U (/ mag old-mag))) > > This assumes access to old-mag. It also assumes that > floating point arithmetic is perfect and has no > accumulative errors. `old-mag' would be the context-property Staff.magnifyStaffValue (which defaults to 1 if not found), accessed through \applyContext. Also, I had thought about the loss of accuracy with floating point numbers, but I just assumed that such effects would be negligible. You are leading me to believe that I am foolish to assume such things... :) > So I don't see that this approach will fly. Darn, and I felt so clever, too! Okay. >> It makes sense to me that, at least initially, the >> default size should be the size of the staff when >> magnifyStaff is first used. > > I repeat: that seems like a total nightmare in situations > using quotes or similar. The question is where we could > access a reasonably "default" setting that relative > references could be based on. I guess I'm having trouble visualizing the problem. Can you provide a minimal example (abbreviated if need be) demonstrating what you're referring to? > Perhaps the easiest way out would be to have a staff-size > relative setting in analogy to the current font-size > setting. It would have to be factored in "at the last > moment" just like font-size is and should cater for ossia > staves and similar reasonably gracefully. > > Apropos gracefully: maybe it might be worth checking how > grace-settings et al work and take a hint from them. Okay, but at this point, this may have to wait at least 2 weeks as I am coming up on a possible (short) hiatus to my LilyPond work. But answers to my current questions will still help me no doubt. Anyway, thanks for all of your help so far, Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel