Consider the edition engraver targeting "id"s

[uliska]

Originally the edition engraver's coolest feature is that it can target commands at a specific point in time, so one can separate the definition of tweaks or additions from the actual input.

However, I think there are applications where it will become useful to address ids instead of moments in time - although this seems against the intial idea of the tool. Actually the current addressing scheme is deficient as soon as the ly:moment? of an item is not known or may change, for example when dealing with compositions of non-fixed form (or in-development pieces) or when dealing with alternative readings that have differing dimensions.

So it would be good if the edition-engraver could additionally address items by an id property.

There are basically three ways to define/apply such an id:

1. Enter it manually in the input, for any element the user knows about that will need it
   (probably this is usually not very practical)
2. Have tools like Frescobaldi generate such an id, for example when calculating overrides through graphical means. I think it would be terrific if we could graphically shape, say, a slur and have the corresponding override not being written in the input file but in an external file as an id-addressed edition-engraver override.
3. Have external tools generate ids for all items. While this seems completely irrelevant from a LilyPond-only perspective it becomes a killer feature when LilyPond should consume MEI data. We are currently discussing an integration of LilyPond into MEI contexts, for example a way to integrate a tweaking tool in the Edirom tools. The (one) idea is to produce a file with overrides that is then sent along with the to-be-converted MEI data. That way we'd be able to store the rendering hints on the side of the MEI data and reuse it, without needing a persistent intermediate LilyPond file state.

[kierenmacmillan]

Hi Urs (et al.),

Originally the edition engraver's coolest feature is that it can target commands at a specific point in time, so one can separate the definition of tweaks or additions from the actual input.

However, I think there are applications where it will become useful to address ids instead of moments in time

Yes. This is the logical conclusion of the “anchor” (a.k.a. “\addAt”) feature I was brainstorming on-list when I first found out about the edition-engraver [and thus abandoned my "anchor" campaign.] We should be able to put anchors in the code arbitrarily, and target a moment relative to an anchor.

Actually the current addressing scheme is deficient as soon as the ly:moment? of an item is not known or may change, for example when dealing with compositions of non-fixed form (or in-development pieces) or when dealing with alternative readings that have differing dimensions.

I believe it’s still an open request — at least unofficially — that the EE’s moment references are relative to a \mark or other anchor; I’ve been running into this limitation a lot recently, while making major revisions to very large scores.

Have external tools generate ids for all items. While this seems completely irrelevant from a LilyPond-only perspective it becomes a killer feature when LilyPond should consume MEI data. We are currently discussing an integration of LilyPond into MEI contexts, for example a way to integrate a tweaking tool in the Edirom tools. The (one) idea is to produce a file with overrides that is then sent along with the to-be-converted MEI data. That way we'd be able to store the rendering hints on the side of the MEI data and reuse it, without needing a persistent intermediate LilyPond file state.

Interesting! It would be good to brainstorm how that might affect (or be affected by) explicit id choices in the “pre-MEI” code.

Cheers, Kieren.

---

Kieren MacMillan, composer ‣ website: www.kierenmacmillan.info ‣ email: info@kierenmacmillan.info

[flaminghakama]

On Thu, Oct 15, 2015 at 11:02 AM, kierenmacmillan notifications@github.com wrote:

Hi Urs (et al.),

Originally the edition engraver's coolest feature is that it can target commands at a specific point in time, so one can separate the definition of tweaks or additions from the actual input.

However, I think there are applications where it will become useful to address ids instead of moments in time

Yes. This is the logical conclusion of the “anchor” (a.k.a. “\addAt”) feature I was brainstorming on-list when I first found out about the edition-engraver [and thus abandoned my "anchor" campaign.] We should be able to put anchors in the code arbitrarily, and target a moment relative to an anchor.

FWIW, this sounds like an extrordinarily great idea. I have refrained from exploring the edition engraver based on it's method of using timecode.

David Elaine Alt 415 . 341 .4954 "Confusion is highly underrated" elaine@flaminghakama.com self-immolation.info skype: flaming_hakama Producer ~ Composer ~ Instrumentalist -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

[kierenmacmillan]

Hi all,

On Oct 15, 2015, at 2:38 PM, D. Elaine Alt notifications@github.com wrote:

I have refrained from exploring the edition engraver based on it's method of using timecode.

Don’t let that stop you from using it right now!

I’m 99% certain that the frustrations I will inevitabely encounter when it comes time to convert my existing edition-code to some new/enhanced [non-timecode-based] edition-code will be far outstripped by the benefits — and frustration elimination — already afforded by the EE in the meantime.

