2014-04-04 12:43 GMT+02:00 Urs Liska <address@hidden>:
(the
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
them
on bug-lilypond to discuss if some of them might warrant a feature
request.
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
characters.
As a response to my argument that I prefer explicit pitches (a fis is a
fis,
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
the
key. When I'm seeing the current key in the score display, I do know that
in
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
always
unambiguous and can't produce misunderstandings. I have the impression
that
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
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.
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
keep
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
parameters.
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
thinking.
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
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.
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
course
Amadeus files have to be compiled before the result is visible, and this
can
be automatically done upon save. I think Frescobaldi's behaviour with
Ctrl-M
and by now the autocompile is an equivalent approach here. But the
engraver
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
and
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
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.
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. :(