[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
- Re: Serious feedback and improvement headroom, (continued)
Message not available
Re: Serious feedback and improvement headroom, Henning Hraban Ramm, 2014/04/04
Re: Serious feedback and improvement headroom, Francisco Vila, 2014/04/05
Re: Serious feedback and improvement headroom, Jan Warchoł, 2014/04/09