[Top][All Lists]

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

Re: [SPAM] Re: Serious feedback and improvement headroom

From: Urs Liska
Subject: Re: [SPAM] Re: Serious feedback and improvement headroom
Date: Thu, 10 Apr 2014 11:10:06 +0200
User-agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.4.0

Am 09.04.2014 11:53, schrieb Jan Warchoł:
2014-04-04 12:43 GMT+02:00 Urs Liska <address@hidden>:
handling of accidentals in the input for example: In Amadeus you write the
"visible" notes, that is: the meaning of "d f a" depends on the currently
active key signature). But some others look interesting, and I'll post
on bug-lilypond to discuss if some of them might warrant a feature
But beyond the basic music items there are significant conceptual
differences in the input language. In general LilyPond's language is more
verbose than Amadeus'. A few examples:

treble F 4/4 is the equivalent to

\clef treble
\key f \major
\time 4/4

(,9 .... ),10_a140140h30
seems to be an equivalent to a \shape invocation
But he's also arguing at the level of actually entered number of
As a response to my argument that I prefer explicit pitches (a fis is a
regardless of needing a sharp or not, while in Amadeus a pitch is only
defining a notehead position) he sais: "I don't understand why I should
always enter the accidentals explicitly when they are already defined by
key. When I'm seeing the current key in the score display, I do know that
es major the a is actually an as, isn't it? Apart from that the editor
always shows me the currently active key. The encoding in Amadeus is
unambiguous and can't produce misunderstandings. I have the impression
LilyPond always needs twice or three times the characters for the same
content. That's offputting ..."
While I still think that explicit pitches are better for a number of
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

I don't suggest any significant changes in our input syntax. But I want to
point out that editing efficiency on that level _is_ an issue we should
taking into account when it comes to professional work. For this guy it
makes a difference if he can (thousands of times) type "ho" instead of
"\stemUp". And we all know that the process of tweaking output isn't that
straightforward with LilyPond (although I very much appreciate all the
little and bigger improvements we constantly see).

We could use an external editor with efficient input mode and lots of
keyboard shortcuts.  Shouldn't be too hard to add to Frescobaldi (of course
simply adding keyboard shortcuts is trivial, but i think about a more
involved method of inputting)
For some things we can use special shorthand commands.  Since LilyPond is
open source, every command can be inspected and a shorthand created.  For
things like shape, it is possible to create a special function that would
take a string as a condensed input and parse it to regular \shape

Sure, some things cannot be avoided - indeed, \ho is one character more
than ho.  But in the end i don't believe that he really writes the scores
as fast as he can type.  I suppose that he still spends 2/3 of the time

OK, I think this aspect is sufficiently discussed now. I don't think anybody sees the necessity to spend significant work towards that direction. Of course it is not our job to tweak LilyPond and its tools to the liking of one specific engraver who isn't expected to do the switch anyway. I know enough to tell him what _would_ be possible, and that should do it for now.

2014-04-04 16:18 GMT+02:00 Urs Liska <address@hidden>:
Partly yes. When it comes to creating the input text for tweaks I agree
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
editing tools can do for you.

As David wrote, you could have a special input mode in Frescobaldi which
would detect the current key signature and insert "fis" when you press "f".

Another aspect that I found very astonishing is compilation speed. Of
Amadeus files have to be compiled before the result is visible, and this
be automatically done upon save. I think Frescobaldi's behaviour with
and by now the autocompile is an equivalent approach here. But the
claims that recompilation of a 30 page scores needs 2/10 of a second on an
average computer. So this _is_ a fundamental difference, because he _does_
have practically instant WYSIWYG while still benefitting from text input
the compiled approach. [.....]

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), we'd have to either hire someone or
wait for someone to appear.  This is not a project that could be done
'part-time', i'm afraid.

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
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
0.2 or 12 seconds to get visual feedback for your editing.

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
correctly.  For example, when i'm tweaking a slur, i have less than 10-20%
chance that my initial \shape arguments will be optimal (and that's with
all my experience after tweaking 1200+ slurs!!).  I just _have_ to
recompile to see how it worked, and to readjust the parameters.  Really.
\shapeII with polar coordinates helps with that, but it doesn't eliminate
the problem.

And there are other things than shaping slurs that need immediate
checking-by-recompiling.  :(

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 cases. 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 feedback.

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.



reply via email to

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