[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Serious feedback and improvement headroom

From: Urs Liska
Subject: Re: Serious feedback and improvement headroom
Date: Fri, 11 Apr 2014 00:36:20 +0200
User-agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.4.0

That's a difficult issue, and I think you both (Janek and David) are completely right with what you write.

Nevertheless I think that trying to improve usability _now_ _is_ a good thing.

A user of a (notation) software usually needs to finish stuff for a concrete purpose. An engraver will probably need to finish a score for being printed. And he needs to do that "now". Telling him "we could make it easier for you, but that will make your scores less flexible regarding future development of LilyPond" sounds completely ridiculous from the user's perspective. OTOH it's clear that on the long run this user would benefit significantly when he wouldn't have to use manual tweaks. at least as soon as he wants to do a second run with some fixes.

It's similar with visual feedback. Telling someone that we don't help with getting visual feedback for ideological reasons ("we provide a text based workflow which we consider superior, so please respect that and stick to text - otherwise got back to Finale") doesn't make any sense to me. There are undisputable advantages in text based workflows, but these don't have anything to do with whether the user wants or needs visual feedback for his work.


Am 10.04.2014 11:51, schrieb David Kastrup:
Urs Liska <address@hidden> 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.

In the current environment?  I don't think all that much.  The important
thing remains the creative process, and that does not (or should not)
involve running LilyPond.

2014-04-04 16:42 GMT+02:00 David Kastrup <address@hidden>:
That's about one page every 50 minutes.  12 seconds are not much for
that as long as the tools don't require you to recompile for doing every
trivial little correction.

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.  LilyPond is _not_
the tool to use for a graphical workflow.  This is like listing the time
you spend straightening out nails when using a screwdriver to drive them
into a wall and asking for a faster screwdriver to make up for it.

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".

And the issue was currently newly pointed at from the perspective of
another engraving program that shares a number of aspects with
LilyPond but _does_ manage to provide this kind of near-instant

If that's the priority rather than automatic typesetting, then you have
to _start_ the design with that priority and keep throwing everything
overboard interfering with it.  Which includes the majority of automatic
positioning algorithms.  And extensibility.

And then it makes _perfect_ sense to build the application around
graphical interfaces and instantaneous feedback.  If Amadeus were not as
old as it is, that's likely what it would have started out with.

To some extent we will probably have to live with that because nobody
will want to go back to write 80s code without all the conveniences
modern programming systems have given the programmer (at the cost of
runtime speed). And because nobody's available to tackle significant
improvements in that direction.  I think this means that we should
think more in the direction of partial compilation. I have some ideas
but didn't have the time so far to bring them to the shape of a
concrete question/proposal.

Let me be quite straightforward here: architecturing "partial
compilation" into a global optimization framework like that of LilyPond
is a buzzphrase that may be fun to throw around.  But it will end up
more work and less useful than cranking LilyPond's speed up by a factor
of 4.  And it will be quite useless for an actually text-based input
mode of LilyPond rather than a tool detached from the input like Denemo.

If you take a comparative look, Display PostScript was a footnote in
history, and it _never_ resulted in some tool where you would work on
creating PostScript files manually with some form of "partial
compilation".  PostScript is not structured enough for that, and
LilyPond is not structured enough for that.

It's not just a matter of architecturing systems for interactive
response, it is also a matter of architecturing input structures
amenable to incremental interpretation.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]