2014-04-10 11:51 GMT+02:00 David Kastrup <address@hidden
> Urs Liska <address@hidden
>> 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
> 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
> 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.