discrete slurs and ties
Due to this marvellous video http://www.youtube.com/watch?v=345o3Wu95Qo I have learned that short slurs and ties aren't engraved manually; instead, there are ready-to-use stamps. In other words, since the number of such stamps is limited, tie and slur shapes become discrete if their length is below a certain threshold. Do we handle this similarly? People can argue that this is an unnecessary limitation; lilypond can do a `better' job. However, I'm not sure whether we should do better... Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: discrete slurs and ties
On Wed, May 23, 2012 at 9:32 AM, Werner LEMBERG w...@gnu.org wrote: Due to this marvellous video http://www.youtube.com/watch?v=345o3Wu95Qo I have learned that short slurs and ties aren't engraved manually; instead, there are ready-to-use stamps. In other words, since the number of such stamps is limited, tie and slur shapes become discrete if their length is below a certain threshold. Do we handle this similarly? People can argue that this is an unnecessary limitation; lilypond can do a `better' job. However, I'm not sure whether we should do better... We should, definitely! There are bad tie and slur shapes in Lily, but this is not due to not having discrete lengths. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: discrete slurs and ties
People can argue that this is an unnecessary limitation; lilypond can do a `better' job. However, I'm not sure whether we should do better... We should, definitely! There are bad tie and slur shapes in Lily, but this is not due to not having discrete lengths. Umm, yes. I've meant: Should lilypond do a `better' job than the engravers working with those stamps? I say no. This limitation has become part of the appearance of well-crafted scores. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: discrete slurs and ties
Werner LEMBERG w...@gnu.org writes: People can argue that this is an unnecessary limitation; lilypond can do a `better' job. However, I'm not sure whether we should do better... We should, definitely! There are bad tie and slur shapes in Lily, but this is not due to not having discrete lengths. Umm, yes. I've meant: Should lilypond do a `better' job than the engravers working with those stamps? I say no. This limitation has become part of the appearance of well-crafted scores. Frankly, I don't see the point in simulating well-craftedness by artificially introducing minor deficiencies associated with some of the better work. We don't make slightly eroded staff lines copying the wear and tear on the tools of particularly renowned publishers, either. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: discrete slurs and ties
On Wed, May 23, 2012 at 11:15 AM, Werner LEMBERG w...@gnu.org wrote: We should, definitely! There are bad tie and slur shapes in Lily, but this is not due to not having discrete lengths. Umm, yes. I've meant: Should lilypond do a `better' job than the engravers working with those stamps? I understand. On Wed, May 23, 2012 at 11:31 AM, David Kastrup d...@gnu.org wrote: Frankly, I don't see the point in simulating well-craftedness by artificially introducing minor deficiencies associated with some of the better work. We don't make slightly eroded staff lines copying the wear and tear on the tools of particularly renowned publishers, either. +1 @Werner: i could live with an *option* doing this, but i doubt that people are interested in writing it. And i think we have much, much, much more important stuff to work on. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: discrete slurs and ties
Frankly, I don't see the point in simulating well-craftedness by artificially introducing minor deficiencies associated with some of the better work. @Werner: i could live with an *option* doing this, but i doubt that people are interested in writing it. And i think we have much, much, much more important stuff to work on. I think I was still unclear, since you both missed my point. The engraver's main deficiencies IMHO were imprecise positioning of the stamped beams. But using stamps instead of hand-cutting such small slurs and ties was an *intentional* decision. Lilypond already does a good job, as the attached image shows, but there might be cases where this isn't so, and adding some discreteness might improve the visual results. I fully agree that this isn't important at all currently. BTW, restricting lilypond to discrete tie and slur shapes below a given threshold should actually simplify the layout process since the number of positioning choices gets reduced. We don't make slightly eroded staff lines copying the wear and tear on the tools of particularly renowned publishers, either. Well, to be honest, this is debatable. There is something similar in the typography: ITC Founder's Caslon http://www.fonts.com/NR/rdonlyres/925BEFBB-34EE-4D67-94A6-9B018A02F313/0/FoundersCaslon.pdf With some background here (describing another revival of Caslon): http://ilovetypography.com/2010/07/26/reviving-caslon-the-snare-of-authenticity/ (And no, such an effect is not what I'm asking to implement :-) Werner inline: l.png___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Get the positions of a beam (or other grob with positions)
Hi David,
i'm writing just to let you know that the function changing arpeggio length:
offsetArpeggioPositions =
#(define-music-function (parser location offsets) (pair?)
#{
\override Arpeggio #'positions = #(lambda (grob)
(let* ((func (assoc-get 'positions (cdr
(ly:grob-basic-properties grob
(pos (func grob)))
(coord-translate pos offsets)))
#})
suffered form exactly the same problem as the \shape functions (if it
was used before another override of the same object, LilyPond
crashed). Fortunately, the same fix can be applied! Here is a more
generic version of the funciton (takes context name and grob name as
argument) that doesn't have this bug:
offsetPositions =
#(define-music-function (parser location context-name grob-name
offsets) (string? string? pair?)
#{
\override $context-name . $grob-name #'positions = #(lambda (grob)
(let* ((func (assoc-get 'positions
(reverse(ly:grob-basic-properties grob
(pos (func grob)))
(coord-translate pos offsets)))
#})
% example of use:
\layout {
\offsetPositions Staff Arpeggio #'(-1 . 1)
\offsetPositions PianoStaff Arpeggio #'(-3 . 2)
}
\relative c' {
c e g c2\arpeggio
}
\new PianoStaff \relative c'
\set PianoStaff.connectArpeggios = ##t
\new Staff {
e g2\arpeggio
}
\new Staff {
\clef bass
c, e2\arpeggio
}
this is cool! :D
I wish it was possible to add context to grob name in a more
LilyPondish way (i.e. with a dot)
cheers,
Janek
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: discrete slurs and ties
Werner LEMBERG w...@gnu.org writes: Frankly, I don't see the point in simulating well-craftedness by artificially introducing minor deficiencies associated with some of the better work. @Werner: i could live with an *option* doing this, but i doubt that people are interested in writing it. And i think we have much, much, much more important stuff to work on. I think I was still unclear, since you both missed my point. The engraver's main deficiencies IMHO were imprecise positioning of the stamped beams. But using stamps instead of hand-cutting such small slurs and ties was an *intentional* decision. Sure. As is using printing letters instead of hand-made calligraphy. It makes for a consistent stencil quality. But we don't have stencil quality problems. Your argument may be that it somehow helps if identical meaning is conveyed by identical shapes. But if that were actually the case, we would not need optical correction. In fact, the most common _deficiency_ of computer music typesetting is that the computer overuses mathematically correct identical shapes and placements. Lilypond already does a good job, as the attached image shows, but there might be cases where this isn't so, and adding some discreteness might improve the visual results. I fully agree that this isn't important at all currently. BTW, restricting lilypond to discrete tie and slur shapes below a given threshold should actually simplify the layout process since the number of positioning choices gets reduced. Calculating a shape does not even involve a run-time _choice_ (choices are, in my opinion, discrete), so no, this does not simplify things. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Developing for LilyPond
On 22 mai 2012, at 22:15, David Nalesnik wrote: On Tue, May 22, 2012 at 2:10 PM, m...@mikesolomon.org m...@mikesolomon.org wrote: On 22 mai 2012, at 21:01, David Nalesnik wrote: Hi Mike, On Tue, May 22, 2012 at 1:20 PM, m...@mikesolomon.org m...@mikesolomon.org wrote: Hey David, You've been doing some incredible work for the LilyPond community over the past year and I wanted to touch base to see if you'd be interested in developing for LilyPond. There's no official process to become a developer (you already are one, as you are developing solutions for LilyPond) but it does take some getting used to w/ respect to the source code and how things work. If this is of interest, let me know - I'd be glad to show you the ropes! Cheers, Mike I'm glad that you like what I've been doing, and I'd be delighted to become a developer! I do have a lot to learn, though, and I'd need to start small... I'm perfectly fine within the confines of an .ly file tweaking a function, but once I get into the realm of the CG, I'm a bit overwhelmed and I'm going to have to do a lot of study. (Well, now that the semester's over and I'm pretty underemployed, it's the perfect time--for that and composing!) At the moment, I'm trying to get the curve-shaping function into a patch (Janek has offered to help me with the process of getting it onto rietveld), but I could seriously use some advice on where it should go, whether it should be a single music function in music-functions-init.ly, or split up, etc. I've got LilyDev up and running, and I'm trying to learn what I can from the CG before I burden anyone with questions! Thank you so much for your offer to help! As I say, I would LOVE to be able to contribute more to Lily! Hey David, I'm glad to hear that you're interested! It'll be a great way for you to take your knowledge (which is quite substantial) and allow it to benefit a large number of users in a permanent way. I'll be able to take a look at your curve-shaping function tomorrow on the ride to work. Work is pretty hectic until Saturday but I'll do my best to write you a response - don't hesitate to get back in touch if you don't hear from me by then! Cool! I'm attaching the latest version which is a self-contained unit that I would stick in music-functions-init. The version that's in the thread on -user includes warnings (telling you if the slur is broken but you've given offsets for one part only, etc.) These are more in the line of helpful suggestions, and I've stripped them out of what I feel is the bare-bones function. There's a bunch of examples attached. I'll of course pare this way way down for any regression test(s), but it gives you something to try it out on. Thanks so much! -David shape-for-patch01.ly Hey David, I had a chance to look at your patch. All looks good! There's not much I can add - it looks more or less ready to go, and you can likely put it in music-functions-init.ly without many changes. If Janek's already offered to help with patch review, I'll let him tackle that. What I'd like to do is give you a bit of info about how your patch locks into the rest of LilyPond's code base and some basic design principles of what belongs in .ly, .scm, and .cc files. In general, the C++ code in LilyPond provides three key advantages over Scheme. 1) It is faster and should be used for functions that are called often or functions with loops that iterate many times. 2) It should be used to communicate with linked libraries like freetype or guile. 3) There are certain problems that are much easier to conceive of and implement in object-oriented terms and even if they could be expressed through Scheme, they are much more elegantly elaborated through C++. LilyPond's automation for slurs and ties relies on a system of weights and balances where users express desires through a details list and a few other properties. The goal of these properties is twofold: 1) Use the minimum number of linearly independent properties that can communicate how slurs and ties should be constrained in real music. 2) Give the user an intuitive way to change slur and tie behavior in common cases. In the best case scenarios 1 2 work together and in the worst they are at odds (for example, when multiple linear dependent properties, all of which have musical significance, are changed they may lead to an unexpected and confusing result). These mechanisms are put into play in different ways for different grobs, but for slurs, most of it is in slur-configuration.cc. Specifically, look through file for state.parameters_. You'll see things like state.parameters_.edge_slope_exponent_ and state.parameters_.edge_attraction_factor_. If you trace names like edge_slope_exponent_ through the C++ using git grep, you'll see where it's initialized from scheme, and how it is used. None of this has
Re: Get the positions of a beam (or other grob with positions)
On Wed, May 23, 2012 at 1:02 PM, David Kastrup d...@gnu.org wrote: Janek Warchoł janek.lilyp...@gmail.com writes: I wish it was possible to add context to grob name in a more LilyPondish way (i.e. with a dot) It is conceivable as a parser extension, That's good news! like 3/4 is nowadays generally read as '(3 . 4). I'm very happy that this is the case. It's one of the small things that make Lily more user-friendly. One would turn aa.bb.cc (no spaces!) to #'(aa bb cc) in the lexer. It would likely be somewhat tricky to make sure that one does not get surprises in lyrics and so on. Since aa is rendered as a _string_, it might be more consistent to just read aa.bb.cc as one string and leave splitting to the music function. I have not found a choice that would really be convincingly consistent, so I have not done anything of the sort yet. I'm not sure which one is better, either. Maybe GLISS will introduce some changes that will make the descision easier. best, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Get the positions of a beam (or other grob with positions)
2012/5/23 Janek Warchoł janek.lilyp...@gmail.com:
On Wed, May 23, 2012 at 1:02 PM, David Kastrup d...@gnu.org wrote:
Janek Warchoł janek.lilyp...@gmail.com writes:
I wish it was possible to add context to grob name in a more
LilyPondish way (i.e. with a dot)
It is conceivable as a parser extension,
That's good news!
like 3/4 is nowadays generally read as '(3 . 4).
I'm very happy that this is the case. It's one of the small things
that make Lily more user-friendly.
One would turn aa.bb.cc (no spaces!) to #'(aa bb cc)
in the lexer. It would likely be somewhat tricky to make sure that one
does not get surprises in lyrics and so on.
Since aa is rendered as a _string_, it might be more consistent to just
read aa.bb.cc as one string and leave splitting to the music function.
I have not found a choice that would really be convincingly consistent,
so I have not done anything of the sort yet.
I'm not sure which one is better, either.
Maybe GLISS will introduce some changes that will make the descision easier.
best,
Janek
Hi,
I tried it similar to `overrideProperty' from `music-functions-init.ly'
But I didn't manage to get rid of the -signs, when specifying the
coctext. Is this possible?
\version 2.15.38
offsetPositions =
#(define-music-function (parser location name offsets) (string? pair?)
(let ((name-components (string-split name #\.))
(context-name Voice)
(grob-name #f))
(if ( 2 (length name-components))
(set! grob-name (car name-components))
(begin
(set! grob-name (list-ref name-components 1))
(set! context-name (list-ref name-components 0
#{
\override $context-name . $grob-name #'positions = #(lambda (grob)
(let* ((func (assoc-get 'positions
(reverse(ly:grob-basic-properties grob
(pos (func grob)))
(coord-translate pos offsets)))
#}))
% example of use:
\layout {
\offsetPositions Arpeggio #'(-1 . 1)
\offsetPositions PianoStaff.Arpeggio #'(-3 . 2)
}
\relative c' {
c e g c2\arpeggio
}
\new PianoStaff \relative c'
\set PianoStaff.connectArpeggios = ##t
\new Staff {
e g2\arpeggio
}
\new Staff {
\clef bass
c, e2\arpeggio
}
-Harm
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: discrete slurs and ties
On Wed, May 23, 2012 at 12:16 PM, Werner LEMBERG w...@gnu.org wrote: Frankly, I don't see the point in simulating well-craftedness by artificially introducing minor deficiencies associated with some of the better work. @Werner: i could live with an *option* doing this, but i doubt that people are interested in writing it. And i think we have much, much, much more important stuff to work on. I think I was still unclear, since you both missed my point. The engraver's main deficiencies IMHO were imprecise positioning of the stamped beams. But using stamps instead of hand-cutting such small slurs and ties was an *intentional* decision. I think it was for efficiency's sake. It takes less time to stamp something than carve it, and small slurs seem to be more difficult to carve manually, too. Lilypond already does a good job, as the attached image shows, but there might be cases where this isn't so, and adding some discreteness might improve the visual results. Maybe... but i'd have too see an example, i cannot myself imagine any situation where that would be the case. We don't make slightly eroded staff lines copying the wear and tear on the tools of particularly renowned publishers, either. Well, to be honest, this is debatable. There is something similar in the typography: ITC Founder's Caslon http://www.fonts.com/NR/rdonlyres/925BEFBB-34EE-4D67-94A6-9B018A02F313/0/FoundersCaslon.pdf With some background here (describing another revival of Caslon): http://ilovetypography.com/2010/07/26/reviving-caslon-the-snare-of-authenticity/ Interesting! Thanks for sharing :) Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Get the positions of a beam (or other grob with positions)
On Wed, May 23, 2012 at 1:43 PM, Thomas Morley
thomasmorle...@googlemail.com wrote:
I tried it similar to `overrideProperty' from `music-functions-init.ly'
But I didn't manage to get rid of the -signs, when specifying the
coctext. Is this possible?
\version 2.15.38
offsetPositions =
#(define-music-function (parser location name offsets) (string? pair?)
(let ((name-components (string-split name #\.))
(context-name Voice)
(grob-name #f))
(if ( 2 (length name-components))
(set! grob-name (car name-components))
(begin
(set! grob-name (list-ref name-components 1))
(set! context-name (list-ref name-components 0
#{
\override $context-name . $grob-name #'positions = #(lambda (grob)
(let* ((func (assoc-get 'positions
(reverse(ly:grob-basic-properties grob
(pos (func grob)))
(coord-translate pos offsets)))
#}))
Thank you! Making unnecessary would be great, but it's already excellent!
Janek
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Developing for LilyPond
Hi Mike, On Wed, May 23, 2012 at 12:47 AM, m...@mikesolomon.org m...@mikesolomon.org wrote: [ ... ] Your patch is a post-processing corrective for when this fails. However, the goal of LilyPond is twofold: 1) Provide users with the ability to tweak LilyPond's output when for some reason the automation mechanisms put in place are not sufficient (which is what you're doing). I find that the automation settings generally produce a good-looking result, and looking through some of my scores I find that I usually let slurs, ties, etc. alone, with an occasional override of 'positions. For me this is testament to how well the system does work in the majority of cases. My use of \shape seems to be in the realm of small tweaks of curves which are generally OK (to my eye, this part of the slur passes a little too close to a note head--that sort of thing.) One of the nice things here is that you can set 'positions (and other properties like 'height-limit, 'eccentricity, etc.) and tweak _those_ results. It's great to have the minute control that 'control-points affords, but it is certainly time-consuming to create your ideal curve from scratch this way--and then redo it when the layout changes... I was just looking at the example in the NR which deals with control-points http://www.lilypond.org/doc/v2.15/Documentation/notation/modifying-shapes and this is a case in point (if any is needed) why an easier way to use 'control-points would be a big help. I've tried to duplicate the tie constructed with control-points there using \shape in the attached file (which accounts for some of the fussiness!) \shape gives you some semblance of the curve you want whether ragged-last is #t or #f, but of course you'd need to redo your 'control-points override (in this admittedly extreme case). As a next step (should you wish to pursue your slur work further), I'd recommend considering the cases that your work is responding to from a musical perspective (where does LilyPond fail in your own scores or in scores you're reading?) and the type of information you are using to correct the problem. Is there any way that this information can be used as hints to the automation process (the elaboration of curves, their scoring, etc.) that could make it more likely that slurs will not need to be tweaked down the line? I will certainly look with new eyes at the sorts of situations I've been trying to accommodate (and try to understand what might be going on--but I suspect that this will be a steep climb!!) Thank you very much for your detailed and helpful explanations. You've given me a nice road map so I can understand the process a little better. Let me know if you have any questions or need any further explanations and thanks for your work! Will do, and thank you so SO much for yours! Best, David shape-tie-test.ly Description: Binary data ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Developing for LilyPond
On Wed, May 23, 2012 at 5:16 PM, David Nalesnik david.nales...@gmail.com wrote: I find that the automation settings generally produce a good-looking result, and looking through some of my scores I find that I usually let slurs, ties, etc. alone, with an occasional override of 'positions. For me this is testament to how well the system does work in the majority of cases. My use of \shape seems to be in the realm of small tweaks of curves which are generally OK (to my eye, this part of the slur passes a little too close to a note head--that sort of thing.) I envy you - i see wrong slurs quite often, and bad ties are just about everywhere in the scores i look at! cheers :) Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Developing for LilyPond
Hi all, Speaking of ugly slurs and slur controls… ;) Is there any easy way to get back the Slur #'attachment property we used to have? Cheers, Kieren. On 2012-May-23, at 16:51, Janek Warchoł wrote: On Wed, May 23, 2012 at 5:16 PM, David Nalesnik david.nales...@gmail.com wrote: I find that the automation settings generally produce a good-looking result, and looking through some of my scores I find that I usually let slurs, ties, etc. alone, with an occasional override of 'positions. For me this is testament to how well the system does work in the majority of cases. My use of \shape seems to be in the realm of small tweaks of curves which are generally OK (to my eye, this part of the slur passes a little too close to a note head--that sort of thing.) I envy you - i see wrong slurs quite often, and bad ties are just about everywhere in the scores i look at! cheers :) Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