=)

FWIW, Kieren.

---

Kieren MacMillan, composer ‣ website: www.kierenmacmillan.info ‣ email: info@kierenmacmillan.info

[jpvoigt]

Hi Urs, hi Kieren,

first: I haven't been working on the EE lately ... but let's see, what we can come up with next.

Your ideas are more than reasonable and shall be implemented. Technically this should be easier to create than the other two points I wish to have in the edition-engraver:

1. real tweaks - tweak one note in an event-chord (or the like).
2. add "time-consuming" grobs - namely cue-notes

Now the "anchor"-idea is on the feature-request-list too.

I am still busy with another job, that is not lilypond-related. But I came across TEI, which is related to MEI. And moving this towards MEI, MEISE and edirom is very interesting!

Best, Jan-Peter

Am 15.10.2015 um 20:02 schrieb kierenmacmillan:

Hi Urs (et al.),

Originally the edition engraver's coolest feature is that it can target commands at a specific point in time, so one can separate the definition of tweaks or additions from the actual input.

However, I think there are applications where it will become useful to address ids instead of moments in time

Yes. This is the logical conclusion of the “anchor” (a.k.a. “\addAt”) feature I was brainstorming on-list when I first found out about the edition-engraver [and thus abandoned my "anchor" campaign.] We should be able to put anchors in the code arbitrarily, and target a moment relative to an anchor.

Actually the current addressing scheme is deficient as soon as the ly:moment? of an item is not known or may change, for example when dealing with compositions of non-fixed form (or in-development pieces) or when dealing with alternative readings that have differing dimensions.

I believe it’s still an open request — at least unofficially — that the EE’s moment references are relative to a \mark or other anchor; I’ve been running into this limitation a lot recently, while making major revisions to very large scores.

Have external tools generate ids for all items. While this seems completely irrelevant from a LilyPond-only perspective it becomes a killer feature when LilyPond should consume MEI data. We are currently discussing an integration of LilyPond into MEI contexts, for example a way to integrate a tweaking tool in the Edirom tools. The (one) idea is to produce a file with overrides that is then sent along with the to-be-converted MEI data. That way we'd be able to store the rendering hints on the side of the MEI data and reuse it, without needing a persistent intermediate LilyPond file state.

Interesting! It would be good to brainstorm how that might affect (or be affected by) explicit id choices in the “pre-MEI” code.

Cheers, Kieren.

---

Kieren MacMillan, composer ‣ website: www.kierenmacmillan.info ‣ email: info@kierenmacmillan.info

— Reply to this email directly or view it on GitHub https://github.com/openlilylib/openlilylib/issues/134#issuecomment-148474004.

[uliska]

Originally the edition engraver's coolest feature is that it can target commands at a specific point in time, so one can separate the definition of tweaks or additions from the actual input.

However, I think there are applications where it will become useful to address ids instead of moments in time

Yes. This is the logical conclusion of the “anchor” (a.k.a. “\addAt”) feature I was brainstorming on-list when I first found out about the edition-engraver [and thus abandoned my "anchor" campaign.] We should be able to put anchors in the code arbitrarily, and target a moment relative to an anchor.

Ah yes, I recall that discussion but didn't think of it currently. Obviously this is something to consider in the context of the current fundamental discussion.

Have external tools generate ids for all items. While this seems completely irrelevant from a LilyPond-only perspective it becomes a killer feature when LilyPond should consume MEI data. We are currently discussing an integration of LilyPond into MEI contexts, for example a way to integrate a tweaking tool in the Edirom tools. The (one) idea is to produce a file with overrides that is then sent along with the to-be-converted MEI data. That way we'd be able to store the rendering hints on the side of the MEI data and reuse it, without needing a persistent intermediate LilyPond file state.

Interesting! It would be good to brainstorm how that might affect (or be affected by) explicit id choices in the “pre-MEI” code.

Good point. The "id" thing is an important thing to be discussed thoroughly, in several contexts:

• The context we're currently discussing: inserting IDs as arbitrary anchors
• Using IDs for several things with regard to the resulting files, e.g. in the SVG code
• Using IDs to make trans-voice spanners addressable
• Matching the IDs in an MEI file

All this is not really trivial and should be considered carefully. For example, in an MEI file typically every item has an xmlid tag, and usually an extensive one, e.g. a GUID. If these would show up in LilyPond code that would become completely unreadable and unusable. In any case, the syntax and concept must be consistent throughout the different use cases.

[uliska]

Moved to https://github.com/openlilylib/edition-engraver/issues/13