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. :(