lilypond-devel
[Top][All Lists]
Advanced

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

Re: Suggestion: Keep original breaks


From: Urs Liska
Subject: Re: Suggestion: Keep original breaks
Date: Wed, 27 Nov 2013 14:34:56 +0100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.0

Am 27.11.2013 12:25, schrieb David Kastrup:
Urs Liska <address@hidden> writes:

Of course I can achieve the same with tags. But there will be many
instances where  I don't "need them anyway" because I don't really
care about the state of the original score except for this
simplification while inputting/proofing.
So what?  Why hard code one particular special case?

Because that can be a significant improvement for a not-so-particularly-special use case (copying from existing scores). If that's accessible out-of-the-box for anyone it may even be a selling point, surely more than writing a tutorial how to define one's library functions to achieve that effect.


Using tags requires more munging of the input file, which for example
might pollute diffs when versioning scores.
No, it doesn't.  It's trivial to define \originalBreak in terms of tags,
so you can of course use \originalBreak just the way you'd like.
OK. But I _have_ to define it and ensure that any potential user of the file has it too. Which means either redoing it for every project or putting it in a library and requiring that library to be present and findable.

With the command line switch I can simply wrap the call to lilypond in
a custom script or make it a checkbox in Frescobaldi's Layout Control
Options.
The same is true when using tags for that mechanism, except that it
would be much more versatile.  And even if you want to get along without
any warnings and changes to LilyPond or init file, stuff like

lilypond -e "(define-public taglist '(original trumpet))" ...

will define a taglist for use in your file.

Accepted.
But this doesn't contradict my above comment.

I'm not talking about pushing something into LilyPond just for my personal convenience but about adding a usability feature for a wider audience. And this just is nicer if it is directly accessible than if it is just feasible. \slurUp wasn't necessary either - you can easily define it yourself as \override Slur #'direction = #UP.

What I actually want is to add that behaviour as an option to Frescobaldi's Layout Control Mode. And it's a no-go to inject arbitrary code into to input files that would either make scores dependent on Frescobaldi or on a separately shipped library.


Urs



reply via email to

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