Re: Serious feedback and improvement headroom

[David Kastrup]

Urs Liska <address@hidden> writes:

>>     This becomes particularly important when it comes to tweaking
>>     output. He wrote (my translation): "My first look at LilyPond [through
>>     my presentation and a follow-up email] shows similarities to Amadeus,
>>     but OTOH I have the suspicion that the operation isn't sufficiently
>>     mature to allow economic ans fast work. I think, you just have to
>>     input too much information to get an optimal result." But he's also
>>     arguing at the level of actually entered number of characters.
>>
>>
>> That's something better addressed by input tools rather than the
>> language.  Emacs would be a good building block if you are used to
>> UNIX-like systems (and if you ported some large application for generic
>> UNIX to GNU/Linux, you probably have a bit of exposure here).  It's been
>> a long time since I looked at what lyqi, the "LilyPond quick input" mode
>> by, uh, Nicolas Sceaux?, did.
>
> Partly yes. When it comes to creating the input text for tweaks I
> agree that editing tools can do a lot to improve things. But when you
> have the strong opinion that typing "f" is an improvement over typing
> "fis" there's not much editing tools can do for you.

Huh?  The editing tools can, of course, be made to insert "fis" into
your text when you are typing f.

>>     I have the impression that LilyPond always needs twice or three times
>>     the characters for the same content. That's offputting ..."
>>
>>
>> Introduce him to MusiXTeX.
>
> That's not the point. He's (rightly) only interested in the comparison
> to Amadeus.

That _is_ for the comparison to Amadeus.  MusiXTeX is output-oriented
and has a concise but totally cryptic input language.

>>     While I still think that explicit pitches are better for a number of
>>     reasons this _is_ the way someone thinks who has to produce
>>     1.500-2.000 pages of high-quality scores per year. For him each
>>     additional character makes a difference.
>>
>>
>> Input tool problem.
>
> I don't think so.
> Take the "ho" example, which is shorter than "\stemUp".
> You can define a wrapper and write "\ho", which is still longer than
> "ho". The only thing to come to par with the two characters would be a
> keyboard shortcut. But of course it's not a good idea to create
> shortcuts for all of these commands. That would be way over the top.

Why?  That's what Emacs abbrevs are for, for example.

> I think he is right in saying that with LilyPond you need more typing
> than with Amadeus.

You need more screen and file estate.  But the typing is a matter of the
input tool.  LilyPond only provides a _language_, not an application.

> But I think that's not the real point. I think it's a tradeoff between
> number of characters to type, clarity and verbosity.

Clarity and verbosity are a feature of the language, numbers of
characters to type of the input tool.  They are the same only when using
a plain text editor without LilyPond-specific support.

>> Much of the internals of LilyPond are inefficient, and the glue layers
>> and data structures of Scheme also come at a cost (and using
>> GUILEv1,
>> not exactly renowned to be an efficient Scheme implementation, also
>> plays into that).  But Scheme is also giving us building blocks for
>> solving a lot of stuff without recompilation.
>
> OK, that may well be. But in effect it's a usability issue that
> shouldn't be underestimated. near-realtime WYSIWIG is an important
> factor, particularly when you have to tweak things iteratively by
> trial-and-error. Against Finale users we can always say that the
> compiled approach has inherent advantages that are worth the waiting
> time. But in this case that doesn't count.

If it does not even count, you want a visual workflow.  LilyPond is not
tailored for that.  It does not sound like Amadeus is, either, but its
performance makes it easier to gloss over that.

>> 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.
>
> I don't understand what you mean. You mean the creative process of
> preparing the content of a score takes more time than compiling the
> LilyPond file?
> We're talking about producing an average of ~10 publication quality
> pages per working day, and for this it does make a difference if you
> have to wait 0.2 or 12 seconds to get visual feedback for your
> editing.

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.

-- 
David Kastrup