On Tue, 2021-11-02 at 16:58 +0200, Lib Lists wrote:
> Hi and thank you as always!
> Comments below.
>
> On Mon, 1 Nov 2021 at 19:40, Richard Shann
> wrote:
> >
> > On Mon, 2021-11-01 at 18:01 +0200, Lib Lists wrote:
> > > Hi,
> > > a couple of questions:
> > >
> > > 1. I would like to use a custom G clef in my scores, in
> > > particular
> > > this one: http://lilybin.com/vxtdv7/1.
> >
> > That example can be done by pasting the text from the top to the
> > \clefGScore line into the LilyPond Score Prolog:
> >
> > Command: LilyPond Score Prolog
> > Inserts LilyPond syntax for include files etc at head of score.
> > Location: Object Menu ▶ Score
> > Internal Name: ScoreProlog
>
> In one of my scores (a collection of exercises consisting of many
> movements) I'm using the Score Prolog to insert a long introductory
> text between the main title (added via Score->Titles->Simple
> Titles->Set Titles) and the first movement. I'd like if possible to
> keep the Score Prolog free from other elements that I might change in
> the future. Or better, is there another way to place the introductory
> text, freeing the Score Prolog for the custom G clef?
yes, having created it once you can go into the Score Properties Editor
and click "Get Script into Scheme Window". Once you have this script
you can change the tag to a suitable name (avoiding name clashes with
any other command - prefix with Lib- or something) and while you are
there reduce the d-PutDirective ...-display tag "." to
something shorter (I think the ScoreProlog command should truncate it
really...). Then you can create a palette button or a command to
install this and it will no longer be overwritten by a further use of
ScoreProlog (it's that tag being different that causes it not to be
overwritten).
Note that the "Get Script into Scheme Window" makes a script that only
installs the prolog if it is not already present, so don't be caught
out if you are trying to write different versions of it as it won't
overwrite, you would have to go in and delete the old directive. (The
alternative is the "Create Button for Clone" which creates a script in
a palette button, that script *will* overwrite).
>
>
> >
> > as I have done in the example score attached.
> >
> > You could make the LilyPond syntax less monolithic by creating the
> > definition of the variable \clefGScore using the command:
> >
> > Command: LilyPond Definition
> > Create a definition at the head of the LilyPond output. This can
> > then
> > be referenced in the music. See LilyPond documentation.
> > Location: Object Menu ▶ Score
> > Internal Name: LilyPondDefinition
> >
> > and you *could* place the first bit which calls the define-markup-
> > command procedure to the head of the LilyPond syntax but there are
> > no
> > ready made commands for that, you would need to write the Scheme
> > (in
> > the source code is the "examples" directory that has a Denemo Score
> > with all the variety of placements that can be done for the
> > LilyPond
> > syntax but it would be a bit of a slog for you to sort that out...)
>
> I tried to find the Denemo Score you mentioned, but I could find only
> one called AllFeaturesExplained, but I don't think it's the one you
> referred to.
http://git.savannah.gnu.org/gitweb/?p=denemo.git;a=blob;f=samples/AllDenemoDirectiveOutputs.denemo;h=af852cd91f02d0fdb55a2b5d0bc6f57799c3ac62;hb=HEAD
is the Denemo score I meant.
>
> >
> >
> > >
> > > 2. I'd like to use a Roman font family for the chord symbols, as
> > > in
> > > here: http://lilybin.com/x9shb7/1
> >
> > That's easier you can just use
> >
> > Command: Insert Lilypond
> > Insert or edit a directive in the LilyPond music typesetting
> > language.
> > This can be used for extra spacing, transposing or almost anything.
> > See
> > LilyPond documentation for ideas.
> > Location: Object Menu ▶ Directives
> > Internal Name: InsertStandaloneDirective
> >
> > to insert the syntax
> >
> > \override ChordName.font-family = #'roman
> >
> > before the chords you want to appear in roman or whatever, as in
> > the
> > attached. Again there are more elegant ways (for the LilyPond
> > view),
> > but if you are not going on to edit the LilyPond you may not care
> > to
> > get involved.
>
> Thank you for this, it will work for now. However, thinking about the
> future, I might want to keep all the visual customizations separated,
> creating a sort of style sheet
That could be a template or a Scheme script, or even Scheme written
into the initialization script that is run whenever you open a file.
> that I can change (for example I
> predict I might switch fonts after the adoption of SMuFL in LilyPond
> will be completed).
> Thank you!
> Lib
>
> >
> > Richard
> >
