Re: Developing for LilyPond

2012-05-23 Thread m...@mikesolomon.org

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

2012-05-23 Thread David Nalesnik
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

2012-05-23 Thread Janek Warchoł
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

2012-05-23 Thread Kieren MacMillan
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