[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Serious feedback and improvement headroom
From: |
Jan-Peter Voigt |
Subject: |
Re: Serious feedback and improvement headroom |
Date: |
Fri, 04 Apr 2014 15:04:10 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 |
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
Message not available
Re: Serious feedback and improvement headroom, Henning Hraban Ramm, 2014/04/04