Re: Quit [now definitely O/T]
Jan-Peter Voigt wrote Thursday, November 12, 2009 3:58 PM So my question would be, is there a guide to the sources? Are there key principals in the architecture? If there is a chance to get into this next to my job, I would really like to give Lily somthing! Thanks for the offer! You will be made welcome, but as we have been discussing there is no easy introduction to LilyPond's sources. However, there is an embryonic Contributor's Guide which outlines the first steps and a group of early contributors called the Frogs which has their own mailing list. For the Contributor's Guide see http://kainhofer.com/~lilypond/Documentation/contributor/index.html. For the Frogs mailing list see http://frogs.lilynet.net/ Trevor ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Quit [now definitely O/T]
Op woensdag 11-11-2009 om 17:47 uur [tijdzone -0500], schreef Kieren MacMillan: I've got to learn yet another markup language There is nothing to learn. Have you seen a file? Adding plain text is more intuitive than using Apple's finder. Really. and install a bunch of apps (still in progress, over an hour later?!) before I can even start the [alleged] 2-5 hours of content development/improvement. The lilypond developer community currently uses GNU/Linux to develop lilypond. Almost exclusively, always has. That may change. Chances are problems are fixed before you encounter them if you use a platform other people use. I guess what I'm really saying is, if we think the barrier-to-entry for USERS is high, we've got another thing coming re: DEVELOPERS... =\ As a new contributor/developer, by using a different, and a particular unfriendly platform for free software development, you are faced with tackling several difficult problems at once. This is only meant as an observation and an apology. Had you be using a common GNU/Linux platform, installing all dependencies can be done in a single command that runs in under a minute on my box. Keep hanging in there! Greetings, Jan. p.s. Hopefully I'm more resilient than others who have come before me — and subsequently dropped off the face of the interwebs, if Graham's 0 documentation developers is accurate — and I'll be able to get past these initial obstacles without losing [too much of] my goodwill steam. Yes, I hope that too. PS: you may try using the #lilypond irc channel, that may help to move things forward. -- Jan Nieuwenhuizen jann...@gnu.org | GNU LilyPond - The music typesetter Avatar®: http://AvatarAcademy.nl| http://lilypond.org ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Quit [now definitely O/T]
Op donderdag 12-11-2009 om 08:41 uur [tijdzone +0100], schreef David Kastrup: Carl Sorensen c_soren...@byu.edu writes: _Addressing_ the actual problems is definitely more suitably done on the developer list. So what are the actual problems? Is LilyPond really too difficult? Do we rely too much on crufty input-language solutions? How many ritardando-like hacks do we have for common problems? Are they listed/categorised somewhere? Maybe it's just that we are not tempting enough to be used. I cannot imagine that OP would have stopped with a frustating message to sibelius-user after having paid for the program? That would me he basically threw away that money. Quitting with LilyPond seems to cost him nothing. He only gets uglier scores and does not care about the end result, maintainability, shareability, or the social impact/implications of spending money on proprietary software as opposed to devising and documenting solutions for a free software? How about a frogs project to make our image sexier? Greetings, Jan. -- Jan Nieuwenhuizen jann...@gnu.org | GNU LilyPond - The music typesetter Avatar®: http://AvatarAcademy.nl| http://lilypond.org ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Quit [now definitely O/T]
Continued on developer list. Jan Nieuwenhuizen janneke-l...@xs4all.nl writes: As a new contributor/developer, by using a different, and a particular unfriendly platform for free software development, you are faced with tackling several difficult problems at once. This is only meant as an observation and an apology. Had you be using a common GNU/Linux platform, installing all dependencies can be done in a single command that runs in under a minute on my box. It's basically a startup investment. Personally, I have the impression that the current structure of C++ plus Scheme may not be the best setup since Scheme, as the principal script language, does not have the expressive power to work with Lilypond's internal data structures. Taking a comparative look at C/Elisp as used in Emacs, the actual programming is done in Elisp, with C delivering primitives and all access to the Elisp data structures. _If_ Emacs has the principal capabilities for some task, you can code the whole task in Elisp. This does not appear to be doable with Lilypond's Scheme. At least not to the degree where it is the preferred way of thinking about new tasks. At least I don't see how one can whip up new translators or context types just writing Scheme code. For a start from scratch, Lua would be a nice choice: message-passing coroutines (very nice for translators keeping context!), procedural syntax, very portable, fast. And you can learn everything worth knowing about it in few days. I can actually understand and work with the Lua coroutines. In contrast, I am not sure that trying to solve tasks with Scheme continuations in Lilypond will not crash down everything around you. Pretty much all usable Scheme data _structures_, (cons cell, array), have a non-local existence, and just the named handle to them is actually part of the dynamic context. So while continuations may have well-defined semantics on the dynamic context, this does not buy you useful semantics for the structured data you would want to manipulate in this context. Anyway, water down the drawbridge. Would it be feasible to create new listeners/performers/contexts purely in Scheme, by having generic enough C++ listener/performer/context factories that one can fit in everything worth having by using Scheme? Scheme might not be the nicest language for programming, but being able to solve everything important in some application in _one_ language without need of recompiling (or heap management) or language interfacing would be a good step towards recruiting new programmers and solving tasks, partly in form of libraries or packages which can be just used on-demand rather than needing to be compiled in. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Quit [now definitely O/T]
Jan Nieuwenhuizen janneke-l...@xs4all.nl writes: Op donderdag 12-11-2009 om 08:41 uur [tijdzone +0100], schreef David Kastrup: Carl Sorensen c_soren...@byu.edu writes: _Addressing_ the actual problems is definitely more suitably done on the developer list. So what are the actual problems? The actual problem is the payoff. If I can write just music, it means I can freely rearrange my material and reread it. One example is transposition or augmentation: manual text changes and accent placements will then tend to fall apart. Is LilyPond really too difficult? Depends on the tasks. Simple common tasks should be simple and straightforward, and a sizeable subset of those isn't. Do we rely too much on crufty input-language solutions? We don't rely on them. LSR is not a part of Lilypond. Every hack in LSR is a hack too much. That's why I proposed that a lot of LSR snippets would become more inspirational by adding a variant this is how one would write this snippet in an ideal world. Maybe it's just that we are not tempting enough to be used. I cannot imagine that OP would have stopped with a frustating message to sibelius-user after having paid for the program? Why not? People try out and forget about software all the time. That would mean he basically threw away that money. At some point of time, that's what you do. Quitting with LilyPond seems to cost him nothing. He only gets uglier scores and does not care about the end result, maintainability, shareability, or the social impact/implications of spending money on proprietary software as opposed to devising and documenting solutions for a free software? How about a frogs project to make our image sexier? You could start by not writing paragraphs like the one before your question. Name-calling people who do not manage to make Lilypond fit their bill gets us nowhere. It also stifles people from giving feedback. If people don't share your exact set of values, that does not make them unsuitable for contributing. Freedom is not something to be reserved for freedom-fighters. That's not its point. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Quit [now definitely O/T]
Hi Jan, There is nothing to learn. Have you seen a file? Adding plain text is more intuitive than using Apple's finder. Really. Well, since I don't even have a build system that works yet, this is all totally moot at the moment... Chances are problems are fixed before you encounter them if you use a platform other people use. So we should all use Windows? ;) Keep hanging in there! I'll try. Kieren. PS: you may try using the #lilypond irc channel that may help to move things forward. What's IRC? [Only 1/2 kidding...] ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Quit [now definitely O/T]
Op donderdag 12-11-2009 om 05:49 uur [tijdzone -0500], schreef Kieren MacMillan: Hi Kieren, There is nothing to learn. Have you seen a file? Adding plain text is more intuitive than using Apple's finder. Really. Well, since I don't even have a build system that works yet, this is all totally moot at the moment... Graham may be happy to receive/include useful plain text bits that have not been verified by the build system. Chances are problems are fixed before you encounter them if you use a platform other people use. So we should all use Windows? ;) Choice comes with a price. We choose GNU/Linux as a primary development platform because we wanted to develop a free software. I think that was -- and still is -- the most sensible choice. It is not my intention to ridicule or limit /your/ choices. I'm just pointing out that choosing something different will --currently still -- cost you. What's IRC? [Only 1/2 kidding...] http://lilypond.org/web/about/index.html search for irc :-) Greetings, Jan. -- Jan Nieuwenhuizen jann...@gnu.org | GNU LilyPond - The music typesetter Avatar®: http://AvatarAcademy.nl| http://lilypond.org ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Quit [now definitely O/T]
On 11/11/09 4:23 PM, Jonathan Wilkes jancs...@yahoo.com wrote:
spannerText =
#(define-music-function (parser location span-text)
(string?)
#{
\override TextSpanner #'(bound-details
left text) = #$span-text
#)
which would allow above example to be coded much more
easily in the input
file
\spannerText rit.
b1\startTextSpan
e,\stopTextSpan
but would hide the underlying LilyPond functionality (the
\override) and
make users less likely to learn how to do overrides that
they may need to do
for their own challenging music.
Stay tuned for the GLISS, and get your own opinion in.
Thanks,
Carl
Hello David and Carl,
I was really excited to read David's suggestion for \startTextSpan
taking an argument. For me, it makes much more sense and flows better
when entering notes to write:
b1\startTextSpan accel.
c,\stopTextSpan a tempo
than the syntax Carl has used above. I cannot imagine any scenario
where this would hinder one's understanding of the \override syntax and
am curious what the reasoning is behind this assumption.
To me, this syntax looks a lot like:
b1^so easy to learn, retain, type...
c,_...and teach!
Just my two cents. I'm not a programmer but would be happy to test the
heck out of this functionality if you know how to implement it, David.
Well, I'm also happy to test Carl's syntax too if that's the way
most people prefer it; it's still way better than having to override
the text spanner to enter text (which is still not as bad as having to
draw your own splayed stem when you click the splayed stem button in
Finale!).
Yes, but implementing the syntax that David proposes requires changes to the
parser (which is a difficult challenge, for me).
The syntax I proposed can be implemented by you, right now, by just copying
and pasting the code I posted into your lilypond file (or into another file,
say spannertext.ily, and then including spannertext.ily in all of your
lilypond files). So there's no need to wait for us -- just go ahead and use
it right now.
Thanks,
Carl
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Quit [now definitely O/T]
Hi Jan, I'm just pointing out that choosing something different will --currently still -- cost you. Absolutely... and, as we've witnessed, this is almost certainly materially affecting the number of developers that can/will work on Lilypond. Like it or not, 95% of the computer world is not on Linux — for example, see http://www.w3counter.com/globalstats.php, which puts Linux at ~2.2% share. Put another way, the difficulty of setting up a development system on anything but Linux is a significant obstacle to Lilypond's potential. Cheers, Kieren. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Quit [now definitely O/T]
Op donderdag 12-11-2009 om 08:36 uur [tijdzone -0500], schreef Kieren MacMillan: Hi Kieren, Absolutely... and, as we've witnessed, this is almost certainly materially affecting the number of developers that can/will work on Lilypond. Of course. Like it or not, 95% of the computer world is not on Linux — for example, see http://www.w3counter.com/globalstats.php, which puts Linux at ~2.2% share. Yes. Put another way, the difficulty of setting up a development system on anything but Linux is a significant obstacle to Lilypond's potential. Well, that's the question, isn't it? It depends on the percentage of users on each platform that are able and willing to contribute. It would surprise me if you could find many developers that want to volunteer their time working on free software, yet continue to do so using [and paying for] a rigid, proprietary system and developer tools? Jan. -- Jan Nieuwenhuizen jann...@gnu.org | GNU LilyPond - The music typesetter Avatar®: http://AvatarAcademy.nl| http://lilypond.org ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Quit [now definitely O/T]
Kieren MacMillan kieren_macmil...@sympatico.ca writes: Hi Jan, I'm just pointing out that choosing something different will --currently still -- cost you. Absolutely... and, as we've witnessed, this is almost certainly materially affecting the number of developers that can/will work on Lilypond. Like it or not, 95% of the computer world is not on Linux — for example, see http://www.w3counter.com/globalstats.php, which puts Linux at ~2.2% share. Put another way, the difficulty of setting up a development system on anything but Linux is a significant obstacle to Lilypond's potential. It's not as bad as the numbers suggest. The ratio of serious developers who will balk at getting their development environment up and running will not be all that large. I think that the user base is affected more than the developer base. But again: batch processing is something that tends to scare more Windows users than Linux/Unix/etc. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Quit [now definitely O/T]
Hi Jan, Well, that's the question, isn't it? It depends on the percentage of users on each platform that are able and willing to contribute. Absolutely. It would surprise me if you could find many developers that want to volunteer their time working on free software, yet continue to do so using [and paying for] a rigid, proprietary system and developer tools? I'm one — in fact, I'm going out today to pay $$$ (only 3) for Mac OS X 10.6, only to come home and volunteer my time working on (free) Lilypond. =) Kieren. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Quit [now definitely O/T]
On Thu, Nov 12, 2009 at 02:50:08PM +0100, Jan Nieuwenhuizen wrote: Put another way, the difficulty of setting up a development system on anything but Linux is a significant obstacle to Lilypond's potential. It would surprise me if you could find many developers that want to volunteer their time working on free software, yet continue to do so using [and paying for] a rigid, proprietary system and developer tools? Jan, I love you dearly, but... don't be an idiot. Are you /seriously/ doubting the enormous effort and time that Trevor Daniels has put into the docs? And even some bugfixes? Are you /seriously/ doubting the enormous effort and time that Mark Polesky put into all the bugfixes and misc stuff he worked on? Out of the top four new contributors from the past year, windows users occupy two of the places. Cheers, - Graham ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Quit [now definitely O/T]
Hi David, It's not as bad as the numbers suggest. The ratio of serious developers who will balk at getting their development environment up and running will not be all that large. That may be true, but irrelevant to my point: the vast majority of the potential/actual serious [new] developers for Lilypond don't/ won't use Linux — any additional obstacle (over the Linux setup) needs to be addressed and removed, if we are to attract those (desperately needed) new developers. I think that the user base is affected more than the developer base. Possibly, but again irrelevant (or at least orthogonal) to the discussion: I think that 100% of the new developer base will have started as part of the user base, since it seems unlikely to the point of impossibility that a random non-Lilypond-using developer (Linux-based or otherwise) will suddenly decide to join the dev team out of sheer good will. Regards, Kieren. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Quit [now definitely O/T]
Kieren MacMillan kieren_macmil...@sympatico.ca writes: Possibly, but again irrelevant (or at least orthogonal) to the discussion: I think that 100% of the new developer base will have started as part of the user base, since it seems unlikely to the point of impossibility that a random non-Lilypond-using developer (Linux-based or otherwise) will suddenly decide to join the dev team out of sheer good will. I am responsible for a good part of classical Greek support in LaTeX. Fault of my former girlfriend's philosophy paper requirements. The best programmers are often programmers that are into programming for the sake of programming. Ask such a person for help with typesetting music, and Lilypond will be one of the points of attraction for him, and obstacles are disproving his geek state (or the state of what he claimed to be the best he can deliver). For many pet projects, the principal programmers are casual users at best, since they are mostly, well programmers. That often leads to situations like your application slows down unbearably on million-line files -- million lines? for real? -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Quit [now definitely O/T]
Hi David, The best programmers are often programmers that are into programming for the sake of programming. Ask such a person for help with typesetting music, and Lilypond will be one of the points of attraction for him, and obstacles are disproving his geek state (or the state of what he claimed to be the best he can deliver). For many pet projects, the principal programmers are casual users at best, since they are mostly, well programmers. Please invite all of these people to the ’Pond... I can't wait to see/hear the stampede. Regards, Kieren. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Quit [now definitely O/T]
Kieren MacMillan kieren_macmil...@sympatico.ca writes: Hi David, The best programmers are often programmers that are into programming for the sake of programming. Ask such a person for help with typesetting music, and Lilypond will be one of the points of attraction for him, and obstacles are disproving his geek state (or the state of what he claimed to be the best he can deliver). For many pet projects, the principal programmers are casual users at best, since they are mostly, well programmers. Please invite all of these people to the ’Pond... I can't wait to see/hear the stampede. They don't get along with each other and spend all their time working on Emacs, anyway. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Quit [now definitely O/T]
Hello Kieren, hello David, hello out there, I followed this conversation a little bit. Well I have been a quite good C++ coder, but that was about 10 years ago. Right now I am one of those million java developers. For my Job I had to turn to Java, wich I didn't really love. With Java5 it got a lot better. But thats not my point now ;) Nowadays I have to feed my family, so my afforts to get back into music business are very careful ... I came over Lilypond last May, when I had too get some chants in the paper (how do you call it?) of my cousins wedding. I first tried to copy them from the book. But there were ugly black margins, then I started to typeset in Logic Pro, wich I used and liked a long time for music production, but then I found this very pretty piece Lilypond. It took me half an hour to typeset those 4 chants on my Ubuntu machine. From those days on I used it a lot of times to get choral scores more readable, to transpose pieces and, most important, to typeset my own and my familys compositions. Now I am really passionate in talking about Lily. It feels so good, when there is such a nice Score to view after typing a few characters. So my question would be, is there a guide to the sources? Are there key principals in the architecture? If there is a chance to get into this next to my job, I would really like to give Lily somthing! Regards, Jan-Peter. Am 12.11.2009 um 15:42 schrieb Kieren MacMillan: Hi David, The best programmers are often programmers that are into programming for the sake of programming. Ask such a person for help with typesetting music, and Lilypond will be one of the points of attraction for him, and obstacles are disproving his geek state (or the state of what he claimed to be the best he can deliver). For many pet projects, the principal programmers are casual users at best, since they are mostly, well programmers. Please invite all of these people to the ’Pond... I can't wait to see/hear the stampede. Regards, Kieren. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Quit [now definitely O/T]
Hello there!... El 12/11/2009, a las 04:11 a.m., David Kastrup escribió: Continued on developer list. Jan Nieuwenhuizen janneke-l...@xs4all.nl writes: As a new contributor/developer, by using a different, and a particular unfriendly platform for free software development, you are faced with tackling several difficult problems at once. access to the Elisp data structures. _If_ Emacs has the principal capabilities for some task, you can code the whole task in Elisp. This does not appear to be doable with Lilypond's Scheme. At least not to the degree where it is the preferred way of thinking about new tasks. Lilypond's Scheme is GUILE's Scheme. And the fact you are pointing out is repeatedly found on hundreds of blogs around the internet , whenever some Java/C/C++ programmer is faced with Scheme/Lisp. They all have said the same thing: How come we have to use such and old language, when we have such great new (and modern!) new ones that could handle everything easily? Fashionability is the keyword here. Java, for example, with all the bell and whistles it has, is *barely* (from a distance) catching up with Lisp. Sure, there are more books being sold by thie X language, or it sounds more fashianble to work this Y language in the opensource community but then what?... would lilypond's owners have to change the whole concept behind it in order to bring up more programmers? Is there a need for programming language or interfaces other than the ones already in? I think not. Perhaps the project need more people *organizing* the information regarding the interfaces and polishing the syntax... I would not know what the higher powers would want. For a start from scratch, Lua would be a nice choice: message-passing coroutines (very nice for translators keeping context!), procedural syntax, very portable, fast. And you can learn everything worth knowing about it in few days. Why not Java? or Objective C for that matter?... Or Ada, or COBOL, or ALGOL or Fortran, or ... hmmm... gosh... there are so many. In the beggining (1958) there were only 2. And currently just Lisp stays strong and way ahead of all others in terms of flexibility, scalabilty and freedom to do whatever anybody might want. I can actually understand and work with the Lua coroutines. In contrast, I am not sure that trying to solve tasks with Scheme... That is a problem of perspective that is faced with all programmers that have ever read one line of scheme/lisp code. The problem has historical roots and has been documented elsewere. Notwithstanding, there are several ways to overcome this perpective limitation. Scheme might not be the nicest language for programming, but being able to solve everything important in some application in _one_ language without need of recompiling (or heap management) or language interfacing would be a good step towards recruiting new programmers and solving tasks, partly in form of libraries or packages which can be just used on-demand rather than needing to be compiled in. Where can I vote? Guillermo ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Quit [now definitely O/T]
Jesús Guillermo Andrade gandr...@usermail.com writes: El 12/11/2009, a las 04:11 a.m., David Kastrup escribió: Jan Nieuwenhuizen janneke-l...@xs4all.nl writes: As a new contributor/developer, by using a different, and a particular unfriendly platform for free software development, you are faced with tackling several difficult problems at once. access to the Elisp data structures. _If_ Emacs has the principal capabilities for some task, you can code the whole task in Elisp. This does not appear to be doable with Lilypond's Scheme. At least not to the degree where it is the preferred way of thinking about new tasks. Lilypond's Scheme is GUILE's Scheme. And the fact you are pointing out is repeatedly found on hundreds of blogs around the internet , whenever some Java/ C/C++ programmer is faced with Scheme/Lisp. They all have said the same thing: How come we have to use such and old language, when we have such great new (and modern!) new ones that could handle everything easily? Huh? Did you understand at all what I have been trying to say? My complaint is not that I have to use Scheme. Quite contrary. My complaint is that using Scheme is not sufficient and I have to use C++ as well. And that's a nuisance. Fashionability is the keyword here. No. Limiting the required knowledge to actually do something is the keyword. For a start from scratch, Lua would be a nice choice: message-passing coroutines (very nice for translators keeping context!), procedural syntax, very portable, fast. And you can learn everything worth knowing about it in few days. Why not Java? or Objective C for that matter? Because the syntax diagram for Lua fits on one half-letter page. Because it has a single data structure (the table). Because in two days you have learnt all that is relevant to learn about Lua, and can turn to learning about Lilypond. ... Or Ada, or COBOL, or ALGOL or Fortran, or ... hmmm... gosh... there are so many. In the beggining (1958) there were only 2. And currently just Lisp stays strong and way ahead of all others in terms of flexibility, scalabilty and freedom to do whatever anybody might want. Not really. Emacs Lisp is a fossilized half-lexical abomination. But it does the job. And most Lisp is designed as functional, and programmed as procedural, with the fundamental data structure, the list, being basically non-scope-local. And that's the main point: does the job. The one thing Emacs Lisp has going over Common Lisp that it is a reasonably limited language to learn in comparison. Which is a nuisance to seasoned Lisp programmers, and gets quite more people to meddle with it. I can actually understand and work with the Lua coroutines. In contrast, I am not sure that trying to solve tasks with Scheme... That is a problem of perspective that is faced with all programmers that have ever read one line of scheme/lisp code. The problem has historical roots and has been documented elsewere. Notwithstanding, there are several ways to overcome this perpective limitation. Oh come on, get down from your high horse. I am maintaining Emacs Lisp packages and have written a few. I am familiar with the proceduralisms of applied Lisp, but it does not mean I can't write something in a functional style like ((lambda (f n) (f f n)) (lambda (f n) (if ( n 1) (* n (f f (- n 1))) 1)) 5) Scheme might not be the nicest language for programming, but being able to solve everything important in some application in _one_ language without need of recompiling (or heap management) or language interfacing would be a good step towards recruiting new programmers and solving tasks, partly in form of libraries or packages which can be just used on-demand rather than needing to be compiled in. Where can I vote? In the usual way, with patches on the list. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Quit [now definitely O/T]
Sorry, I initially just sent this to Jan and meant to send it to the group. On Nov 12, 2009, at 2:11 AM, Jan Nieuwenhuizen wrote: Op donderdag 12-11-2009 om 08:41 uur [tijdzone +0100], schreef David Kastrup: Carl Sorensen c_soren...@byu.edu writes: _Addressing_ the actual problems is definitely more suitably done on the developer list. So what are the actual problems? Is LilyPond really too difficult? Well, in a word, yes. OK, that's too glib because the second question is too difficult for what and that wasn't asked. It's too difficult (as in the learning curve is too steep and seems practically infinite) for the majority of casual users who will give it a try. You do have to look at it through naive eyes to see that the start of the learning curve is like standing at the base of Monolith when all one wanted was to go for a little hike. I have mastered LilyPond just enough to do the simple jazz lead sheets I need (and am not quite there yet- I get flummoxed by something on every other score). I've tried to interest a lot of fellow jazz musicians (some of them college professors, high powered professionals and some pro musicians, all of them quite intelligent) and to a person they threw up their hands within minutes. I know one other jazz musician who uses LilyPond, the rest use Finale (or just do charts by hand). Once one has to resort to hacks to get stuff done, it becomes a brute-force approach which is beyond the interest of (IMHO) the vast majority of users. Do we rely too much on crufty input-language solutions? It happens pretty quickly on pretty simple charts that one has to use overrides and the like to get glyphs to position correctly, which means that new users are likely very frustrated with output issues (e.g., why is the coda glyph appearing there when I put it here?). It makes for inelegant code in the .ly file and a greater likelihood of the input being broken with each upgrade, causing trouble and frustration for the user. There does not have to be a GUI to make it simple and easy to use. Text input is fine, it just has to have a clear, consistent and predictable input syntax which makes it simple to position notes, rests, bars, text, lyrics, glyphs and structural things like repeats. It's almost there, but having to read hundreds of pages of arcane documentation to produce a one page lead sheet remains problematic. How many ritardando-like hacks do we have for common problems? Are they listed/categorised somewhere? Much of the LSR contains such hacks. Isn't that what it's for? It seems to me that there are hundreds of hacks in the LSR to make LilyPond do something that the standard markup language cannot do, or at least can't do readily. Now, don't get me wrong. LilyPond produces better looking sheet music than anything else I have seen. It's amazingly powerful and can do a gigantic variety of things, which is both a strength and its Achilles' heel. But it's also like Emacs using LaTeX in its complexity and power while most potential users are just looking for NotePad. One question is how LilyPond positions itself in the market. As it currently stands, it is not for the average user. It is an application squarely aimed at power users who enjoy the problem- solving aspect of dealing with using two different languages simultaneously (LilyPond's LaTeX-like markup language and Scheme) and don't mind the challenge of making the application produce the output you want. It is not for the musician who just wants a chart with a minimum of fuss and time. There's nothing wrong with that, other than that the former market is small and the latter market is large- and there's nothing wrong with that either. The market for a Lexus LFA is small, the market for a Toyota Corolla is large. If LilyPond is intended to be a Lexus, then things are pretty fine. If it is intended to be a Corolla, then there is a lot of fundamental work to be done on the user-friendliness of the markup language. People often get mad when things like this are said because it seems to negate the hundreds or thousands of hours they put into development. I certainly do not mean to do that and hope that no one takes it that way. As I said earlier, LilyPond is an amazingly powerful program. But that power may mean that it has a limited market appeal. NotePad has probably three orders of magnitude more users than Emacs for the same reasons- relatively few users need the power and flexibility of Emacs because they just want to write a quick note to Aunt Martha. There is nothing wrong with that. It may very well be that trying to cater to casual users who just want to make a simple score or a rock tune or a folk song or something like that is not realistic for LilyPond. Nothing wrong with that either. It's a badass powerful music engraving
Re: Quit [now definitely O/T]
Tim McNamara tim...@bitstream.net writes: On Nov 12, 2009, at 2:11 AM, Jan Nieuwenhuizen wrote: Op donderdag 12-11-2009 om 08:41 uur [tijdzone +0100], schreef David Kastrup: Carl Sorensen c_soren...@byu.edu writes: _Addressing_ the actual problems is definitely more suitably done on the developer list. So what are the actual problems? Is LilyPond really too difficult? Well, in a word, yes. OK, that's too glib because the second question is too difficult for what and that wasn't asked. It's too difficult (as in the learning curve is too steep and seems practically infinite) for the majority of casual users who will give it a try. You do have to look at it through naive eyes to see that the start of the learning curve is like standing at the base of Monolith when all one wanted was to go for a little hike. Can't say I agree here all too much. Scheme-less Lilypond is reasonably comfortable to write. You can start with an abc-like subset. I have mastered LilyPond just enough to do the simple jazz lead sheets I need (and am not quite there yet- I get flummoxed by something on every other score). I've tried to interest a lot of fellow jazz musicians (some of them college professors, high powered professionals and some pro musicians, all of them quite intelligent) and to a person they threw up their hands within minutes. I know one other jazz musician who uses LilyPond, the rest use Finale (or just do charts by hand). Once one has to resort to hacks to get stuff done, it becomes a brute-force approach which is beyond the interest of (IMHO) the vast majority of users. Yes. Which is why I'd like to accompany LSR-snippets by if the world were ideal hack-less snippets which don't run (yet!). It happens pretty quickly on pretty simple charts that one has to use overrides and the like to get glyphs to position correctly, which means that new users are likely very frustrated with output issues (e.g., why is the coda glyph appearing there when I put it here?). And one should not need to position coda glyphs at all. Tell Lilypond the repeat structure and let it do the typesetting. Overrides and manual glyphing for facsimile reproductions are fine as a fallback, but they should not be the rule. Now, don't get me wrong. LilyPond produces better looking sheet music than anything else I have seen. MusiXTeX gives pretty usable output as well, at the cost of horrific manual work, illegible input and an interfering idiosyncratic typesetting engine. The Lilypond tradeoff is much better, but it needs to get better still. Simple things need to be consistently simple. One question is how LilyPond positions itself in the market. As it currently stands, it is not for the average user. It is an application squarely aimed at power users who enjoy the problem- solving aspect of dealing with using two different languages simultaneously (LilyPond's LaTeX-like markup language and Scheme) You are forgetting C++ which is required for translators AFAICS. and don't mind the challenge of making the application produce the output you want. It is not for the musician who just wants a chart with a minimum of fuss and time. I use it for that as well. That's fine until you run into an unexpected road block. People often get mad when things like this are said because it seems to negate the hundreds or thousands of hours they put into development. I certainly do not mean to do that and hope that no one takes it that way. As I said earlier, LilyPond is an amazingly powerful program. But that power may mean that it has a limited market appeal. As long as simple things are simple to do, power does not harm. NotePad has probably three orders of magnitude more users than Emacs for the same reasons- relatively few users need the power and flexibility of Emacs because they just want to write a quick note to Aunt Martha. Nowadays it is more because people using Notepad hear the stories from people who had exposure to Emacs 20 years ago and got frustrated. Today's Emacs gets very little into your hair when you are just trying to use it in the obvious way. There is nothing wrong with that. It may very well be that trying to cater to casual users who just want to make a simple score or a rock tune or a folk song or something like that is not realistic for LilyPond. Hm? That's what I mostly use it for. Nothing wrong with that either. It's a badass powerful music engraving application, after all. Try MusiXTeX for a week. Should be a perspective-changer. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Quit [now definitely O/T]
Dear David: Thank you very much for your reply. If I was not that clear, please accept my apologies. I was not trying to seem pretentious or arrogant (far from it since I went into the thread as a newbie). My first language was COBOL, then Pascal, Perl and C. I barely have some notions of C++ (with emphasis over the + signs) :-) For Lisp I started with Emacs many years ago, but I never put it into practice since I did not need it until recently. El 12/11/2009, a las 02:17 p.m., David Kastrup escribió: And that's the main point: does the job. The one thing Emacs Lisp has going over Common Lisp that it is a reasonably limited language to learn in comparison. Which is a nuisance to seasoned Lisp programmers, and gets quite more people to meddle with it. But surely from a practical point of view: would not that kind of shift change the whole design philosophy of lilypond? How much would have to adapt? Maybe start of scratch? I can actually understand and work with the Lua coroutines. In contrast, I am not sure that trying to solve tasks with Scheme... That is a problem of perspective that is faced with all programmers that have ever read one line of scheme/lisp code. The problem has historical roots and has been documented elsewere. Notwithstanding, there are several ways to overcome this perpective limitation. Oh come on, get down from your high horse. I am maintaining Emacs Lisp packages and have written a few. I am familiar with the proceduralisms of applied Lisp, but it does not mean I can't write something in a functional style like ((lambda (f n) (f f n)) (lambda (f n) (if ( n 1) (* n (f f (- n 1))) 1)) 5) I get the point... Scheme might not be the nicest language for programming, but being able to solve everything important in some application in _one_ language without need of recompiling (or heap management) or language interfacing would be a good step towards recruiting new programmers and solving tasks, partly in form of libraries or packages which can be just used on-demand rather than needing to be compiled in. Where can I vote? In the usual way, with patches on the list. I will. Thanks. Guillermo. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Quit [now definitely O/T]
Jesús Guillermo Andrade gandr...@usermail.com writes: El 12/11/2009, a las 02:17 p.m., David Kastrup escribió: And that's the main point: does the job. The one thing Emacs Lisp has going over Common Lisp that it is a reasonably limited language to learn in comparison. Which is a nuisance to seasoned Lisp programmers, and gets quite more people to meddle with it. But surely from a practical point of view: would not that kind of shift [Going to a single extension language, with the from-scratch proposal Lua] change the whole design philosophy of lilypond? The design, as in principal data flow, would not change. The implementation would. How much would have to adapt? All. Unless one plugs in a Baby scheme interpreter. But that's likely not a totally fantastic idea. Maybe start of scratch? All this was under the start from scratch premise. It would be sensible to fade out C++ against C in the process, change the data structures to Lua friendly ones, change most of the internal Scheme code, provide a chicken Scheme interpreter at user level. The principal Lilypond data structure, the property list, would actually be quite more efficiently implemented using Lua tables. I can actually understand and work with the Lua coroutines. In contrast, I am not sure that trying to solve tasks with Scheme... That is a problem of perspective that is faced with all programmers that have ever read one line of scheme/lisp code. The problem has historical roots and has been documented elsewere. Notwithstanding, there are several ways to overcome this perpective limitation. Oh come on, get down from your high horse. I get the point... The problem is that a cons is not self-contained data. So even with continuations, the main data structures don't have scoped behavior. That makes much of the control structures in Scheme work out less than fabulous in practice once you don't just juggle atoms. But still just Scheme is better than Scheme+C++ for extension. If one can do. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Quit
On Wed, 2009-11-11 at 00:44 -0500, lilypond-user-requ...@gnu.org wrote: Also, the complaint here isn't that there's some inherent defect in the program or the documentation, rather that you didn't want to take the time to learn how to use lilypond when you could do it in sibelius faster. James E. Bailey I must say that the faster thing is a typical United States behavior. Our markets and media constantly barrage us with time issues. The main point of sale is if you buy our product you can get it done faster. The barrage has brought about an almost infantile attitude amongst US citizens. They want it fast and now! There is no other way. It has effected how we eat, think, commute, learn, and often make products (we really don't do that anymore). As a 50 year old composer, a guy that will take 3 months to write a saxophone concerto, I watch this whirlwind and frenzy every day- It is taking a toll on US citizens, the stress level is bizarre. It is incredible to watch these poor souls demanding more and more from each other, faster and faster, stronger and stronger... to finally get... somewhere? Eventually my grand children will look back on this era as truly infantile. I know that is such a harsh word, but that is how monopolies want their customers-- infantile and dependent for everything. Craig Bakalian ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Quit [now definitely O/T]
Hi Craig (et al.), I must say that the faster thing is a typical United States behavior. Whether or not it started in the USA, it's a worldwide phenomenon now. =) [Disclosure: I'm Canadian.] Our markets and media constantly barrage us with time issues. I think maybe convenience is a better word to describe what our culture really [apparently] prizes, since convenient implies both faster (time) and easier (effort) — and, usually, cheaper (cost), at least in the short term. I'm constantly fascinated by the fact that people will pay more for lower quality (e.g., cellular phones ALWAYS sound worse and cut out more often than land lines, yet cost far more to own/operate). Furthermore, our culture now prizes digital downloads (regardless of price) despite the obvious drop in aural/visual quality. [I still buy all my music on CD, and all my movies on DVD.] It has effected how we eat, think, commute Ironically, most people have MUCH longer (and slower) commutes now than they did years ago — my commute, fortunately, is only about 10 seconds from breakfast room to composition studio. ;) As a 50 year old composer, a guy that will take 3 months to write a saxophone concerto Good for you! Although I do [out of necessity] compose quickly from time to time (e.g., my writing partner and I completed our last musical in about 2.5 weeks), the really good stuff takes time, space, and focus. Cheers, Kieren. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: quit
On Tue, Nov 10, 2009 at 9:01 PM, Erik Appeldoorn ursus.k...@ziggo.nl wrote: [...] On the plus I found, good looking scores, very flexible On the minus I found, very tedious, time-consuming and heavily relying on work-arounds. Hope this will give some inside. I won't say I'll never try again, but not just now. Hou je goed / Keep well, Erik This is some good criticism. The cons you mention are, however, what makes Lilypond able to produce truly good-looking scores, which is -as you say- a plus. I would add that your challenge is a tough one: to write complex, non-standard scores. I remember you asking something regarding ties between different voices, for example, and those are difficult to express in text, but really easy to express using a GUI (press some 'tie' button, click one head, click another head, done.) So yes, in your particular case, doing that in a good editor like Sibelius should be easier. (But I'm _sure_ Lilypond produces a better looking score!) Anyways, I hope you manage to get around. Sibelius _is_ a great piece of software, no point on negating that. But, in my case, I write scores just for the fun of it, so I cannot spend US$600 just upload free things to the series of tubes... Regards, -- Leonardo Herrera mailto:leonardo.herr...@gmail.com http://leus.epublish.cl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Quit [now definitely O/T]
Kieren MacMillan kieren_macmil...@sympatico.ca writes: Hi Craig (et al.), I must say that the faster thing is a typical United States behavior. Whether or not it started in the USA, it's a worldwide phenomenon now. =) [Disclosure: I'm Canadian.] It is too cheap to put this down to faster. The problem is not that you need longer to do some things with Lilypond initially. The problem is that there is a large number of things for which there is no proper way to do them at all, and you have to take out the crowbar. Lilypond is supposed to be a music typesetter. Music in, glyph placement out. If I have to do the typesetting myself, placing glyphs rather than specifying musical content, Lilypond is not doing its job. And some Scheme/C++/whatever hackery for manually placing some glyphs one by one sure as heck is less convenient than just point and click. The documentation for extending Lilypond is not working out well: the automatically generated lilypond-internals contains no useful examples or explanations, the concepts for the C++, Scheme and Lilypond data structures that one needs for internal programming are not explained anywhere visibly, it is not clear what one can or cannot hope to do in what layer and with what level of expertise. lilypond-extending does not contain examples for the various layers. There are no examples for how to work in Midi functionality. As a side-effect of taking out the crowbar and doing visual arrangement of music content manually, of course the Midi output does not get any relevant info. Things like ritardando can't be found in the notation index and are programmed something like Some performance indications, e.g., rallentando or accelerando, are written as text and are extended over multiple notes with dotted lines. Such objects, called spanners, may be created from one note to another using the following syntax: \override TextSpanner #'(bound-details left text) = rit. b1\startTextSpan e,\stopTextSpan inline: lily-e4038aeb.png Not only does it appear ridiculous to have to use a TextSpanner override before even starting the relevant note just to specify the text (rather than have \startTextSpan take an argument), naturally nothing will appear in the Midi output. There is a lot of things that you can do with Lilypond, but it is important that Lilypond gets to do more things all by itself (and the vocabulary to tell it what happens _musically_ so that it will produce PDF and Midi without further intervention). If the input for a facsimile of some historical score is basically indistinguishable from a modern score input (just differing by how one does everything manually), something is wrong. It does not even matter if Lilypond's first implementation/iteration at doing something sucks: once I can _express_ my musical intent to Lilypond, future improvements of Lilypond will lead to better output. But if I can only express a glyph arrangement, improvement is off the chart. The mailing list is somewhat helpful, but many of the answers are in the line of you can trick Lilypond into showing this/you can hack the output to be like this rather than Lilypond's language for this musical construct would be. And that makes you continue your dependence on others' manual help. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Quit [now definitely O/T]
Hi David, It is too cheap to put this down to faster. The problem is not that you need longer to do some things with Lilypond initially. The problem is that there is a large number of things for which there is no proper way to do them at all, and you have to take out the crowbar. As is also true with Finale/Sibelius/etc. — for example, try doing http://lsr.dsi.unimi.it/LSR/Item?id=506 and its opposite (i.e., barline-synced version) in a single score in Fin/Sib. ;) The documentation for extending Lilypond is not working out well Any chance you can/will improve it? lilypond-extending does not contain examples for the various layers. There are no examples for how to work in Midi functionality. Since I don't [yet] make any use of MIDI, this doesn't really matter to me — if it matters to you or others, by all means make it better! Things like ritardando can't be found in the notation index Patch? Not only does it appear ridiculous to have to use a TextSpanner override before even starting the relevant note just to specify the text (rather than have \startTextSpan take an argument), naturally nothing will appear in the Midi output. 1. Define a music function to do this. 2. Submit a patch. it is important that Lilypond gets to do more things all by itself I couldn't agree more! [See Steps 12, above.] The mailing list is somewhat helpful, but many of the answers are in the line of you can trick Lilypond into showing this/you can hack the output to be like this rather than Lilypond's language for this musical construct would be. Can you give an actual example from the archives? i.e., link to a message where the answer wasn't what you needed/ wanted, and rewrite the answer so that it is Thanks, Kieren. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Quit [now definitely O/T]
I don't see the now definitely O/T you put in the subject line. The subject was that somebody quit, and we are talking about the reasons. Kieren MacMillan kieren_macmil...@sympatico.ca writes: It is too cheap to put this down to faster. The problem is not that you need longer to do some things with Lilypond initially. The problem is that there is a large number of things for which there is no proper way to do them at all, and you have to take out the crowbar. As is also true with Finale/Sibelius/etc. If I have to wield a crowbar rather than _saying_ what I want, I prefer at least seeing where I hit. WYSIWYG. [...] Any chance you can/will improve it? [...] if it matters to you or others, by all means make it better! [...] Patch? [...] 1. Define a music function to do this. 2. Submit a patch. [...] I couldn't agree more! [See Steps 12, above.] I think that sums up very well why somebody would prefer not working with Lilypond. Not only do you have to rely on expert advice, but the main advice is please do what an expert would do, or shut up. If there is no reasonable way to become an expert, this is equivalent to Lilypond is not for you. Go away. Which is what the original poster did. Now I am in the situation of being an expert _programmer_. If you had actually bothered taking a look at recent postings of mine, you would have noticed that I am trying to get some functionality into Lilypond. There is little enough useful information to go by, there is very little advice on the list (Carl was the only one to give any pointers to repetitive requests for advice or reviews), there is no big picture you get for how to work which functionality in where. The problem is that this state does not just turn away prospective users, it also turns away prospective _programmers_ who could help moving Lilypond further on its roadmap, according to its design and vision. But if there is roadmap, design and vision, I have not yet been able to find it in the obvious places I have been looking for. And that means that not only do I have to do all the coding for my task, I also have to invent interfaces which may be completely inconsistent with what other people with special instruments do. And I don't _want_ to have my code just remain in the state of some ad-hoc snippet. I want it to become part of Lilypond proper. For me, this situation is awkward, impeding and dissatisfactory. For others, it is reason to go away. I don't see that anything is gained for chastising me for my impression. That is merely shooting the messenger. Actually, more than the messenger. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Quit [now definitely O/T]
Kieren MacMillan kieren_macmil...@sympatico.ca writes: [...] I don't see the now definitely O/T you put in the subject line. The subject was that somebody quit, and we are talking about the reasons. [...] It is too cheap to put this down to faster. The problem is not that you need longer to do some things with Lilypond initially. The problem is that there is a large number of things for which there is no proper way to do them at all, and you have to take out the crowbar. As is also true with Finale/Sibelius/etc. If I have to wield a crowbar rather than _saying_ what I want, I prefer at least seeing where I hit. WYSIWYG. [...] Any chance you can/will improve it? [...] if it matters to you or others, by all means make it better! [...] Patch? [...] 1. Define a music function to do this. 2. Submit a patch. [...] I couldn't agree more! [See Steps 12, above.] I think that sums up very well why somebody would prefer not working with Lilypond. Not only do you have to rely on expert advice, but the main advice is please do what an expert would do, or shut up. If there is no reasonable way to become an expert, this is equivalent to Lilypond is not for you. Go away. Which is what the original poster did. Now I am in the situation of being an expert _programmer_. If you had actually bothered taking a look at recent postings of mine on the developer list, you would have noticed that I am trying to get some functionality into Lilypond. There is little enough useful information to go by, there is very little advice on the list (Carl was the only one to give any pointers given repetitive requests for advice or reviews), there is no big picture you get for how to work which functionality in where. The problem is that this state does not just turn away prospective users, it also turns away prospective _programmers_ who could help moving Lilypond further on its roadmap, according to its design and vision. But if there is roadmap, design and vision, I have not yet been able to find it in the obvious places I have been looking for. And that means that not only do I have to do all the coding for my task, I also have to invent interfaces which may be completely inconsistent with what other people with special instruments do. And I don't _want_ to have my code just remain in the state of some ad-hoc snippet. I want it to become part of Lilypond proper so that the next person will not have to start at the same point again. For me, this situation is awkward, impeding and dissatisfactory. For others, it is reason to go away. I don't see that anything is gained for chastising me for my impression. That is merely shooting the messenger. Actually, more than the messenger. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Quit [now definitely O/T]
I'm not topposting Third attempt because of topposting automoderation -- this _is_ a nuisance. Kieren MacMillan kieren_macmil...@sympatico.ca writes: [...] I don't see the now definitely O/T you put in the subject line. The subject was that somebody quit, and we are talking about the reasons. [...] It is too cheap to put this down to faster. The problem is not that you need longer to do some things with Lilypond initially. The problem is that there is a large number of things for which there is no proper way to do them at all, and you have to take out the crowbar. As is also true with Finale/Sibelius/etc. If I have to wield a crowbar rather than _saying_ what I want, I prefer at least seeing where I hit. WYSIWYG. [...] Any chance you can/will improve it? [...] if it matters to you or others, by all means make it better! [...] Patch? [...] 1. Define a music function to do this. 2. Submit a patch. [...] I couldn't agree more! [See Steps 12, above.] I think that sums up very well why somebody would prefer not working with Lilypond. Not only do you have to rely on expert advice, but the main advice is please do what an expert would do, or shut up. If there is no reasonable way to become an expert, this is equivalent to Lilypond is not for you. Go away. Which is what the original poster did. Now I am in the situation of being an expert _programmer_. If you had actually bothered taking a look at recent postings of mine on the developer list, you would have noticed that I am trying to get some functionality into Lilypond. There is little enough useful information to go by, there is very little advice on the list (Carl was the only one to give any pointers given repetitive requests for advice or reviews), there is no big picture you get for how to work which functionality in where. The problem is that this state does not just turn away prospective users, it also turns away prospective _programmers_ who could help moving Lilypond further on its roadmap, according to its design and vision. But if there is roadmap, design and vision, I have not yet been able to find it in the obvious places I have been looking for. And that means that not only do I have to do all the coding for my task, I also have to invent interfaces which may be completely inconsistent with what other people with special instruments do. And I don't _want_ to have my code just remain in the state of some ad-hoc snippet. I want it to become part of Lilypond proper so that the next person will not have to start at the same point again. For me, this situation is awkward, impeding and dissatisfactory. For others, it is reason to go away. I don't see that anything is gained for chastising me for my impression. That is merely shooting the messenger. Actually, more than the messenger. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Quit [now definitely O/T]
Hi David, I think that sums up very well why somebody would prefer not working with Lilypond. Not only do you have to rely on expert advice, but the main advice is please do what an expert would do, or shut up. Please show me where I said anything resembling shut up...? I'm sorry if you inferred something like that, but I certainly neither meant it nor [in my opinion] implied it — and I *certainly* didn't explicitly type anything of the sort. If there is no reasonable way to become an expert As we both (all) know, there IS a reasonable way to become an expert at Lilypond — it just may take more effort than with a point- and-click interface like Fin/Sib, and that (unfortunately) may be too much to ask of many people/users. Naturally, I wish that the barrier-to-entry were lower. And, like others, I am making material efforts to lower that barrier all the time. Now I am in the situation of being an expert _programmer_. If you had actually bothered taking a look at recent postings of mine, you would have noticed that I am trying to get some functionality into Lilypond. I *have* actually bothered taking a look at recent postings of yours — in fact, I thoroughly read almost every post on this list. Hence, I had noticed that you are contributing, and was therefore wondering aloud if you would be adding more functionality to solve the problem(s) you were highlighting — specifically, I wondered if you were able [technically] to do so, and might be doing so in the near future: “Any chance you can/will improve it?” if there is roadmap, design and vision, I have not yet been able to find it in the obvious places I have been looking for. Then I think that needs to be fixed — suggestions on where in the documentation this roadmap/design/vision should be? I don't see that anything is gained for chastising me for my impression. Once again, I ask you to please point out exactly (with quotations) where I “chastised” you... since I clearly didn't intend to, I want to know how to avoid having my intentions misinterpreted in the future. Cheers, Kieren. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Quit [now definitely O/T]
Sorry for the post in triplicate. Gmane's response time confused me. Kieren MacMillan kieren_macmil...@sympatico.ca writes: Hi David, I think that sums up very well why somebody would prefer not working with Lilypond. Not only do you have to rely on expert advice, but the main advice is please do what an expert would do, or shut up. Please show me where I said anything resembling shut up...? Well, I omitted the other option or whine on. My fault. More pointedly: for every question I asked, you basically replied: could you please answer this question yourself and contribute the answer? And that, while a popular way to stifle contributions, is not a reasonable expectation. The first stumbling steps don't teach you what the best way to walk is, and how to teach others to walk. If there is no reasonable way to become an expert As we both (all) know, there IS a reasonable way to become an expert at Lilypond No. A _reasonable_ way to become an expert is by reading into increasingly more expert-level documentation and working with it. Humanly possible is not the same as reasonable. Reasonable entails a collective effort not to repeat avoidable work and frustration. Now I am in the situation of being an expert _programmer_. If you had actually bothered taking a look at recent postings of mine, you would have noticed that I am trying to get some functionality into Lilypond. I *have* actually bothered taking a look at recent postings of yours — in fact, I thoroughly read almost every post on this list. Hence, I had noticed that you are contributing, and was therefore wondering aloud if you would be adding more functionality to solve the problem(s) you were highlighting — specifically, I wondered if you were able [technically] to do so, I am able to create functionality. I am not able to guess what the Lilypond way of adding this functionality would be. I don't like doing work that does not benefit others. I don't like incoherent interfaces and bad code. I don't see how I can avoid doing those. I am not interested into prodding Lilypond to accidentally produce output that matches what I need. I want Lilypond to understand straightforward instructions in its Lilypond way to get the output I want. For that I need to understand the Lilypond way of doing this, and the available information is not sufficient. Please create this information does not make sense, since there presumably _is_ something like coding style or idea behind Lilypond, and guessing from code is unreliable. and might be doing so in the near future: “Any chance you can/will improve it?” I can't improve what I can't see or understand. if there is roadmap, design and vision, I have not yet been able to find it in the obvious places I have been looking for. Then I think that needs to be fixed — suggestions on where in the documentation this roadmap/design/vision should be? The internals documentation should likely spell out the layers of C++, Scheme, Music macros and what one can hope to reasonably implement in what layer. What new functionality requires equivalence of new engravers or performers, can one implement them in Scheme, does one need C++, and what exactly does one _do_ when creating them? The extending documentation should point people to what kind of stuff they need to consider for adding things like chords, lyrics, general bass, tabs and so on themselves: what layers need to be meddling with for what task, what will work only with recompilation, what might work with Scheme code. Give a sketch of the layout of some existing functionality in Lilypond, and what one would need to add it if it did not exist. I don't see that anything is gained for chastising me for my impression. Once again, I ask you to please point out exactly (with quotations) where I “chastised” you... since I clearly didn't intend to, I want to know how to avoid having my intentions misinterpreted in the future. If a posting does not contain anything except please contribute this yourself, it is not likely to cause anything but annoyance. The topic was why people find Lilypond too cumbersome to use. I gave reasons, and the reaction please change it yourself is not addressing the topic at all. It also delivers the impression that the current state is basically my fault and responsibility, and nothing needs to be done about it that I don't do myself. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Quit [now definitely O/T]
On Wed, Nov 11, 2009 at 06:11:26PM +0100, David Kastrup wrote: Kieren MacMillan kieren_macmil...@sympatico.ca writes: I couldn't agree more! [See Steps 12, above.] I think that sums up very well why somebody would prefer not working with Lilypond. Not only do you have to rely on expert advice, but the main advice is please do what an expert would do, or shut up. That's not quite it -- we're saying lilypond is open source; please help. With varying degrees of politeness, depending on how polite the original complaint was. What else *can* we say? We don't have the amount of developers that people think we have. For most issues, all we can do is add it to the tracker and hope that somebody works on it sometime. I know that's not a very encouraging answer, but it's the only honest one I can give. Now I am in the situation of being an expert _programmer_. If you had actually bothered taking a look at recent postings of mine, you would have noticed that I am trying to get some functionality into Lilypond. There is little enough useful information to go by, there is very little advice on the list (Carl was the only one to give any pointers to repetitive requests for advice or reviews), there is no big picture you get for how to work which functionality in where. Carl is in charge of the Frogs, which is the developer training / mentoring project. Of course he should answer. Would it be nice if more in-training developers joined the discussion? Well, yes. But they probably feel shy because they aren't really certain about the topic at hand. *shrug* again, what else can we do? Unless we kidnap Han-Wen and force him to answer questions at gunpoint -- which, quite apart from the legal and ethical considerations, is just plain *rude*[1] -- there is *nothing* else we can do. [1] can you tell I'm a Canadian? :) But if there is roadmap, design and vision, I have not yet been able to find it in the obvious places I have been looking for. The information for developers is the CG. I have a rough roadmap and vision in my head (assuming those terms mean plan for the future), but completely lack the developers to implement it. So there's no point writing it down. As for the CG... would you prefer it if Carl stopped answering your emails, and wrote stuff for the CG instead? Would you prefer it if we kidnapped Carl, strapped him to a wooden board, and whipped him until he wrote more CG *and* still answered emails? We can't demand any more work than what people are willing to do. I think we should *thank* the past/present developers for the work they did/are doing, not demand that they work more. I've done everything I can to create the organizational infrastructure. We have the Extending manual for how to program lilypond. We have the CG for how to interact with git + the developer community. We have the Frogs to train a new generation of developers. Are any of those items as complete, or working as well, as I had hoped? No. But what else can I do? I really can't think of _anything_ else. Other than kidnap + torture, of course. I might vote for this, but it strikes me that it might cause long-term problems... I mean, who'd want to become a lilypond developer if they knew that _they_ might be subjected to waterboarding in 5-10 years? - Graham ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Quit [now definitely O/T]
On Wed, Nov 11, 2009 at 07:12:44PM +, Graham Percival wrote: Other than kidnap + torture, of course. I might vote for this, but it strikes me that it might cause long-term problems... Addendum: I don't know the details that you want, so torturing me won't help. I'd *like* to know those details. I'd *like* to be working on the collisions, defects, and making a dent in the 300+ known issues. But recently I've been spending all my time on the basic infrastructure (like GUB). Why do I think I'm so shrill about finding people to do grunt work on the new website? Because we don't need me to edit bloody .texi files. People in GDP did that after 1 hour of reading the CG. If we had more people taking over the mundane easy jobs, that would give me more time to investigate the medium iffy jobs. And after a few weeks of those mundane easy jobs, the helpers could tackle the medium iffy jobs, and I could do the horrendously complicated jobs. I would *love* to do things like making lilypond take advantage of multiple CPUs! Or, you know, I could keep on plugging away at the easy jobs, and everything else can be dumped in the issue tracker to be ignored for years. - Graham ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Quit [now definitely O/T]
Hi David, [By the way, since it's apparently open season on posting style criticism: your consistent lack of salutation and valediction in your posts makes you seem rude, curt, and above all patronizing.] Reasonable entails a collective effort not to repeat avoidable work and frustration. e.g., the GDP and the 000s of hours Graham P personally has put in to improving the docs...? presumably _is_ something like coding style c.f. http://lilypond.org/doc/v2.13/Documentation/contributor/Code- style#Code-style What needs to be added/improved? Once again, I'm sincerely asking, since you obviously still have questions about Lilypond coding style that weren't answered by that page (and surrounding ones). or idea behind Lilypond c.f. http://lilypond.org/doc/v2.13/Documentation/contributor/Overview- of-LilyPond-architecture#Overview-of-LilyPond-architecture http://lilypond.org/web/images/thesis-erik-sandberg.pdf Same question as above. The internals documentation should likely spell out the layers of C+ +, Scheme, Music macros and what one can hope to reasonably implement in what layer. What new functionality requires equivalence of new engravers or performers, can one implement them in Scheme, does one need C++, and what exactly does one _do_ when creating them? The introductory page http://lilypond.org/doc/v2.13/Documentation/contributor/Overview- of-LilyPond-architecture#Overview-of-LilyPond-architecture does spell this out, I believe. Cheers, Kieren. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Quit [now definitely O/T]
Graham Percival gra...@percival-music.ca writes: On Wed, Nov 11, 2009 at 06:11:26PM +0100, David Kastrup wrote: But if there is roadmap, design and vision, I have not yet been able to find it in the obvious places I have been looking for. The information for developers is the CG. The manuals don't tell anything about CG, where it is, what it does. URL:http://lilypond.org/web/devel/participating/ does not tell. There is no directory of that name in the distribution. I have a rough roadmap and vision in my head (assuming those terms mean plan for the future), but completely lack the developers to implement it. So there's no point writing it down. Wrong, because it means that nobody can work in the right direction even if he wanted to. If you write at one point of time, we want the following code to work:, that gives people a goal to work towards. Beginning contributors can massage code until it achieves a certain thing. But they can't figure out what is a good idea and what not, and what fits into the general scheme of Lilypond, and what not. You waste the low-level contributors in that manner, adding to your resource shortage. As for the CG... would you prefer it if Carl stopped answering your emails, and wrote stuff for the CG instead? Would you prefer it if we kidnapped Carl, strapped him to a wooden board, and whipped him until he wrote more CG *and* still answered emails? I can make no educated guess, since I don't know what the CG is. It is likely that I should be called names for that, but I don't see any obvious source of information explaining it. Not the general manuals, not the web page, not in the FAQ, not in the learning manual, not even in the Wiki AFAICS. We can't demand any more work than what people are willing to do. I think we should *thank* the past/present developers for the work they did/are doing, not demand that they work more. Tell that to Killian. I've done everything I can to create the organizational infrastructure. We have the Extending manual for how to program lilypond. We have the CG for how to interact with git + the developer community. We have the Frogs to train a new generation of developers. Where or what is the CG? Where do the Frogs train their new generation of developers? Why aren't they mentioned on URL:http://lilypond.org/web/devel/participating/? Other than kidnap + torture, of course. I might vote for this, but it strikes me that it might cause long-term problems... I mean, who'd want to become a lilypond developer if they knew that _they_ might be subjected to waterboarding in 5-10 years? My impression is that the waterboarding starts right away. Of course, the answers will not prove very high quality. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Quit [now definitely O/T]
Hi David (and anyone else who makes it here, wondering how to find the CG), The manuals don't tell anything about CG, where it is, what it does. URL:http://lilypond.org/web/devel/participating/ does not tell. There is no directory of that name in the distribution. Step 1: Go to home page. Location: http://lilypond.org Step 2: Click on Documentation. Location: http://lilypond.org/web/documentation Step 3: Click on Documentation for LilyPond 2.13 (latest development) [since you're going to be helping with development, this is the logical choice]. Location: http://lilypond.org/doc/v2.13/Documentation/ Step 4: Click on either Manuals or Community. Location: either http://lilypond.org/doc/v2.13/Documentation/ manuals#manuals or http://lilypond.org/doc/v2.13/Documentation/ community#community Step 5: Click on Development http://lilypond.org/doc/v2.13/Documentation/development#development Not the general manuals, not the web page, not in the FAQ, not in the learning manual, not even in the Wiki AFAICS. [...] Where or what is the CG? What else could have been done to make the CG more available/obvious? Regards, Kieren. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Quit [now definitely O/T]
On Wed, Nov 11, 2009 at 08:47:33PM +0100, David Kastrup wrote: Graham Percival gra...@percival-music.ca writes: The information for developers is the CG. The manuals don't tell anything about CG, where it is, what it does. URL:http://lilypond.org/web/devel/participating/ does not tell. There is no directory of that name in the distribution. In case you've been living under a rock, there's a new website that's almost ready. http://lilypond.org/doc/v2.13/Documentation/ in particular, see http://lilypond.org/doc/v2.13/Documentation/development would it be nice if this new website was _ready_, and not almost ready? Definitely. I have a rough roadmap and vision in my head (assuming those terms mean plan for the future), but completely lack the developers to implement it. So there's no point writing it down. Wrong, because it means that nobody can work in the right direction even if he wanted to. If you write at one point of time, we want the following code to work:, that gives people a goal to work towards. Ok. Start with no high-priority or regression-priority bugs. You waste the low-level contributors in that manner, adding to your resource shortage. The waste in my high-level contributions far outweighs the waste of low-level contributors. Where or what is the CG? Where do the Frogs train their new generation of developers? Why aren't they mentioned on URL:http://lilypond.org/web/devel/participating/? Again, new website. Yes, I'll fill in the help wanted section if and when the new website is almost ready. Since almost nothing has happened in the past two months, I'm not holding my breath. I've been working on getting development packages out there... including having it working on OSX 10.6. Is that more or less important than the new website? I don't know. I decided it was, but I really have no evidence to support my decision to abandon the website in favor of that work. *shrug* maybe that was a mistake. But it was _my_ mistake to make, since it was my time stake. (rhyme unintentional) - Graham ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Quit
Op woensdag 11-11-2009 om 20:08 uur [tijdzone +0100], schreef David Kastrup: As we both (all) know, there IS a reasonable way to become an expert at Lilypond No. A _reasonable_ way to become an expert is by reading into increasingly more expert-level documentation and working with it. Humanly possible is not the same as reasonable. Reasonable entails a collective effort not to repeat avoidable work and frustration. Being able to maintain this pov would be nice. However, how do you suggest we get there? It may well be that you are helping with the first steps right now: identification of the problem. The thing with open source/ LilyPond is: someone needs to follow up and do the work to get from Humanly possible to Reasonable. Until now, that has not been done yet. And my question would be: is it worth it? Several times we have seen people sending perfect patches or code right out of the blue, without asking any questions. Simon Tatham with his Gonville font being the latest instance I remember. This falls in the category of Humanly possible. Possibly harsh and not enough for some potential contributors. The good thing is: it did not cost us any resources. Also seen several times are people sending /lots/ of questions, be it users or developers, and after everything has been answered, the user quits or potential developers says she has no time or does not thing she is up for it after all. While I do not have a final verdict on this, it seems safe to spend most of our development efforts on developing. You need to be pretty good to add something to LilyPond and I doubt if developer documentation/hand-holding is going to make that any easier. I can't improve what I can't see or understand. Can you change what you see and then look what happened? The topic was why people find Lilypond too cumbersome to use. I gave reasons, and the reaction please change it yourself is not addressing the topic at all. It also delivers the impression that the current state is basically my fault and responsibility, and nothing needs to be done about it that I don't do myself. Apparently, making this Reasonable is something you consider to be important. The thing to do here would be to pick up that task -- if it's important enough for you. It is next to impossible to get people to do what you want by merely stating that it is important. Several months ago I tried to coax people to help with the website and look into SEO [Do we have the best search terms that will bring new users/developers in?]. I argued that most of our potential users/developers by far (99%) never heard of LilyPond yet and I figured that good findability/visibility and attractiveness of the website were probably of utmost importance. Well, have you read some of Graham's cries for help? Noone cares. Greetings, Jan. -- Jan Nieuwenhuizen jann...@gnu.org | GNU LilyPond - The music typesetter Avatar®: http://AvatarAcademy.nl| http://lilypond.org ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Quit [now definitely O/T]
On Wed, Nov 11, 2009 at 03:01:33PM -0500, Kieren MacMillan wrote: Step 3: Click on Documentation for LilyPond 2.13 (latest development) [since you're going to be helping with development, this is the logical choice]. Location: http://lilypond.org/doc/v2.13/Documentation/ Not the general manuals, not the web page, not in the FAQ, not in the learning manual, not even in the Wiki AFAICS. [...] Where or what is the CG? What else could have been done to make the CG more available/obvious? In David's defense (not that I _want_ to be doing this), the more available/obvious choice would be to make the new website the main one. Currently, that's waiting on: - 2-5 hours of texinfo file editing. - 5-15 hours of technical build system + server work - *maybe* a few weeks of time for the translators to catch up, although at the moment I'm not feeling patient. I'm not asking anybody else to touch the build system or the web server. But I'm not going to make those a priority until the .texi file editing is done. Cheers, - Graham ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Quit [now definitely O/T]
On Wed, Nov 11, 2009 at 2:01 PM, Kieren MacMillan kieren_macmil...@sympatico.ca wrote: Hi David (and anyone else who makes it here, wondering how to find the CG), The manuals don't tell anything about CG, where it is, what it does. URL:http://lilypond.org/web/devel/participating/ does not tell. There is no directory of that name in the distribution. Hi all, At the risk of stating the obvious (to long-time lilypond contributors anyway), CG stands for Contributor's Guide. Jon p.s. to Graham and anyone else who was wondering: my wrists still aren't really better after months. I'm going to a specialist next week. I hope to be a productive LP community member again one day... -- Jonathan Kulp http://www.jonathankulp.com ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Quit [now definitely O/T]
Hi Graham, the more available/obvious choice would be to make the new website the main one. Currently, that's waiting on: - 2-5 hours of texinfo file editing I just pulled a new origin/master from git. Today, I've got upwards of 3 hours to code: what do you want me to work on? Cheers, Kieren. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Quit [now definitely O/T]
Kieren MacMillan kieren_macmil...@sympatico.ca writes: Hi David, [By the way, since it's apparently open season on posting style criticism: your consistent lack of salutation and valediction in your posts makes you seem rude, curt, and above all patronizing.] Perfectly accurate. Reasonable entails a collective effort not to repeat avoidable work and frustration. e.g., the GDP and the 000s of hours Graham P personally has put in to improving the docs...? Where does the GDP document the meaning of the acronym GDP? presumably _is_ something like coding style c.f. http://lilypond.org/doc/v2.13/Documentation/contributor/Code-style#Code-style What needs to be added/improved? Once again, I'm sincerely asking, since you obviously still have questions about Lilypond coding style that weren't answered by that page (and surrounding ones). Uh, have you read it? It worries about things like indentation, says to prefer C++ over Python (but Python please in PEP 8 whatever that fancy acronym is supposed to be), and some identifier names. It does not say what kind of code to put where for what reason. That is: it tells you minor details about how source should be formatted once you know perfectly what you are doing and which part of the code is appropriate to use. Namely it tells you about the difference between something that compiles and fits in with the rest of the _code_. It does not tell you what language/classes/operations to use to implement what kind of task. or idea behind Lilypond c.f. http://lilypond.org/doc/v2.13/Documentation/contributor/Overview-of-LilyPond-architecture#Overview-of-LilyPond-architecture I have found the contributor's guide by now (not mentioned in the web resources AFAICS). It gives some sort of outline, but lacks examples that walk the prospective programmer through the skeleton of what he needs to do. http://lilypond.org/web/images/thesis-erik-sandberg.pdf Same question as above. The thesis is a thesis. It is unclear what state of Lilypond it documents, and what the current state of Lilypond embeds from what is in the thesis. And some thesis on the web is not a good substitute for programming docs. Because it does not evolve with the program. The internals documentation should likely spell out the layers of C+ +, Scheme, Music macros and what one can hope to reasonably implement in what layer. What new functionality requires equivalence of new engravers or performers, can one implement them in Scheme, does one need C++, and what exactly does one _do_ when creating them? The introductory page http://lilypond.org/doc/v2.13/Documentation/contributor/Overview-of-LilyPond-architecture#Overview-of-LilyPond-architecture does spell this out, I believe. I don't see this. Mostly, it points to sources for reference. That's useful to some degree. But if people write sources with only sources for reference, any design inherent in the first generation of the sources is going to become less and less discernible with successive layers of code. More educational than studying how existing code is written would be to study how the code is _supposed_ to be written. Some self-contained example with well-defined functionality that sits well in the scheme of things. If people can't make their own code as simple and self-contained (or see existing real code much uglier), that is an incentive for improving the state of their and preexisting real code. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Quit [now definitely O/T]
On 11/11/09 12:12 PM, Graham Percival gra...@percival-music.ca wrote: On Wed, Nov 11, 2009 at 06:11:26PM +0100, David Kastrup wrote: But if there is roadmap, design and vision, I have not yet been able to find it in the obvious places I have been looking for. The information for developers is the CG. I have a rough roadmap and vision in my head (assuming those terms mean plan for the future), but completely lack the developers to implement it. So there's no point writing it down. OOPS -- Graham, you forgot that we agreed that we wouldn't use abbreviations on -user. David, CG is the Contributors' Guide, and it's part of the 2.13 docs. It tries to get at the issues you're concerned about. Thanks, Carl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Quit
Jan Nieuwenhuizen janneke-l...@xs4all.nl writes: Also seen several times are people sending /lots/ of questions, be it users or developers, and after everything has been answered, the user quits or potential developers says she has no time or does not thing she is up for it after all. If the gist of the relevant answers are placed in the docs rather than put to rot in the list archives, the effort has not been wasted. If another one independently decides to pick up the lost ball at a later point of time, he does not need to start from scratch. While I do not have a final verdict on this, it seems safe to spend most of our development efforts on developing. There is a limit to how much development each of us can do. There is no limit to how many persons we can be. You need to be pretty good to add something to LilyPond and I doubt if developer documentation/hand-holding is going to make that any easier. It is less distracting to other developers if the likes of me don't blow their top every minute. Apparently, making this Reasonable is something you consider to be important. The thing to do here would be to pick up that task -- if it's important enough for you. It is next to impossible to get people to do what you want by merely stating that it is important. I can't that task before having a clue. I can coax code to do what I want it to do eventually. But I can't coax code into doing things like they were _intended_ to be done. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Quit [now definitely O/T]
On Wed, Nov 11, 2009 at 03:19:37PM -0500, Kieren MacMillan wrote: Hi Graham, - 2-5 hours of texinfo file editing I just pulled a new origin/master from git. Today, I've got upwards of 3 hours to code: what do you want me to work on? The first thing that comes to mind is Alternate input. Documentation/general/introduction.texi @node Alternate input I'm thinking of having 4 main boxes at the top: - denemo - lilypondtool - frescobaldi - emacs+vim then one box with all the others. Probably with only a 1 or 2-sentence descrition, and no pictures. Alternately, maybe have two other boxes: 1 for moderately recommended (i.e. a list, but still pictures), and another for not really recommended (i.e. a list with no pictures). Pictures and descriptions from the project websites are ok as far as I'm concerned. I suppose that *technically* even a one-sentence project description is still under copyright, so *technically* you shoudl ask the project if you can use it. But I think that's getting ridiculous. Pictures (screenshots or not) go in Documentation/pictures/. You'll need to delete the out/ and/or out-www/ in that dir and do another make doc to regenerate them; a simple make doc again won't regenerate those new images. (another joyous build system issue) Now for the disclaimers: - if you're willing to be responsible for this page, then feel free to toss out anything in the above description (other than the technical build system stuff). Organize the page however you maoing feel like it. - as far as I'm concerned, do the minimum amount -- just format the bottom list(s) nicely. Don't bother looking up project webpages to see if Denemo supports windows or anything lile that; if we get stuff wrong, somebody will complain eventually. As a disclaimer to the second disclaimer, somebody posted on bug-lilypond earlier today with a bunch of info that this page could contain, including news that denemo works on windows. So it might be polite to fix that thing, at least... but I maintain that it's probably not worth researching any editor. More generally, find any @help in the new website. They're really ugly flsahing green and red. Somebody already offered to look at the Features page, although having more people looking at it can't be bad. One or two of the @help are directed at build system people (which seems to be me now). But most of them can be done -- at leats, done in a quick band-aid manner -- by just editing the .texi files. Cheers, - Graham ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Quit [now definitely O/T]
Hi David, Where does the GDP document the meaning of the acronym GDP? Here's one place (of many): http://lilypond.org/web/devel/participating/documentation-adding It does not say what kind of code to put where for what reason. http://lilypond.org/doc/v2.13/Documentation/contributor/LilyPond- programming-languages#LilyPond-programming-languages Programming in LilyPond is done in a variety of programming languages. Each language is used for a specific purpose or purposes. This section describes the languages used and provides links to reference manuals and tutorials for the relevant language. […] The core functionality of LilyPond is implemented in C++. The C++ code calls Scheme/GUILE through the GUILE interface […] The LilyPond parser is implemented in Bison, a GNU parser generator. […] GUILE is the dialect of Scheme that is used as LilyPond’s extension language. Many extensions to LilyPond are written entirely in GUILE. etc. It does not tell you what language/classes/operations to use to implement what kind of task. OK, then submit a feature request — rant on -user does not count — and maybe someone in the know will help out. I wish I could help out, but I don't know enough about Lilypond to write (or even start writing) such a page. Good luck, Kieren. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Quit [now definitely O/T]
Jonathan Kulp jonlancek...@gmail.com writes: On Wed, Nov 11, 2009 at 2:01 PM, Kieren MacMillan kieren_macmil...@sympatico.ca wrote: Hi David (and anyone else who makes it here, wondering how to find the CG), The manuals don't tell anything about CG, where it is, what it does. URL:http://lilypond.org/web/devel/participating/ does not tell. There is no directory of that name in the distribution. At the risk of stating the obvious (to long-time lilypond contributors anyway), CG stands for Contributor's Guide. I wish more people would take that kind of risk, never mind how much of a spoilsport that may make them. I plead guilty to having noticed the contributor's guide rather late into my rants. But it does not particularly help that the mailing list conversations avoid pronouncing its full name like it were Youknowwho. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Quit [now definitely O/T]
On Wed, Nov 11, 2009 at 03:53:11PM -0500, Kieren MacMillan wrote: It does not tell you what language/classes/operations to use to implement what kind of task. OK, then submit a feature request — rant on -user does not count — and maybe someone in the know will help out. No, please don't. We really don't need issues in the tracker like improve the learning manual, improve the extending manual. We know that documentation is a never-ending job. We especially know that the advanced docs are weak. Fun fact: right now, 14 months after the Grand Documentation Project (wherein over 20 people worked on the docs), we have 0 people working on the documentation. Many people have good reasons for their absence (serious medical issues, dead computers -- yes, multiple ones!, running the Frogs, etc). But that doesn't change the sadness of 0 documentation writers. Cheers, - Graham ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Quit
On Wed, Nov 11, 2009 at 09:49:28PM +0100, David Kastrup wrote: Jan Nieuwenhuizen janneke-l...@xs4all.nl writes: Also seen several times are people sending /lots/ of questions, be it users or developers, and after everything has been answered, the user quits or potential developers says she has no time or does not thing she is up for it after all. If the gist of the relevant answers are placed in the docs rather than put to rot in the list archives, the effort has not been wasted. Given that we have 0 people working on the docs, I doubt that the relevant answers are making their way into the docs. While I do not have a final verdict on this, it seems safe to spend most of our development efforts on developing. There is a limit to how much development each of us can do. There is no limit to how many persons we can be. I entirely agree... but how many new persons have we had recently? Let me put it another way: if *you're* not willing to step forward and work out the baby steps towards being a fully-fledged developer (and ideally write docs to help the next people interested), then who else is going to do it? Ok, maybe your desired task is too difficult... so pick a different bug/feature to fix/implement, spend a few weeks learning how to fix it, then submit docs to help other people reach that level. If you spend a month or two doing that, it would definitely help the next person. Then you could take a break for a month, and that person could go through the frustration of figuring things out, and hopefully write docs about the next stage. Then maybe a third person could learn from the docs that you both wrote, and go even further. Or, you know, we could just totally waste this discussion and whine about the current state of affairs without doing anything to fix it. - Graham ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Quit [now definitely O/T]
Graham, The first thing that comes to mind is Alternate input. Documentation/general/introduction.texi @node Alternate input I have to mao-ing learn TEXI now? So much for your 2-5 hours estimate... Still-doing-it-but-thinking-there's-almost-definitely-a-better-way, Kieren. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Quit [now definitely O/T]
David,
Thanks for your willingness to articulate some concerns. I think that your
careful thinking can be of real help to the LilyPond community, expecially
if you can help us make things better.
On 11/11/09 7:21 AM, David Kastrup d...@gnu.org wrote:
Kieren MacMillan kieren_macmil...@sympatico.ca writes:
Hi Craig (et al.),
I must say that the faster thing is a typical United States
behavior.
Whether or not it started in the USA, it's a worldwide phenomenon now.
=)
[Disclosure: I'm Canadian.]
It is too cheap to put this down to faster. The problem is not that
you need longer to do some things with Lilypond initially. The problem
is that there is a large number of things for which there is no proper
way to do them at all, and you have to take out the crowbar.
Lilypond is supposed to be a music typesetter. Music in, glyph
placement out. If I have to do the typesetting myself, placing glyphs
rather than specifying musical content, Lilypond is not doing its job.
This is absolutely true. The objective *is* to make the music entirely
tweak-free. Unfortunately, we are not there yet.
And some Scheme/C++/whatever hackery for manually placing some glyphs
one by one sure as heck is less convenient than just point and click.
Yes, that is true. And we understand it.
The challenge is that there are two possible responses to a problem where
LilyPond doesn't do the right thing:
1) File a bug report, and wait for somebody to get around to fixing it
2) Figure out a workaround, which will certainly seem hacky, but doesn't
require waiting for a new LilyPond release.
When option 2 is chosen, we also have the ability to add the hack to the LSR
in order to save it for posterity and allow others to use it.
Unfortunately, when option 2 is chosen, we also lose some of the pressure to
fix the bug in the first place. Since available development time is
severely limited, we tend not to focus on things that have workarounds.
The documentation for extending Lilypond is not working out well: the
automatically generated lilypond-internals contains no useful examples
or explanations, the concepts for the C++, Scheme and Lilypond data
structures that one needs for internal programming are not explained
anywhere visibly, it is not clear what one can or cannot hope to do in
what layer and with what level of expertise.
I completely agree with you here. Your frustration is reasonable. Part of
it stems from a misunderstanding about the intent of lilypond-internals. It
is *not* intended to be a tutorial. It's strictly a reference (think
dictionary, not encyclopedia). The information you're looking for would
ideally be in the Contributors' Guide or a yet-to-be-written LilyPond
Architecture manual.
lilypond-extending does not contain examples for the various layers.
There are no examples for how to work in Midi functionality. As a
side-effect of taking out the crowbar and doing visual arrangement of
music content manually, of course the Midi output does not get any
relevant info.
Lilypond-extending has not been reworked as part of the GDP (Grand
Documentation Project) which greatly improved the Notation Reference
chapters 1-4. If you are having a hard time now, you should have tried it
before the GDP. I have hopes that we'll eventually get Extending worked out
to an equivalent level, but so much to do, so little time...
Midi in LilyPond was implemented not as a way to really play the music as
written, but as a way to proof-hear the notes to make sure the notes were
right. There is no core developer who has MIDI as their primary interest.
Peter Chubb did create articulate.ly to improve the MIDI output (many
thanks, Peter!), but that's hacking the input code, not the source code. I
don't know of *anybody* who has the expertise and interest to do the MIDI
stuff.
Things like ritardando can't be found in the notation index and are
programmed something like
Some performance indications, e.g., rallentando or accelerando, are
written as text and are extended over multiple notes with dotted lines.
Such objects, called spanners, may be created from one note to
another using the following syntax:
\override TextSpanner #'(bound-details left text) = rit.
b1\startTextSpan
e,\stopTextSpan
Yes, so we should add ritardando to the index. A patch is within the
ability of any LilyPond user, and would be speedily applied.
The code to establish a ritardando could be easily written, and may (or may
not) be done as part of the forthcoming GLISS (Grand LilyPond Input Syntax
Stabilization) project. There's currently some disagreement about whether
it would be good to define
spannerText =
#(define-music-function (parser location span-text) (string?)
#{
\override TextSpanner #'(bound-details left text) = #$span-text
#)
which would allow above example to be coded much more easily in the input
file
\spannerText rit.
Re: Quit [now definitely O/T]
On Wed, Nov 11, 2009 at 04:05:59PM -0500, Kieren MacMillan wrote: The first thing that comes to mind is Alternate input. Documentation/general/introduction.texi @node Alternate input I have to mao-ing learn TEXI now? So much for your 2-5 hours estimate... I stand by my 2-5 hours of editing texi, but I forgot to add that this was assuming the worker is familiar with git, texinfo, etc. Still-doing-it-but-thinking-there's-almost-definitely-a-better-way, In the case of that page... just look at Denemo and the current Frescobaldi. - Denemo shows you how the top boxes work. Don't use any other formatting; just copy what's there, and change the text and links to images accordingly. - the current Frescobaldi shows how the bottom list works... or at least, how I imagine it would work the best. Make a note of how that format works (or maybe duplicate it once or twice), then make Frescobaldi into a thing like the current Denemo. And move it higher on the page. The idea behind the website is that it's just like the other docs; once somebody is accustomed to working on the lilypond docs, they can easily work on the html+pdf+info that is general lilypond information. Besides, texinfo is easier than html. Really, seriously. Don't look at any texinfo tutorials or manuals... I don't even recommend looking at the extensive texinfo-related stuff in the Contributor Guide. Just follow the examples already in the file. Cheers, - Graham ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Quit [now definitely O/T]
Carl Sorensen c_soren...@byu.edu writes:
David,
Thanks for your willingness to articulate some concerns. I think that
your careful thinking can be of real help to the LilyPond community,
expecially if you can help us make things better.
Thanks for putting up with me.
On 11/11/09 7:21 AM, David Kastrup d...@gnu.org wrote:
Lilypond is supposed to be a music typesetter. Music in, glyph
placement out. If I have to do the typesetting myself, placing
glyphs rather than specifying musical content, Lilypond is not doing
its job.
This is absolutely true. The objective *is* to make the music
entirely tweak-free. Unfortunately, we are not there yet.
Perhaps the snippets resource should contain snippets for _future_
versions along with the current snippets.
Not just here is how you can do this but also here is how we wish one
could do this. And possibly a list of here are the pieces needed for
that. Part of that might be better located in the issue tracker.
The challenge is that there are two possible responses to a problem
where LilyPond doesn't do the right thing:
1) File a bug report, and wait for somebody to get around to fixing it
2) Figure out a workaround, which will certainly seem hacky, but doesn't
require waiting for a new LilyPond release.
You forgot
3) Work out a proper solution and contribute it.
And in open source software development, that is an option not to be
neglected, because in the end this is the _only_ thing anybody can do
that actually causes things to improve reliably.
When option 2 is chosen, we also have the ability to add the hack to
the LSR in order to save it for posterity and allow others to use it.
Unfortunately, when option 2 is chosen, we also lose some of the
pressure to fix the bug in the first place. Since available
development time is severely limited, we tend not to focus on things
that have workarounds.
I have noticed that some of the LSR entries are revolting. For example,
the diatonic accordion typesetting uses editor macros to
semi-automatically translate music into pseudo-music that happens to
place the tabulature dots in the right locations.
That's pretty absurd since that kind of translation belongs into Scheme.
The resulting source code is no longer transposable, the Midi has
nothing to do with the music, and so on.
This thing belongs in the LSR _only_ accompanied by a task description
of what one would rather be able to write.
It would be an _excellent_ way for _experienced_ programmers to tell
others what do to eventually to label ugly hacks as ugly hacks by
spelling out how a nice solution might look in the _source_.
The code to establish a ritardando could be easily written, and may (or may
not) be done as part of the forthcoming GLISS (Grand LilyPond Input Syntax
Stabilization) project. There's currently some disagreement about whether
it would be good to define
spannerText =
#(define-music-function (parser location span-text) (string?)
#{
\override TextSpanner #'(bound-details left text) = #$span-text
#)
which would allow above example to be coded much more easily in the input
file
\spannerText rit.
b1\startTextSpan
e,\stopTextSpan
but would hide the underlying LilyPond functionality (the \override)
and make users less likely to learn how to do overrides that they may
need to do for their own challenging music.
What is wrong with
b1\startSpan rit.
e,\stopSpan
? Why force meddling with an internal variable in the first place? You
need the text anyway, why not make it part of the macro?
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Quit [now definitely O/T]
@node Alternate input I have to mao-ing learn TEXI now? What's the problem here? If you don't want to do nifty things it's just a quite simple markup language. And since there has already been written a lot of TEXI documentation for lilypond I'm quite sure that you find examples for almost all situations. Werner ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Quit [now definitely O/T]
On Wed, Nov 11, 2009 at 9:33 PM, David Kastrup d...@gnu.org wrote: \spannerText rit. b1\startTextSpan e,\stopTextSpan What is wrong with b1\startSpan rit. e,\stopSpan ? Why force meddling with an internal variable in the first place? You need the text anyway, why not make it part of the macro? To ward off yet more thread drift: that's already in the list of things to consider as part of the Grand LilyPond Input Syntax Stabilization. GLISS will start whenever I have the time to organize it, which will happened whenever GUB and the new website are done, which... well it _might_ be done by Christmas, at the current rate of progress. Cheers, - Graham ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Quit [now definitely O/T]
Werner, What's the problem here? The problem is that I come to Lilypond with a skill set — specifically, many years of Java+Javascript+(X)HTML+XSL(T)+CSS+(La) TeX experience — which should be more than adequate for any modern documentation project involving a WWW component. I want to help move Lilypond forward, and I'm told that documentation is the place to start. Awesome! With apologies to Apple, I've got an app for that! Oh, wait... I've got to learn yet another markup language (one which I am unlikely to use in any other job/situation in my maoing lifetime), and install a bunch of apps (still in progress, over an hour later?!) before I can even start the [alleged] 2-5 hours of content development/improvement. I guess what I'm really saying is, if we think the barrier-to-entry for USERS is high, we've got another thing coming re: DEVELOPERS... =\ Cheers, Kieren. p.s. Hopefully I'm more resilient than others who have come before me — and subsequently dropped off the face of the interwebs, if Graham's 0 documentation developers is accurate — and I'll be able to get past these initial obstacles without losing [too much of] my goodwill steam. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Quit [now definitely O/T]
On Wed, 2009-11-11 at 22:33 +0100, David Kastrup wrote:
Carl Sorensen c_soren...@byu.edu writes:
The code to establish a ritardando could be easily written, and may (or may
not) be done as part of the forthcoming GLISS (Grand LilyPond Input Syntax
Stabilization) project. There's currently some disagreement about whether
it would be good to define
spannerText =
#(define-music-function (parser location span-text) (string?)
#{
\override TextSpanner #'(bound-details left text) = #$span-text
#)
which would allow above example to be coded much more easily in the input
file
\spannerText rit.
b1\startTextSpan
e,\stopTextSpan
but would hide the underlying LilyPond functionality (the \override)
and make users less likely to learn how to do overrides that they may
need to do for their own challenging music.
What is wrong with
b1\startSpan rit.
e,\stopSpan
If proper semantics and MIDI are the eventual goal, you will probably
need something like \startRit and \stopRit instead. This suggests the
need for some C++ work, since Text_spanner_engraver currently only
allows one spanner at a time, so
b\startRit c\startSpan foo d\stopRit d\stopSpan
would act strangely if \startRit used TextSpanners internally.
Joe
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Quit [now definitely O/T]
On Nov 11, 2009, at 11:29 AM, David Kastrup wrote: For me, this situation is awkward, impeding and dissatisfactory. For others, it is reason to go away. I don't see that anything is gained for chastising me for my impression. That is merely shooting the messenger. Actually, more than the messenger. This sort of thing is very common in open source projects IME, basically if you can't supply the solution, then you don't have a right to complain about it. I see less of this attitude on the LilyPond user list, at least, than in most other open source projects I've dealt with (e.g., some of the Emacs Gnus folks can be right ***holes). There's usually just one or two who spout a 'tude like this here and even that's pretty infrequent. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Quit [now definitely O/T]
David, I appreciate your persistence in this. I think that you are having part of the difficulty in this conversation because it's on -user, not on -devel. The modifications to anything except input files (which use lilypond code and embedded scheme) really involve knowledge that's primarily discussed on -devel. On 11/11/09 1:36 PM, David Kastrup d...@gnu.org wrote: Kieren MacMillan kieren_macmil...@sympatico.ca writes: c.f. http://lilypond.org/doc/v2.13/Documentation/contributor/Code-style#Code-styl e What needs to be added/improved? Once again, I'm sincerely asking, since you obviously still have questions about Lilypond coding style that weren't answered by that page (and surrounding ones). Uh, have you read it? It worries about things like indentation, says to prefer C++ over Python (but Python please in PEP 8 whatever that fancy acronym is supposed to be), and some identifier names. I agree. But at least for now, the coding style rules for LilyPond are the GNU coding style without modifications. Hence, the limited stuff that seems to not make much sense. It does not say what kind of code to put where for what reason. That is: it tells you minor details about how source should be formatted once you know perfectly what you are doing and which part of the code is appropriate to use. Namely it tells you about the difference between something that compiles and fits in with the rest of the _code_. It does not tell you what language/classes/operations to use to implement what kind of task. That's right. This kind of documentation does not exist. Several years ago I couldn't understand LilyPond at all, so I started trying such a document. It didn't get very far and it wasn't very accurate (but it did get a reference in Erik's thesis as the only available description). I'm still not sure I'm up to speed. I have some knowledge, but probably just enough to be dangerous. I could write a little bit better description, but probably not a really *good* one. http://lilypond.org/web/images/thesis-erik-sandberg.pdf Same question as above. The thesis is a thesis. It is unclear what state of Lilypond it documents, and what the current state of Lilypond embeds from what is in the thesis. And some thesis on the web is not a good substitute for programming docs. Because it does not evolve with the program. I agree, but the fact is that the thesis *is* currently the best description we have of LilyPond's overall architecture. And it is current, and will likely be current at least through all of 2.x. Details have changed, but not the overall structure. The internals documentation should likely spell out the layers of C+ +, Scheme, Music macros and what one can hope to reasonably implement in what layer. What new functionality requires equivalence of new engravers or performers, can one implement them in Scheme, does one need C++, and what exactly does one _do_ when creating them? I agree that this information is needed. It doesn't belong in the internals documentation, which is a dictionary, as described before. It probably belongs in the Contributors' Guide, or a separate Program Architecture manual. Would you be willing to create an outline of a Program Architecture manual? It could have headings that relate to your questions, and then we could fill in the answers, roughly at first and later in greater detail. The introductory page http://lilypond.org/doc/v2.13/Documentation/contributor/Overview-of-LilyPond -architecture#Overview-of-LilyPond-architecture does spell this out, I believe. I don't see this. Mostly, it points to sources for reference. That's useful to some degree. But if people write sources with only sources for reference, any design inherent in the first generation of the sources is going to become less and less discernible with successive layers of code. As a matter of fact, Han-Wen is consistent in telling us to Use the Source, Luke, rather than referring to other materials. So referring to the source is important, but need not be exclusive. More educational than studying how existing code is written would be to study how the code is _supposed_ to be written. Some self-contained example with well-defined functionality that sits well in the scheme of things. If people can't make their own code as simple and self-contained (or see existing real code much uglier), that is an incentive for improving the state of their and preexisting real code. I think this is a great idea -- a sort of Learning Manual for programming. Aimed not at users, but at developers. Something that works through a simple engraver, and describes the key components that are used. I don't know that we have anybody who knows enough and has the time and interest to write such a beast, but it would probably help increase the number of developers on the project. I've cross-posted this tho -devel; let's see if there's any interest in
Re: Quit [now definitely O/T]
Carl Sorensen c_soren...@byu.edu writes: David, I appreciate your persistence in this. I think that you are having part of the difficulty in this conversation because it's on -user, not on -devel. The modifications to anything except input files (which use lilypond code and embedded scheme) really involve knowledge that's primarily discussed on -devel. Certainly. This thread started by a user throwing in the towel, on the user list, explaining his reasons for doing so. This was followed by several comments that questioned his commitment in getting to learn Lilypond. As it is my impression that this in several respects was doing the original poster injustice as well as pasting over existing deficiencies in how Lilypond keeps up with what it is advertised for, I wanted to pitch in with my personal take. _Addressing_ the actual problems is definitely more suitably done on the developer list. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: quit
On 10.11.2009, at 20:36, Erik Appeldoorn wrote: I’ve been around for a short while only. A month with lilypond and 3 weeks on the list. Made a couple of scores, quite complex ones. But for each and every one I had to fiddle for hours and hours trying to grab all the details. All the while I had Sibelius at the ready and whenever I did fallback finished the score in record time. This is not going to continue I thought. I’d rather have a score that looks 85% than no score at all. So for now it’s quits with Lilypond. Perhaps I’ll be back, I just don’t know. All that helped, many thanks. I have now disabled the posts from the list, any reply have to be personal. Hou je goed / Keep well, Is this the equivalent of quitting your job and telling all of the people there you're all a bunch of idiots! except that no one here really cares whether or not you use lilypond? For what it's worth, I lasted about the first time I downloaded lilypond back in 2005, and then maybe four months the next time. And it really wasn't until the documentation was re-written, and I had the time to devote three months to learning lilypond that I finally got it. Until that time (and while I was writing the music for my senior recital) I unhappily used finale. James E. Bailey ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: quit
Sibelius is a really great software. It is not free, can't be run from a wiki, but great, it even handles collisions pretty well. Still I think it is worth spending time with LilyPond, it took me far more than 1 month on the list, so congratulations, that you could create complex scores after that short period of time. I think there are cases when LilyPond is the perfect tool, and there are situations when not. Bert James E. Bailey wrote: On 10.11.2009, at 20:36, Erik Appeldoorn wrote: I’ve been around for a short while only. A month with lilypond and 3 weeks on the list. Made a couple of scores, quite complex ones. But for each and every one I had to fiddle for hours and hours trying to grab all the details. All the while I had Sibelius at the ready and whenever I did fallback finished the score in record time. This is not going to continue I thought. I’d rather have a score that looks 85% than no score at all. So for now it’s quits with Lilypond. Perhaps I’ll be back, I just don’t know. All that helped, many thanks. I have now disabled the posts from the list, any reply have to be personal. //Hou je goed / Keep well,// Is this the equivalent of quitting your job and telling all of the people there you're all a bunch of idiots! except that no one here really cares whether or not you use lilypond? For what it's worth, I lasted about the first time I downloaded lilypond back in 2005, and then maybe four months the next time. And it really wasn't until the documentation was re-written, and I had the time to devote three months to learning lilypond that I finally got it. Until that time (and while I was writing the music for my senior recital) I unhappily used finale. James E. Bailey ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
RE: quit
Seems like a month is too short a time before giving up. I really have no other experience with other software like Finale or Sibelius, so I can't say anythign about them, but I have been very pleased with what I can do with LP. But it did take about 6 months before I was really getting it (not that I really do, I'm constantly learning more about my dinosaur version 2.6)... But I am a computer programmer so the way we create scores makes sense to me. Others might like a more point and click environment. Best of luck. On 10.11.2009, at 20:36, Erik Appeldoorn wrote: I’ve been around for a short while only. A month with lilypond and 3 weeks on the list. Made a couple of scores, quite complex ones. But for each and every one I had to fiddle for hours and hours trying to grab all the details. All the while I had Sibelius at the ready and whenever I did fallback finished the score in record time. This is not going to continue I thought. I’d rather have a score that looks 85% than no score at all. So for now it’s quits with Lilypond. Perhaps I’ll be back, I just don’t know. All that helped, many thanks. I have now disabled the posts from the list, any reply have to be personal. Hou je goed / Keep well, ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user _ Find the right PC with Windows 7 and Windows Live. http://www.microsoft.com/Windows/pc-scout/laptop-set-criteria.aspx?cbid=wlfilt=200,2400,10,19,1,3,1,7,50,650,2,12,0,1000cat=1,2,3,4,5,6brands=5,6,7,8,9,10,11,12,13,14,15,16addf=4,5,9ocid=PID24727::T:WLMTAGL:ON:WL:en-US:WWL_WIN_evergreen2:112009___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: quit
On Tue, Nov 10, 2009 at 11:36 AM, Erik Appeldoorn ursus.k...@ziggo.nl wrote: I’ve been around for a short while only. A month with lilypond and 3 weeks on the list. Made a couple of scores, quite complex ones. But for each and every one I had to fiddle for hours and hours trying to grab all the details. All the while I had Sibelius at the ready and whenever I did fallback finished the score in record time. This is not going to continue I thought. I’d rather have a score that looks 85% than no score at all. So for now it’s quits with Lilypond. Perhaps I’ll be back, I just don’t know. All that helped, many thanks. I have now disabled the posts from the list, any reply have to be personal. While it's interesting that you have stopped using LilyPond, I wish you would have posted some constructive feedback or criticism. Do you have suggestions to improve the documentation or the program itself? Thanks, Patrick ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
RE: quit
As several users have responded asking for feedback why I stopped with lilypond (or criticism). Here's my 2cents worth. During the last four weeks I have been restoring a piece. It has come to me in several different parts. Handwriting, several voices just as extraction parts. The publisher asked for goodlooking, editable scores. Which seemed like a good point to start with lilypond. I started with the simplest piece, a voice with organ. Laying it all out wasn't the problem. I am familiar with programming, and familiar with other markup languages. From day one I ran into trouble with notating what was asked. I have found the list very friendly and very helpful. In the end all my questions were answered, and all notating puzzles solved. But the fact I had to use several of these solutions (or work arounds) in one score (or even in one bar) made inputting very tedious. The last piece I did was a short piece of 25 bars, four voices. Took me two days to complete. And although I can see that the speed will get greater, at this point I'm only frustrated. I created all 10 movements in Sibelius, took me about 5 evenings. I have created the 4 smallest of them with lilypond, took me 20 evenings. So I take all the blame. I'm just to slow. On the practical side the work just could not wait. On the plus I found, good looking scores, very flexible On the minus I found, very tedious, time-consuming and heavily relying on work-arounds. Hope this will give some inside. I won't say I'll never try again, but not just now. Hou je goed / Keep well, Erik -Original Message- From: Patrick McCarty [mailto:pnor...@gmail.com] Sent: woensdag 11 november 2009 0:39 To: Erik Appeldoorn Cc: lilypond-user@gnu.org Subject: Re: quit On Tue, Nov 10, 2009 at 11:36 AM, Erik Appeldoorn ursus.k...@ziggo.nl wrote: I've been around for a short while only. A month with lilypond and 3 weeks on the list. Made a couple of scores, quite complex ones. But for each and every one I had to fiddle for hours and hours trying to grab all the details. All the while I had Sibelius at the ready and whenever I did fallback finished the score in record time. This is not going to continue I thought. I'd rather have a score that looks 85% than no score at all. So for now it's quits with Lilypond. Perhaps I'll be back, I just don't know. All that helped, many thanks. I have now disabled the posts from the list, any reply have to be personal. While it's interesting that you have stopped using LilyPond, I wish you would have posted some constructive feedback or criticism. Do you have suggestions to improve the documentation or the program itself? Thanks, Patrick ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: quit
On 11.11.2009, at 01:01, Erik Appeldoorn wrote: As several users have responded asking for feedback why I stopped with lilypond (or criticism). Here's my 2cents worth. During the last four weeks I have been restoring a piece. It has come to me in several different parts. Handwriting, several voices just as extraction parts. The publisher asked for goodlooking, editable scores. Which seemed like a good point to start with lilypond. I started with the simplest piece, a voice with organ. Laying it all out wasn't the problem. I am familiar with programming, and familiar with other markup languages. From day one I ran into trouble with notating what was asked. I have found the list very friendly and very helpful. In the end all my questions were answered, and all notating puzzles solved. But the fact I had to use several of these solutions (or work arounds) in one score (or even in one bar) made inputting very tedious. The last piece I did was a short piece of 25 bars, four voices. Took me two days to complete. And although I can see that the speed will get greater, at this point I'm only frustrated. I created all 10 movements in Sibelius, took me about 5 evenings. I have created the 4 smallest of them with lilypond, took me 20 evenings. So I take all the blame. I'm just to slow. On the practical side the work just could not wait. I'm guessing the Sibelius comparison also applies to the first month you spent using sibelius? I've heard it has a very intuitive interface, but I know the first couple of months I spent with finale were very difficult. Also, the complaint here isn't that there's some inherent defect in the program or the documentation, rather that you didn't want to take the time to learn how to use lilypond when you could do it in sibelius faster. James E. Bailey ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
