[Top][All Lists]

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

Re: Serious feedback and improvement headroom

From: David Kastrup
Subject: Re: Serious feedback and improvement headroom
Date: Fri, 04 Apr 2014 16:42:46 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)

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

reply via email to

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