Re: Serious feedback and improvement headroom

[Jan-Peter Voigt]

Am 04.04.2014 14:24, schrieb David Kastrup:
> Urs Liska <address@hidden> writes:
> 
>> The most interesting aspect of the meeting was that Henle's (only)
>> in-house engraver was present too, and this may become a fruitful
>> contact. He is using Amadeus, a Linux (!) program he bought for 20.000
>> Euro in 1988
> Well, in 1988 there was no Euro.  I presume that you have just converted
> by some factor.  But in 1988 there also was no Linux.  Obviously,
> conversion by a factor would not help with that.
maybe he bought a unix-application, which runs on linux?
anyway, thats not the point ;)

>> 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?
> 
> Oh, he's perfectly right about that.  If you are writing a _score_, it
> is reasonable to write down what you see if your goal is to reflect a
> manuscript.  With LilyPond, the focus is on describing music rather than
> programming output, however.  There are advantages to that since I am
> not fixed in the key signature.  I can easily decide at a late stage of
> publishing whether I'll be writing Bach's "Dorische" in the rather
> unmotivated dorian key or whether I just punt and print it in d minor.
> 
> I can use the same source for a number of different styles including the
> Urtext.
+1
I'd never want to give up the flexibility.

>> 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.
> Current LilyPond input tools, editors, and workflows suck.  That is not
> LilyPond's "responsibility" as a command line tool, but of course it is
> something affecting its uptake nevertheless.
Frescobaldi doesn't suck! It is a very handy tool to enter lilypond code
with its code assistance. But for anyone used to another application, it
is a foreign tool-chain. I know so many people, who fear the switch from
MS Office to OpenOffice, because they are so different.


>> So maybe we really have a conceptual issue with the efficiency of
>> LilyPond's runtime work.
> 
> 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.
> 
> We _are_ too slow in our backend.  No question about that.  Parsing a
> file is much faster than typesetting it.  And the parsing still could be
> sped up considerably regarding the Scheme/LilyPond synchronization.
> 
>> As I can't imagine that we can speed up LilyPond's processing time by
>> 95% I really think we should find ways for partial recompilation. This
>> is reportedly also the approach the new Steinberg application
>> takes. For example when entering music I could do with only updating
>> the currently interesting section (maybe a system would be a good unit
>> for that).
> 
> LilyPond is a command line application.  Partial recompilation does not
> really map sensibly to it.

>> Maybe it would be possible to create compilation modes that have a
>> significantly sloppier approach to breaking. There are many stages in
>> the development of a score where I don't care at all about the layout
>> of the complete score. I recall that in Finale you could (probably:
>> can) switch between score and roll mode (however this has been
>> called).
> 
> You can do that in LilyPond as well.  The resulting output is not
> necessarily all that handy for typical previewers.
> 
>> Using strategies with skipTypesetting can help a lot in saving
>> compilation time. But it would be an extremely useful enhancement if
>> we could get some kind of partial recompilation _within_ the context
>> of an existing score.
> 
> That kind of stuff needs to get integrated into editing tools and modes
> since only editing tools and modes have the effortless information about
> what is currently on-screen and/or edited.
> 
>> [I just got another email indicating that Amadeus will by default
>> recalculate the current page only, and this works in near instant
>> time. I think with this we can get to an area where calculating
>> efficiency can make such a difference.]
> 
> Still needs integration with the editing tool.
> 
>> What I would vote for very much is an option to recalculate the
>> current system only, but with outputting the complete score anyway
>> (however it may be determined what "current" is). This should work in
>> many cases when a modification doesn't change line breaking. And it
>> would dramatically increase the editing experience.
> 
> There is little point in investing a lot of effort here when the current
> editing tools do not even deal with skipTypesetting and other things.
> 
> Frescobaldi is the only LilyPond text editor that is actively developed.
> Denemo could probably make use of some of that technology, but as it has
> its own display engines, there is not a lot of pressure to get partial
> updates for it.

But lilypond probably could assist a frontend with a map from musical
flow to paper-flow. If the GUI knows that on page 3 are measures 27-42
and the front end tracks an action, where I modified one slur-shape or
one pitch, the front-end could trigger a compilation of measures 27-42
and not the whole score.
Its just an idea ...

I think Guile V2 is the most important issue regarding lilypond in
general and especially with these thoughts. This would speed up the
scheme-part of lilypond and ensure its inclusion in linux-distros. And
if one wants to write something talking to lilypond, its more reasonable
to develop against a current API.

Just another idea I had:
One could write a GUI which is started as a guile-module. This module
would have access to all internal lilypond structures and could change
music-properties on the "living" objects.
I once tried a scheme-module, that started a little java-HTTP-server
through JNI. It is incredibly unstable, but it can load music and store
in variables and then serve it as .ly or .pdf ...

Best, Jan-Peter