Kieren has sent a very interesting proposal: http://lists.gnu.org/archive/html/lilypond-devel/2009-07/msg00544.html

"

Like many Lilyponders, I break down my code into variables, e.g. global (for time signature changes, etc.), notes, dynamics, etc. The main irritation with this (IMO) is that each variable requires a complete set of skips in order to keep the timing accurate.

Would it be technically feasible/possible to establish a system of "anchors" instead? That is, could we declare an anchor point in the global setup, and then refer to it in other code? e.g.

global = { \time 4/4 s4*4*10 \time 3/4 s4*3*5 \time 7/4 s4*7 \time 4/4 \anchor #'coda s4*4*10 \bar "|." }

tempoChanges = { \tempo \markup "Opening tempo" \anchorTo #'coda \tempo \markup "Extremely slow" } "

Jay has proposed a slightly simpler syntax:

" That's a neat idea. It might be easier to do something like:

global = { \time 4/4 s4*4*10 \time 3/4 s4*3*5 \time 7/4 s4*7 \time 4/4 \anchor #'coda s4*4*10 \bar "|." }

\addAt #'coda \global {\tempo \markup "Extremely slow"}

Then the addAt function could weave the tempo in at the correct point. "

Han-Wen has offered to help anyone would be willing to implement it: http://lists.gnu.org/archive/html/lilypond-devel/2009-08/msg00102.html " I can imagine how this would be implemented, but it would be a lot of work. If anyone is up for a challenge, I can give some pointers. :) "

I suspect many people would pay for such a killer-feature. As always, I am ready to double the fee.

I offer US$150.

A workaround has been proposed by Gilles: http://lists.gnu.org/archive/html/lilypond-devel/2010-11/msg00234.html

As to the $300, my Email address is registered at Paypal, but I'll also provide bank account data on request (should be without fee in the Euro zone). I have to admit that this is not all too hard-earned, but then most of the stuff I do is not covered by bounties at all, so I don't have much of a bad conscience.

This is actually basic enough to make a nice example in "Extending Lilypond".

Looking at my rather cryptic mails in the bug report, it looks like I should have been more explicit. The attachment "cash.ly" contains definitions for the two music functions \anchor and \addAt which, given the desired input (copied into the end of cash.ly) produces the desired output.

The modification with map-music-function happens in-place, so one should preferably use this in the same manner as Scheme functions reverse!, namely when the result is assigned back to the source or not used otherwise anymore.

When this does not seem user-friendly, adding a ly:deep-music-copy call in the code will sort this out at the cost of memory use (typically cleared up by the garbage collector eventually). A different option would be to open-code the part currently done by map-music-function and create copies only for those parts of the structure that change by \addAt.

Suggestions about where to put that code in what form?

Actually, the example can still be simplified: setting the origin in the music expression is not necessary since that is already catered for by define-music-function.

Suggestions for better names? \addAt is not so Lilypondish.

how about \addAnchorAt ? or maybe \anchorAt ?

Uh, actually looking at ly/music-function-init.ly I find that camelCase is all the rage with Lilypond. Don't ask me what I was thinking.

I think \atAnchor would be just fine. \addAt is less specific to anchors and uglier in casification.

I just pushed 264022bd6ebfed3220c0272d2c4a1c8ef9db4028 which introduces \pushToTag and \appendToTag functions (unfortunately, the commit message misspells them) complete with notation manual documentation and regtest. For a usage example, see input/regression/push-to-tag.ly or recompile the notation manual and reread the section about tags.

I consider the naming sane, the implementation efficient and versatile, integrating well with existing code, and quite capable of addressing the problem described in this issue.

In other words: I now have no qualms claiming the bounties.

Fixed in which stable, please?

lilypond@googlecode.com writes:

No stable yet. Wasn't it "Fixed" when fixed in the development version, "Fixed_xxx" when fixed in a certain release?

Let me check the CG:

• Fixed: a contributor claims to have fixed the bug. The Bug Squad should check the fix with the next official binary release (not by compiling the source from git). Owner should be set to that contributor.

Well, I claim to have fixed the bug. Nothing more, nothing less. Working regtest is there, user level documentation is there, no word from the bounty offerers. No bad conscience here on my part.

Dmytro simply misspoke; he meant to ask "fixed in which release".

Since that commit came after 2.15.12, the fix will appear in 2.15.13.

To David:

No problem, all is well. However, trying to verify this issue, I figured out that the original code will/should not work; then looked (should I?..) at the patch and grabbed the code from it; then decided that "it does not work" --- verification has failed! ,)

So... When I see the list of issues to verify --- labels like "fixed_x.y.z" save my time a lot.

On the other hand, I never know whether the patch won't be reverted before the nearest stable release. That's why I am about not considering issues without "fixed_x.y.z" as being really fixed. (Yes, right, a developer can update an issue upon reverting; but actually bugsquad is the only entity I can really trust;-)

I can be wrong .) Please, let me know, if so. Thanks!

ps. Thank you, Graham.

Kieren remarked in private communication that these macros nest awfully:

\pushToTag #'coda \pushToTag #'sevenfour \pushToTag #'threefour \global { \tempo \markup "Starting slow" } { \tempo \markup "Getting faster" } { \tempo \markup "As fast as possible" }

as opposed to \pushToTag #'coda { \tempo \markup "As fast as possible" } \pushToTag #'sevenfour { \tempo \markup "Getting faster" } \pushToTag #'threefour { \tempo \markup "Starting slow" } \global

I guess he is right: I had a reason for choosing the order of arguments, but his reason is much better.

So I am going to change the order (and push to staging) while nobody has yet written significant code using the feature.

Since I already wrote regtests and documentation, this will take a bit more work. Should be worth it.

pushed to dev/staging. I am currently waiting for a recompilation to succeed in order to check the changed regtest. I'll likely push to master once the regtest looks fine, the code in the manual is just a copy of that.

Regtests worked out fine, pushed to master as cfb9a2a0446a4037a635be4042d195c3800aba90

The solution does not use exactly the syntax at the top, but

global = { \time 3/4 s4*3*10 \time 4/4 \tag #'coda << s4*4*10 >> \bar "|." }

\anchoredStuff = { \tempo "Extremely slow" c'2 e' }

globalVariant = \pushToTag #'coda \anchoredStuff \global

The original \global remains unchanged, and the new \globalVariant is distinct music expression as if you typed globalVariant = { \time 3/4 s4*3*2 \time 4/4 << \anchoredStuff s4*4*2 >> \bar "|." }

Instead of the simultaneous <<..>> the \tag can be on a sequence {..} if you want \globalVariant to be longer in duration than \global by the length of \anchoredStuff

The pushToTag and addToTag functions work purely at the music expression level. There is some case to be made to have synchronization capabilities on the iteration level, where it is possible to wait for a specific mark or measure number.

\pushToTag and \addToTag provide a low-level mechanism for the task they do; it's conceivable that some abstraction could be built from it that better expresses actual use cases. However, it may make sense to first see how to provide functionality at the iteration stage, and then see whether one can model aspects of this functionality reasonably similar at the pure music expression level.