Re: Defining new contexts
On Tue, Feb 24, 2015 at 10:14:22AM -0700, Paul Morris wrote:
> Jim Long wrote
> > Is there a way I can define a context based on ChordNames and
> > have it automatically inherit all of the properties of a
> > ChordNames context, except the ones that I specifically change in
> > my custom definition?
>
> Yes, in fact you're already doing this, explained below...
>
>
> Jim Long wrote
> > In other words, a way to eliminate the
> > need for the second \context {} block in your example?
>
> The short answer is no. Whether (for example) a PianoStaff context can
> contain ("accepts") a ChordNames context or not is not a property of
> ChordNames but a property of PianoStaff. So you have to tell PianoStaff
> (and friends) to accept your new and unknown context.
Yes, I have sighed and accepted this. But it would be nice, if
it is practical, for "Higher" contexts to decide to accept "Lower"
contexts based on context name (\ChordNames) as well as on alias
(\alias ChordNames). On the prinicple that "any friend of
ChordNames is a friend of mine!"
> You can just do it once and put it in an include file so you don't have to
> do it again. That's what I do.
>
> (I suppose it would be possible to change how LilyPond handles this so that
> unknown/custom contexts were accepted by default by other contexts (rather
> than rejected by default).
I don't ask for "accepted by default," but I was hoping rather
that A would accept C because A accepts B, and C is explicitly
declared as an alias of B. Therefore, A would accept B and all
aliases of B.
> Or, probably better, introduce some kind of
> "passes as" property where you could tell other contexts to "treat this
> context like X context for purposes of accepting/rejecting it".)
??? I was hoping that "\alias ChordNames" would buy that for me.
> Hope that helps,
> -Paul
You have taken some of the sting out of it, but I will still be
grateful to anyone who has the time and a patch to make this more
automatic.
Thanks, Paul.
Jim
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Defining new contexts
Paul Morris wrote > Or, probably better, introduce some kind of "passes as" property where you > could tell other contexts to "treat this context like X context for > purposes of accepting/rejecting it". On second thought, why not just use the existing \alias for this too? Most of the time if we want commands from context-X to work in context-Y (by using \alias context-X), we also want context-Y to be accepted wherever context-X is accepted. So when say context-Z is determining whether to accept a new context-Y... have it first check context-Y's name, and if the name is unknown (not in its "accepts" list) then have it check context-Y's alias (context-X). If the alias context-X is in the "accepts" list, then context-Z would accept context-Y. In rare cases where we didn't want these things coupled (where we wanted commands from context-X to work in context-Y, but we didn't want context-Y to be accepted wherever context-X is accepted), then we could use \denies and \accepts to define exactly where we want context-Y to be accepted or denied. This would really simplify the process of creating custom contexts, especially in the common case of wanting a modified version of an existing context that works everywhere it does. Basically, it would work the way Jim expected it to. Anyway, it certainly seems like it would be a simplification and improvement, looking at it from this angle, but I'm not really familiar with how these things are used internally by LilyPond, so there may be more to it, reasons why it is set up the way it is... -Paul -- View this message in context: http://lilypond.1069038.n5.nabble.com/Defining-new-contexts-tp172185p172264.html Sent from the User mailing list archive at Nabble.com. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Defining new contexts
Jim Long wrote
> Is there a way I can define a context based on ChordNames and
> have it automatically inherit all of the properties of a
> ChordNames context, except the ones that I specifically change in
> my custom definition?
Yes, in fact you're already doing this, explained below...
Jim Long wrote
> In other words, a way to eliminate the
> need for the second \context {} block in your example?
The short answer is no. Whether (for example) a PianoStaff context can
contain ("accepts") a ChordNames context or not is not a property of
ChordNames but a property of PianoStaff. So you have to tell PianoStaff
(and friends) to accept your new and unknown context.
You can just do it once and put it in an include file so you don't have to
do it again. That's what I do.
(I suppose it would be possible to change how LilyPond handles this so that
unknown/custom contexts were accepted by default by other contexts (rather
than rejected by default). Or, probably better, introduce some kind of
"passes as" property where you could tell other contexts to "treat this
context like X context for purposes of accepting/rejecting it".)
Hope that helps,
-Paul
--
View this message in context:
http://lilypond.1069038.n5.nabble.com/Defining-new-contexts-tp172185p172251.html
Sent from the User mailing list archive at Nabble.com.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Defining new contexts
Hi Jim,
> Thank you. But if I have to do all the \Score \accepts stuff,
> then I guess I don't understand what '\alias ChordNames’ does
If I understand correctly, it allows your new context to accept any commands
that a \ChordNames context does.
> Is there a way I can define a context based on ChordNames and
> have it automatically inherit all of the properties of a
> ChordNames context, except the ones that I specifically change in
> my custom definition? In other words, a way to eliminate the
> need for the second \context {} block in your example?
Yes: don’t give it a new name. ;)
Hope this helps!
Kieren.
___
Kieren MacMillan, composer
www:
email: i...@kierenmacmillan.info
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Defining new contexts
On Mon, Feb 23, 2015 at 10:28:37AM +0100, Thomas Morley wrote:
>
> Try the following, comments inline:
>
> \score {
> <<
> \new XChords \chordmode { c1 }
> \new Staff \chordmode { c1 }
> >>
> \layout {
> \context {
> %% copies settings from ChordNames
> %% No need to create a new context from scratch
> \ChordNames
> \name XChords
> \alias ChordNames
> \override ChordName.font-size = #12
> }
> %% let Score accept XChords, likely need to let it be accepted by other
> %% context as well. I.e. do the same for Pianostaff, GrandStaff,
> ChoirStaff,
> %% maybe more, have a look in engraver-init.ly to see which contexts
> %% accept the default ChordNames
> \context {
> \Score
> \accepts XChords
> }
> } % layout
> }
>
> HTH,
> Harm
Thank you. But if I have to do all the \Score \accepts stuff,
then I guess I don't understand what '\alias ChordNames' does in
your example. I'd like to find a simple way of declaring that
"my custom context X is just like built-in context Y, except that
it modifies these settings." The appeal of that goes downhill
quickly if there are loose ends that have to be tied back into
Lilypond internals.
Is there a way I can define a context based on ChordNames and
have it automatically inherit all of the properties of a
ChordNames context, except the ones that I specifically change in
my custom definition? In other words, a way to eliminate the
need for the second \context {} block in your example?
Jim
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Defining new contexts
Jim Long wrote > I'm experimenting with defining and using custom contexts. Hi Jim, Looks like Harm has you covered. See also this snippet that shows how to define a custom staff context: http://lsr.di.unimi.it/LSR/Item?id=882 If you are generating midi files you will also need to define your context for midi as well as layout, as shown in that snippet. Otherwise you will get warnings. HTH, -Paul -- View this message in context: http://lilypond.1069038.n5.nabble.com/Defining-new-contexts-tp172185p172192.html Sent from the User mailing list archive at Nabble.com. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Defining new contexts
2015-02-23 9:56 GMT+01:00 Jim Long :
> I'm experimenting with defining and using custom contexts.
>
> I have not succeeded in applying the example at:
>
> http://lilypond.org/doc/v2.18/Documentation/notation/defining-new-contexts
>
> to my tiny example below attempting the creation of a custom
> ChordNames context. The '\new XChords' line throws a warning:
>
> GNU LilyPond 2.18.2
> Processing `foo.ly'
> Parsing...
> Interpreting music...
> Preprocessing graphical objects...
> Interpreting music...
> warning: cannot find or create new `XChords'
> Preprocessing graphical objects...
> Finding the ideal number of pages...
> Fitting music on 1 page...
> Drawing systems...
> Layout output to `foo.ps'...
> Converting to `./foo.pdf'...
> Success: compilation successfully completed
>
>
> How can I modify the second score's source to have the scores
> engrave the same in the output file?
>
> Thank you!
>
> Jim
>
>
> \version "2.18.2"
>
> \score {
> \layout {
> \context {
> \ChordNames
> \override ChordName.font-size = #12
> } % context
> } % layout
> <<
> \new ChordNames \chordmode { c1 }
> \new Staff \chordmode { c1 }
> >>
> }
>
>
> \score {
> \layout {
> \context {
> \name XChords
> \alias ChordNames
> \override ChordName.font-size = #12
> \type "Engraver_group"
> } % context
> } % layout
> <<
> \new XChords \chordmode { c1 }
> \new Staff \chordmode { c1 }
> >>
> }
Try the following, comments inline:
\score {
<<
\new XChords \chordmode { c1 }
\new Staff \chordmode { c1 }
>>
\layout {
\context {
%% copies settings from ChordNames
%% No need to create a new context from scratch
\ChordNames
\name XChords
\alias ChordNames
\override ChordName.font-size = #12
}
%% let Score accept XChords, likely need to let it be accepted by other
%% context as well. I.e. do the same for Pianostaff, GrandStaff, ChoirStaff,
%% maybe more, have a look in engraver-init.ly to see which contexts
%% accept the default ChordNames
\context {
\Score
\accepts XChords
}
} % layout
}
HTH,
Harm
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Defining new contexts
I'm experimenting with defining and using custom contexts.
I have not succeeded in applying the example at:
http://lilypond.org/doc/v2.18/Documentation/notation/defining-new-contexts
to my tiny example below attempting the creation of a custom
ChordNames context. The '\new XChords' line throws a warning:
GNU LilyPond 2.18.2
Processing `foo.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...
Interpreting music...
warning: cannot find or create new `XChords'
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Layout output to `foo.ps'...
Converting to `./foo.pdf'...
Success: compilation successfully completed
How can I modify the second score's source to have the scores
engrave the same in the output file?
Thank you!
Jim
\version "2.18.2"
\score {
\layout {
\context {
\ChordNames
\override ChordName.font-size = #12
} % context
} % layout
<<
\new ChordNames \chordmode { c1 }
\new Staff \chordmode { c1 }
>>
}
\score {
\layout {
\context {
\name XChords
\alias ChordNames
\override ChordName.font-size = #12
\type "Engraver_group"
} % context
} % layout
<<
\new XChords \chordmode { c1 }
\new Staff \chordmode { c1 }
>>
}
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Tip: defining new contexts ... starting from existing contexts
2007/9/11, Graham Percival <[EMAIL PROTECTED]>: > We *need* to settle on the overall design of the manual before we can > start doing things like this. Hence the last sentence in my previous mail :) 2007/9/11, Valentin Villenave <[EMAIL PROTECTED]>: > But this will take place in several weeks anyway. Regards, Valentin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Tip: defining new contexts ... starting from existing contexts
Trevor Bača wrote: On 9/11/07, Valentin Villenave <[EMAIL PROTECTED]> wrote: (For the original mail, see http://lists.gnu.org/archive/html/lilypond-user/2007-07/msg00526.html ) Sure. If you or Graham tell me where to stick the content, I'll turn that post into real docs. Thanks for the offer, but this is exactly what I don't want to be doing now... (I've lost track of the halftime score on the doc discussion: in the 2.11 manual, ... for precisely this reason. :) We *need* to settle on the overall design of the manual before we can start doing things like this. Make a note of that link, and we'll revisit it once we get to GDPizing that chapter. Cheers, - Graham ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Tip: defining new contexts ... starting from existing contexts
2007/9/11, Trevor Bača <[EMAIL PROTECTED]>: > (I've lost track of the halftime score on the doc discussion: in the > 2.11 manual, 9.2.7 "Defining new contexts" talks about this stuff; > under the 2.11 structure I would say that we rename 9.2.7 "Defining > new contexts from scratch" and then create a new subsection (9.2.8) > "Defining new contexts from existing contexts". But do we want two > sections like this in the new manual? Or are we now lumping such > things together? Just let me know and I'll write accordingly.) The whole thing is to be rewritten from scratch during the GDP-ization process, so I guess Graham will be glad if he's offered some help then. But this will take place in several weeks anyway. Valentin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Tip: defining new contexts ... starting from existing contexts
On 9/11/07, Valentin Villenave <[EMAIL PROTECTED]> wrote: > 2007/7/21, Valentin Villenave <[EMAIL PROTECTED]>: > > > Looks great (I've often been looking for such a tip in the past). > > > > I'll make a patch soon. > > Mmm... still haven't made any patch yet :( Sorry. > > Since we're talking about GDP and rewriting changing-defaults.itely, I > think we shouldn't forget to add your tip about the order of > definitions, Trevor. > (For the original mail, see > http://lists.gnu.org/archive/html/lilypond-user/2007-07/msg00526.html > ) Sure. If you or Graham tell me where to stick the content, I'll turn that post into real docs. (I've lost track of the halftime score on the doc discussion: in the 2.11 manual, 9.2.7 "Defining new contexts" talks about this stuff; under the 2.11 structure I would say that we rename 9.2.7 "Defining new contexts from scratch" and then create a new subsection (9.2.8) "Defining new contexts from existing contexts". But do we want two sections like this in the new manual? Or are we now lumping such things together? Just let me know and I'll write accordingly.) -- Trevor Bača [EMAIL PROTECTED] ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Tip: defining new contexts ... starting from existing contexts
2007/7/21, Valentin Villenave <[EMAIL PROTECTED]>: > Looks great (I've often been looking for such a tip in the past). > > I'll make a patch soon. Mmm... still haven't made any patch yet :( Sorry. Since we're talking about GDP and rewriting changing-defaults.itely, I think we shouldn't forget to add your tip about the order of definitions, Trevor. (For the original mail, see http://lists.gnu.org/archive/html/lilypond-user/2007-07/msg00526.html ) Regards, Valentin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Tip: defining new contexts ... starting from existing contexts
2007/7/21, Trevor Bača <[EMAIL PROTECTED]>: The following is a short write-up on how to define new contexts starting from existing contexts. The tip augments 9.2.7 "Defining new contexts" which explains how to define new contexts starting from scratch. Looks great (I've often been looking for such a tip in the past). I'll make a patch soon. Thanks, Valentin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Tip: defining new contexts ... starting from existing contexts
Hi,
The following is a short write-up on how to define new contexts
starting from existing contexts. The tip augments 9.2.7 "Defining new
contexts" which explains how to define new contexts starting from
scratch.
Consider the following red-and-blue score.
%%% EX 1 %%%
\version "2.11.26"
\new Score <<
\new Staff \with {
\override NoteHead #'color = #red
\override Stem #'color = #red
} {
c'4 c'4 c'4 c'4
}
\new Staff \with {
\override NoteHead #'color = #blue
\override Stem #'color = #blue
} {
c'4 c'4 c'4 c'4
}
>>
%%% EX 1 %%%
The red-and-blue score in example 1 instantiates two separate staves,
reddens the with-block of the first staff, and then turns the
with-block of the second staff blue.
This approach works great but mixes formatting directives and note
entry together. Maybe externalizing our overrides will give us a
cleaner inputfile.
9.2.6 "Changing context default settings" tells us how change contexts
globally. But this approach is unavailable to us here.
%%% EX 2 %%%
\version "2.11.26"
\layout {
\context {
\Staff
\override NoteHead #'color = #red
\override Stem #'color = #red
\override NoteHead #'color = #blue
\override Stem #'color = #blue
}
}
\new Score <<
\new Staff {
c'4 c'4 c'4 c'4
}
\new Staff {
c'4 c'4 c'4 c'4
}
>>
%%% EX 2 %%%
We can't override the global staff context to be both red and blue.
When we try, the interpreter overwrites our red overrides with our
blue overrides. Our red-and-blue score comes out only blue.
Instead, we've got two different types of staff. So we define two new contexts.
9.2.7 "Defining new contexts" tells us how to define new contexts from
scratch. But the default staff context does an awful lot of work. And
defining new staff contexts from scratch is a pain.
%%% EX 3 %%%
\version "2.11.26"
\layout {
\context {
\type "Engraver_group"
\name "RedStaff"
\consists "Output_property_engraver"
\consists "Bar_engraver"
\consists "Font_size_engraver"
\consists "Volta_engraver"
\consists "Separating_line_group_engraver"
\consists "Dot_column_engraver"
\consists "Staff_collecting_engraver"
\consists "Ottava_spanner_engraver"
\consists "Clef_engraver"
\consists "Key_engraver"
\consists "Time_signature_engraver"
\consists "Ledger_line_engraver"
\consists "Staff_symbol_engraver"
\consists "Collision_engraver"
\consists "Rest_collision_engraver"
\consists "Accidental_engraver"
\consists "Piano_pedal_engraver"
\consists "Piano_pedal_align_engraver"
\consists "Instrument_name_engraver"
\consists "String_number_engraver"
\consists "Axis_group_engraver"
\consists "Figured_bass_engraver"
\consists "Figured_bass_position_engraver"
\consists "Script_row_engraver"
localKeySignature = #'()
createSpacing = ##t
ignoreFiguredBassRest = ##t
instrumentName = #'()
shortInstrumentName = #'()
\defaultchild "Voice"
\accepts "Voice"
\accepts "CueVoice"
\override NoteHead #'color = #red
\override Stem #'color = #red
}
\context {
\type "Engraver_group"
\name "BlueStaff"
\consists "Output_property_engraver"
\consists "Bar_engraver"
\consists "Font_size_engraver"
\consists "Volta_engraver"
\consists "Separating_line_group_engraver"
\consists "Dot_column_engraver"
\consists "Staff_collecting_engraver"
\consists "Ottava_spanner_engraver"
\consists "Clef_engraver"
\consists "Key_engraver"
\consists "Time_signature_engraver"
\consists "Ledger_line_engraver"
\consists "Staff_symbol_engraver"
\consists "Collision_engraver"
\consists "Rest_collision_engraver"
\consists "Accidental_engraver"
\consists "Piano_pedal_engraver"
\consists "Piano_pedal_align_engraver"
\consists "Instrument_name_engraver"
\consi
