Am 04.04.2014 14:24, schrieb David Kastrup: > Urs Liska <u...@openlilylib.org> 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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel