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: 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