Hi Kieren, Am 27.02.2014 04:44, schrieb Kieren MacMillan: > Hi Jan-Peter, > ... > Are you interested in taking up that challenge? =) yes, I am :) And I will answer more , when I left all infections behind, which my children brought from school and kindergarten ...
> I would love a dead-simple, drop-in solution which would require minimal > adjustments to a score in order for it to accept “edition tweaks”. I tried to > adapt your example (see below), but had a few difficulties, and gave up > quickly because of the time constraints I was under at the time — I am now > much freer, and would love to take this to the goal line. Perhaps my explanations get us a step forward to the dead-simple-drop-in. > %%%% BEGIN > > \version "2.18.0" > \include "edition-engraver.ly" > > \addEdition test > % color the notehead red on the second quarter in the second measure > \editionMod test 2 1/4 my.test.Staff.A \once \override NoteHead #'color = #red > % destroy the slur starting on the second quarter in the first measure > \editionMod test 1 2/4 my.test.Staff.A \shape #'((0 . 0)(0 . 1)(0 . -1)(0 . > 0)) Slur > > \layout { > \context { > \Score > \consists \editionEngraver my.test > } > } > > music = \relative c'' { c4 bes a( g) f e d c } > > \new Staff \with { \consists \editionEngraver my.test } > \new Voice \with { \consists \editionEngraver ##f } \music > > %%%% END > > It looks dead simple… but (a) I don’t understand what the “my” is, nor where > “Staff.A” comes from, nor why you need to \consist a ##f engraver in the > Voice, etc. a) The "my" is the first part of an arbitrary identification part of the engraver. In fact "\editionEngraver" is a scheme function, which returns an engraver with the given id-path. So it might be \consists \editionEngraver kierens.great.musical b) The "Staff.A" is added to the path by the engraver on initialization. The engraver adds the context-name to the id-path, which is in this case "Staff", and then adds a counter, which is in fact a letter, so that we can use dot-notation: "kierens.great.musical.Staff.1" will not parse, but "kierens.great.musical.Staff.A" will. c) With "\editionEngraver ##f" an engraver is created, which searches the parental contexts for an id and inherits the id. It is just adding its own context name and counter, in this case "Voice.A". So for the above example it is equivalent to \new Voice \with { \consists \editionEngraver my.test } I found it easier to declare ids per staff: A global \layout { \context { \Voice \consists \editionEngraver ##f } } adds edition-engravers, inheriting the parental id, to each voice automatically. > Start with a simpler (pseudo-)example: > > %%%% BEGIN > > \version "2.18.0" > \include "edition-engraver.ly" > > \addEdition editionA > % color the notehead red on the second quarter in the second measure > \editionMod editionA 2 1/4 Staff.Singer \once \override NoteHead #'color = > #red > % destroy the slur starting on the second quarter in the first measure > \editionMod editionA 1 2/4 Staff.Singer \shape #'((0 . 0)(0 . 1)(0 . -1)(0 . > 0)) Slur > > \layout { > \context { > \Score > \consists \editionEngraver editionA > } > } > > music = \relative c'' { c4 bes a( g) f e d c } > > \new Staff = “Singer" \with { \consists \editionEngraver editionA } \music > > %%%% END > > Why is something like that not possible? > n.b. I'm invoking Occam’s Razor here: I’ll happily accept more complexity > only if it is required for greater power. ;) Hm, what might be possible? First: It is good, that you brought up an "editionA" tag. Second: I try to explain some background: There are multiple distinct attributes to address a location, where, when and if an override shall be applied: 1) edition-engraver id, which is in fact a path to the context 2) measure and moment in music 3) edition-flight-name - or whatever to call that ;) 1) The engraver-id is my.test in the given example, it might be "kieren.musical.about.something" or anthing else. And you can use kieren.musical.about.something.strings.violin.III, to discriminite separate groups. 2) self-explanatory 3) You used editionA in your example - and that is actually what I thought of: One wants to have an editionA for the full-score and an editionB for the soloist parts and so on. A proposed name might be "flight-name" for that. The editionMod command takes a flight name as first argument and the addEdition command doesn't need to be called before that. So you might do in the music definition part (pseudo-code): %%% \editionMod fullscore 2 1/4 path.to.Staff.A \shape #'(<shape for the full-score>) Slur \editionMod part 2 1/4 path.to.Staff.A \shape #'(<shape for the instrumental part>) Slur %%% And then creating part (pseudo-code): %%% \include "edition-engraver.ly" \include "the-music.ly" \include "the-editions.ly" \addEdition fullscore \include "fullscore-template.ly" %%% There are multiple entities to acknowledge: The music, the engraving-process and the edition modifications. It is a lot easier to apply edition-modifications, if the engraving-instructions are really not a part of the music-input. That means, the music has to be stored in a way, that some kind of template is able to engrave it, without knowing anything about the music except, where it is stored. That might be declared variable names. Then you declare the music in variables and the active edition-flightnames. Then you call the proper template to engrave the music. btw: I started a little more writing about the template engine in lalily. https://github.com/jpvoigt/lalily/blob/master/examples/lalily-templates.md That is, where my ideas to the edition-engraver came from. Thats it for now, but ... the challenge just has started ;) Best, Jan-Peter _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user