Re: Developing for LilyPond

[address@hidden]

On 22 mai 2012, at 22:15, David Nalesnik wrote:

On Tue, May 22, 2012 at 2:10 PM, address@hidden <address@hidden> wrote:

On 22 mai 2012, at 21:01, David Nalesnik wrote:

Hi Mike,

On Tue, May 22, 2012 at 1:20 PM, address@hidden <address@hidden> 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 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.