Janek Warchoł <janek.lilyp...@gmail.com> writes: > On Tue, May 8, 2012 at 10:21 AM, David Kastrup <d...@gnu.org> wrote: >> Janek Warchoł <janek.lilyp...@gmail.com> writes: > >>> On Mon, May 7, 2012 at 9:54 PM, James <pkx1...@gmail.com> wrote: >>>> If this were some obscure change that 'most' LP users didn't use - >>>> '#{ ... #}' seemed to get everyone really excited for instance, I >>>> just shrugged, I've never used it, don't even know why I would or >>>> if I could or when I shoul. Or maybe I have but didn't know it? >>> >>> If i understand correctly, everyone uses Scheme functions all the >>> time: when you \transpose, you use a Scheme function. \relative is >>> also a Scheme function. There is lots of Scheme wrapped nicely in >>> commands starting with backslashes. >>> When the #{ ... #} change was made, i didn't see any change in my Lily >>> workflow, too. I still don't know what exactly that change meant (i'd >>> like to learn this some day, though). >> >> It means that the non-programmer types can escape from having to use >> Scheme almost everywhere. Instead of having to write >> (ly:make-pitch 2 3 1/2) in Scheme code (and music functions are Scheme), >> they can write #{ fis''' #}. > > Thank you for explaining this for me. Until now i thought that it > already worked like this...
Oh, it would have worked in 14.1 already, but the result would not have been a pitch, but rather a SequentialMusic with an 'elements property containing a list containing an EventChord event with an 'elements property containing a list containing a NoteEvent event with a 'pitch property containing the actual pitch. My initial work on #{ ... #} got rid of the SequentialMusic, unrelated work got rid of the EventChord, and the named commit got rid of the NoteEvent. Nobody cares since people are used to #{ ... #} being useless for most purposes. But new programmers will at some point experiment around with it and won't be surprised by things working like one would think they should. And they start helping others on the user lists, because it's not really all that hard. And some of them are paying money, partly quite non-trivial amounts, because they trust I know what I am doing. That is quite a substantial amount of "thank you". But the developer list and the vetting process is not exactly a rosegarden. > You can see that i'm quite ignorant in this area :( I didn't realize > how many things need fixing; i took for granted that everything works > mostly fine. This may be the reason why i didn't appreciate your work > enough: i didn't understand it. Much of my work is focused on making things such that they make sense. I don't think that what one can make LilyPond do has changed all that much because of my work. It's more that _how_ you can make it do things is changing. >> Check out the enthusiastic reviews for this one: >> <URL:http://code.google.com/p/lilypond/issues/detail?id=2286> >> <URL:http://codereview.appspot.com/5633043> > > I am sorry that i didn't manage to review your patch. > >> Of course, not everything is apathy. If I get feedback, it is >> commonly in the form of >> <URL:http://lists.gnu.org/archive/html/lilypond-devel/2011-12/msg00247.html> >> or similar. > > I'm sorry :( Too late to run, your GSoC project has already been accepted. >> Finch's landing all over. Which reminds me: "To Kill a Mockingbird" >> is definitely very good reading, and not just because Groklaw and >> lawsuits have recently becoming much more ubiquitous. > > Sorry, but i don't understand what you mean, perhaps because i didn't > read that book. Do it. Trust me on that: you will be glad you did. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel