I agree with this freak called Janek ;) Actually I can hear there some reverberation of my own ideas ;) That's great that you want to make Lilypond more user-friendly and make the initial learning curve not that steep, but it the same time don't forget our you Ultimate Goal. That's awesome! :)
All the best to you and to *she* Lilypond :D, Łukasz 2014-04-10 13:42 GMT-07:00 Jan Warchoł <jan.warc...@gmail.com>: > Post Scriptum: > after rereading my previous email, i see that it sounds as if i believed > that implementing the Ultimate Goal (i.e. automatic engraving) and > effectively improving "efficiency" were mutually exclusive. I don't think > that's the case - in some cases the most effective (= with the biggest bang > for the time spent factor) solution _is_ to make LilyPond Do The Right > Thing. And sometimes the most effective way is to implement part of the > Ultimate Solution. > > But sometimes it may be best to do something else. > > best, > Janek > > > 2014-04-10 22:23 GMT+02:00 Jan Warchoł <jan.warc...@gmail.com>: > > Hi, >> >> 2014-04-10 11:51 GMT+02:00 David Kastrup <d...@gnu.org>: >> >> > Urs Liska <u...@openlilylib.org> writes: >> > >> >> Am 09.04.2014 11:53, schrieb Jan Warchoł: >> >> >> >>> Concerning compilation speed - this is indeed a serious problem for >> >>> LilyPond, and i don't know which part of the code is most responsible >> for >> >>> this. Unfortunately i expect that changing this would require at >> least one >> >>> experienced programmer spending a lot of time (3-6 months?) just on >> that >> >>> issue. So, unless David would like to tackle this (and unfortunately >> this >> >>> is not exactly his area of interest), >> > >> > It's actually the area I am so good at that I never know where to start >> > and end up doing nothing. >> > >> > It's mostly a straightforward benchmark-and-improve cycle. >> >> Hmm, maybe i could help with deciding in some way? >> >> I'd very much like to see performance improvements in Lilypond, so i may >> be able to throw some money at the issue if that helps. >> >> Could you give me an estimate of how much time would you need to reduce >> compliation time by a factor of 2? Of course i understand that such >> estimate would be veeery uncertain, but i'd like to know if it's a matter >> of a week of work or more like 2 months. >> >> >>> I confirm that 0.2 vs 12 seconds does make a big difference. During >> Fried >> >>> songs beautification, i have waited probably 4-5 seconds (on average) >> and i >> >>> considered it waaay too slow for effective and pleasant work >> experience. >> >>> >> >>> This is because with any non-trivial music (i.e. with any music more >> >>> complicated than "twinkle, twinkle, little star" - really) there _is_ >> a lot >> >>> of little corrections that require recompiling to check if they were >> done >> >>> correctly. >> > >> > So the thing to do is making LilyPond do them right. >> >> Yes, this *is* the _ultimate_ goal. But before we reach that goal we >> need ways to effectively _use_ LilyPond to produce beautiful scores. >> >> LilyPond is not an academic project whose point is to "write a music >> engraving tool that does The Right Thing". The point of LilyPond project >> is to provide people with a tool for creating excellent music notation. >> The most important property that LilyPond must have is that it works for >> users effectively, not that it "does things the Right Way" (i would >> certainly love to see LilyPond Do Things the Right Way - but this is only a >> _means_ to an end). >> >> Or, to look from other perspective: at current development speed, it will >> take LilyPond somewhere between 10 and 100 years to reach the stage where >> it does most of the things The Right Way (TM) (i.e. that most of the >> ordinary scores are engraved 100% publication quality by default). In that >> time LilyPond will become obsolete, or at the very least it will completely >> loose any chance to have any noticeable "market share", which would be a >> loss not only for us personally, but also for the cause of Free Software >> and music engraving quality worldwide. >> >> Why i think that failing to get more market share soon will mean a >> failure of Free Software? Because i expect with 80% confidence that if >> LilyPond doesn't become much better soon, in 5 years Steinberg's upcoming >> application will become an unquestionable leader in notation software, and >> noone except the most extreme geeks will ever care about using LilyPond at >> all. It seems that this new application will really be much better than >> both Finale and Sibelius, which means that it will probably be better (i.e. >> more effective) at creating publication-quality scores than LilyPond. >> >> Look at what happened with Browser Wars: in the first half of 2000s, >> Firefox was obviously a better browser than IE by orders of magnitude, and >> nevertheless its adoption was slow. Then, when Google Chrome appeared, it >> had won the first place almost overnight. Now, the problem with Lilypond >> is that it's not as much better to Fin/Sib as Firefox was to IE. When a >> new program will appear that will have both the user-friendliness (=GUI) >> and good notation features, LilyPond won't have a chance. That's why i >> believe we need to make the development go faster so that we win as much >> "market share" as we can *before* Steinberg launches their new software. >> If we don't do this, Free Software will FAIL on the music notation front. >> >> One way to speed up development is to have many many more passionate >> users that will also become developers. Another way is to have some >> "corporate" users that could sponsor further development on a large scale. >> Both of these options require attracting these users with efficient >> notation software, software that works _now_ instead of "being really great >> somewhere in the future". >> >> Do you see my point? >> >> >> I can fully second that. >> >> This isn't like "we want a graphical workflow". We _do_ want a text >> >> based workflow, but visual feedback _is_ important for a number of use >> >> cases. >> > >> > But why would you even want a text based workflow for a fundamentally >> > graphical task? Of course we need LilyPond to do a better job here. >> > Instead people want easier ways to do LilyPond's job and basically say >> > "it is ok if LilyPond sucks at positioning music since we are going to >> > clean up after it anyway". >> >> As i said, while having Lily Do The Right Thing by herself must remain >> our ultimate goal, the question that i believe we should be asking >> ourselves is: how to maximize LilyPond efficiency in the shortest time >> possible (without compromising our ability to implement the Ultimate Goal)? >> >> As i see it, most of the time the most effective way is not to implement >> the Ultimate Goal right away, but to add some helper feature. Graphical >> editing in Frescobaldi is a magnificent example: there will _always_ be >> things that users want to move around, and moving them graphically will >> _always_ be easier than doing it by text overrides. Implementing one tool >> for graphical editing of any object takes much less time than solving *all* >> positioning issues with *all* notation elements. And this doesn't make >> implementing the Ultimate Solution harder in any way. As a bonus, new >> users will be less intimidated by Lilypond's text input. >> >> So, the point is to make LilyPond work for its users. >> >> Let me make sure that we understand ourselves: I agree with you that we >> should improve LilyPond's automatic typesetting. But i believe that's not >> the no.1 priority. We need an efficient way to produce music notation in >> the meantime, while the automatic engraving is improved. >> >> best, >> Janek >> > >
_______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
