lilypond-auto
[Top][All Lists]
Advanced

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

Re: [Lilypond-auto] Issue 4155 in lilypond: Patch: Add original-breaks.l


From: lilypond
Subject: Re: [Lilypond-auto] Issue 4155 in lilypond: Patch: Add original-breaks.ly commands
Date: Tue, 07 Oct 2014 12:05:13 +0000


Comment #4 on issue 4155 by address@hidden: Patch: Add original-breaks.ly commands
https://code.google.com/p/lilypond/issues/detail?id=4155

Hm, maybe I've overlooked something or didn't understand something completely, but I think the use-case is different from that of tags.

AFAICS tags are useful to (re)use music expressions for different targets, e.g. (the classic case) for a full score or an individual part (current example: "All winds as soft as possible" is not terribly useful in the violin part).

For that I take some music (mostly a variable) and use it with \keepWithTag et al. around it..

What I have in mind instead is not different targets but, hm, different "compilation modes". That is, I have *one* score and I want to use the music once (it doesn't matter if I *also* want to use it for different targets). In this score I want to insert commands for the breaks of the original score. And - not depending on the output target but on my current state of work - I want LilyPond either to respect these breaks or do its own breaking.

For this I want to have a switch that can be entered either as a onetime command (\keepOriginalBreaks) or pass it through the command line (#(define keep-original-breaks #t). That way it could also become an editor feature.

I think this is the main difference from my approach to using tags: I wouldn't have to use the \keepWithTag's whereever I *use* a variable.

And no, this is *not* a hyperindividual use-case for my personal needs.

--
You received this message because this project is configured to send all issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings



reply via email to

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