Hello all,
I am used to this topic. And I made up my own tool, which is working for
me, but should be called experimental.
I always hesitate to post my github link, because its not well
formed/documented and a mixup of totally different things ...
but there is one engraver, which actually deals with the named situation:
https://github.com/jpvoigt/lalily
The edition engraver is used to make overrides in named contexts
separate from the music content:
%%%%%%%
\version "2.16.1"
\include "lalily.ly"
music = \new Staff \with {
\consists \editionEngraver #'(my edition)
} \new Voice \with {
\consists \editionEngraver #'(my edition)
} \repeat unfold 3 \relative c'' { bes4( a) c b }
\addEdition master
\editionMod master 2 0/4 #'(my edition Voice A) \once \override NoteHead
#'color = #red
\editionMod master 2 0/4 #'(my edition Voice A) \once \shape Slur #'((0
. 0)(0 . 1)(0 . 1)(0 . 0))
\score {
\music
\layout {
\context {
\Score
\consists \editionEngraver #'(my edition)
}
}
}
%%%%%%%
While I was working on a larger project, I didn't update to 2.17 yet.
But it will make the input of the path-lists to identify the contexts a
lot easier like
\editionMod master 2 0/4 my.edition.Voice.A {...}
The idea is to have a PDF or printout of the score to publish and I can
simply say for example the slur in measure 42 on the second quarter
needs a little shaping, without polluting the actual music content with
overrides. If I store the music in variables, I can include that file
and engrave a score with the needed overrides. (I say overrides, because
it might be difficult to use \tweak.)
Sometimes I use tags, but they can lead to extraordinary long lines -
polluting the input for one engraving task.
With my lalily framework I store the music in a file-structure-like tree
and call with templates, which are actually music-functions. You find
very few basic examples in the examples folder of the project. But thats
another topic.
Best, Jan-Peter
Am 26.11.2013 11:35, schrieb Urs Liska:
> Am 26.11.2013 11:31, schrieb Jan Nieuwenhuizen:
>> We used to have an experimental `tweak editor' that would store tweaks a
>> in a separate tweaks file. In some way it would be a nice intermediate
>> to put all manual tweaks in a separate file and merge them with the
>> actual source. It would be good to experiment more with that.
> A way to permanently separate music source from tweaks would be a good
> thing IMO. Separating content from appearance.
> If that would be possible one could switch a set of tweaks (i.e.
> different target formats) together with the different layout style sheets.
> Actually that's what tags do IISC, but of course they are way too mixed
> in the actual source file.
>
> Urs
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
