lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Score.skipTypesetting


From: Urs Liska
Subject: Re: Score.skipTypesetting
Date: Thu, 13 Aug 2015 15:24:53 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0


Am 13.08.2015 um 15:12 schrieb Orm Finnendahl:
> Hi Barry,
>
>  thanks for the answer. I might have been unclear:
>
> In a chamber music piece I'm writing, the first line of the score is
> (and should be) indented.
>
> While working on the score I want to typeset just the last part of the
> score and use
>
> Score.skipTypesetting = ##f
>
> in the beginning and set
>
> Score.skipTypesetting = ##t
>
> in some later part, e.g. after a \pageBreak.
>
> lilypond renders this partial score with the first line indented which
> is suboptimal as the beginning of this page will *not* get indented in
> the final (non partial) score.
>
> I was just proposing to fix that in case it's not very
> complicated. But as this is not a bug and I can circumvent this easily
> by setting the indentation to #0 when rendering partial scores I don't
> really want to start a bikeshed...

Actually this is what I wanted to say too.
Score.skipTypesetting is most surely used as a means for optimizing the
workflow, and ideally you'd have the output a real excision of the
compiled score - which is of course inherently impossible.

But I would also prefer the output of such a compilation start with a
regular (i.e. non-first) staff, that is without indentation, instrument
names hidden measure number, and perhaps even time signature.

I think this should be rather trivial to implement, either as
skipTypesetting's default behaviour or in a new wrapper function.
More involved (but maybe not impossible) would be the wish to
automatically add missing spanner parts, e.g. starting dynamics or slurs
etc.

One thing I want to implement in Frescobaldi (rather soon, when our
current "manuscript viewer" is finished) is a compilation mode where
- one compilation writes the line and page breaks to a log file
- subsequently any single system can be recompiled through skipTypesetting
- while Frescobaldi determines the proper points for this using the log file
- The compiled line will be replaced in the music view. For this I want
to create a new viewing mode where a score is composed of a chain of
systems without the notion of a page.

This will work as long as the changes don't require the line breaking to
change - which should be detectable. I hope that this will significantly
smooth the user experience, although I know it's far from "instant" (for
example LilyPond still has to interpret the whole score first, so
engraving one system out of a 300 system score still takes a significant
amount of time.

For such an undertaking having the partially compiled score start just
like from within the score (instead of creating a "complete" score)
would be quite useful, although I can easily see a workaround (for my
case): Compile one additional measure before and after the current
system and insert manual line breaks.

So I second Orm's feature request.

Urs

>
> --
> Orm
>
> Am Donnerstag, den 13. August 2015 um 13:57:44 Uhr (+0100) schrieb Kevin 
> Barry:
>> Hi Orm,
>>
>> On Tue, Aug 11, 2015 at 3:13 PM, Orm Finnendahl
>> <address@hidden> wrote:
>>> As the instrument names are short, lilypond must know that it isn't at
>>> the beginning of the piece. It would be preferrable to have unindented
>>> first staffs, as that would better resemble the final layout, if the
>>> typesetting (re)starts at linebreaks.
>> LilyPond won't really try to guess something like this based on
>> instrument names. If you start a new \score block LilyPond will create
>> a new score, indented, at bar 1 etc., which is as it should be IMO
>> (i.e. it behaves consistently rather than trying to guess your
>> intentions). Multi-movement forms (suites, sonatas) frequently do this
>> (start a new indented score on the same page). Sometimes it can be a
>> good solution to use a new \score block in place of a line break in an
>> existing score, in which case the best thing to do would be to
>> continue as you are. If you post a snippet illustrating the problem
>> then perhaps someone could suggest an alternative that you haven't
>> thought of.
>>
>> hth,
>> Kevin
>>
>> _______________________________________________
>> lilypond-user mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/lilypond-user
> _______________________________________________
> lilypond-user mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/lilypond-user




reply via email to

[Prev in Thread] Current Thread [Next in Thread]