|
From: | address@hidden |
Subject: | Re: Developing for LilyPond |
Date: | Wed, 23 May 2012 07:47:40 +0200 |
On 22 mai 2012, at 22:15, David Nalesnik wrote:
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 anything to do with your patch, however. 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). 2) Improve these automation mechanisms such that tweaking is not necessary (which is what I talk about above). In slur-configuration.cc, you'll see a function Slur_configuration::generate_curve. LilyPond generates many curves for slurs and then scores them using the mechanism I describe above. You'll see code calling a bezier class that lives in bezier.cc. This class in turn uses many functions from flower/polynomial.cc. This is much closer to what your code does: it is dealing with the actual elaboration of bezier curve control points. If you follow this function through, you'll see how beziers are expressed in the C++ side. 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? Let me know if you have any questions or need any further explanations and thanks for your work! Cheers, MS P.S. cc-ing devel in case anyone else has anything to add. |
[Prev in Thread] | Current Thread | [Next in Thread] |