Hi Urs, On Sat, Jan 10, 2015 at 3:50 PM, Urs Liska <u...@openlilylib.org> wrote:
> Am 10.01.2015 um 22:04 schrieb David Nalesnik: > >> >> >> On Sat, Jan 10, 2015 at 2:06 PM, Urs Liska <u...@openlilylib.org >> <mailto:u...@openlilylib.org>> wrote: >> >> Hi David, >> >> thank you for that suggestion. >> I'll try to get my mind around this ASAP. >> On the first sight I don't understand too much of it. But at least I >> notice that I'm not afraid of these lambda, let and let* constructs >> anymore. Finally I'm getting *somewhere* to familiarity with the >> basic working of Scheme code. What I'm still at a major loss is how >> Scheme interacts with LilyPond specific functionality. There's >> really a need for education in that sector. >> >> >> Yes, The Scheme comes in a natural progression.. There's plenty on the >> internet to assist self-study, and you can do a lot with simple >> constructs. >> > > One thing I found particularly preventing progress is the variety of > Scheme dialects, and the fact that the learner isn't pointed to that fact > enough. If you're looking for solutions on the internet they so often just > don't apply to LilyPond, and if you're looking for documentation it's just > the same. If you're looking for topics like recursion, list access, loops > or whatever, chances are quite low that search results will lead you to > pages that actually help you, instead they are extremely confusing to the > learner, simply because solutions may not work in LilyPond. > > By now I know that I should never enter "scheme conditional" in a search > engine but rather hope that "guile scheme conditional" will give me a > helping hand. But it's just recently that I found this out. OK, it *is* > stated on http://lilypond.org/doc/v2.18/Documentation/extending/ > scheme-tutorial.html, but this is in a way that you never understand the > implications until you return to it when you already know about it (just > like me rereading this now). And there definitely should be something there to point the user to the manuals for 1.8! > > > LilyPond internals? There's huge room for >> documentation/tutorials here. Not just explanations for the user, but >> comments in the code, of which there are precious few. >> >> > The internal reference of Scheme functions is quite a nightmare for people > like me. I think it can be used as a "desktop reference" for people who are > really familiar with what > > ly:add-option sym val description > > might mean, but for me it's mostly only helpful for getting a vague idea > where I could start trying. I have spent an enormous amount of time learning how to use some of those functions. One example: *Function:* *ly:grob-relative-coordinate** grob refp axis* Get the coordinate in axis direction of grob relative to the grob refp. An extremely useful function. What of the grob refp? The description makes it sound like if you can get your hands on another grob, like a LedgerLineSpanner or something, you can find the coordinate of the grob "grob" relative to it. Not so. The two grobs need to be related by a chain of parentage. The obvious usage of the command--please return the X or Y coordinate of grob in its system--can be done easily like so: (ly:grob-relative-coordinate grob (ly:grob-system grob) X) Similar constraints apply to ly:grob-extent. [Of course, the above assumes you know where such a line might go :) ] There are functions on that page that I have no idea how to use. The series of functions ly:paper-book[...] -- how do I get the Paper_book object they take as an argument? How do I get ly:set-grob-modification-callback to work? > I would love to help out with this, but I don't know where to begin! >> > > Well, the most important thing is not to think you'd have to do everything > in one go, not even having to ensure that a first step leads to a > consistent whole in the future. > I think if we add items to the collection of slow-paced tutorials each > single item is helpful. I think what I've tried with my first Scheme > tutorials is about the right direction. They deal with a very small topic > but try to be quite elaborate and give the reader a chance to slowly > consider the topic from all sides. > Everything that goes into LilyPond's official documentation is more or > less forced to be *concise* - which is of course necessary from the > perspective of the project but not too helpful to get people into this > complicated matter. > So if you would for example write one tutorial at first (even when it > should be split into a number of posts) explaining one aspect thoroughly > this would be very helpful. I've considered that tutorials are the best way to go for me. I would be hard pressed to write something for the NR or Extending. I'd find it considerably easier to tackle a specific problem--let's write a function to do this--and work through it in a relaxed style. > Think about phrases that are commonly simply used to give some other > expert a hint but don't say anything to others. Just a few ideas for such > tutorials: > > - What does "overriding a stencil" mean and imply? > This is something that I believe Harm was working on. See https://code.google.com/p/lilypond/issues/detail?id=3315 > - What is an engraver, really? > How to write one, why? What do the discussions mean about > which information is available at which stage? > This is something I've been working at on and off. > - Where do these ly: functions come from? > -> how can we interact with LilyPond internals? > http://lilypond.org/doc/v2.19/Documentation/extending/lilypond-scheme-interfaces horror vacui :) - How do define-music-function and friends relate to plain "define"? > - etc. > > If you'd be ready spending some time writing (a) tutorial(s) we could > surely find something useful and practical for you ;-) > Sure, happy to help! Best, David
_______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
