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
