Re: Scheme: get current beam-thickness
Am So., 26. Jan. 2020 um 12:41 Uhr schrieb David Kastrup :
>
> Thomas Morley writes:
>
> > Am Sa., 25. Jan. 2020 um 20:31 Uhr schrieb Aaron Hill
> > :
> >>
> >> On 2020-01-25 10:39 am, David Stephen Grant wrote:
> >> > I'm trying to create a custom flag stencil, and would like to get the
> >> > current _beam_ thickness. As a first step, in the following example I
> >> > would
> >> > expect 0.5, then 1, to be printed to the console. Is there a way of
> >> > doing
> >> > this?
> >>
> >> With a little bit of encouragement, yes:
> >>
> >>
> >> \version "2.19.83"
> >>
> >> BeamThicknessToFlag_engraver = #(lambda (...)
> >>`((acknowledgers
> >>(flag-interface . ,(lambda (engraver grob source-engraver)
> >> (ly:grob-set-property! grob 'beam-thickness
> >>(ly:assoc-get 'beam-thickness
> >> (ly:context-grob-definition
> >>(ly:translator-context engraver)
> >>'Beam
> >>
> >> customFlag = #(lambda (grob)
> >>(let ((bt (ly:grob-property grob 'beam-thickness)))
> >> (grob-interpret-markup grob #{ \markup #(number->string bt) #})))
> >>
> >> \new Voice
> >> \with { \consists \BeamThicknessToFlag_engraver }
> >> {
> >>\override Flag.stencil = \customFlag
> >>
> >>c'8 r8
> >>
> >>\override Beam.beam-thickness = #0.5
> >>c'8 r8
> >>
> >>\override Beam.beam-thickness = #1.0
> >>c'8 r8
> >>
> >>\revert Beam.beam-thickness
> >>c'8 r8
> >> }
> >>
> >
> > Hi Aaron,
> >
> > I stand corrected, it is possible.
> > Alas, going for a custom-engraver feels overdone, if not really
> > needed. Thus I asked about the final goal.
> >
> > Even at the risk being regarded as a nitpicker and also being aware we
> > have similar codings (wrt to juggling grob-properties) in our docs,
> > the code will return several programming errors if compiled with
> > -dcheck-internal-types.
>
> I have some incomplete work in branches that would significantly speed
> up property accesses but would not support undeclared properties.
>
> Not that we have a good interface for adding them yet...
Furthermore, ly:add-interface obviously creates a _new_ interface, not
adding something to a probably preexistent one, as I naively assumed.
So below should better read:
#(ly:add-interface
'flag-interface
"A flag"
'(beam-thickness
glyph-name
stroke-style
style))
>
> > To cure, one could add:
> > #(ly:add-interface
> > 'flag-interface
> > "A flag"
> > '(beam-thickness))
>
> --
> David Kastrup
Cheers,
Harm
Re: Scheme: get current beam-thickness
Thomas Morley writes:
> Am Sa., 25. Jan. 2020 um 20:31 Uhr schrieb Aaron Hill
> :
>>
>> On 2020-01-25 10:39 am, David Stephen Grant wrote:
>> > I'm trying to create a custom flag stencil, and would like to get the
>> > current _beam_ thickness. As a first step, in the following example I
>> > would
>> > expect 0.5, then 1, to be printed to the console. Is there a way of
>> > doing
>> > this?
>>
>> With a little bit of encouragement, yes:
>>
>>
>> \version "2.19.83"
>>
>> BeamThicknessToFlag_engraver = #(lambda (...)
>>`((acknowledgers
>>(flag-interface . ,(lambda (engraver grob source-engraver)
>> (ly:grob-set-property! grob 'beam-thickness
>>(ly:assoc-get 'beam-thickness
>> (ly:context-grob-definition
>>(ly:translator-context engraver)
>>'Beam
>>
>> customFlag = #(lambda (grob)
>>(let ((bt (ly:grob-property grob 'beam-thickness)))
>> (grob-interpret-markup grob #{ \markup #(number->string bt) #})))
>>
>> \new Voice
>> \with { \consists \BeamThicknessToFlag_engraver }
>> {
>>\override Flag.stencil = \customFlag
>>
>>c'8 r8
>>
>>\override Beam.beam-thickness = #0.5
>>c'8 r8
>>
>>\override Beam.beam-thickness = #1.0
>>c'8 r8
>>
>>\revert Beam.beam-thickness
>>c'8 r8
>> }
>>
>
> Hi Aaron,
>
> I stand corrected, it is possible.
> Alas, going for a custom-engraver feels overdone, if not really
> needed. Thus I asked about the final goal.
>
> Even at the risk being regarded as a nitpicker and also being aware we
> have similar codings (wrt to juggling grob-properties) in our docs,
> the code will return several programming errors if compiled with
> -dcheck-internal-types.
I have some incomplete work in branches that would significantly speed
up property accesses but would not support undeclared properties.
Not that we have a good interface for adding them yet...
> To cure, one could add:
> #(ly:add-interface
> 'flag-interface
> "A flag"
> '(beam-thickness))
--
David Kastrup
Re: Scheme: get current beam-thickness
Am Sa., 25. Jan. 2020 um 20:31 Uhr schrieb Aaron Hill
:
>
> On 2020-01-25 10:39 am, David Stephen Grant wrote:
> > I'm trying to create a custom flag stencil, and would like to get the
> > current _beam_ thickness. As a first step, in the following example I
> > would
> > expect 0.5, then 1, to be printed to the console. Is there a way of
> > doing
> > this?
>
> With a little bit of encouragement, yes:
>
>
> \version "2.19.83"
>
> BeamThicknessToFlag_engraver = #(lambda (...)
>`((acknowledgers
>(flag-interface . ,(lambda (engraver grob source-engraver)
> (ly:grob-set-property! grob 'beam-thickness
>(ly:assoc-get 'beam-thickness
> (ly:context-grob-definition
>(ly:translator-context engraver)
>'Beam
>
> customFlag = #(lambda (grob)
>(let ((bt (ly:grob-property grob 'beam-thickness)))
> (grob-interpret-markup grob #{ \markup #(number->string bt) #})))
>
> \new Voice
> \with { \consists \BeamThicknessToFlag_engraver }
> {
>\override Flag.stencil = \customFlag
>
>c'8 r8
>
>\override Beam.beam-thickness = #0.5
>c'8 r8
>
>\override Beam.beam-thickness = #1.0
>c'8 r8
>
>\revert Beam.beam-thickness
>c'8 r8
> }
>
Hi Aaron,
I stand corrected, it is possible.
Alas, going for a custom-engraver feels overdone, if not really
needed. Thus I asked about the final goal.
Even at the risk being regarded as a nitpicker and also being aware we
have similar codings (wrt to juggling grob-properties) in our docs,
the code will return several programming errors if compiled with
-dcheck-internal-types.
To cure, one could add:
#(ly:add-interface
'flag-interface
"A flag"
'(beam-thickness))
Best,
Harm
Re: Scheme: get current beam-thickness
On 2020-01-25 12:31 pm, David Kastrup wrote: ...proper English... I fear that ship has long sailed w.r.t. software engineering. Developers are too committed to their neologisms and jargon for any authoritative dictionary to keep meaningful pace with the vernacular. On this topic, I recall when Bill Watterson (via Calvin) famously said, "Verbing weirds language." That said, I commend you for keeping up the good fight. -- Aaron Hill
Re: Scheme: get current beam-thickness
Aaron Hill writes:
> On 2020-01-25 12:05 pm, David Kastrup wrote:
>> Aaron Hill writes:
>>
>>> On 2020-01-25 11:40 am, David Kastrup wrote:
Aaron Hill writes:
> I am unaware of any simpler approach, as it is my understanding that
> grobs do not persist the entire context within which they were
> created.
How would they then make it to the page? Suicided grobs have their
properties deleted prematurely, but those are not the rule.
> Mind you, I would love to be shown that I am incorrect.
This is Scheme anyway. In general, objects persist as long as you
are
able to reference them.
>>> Wait, do grobs have a reference to the context?
>> No, or this would cause the contexts to persist until the end of
>> typesetting.
>>
>>> I know you can use \applyOutput to process grobs at a given moment in
>>> time, and that provides you access to both the grobs and the context.
>>> And my snippet showed using an engraver to achieve something similar.
>>> But within, say, a stencil procedure, it seems like you only have the
>>> grob to work with. Is there some ly:grob-context method that I have
>>> been overlooking?
>> You wrote "it is my understanding that grobs do not persist the
>> entire
>> context within which they were created". "persist" is an intransitive
>> verb, so your statement was about the duration of grobs, not of
>> contexts.
>
> Wiktionary disagrees. The fourth definition is computing-specific and
> allows "persist" to be transitive: "to *cause* to be persisted, made
> permanent" (emphasis mine).
>
> But who cares what some crowd-sourced site says.
dak@lola:/usr/local/tmp/lilypond$ dict persist
3 definitions found
>From The Collaborative International Dictionary of English v.0.48 [gcide]:
Persist \Per*sist"\, v. i. [imp. & p. p. {Persisted}; p. pr. &
vb. n. {Persisting}.] [L. persistere; per + sistere to stand
or be fixed, fr. stare to stand: cf. F. persister. See
{Per-}, and {Stand}.]
To stand firm; to be fixed and unmoved; to stay; to continue
steadfastly; especially, to continue fixed in a course of
conduct against opposing motives; to persevere; -- sometimes
conveying an unfavorable notion, as of doggedness or
obstinacy.
[1913 Webster]
If they persist in pointing their batteries against
particular persons, no laws of war forbid the making
reprisals. --Addison.
[1913 Webster]
Some positive, persisting fops we know,
Who, if once wrong, will needs be always so. --Pope.
[1913 Webster]
That face persists.
It floats up; it turns over in my mind. --Mrs.
Browning.
[1913 Webster]
Syn: See {Persevere}, and {Insist}.
[1913 Webster] Persistence
>From WordNet (r) 3.0 (2006) [wn]:
persist
v 1: continue to exist; "These stories die hard"; "The legend of
Elvis endures" [syn: {prevail}, {persist}, {die hard},
{run}, {endure}]
2: be persistent, refuse to stop; "he persisted to call me every
night"; "The child persisted and kept asking questions" [syn:
{persevere}, {persist}, {hang in}, {hang on}, {hold on}]
3: stay behind; "The smell stayed in the room"; "The hostility
remained long after they made up" [syn: {persist}, {remain},
{stay}]
(3rd source is just a thesauraus).
> If you prefer "persist" only to be intransitive, then we need another
> verb or phrasing. How about: "Grobs do not maintain their own copy
> nor reference to the context in which they were created." Is that an
> accurate statement?
Yes. You could also just replace your transitive "persist" with "make
persist" or "cause to persist" and turn it into proper English. If you
want to use your 4th meaning, I'd strongly recommend using it only in
constructs where it cannot possibly be one of the other meanings.
--
David Kastrup
Re: Scheme: get current beam-thickness
On 2020-01-25 12:05 pm, David Kastrup wrote: Aaron Hill writes: On 2020-01-25 11:40 am, David Kastrup wrote: Aaron Hill writes: I am unaware of any simpler approach, as it is my understanding that grobs do not persist the entire context within which they were created. How would they then make it to the page? Suicided grobs have their properties deleted prematurely, but those are not the rule. Mind you, I would love to be shown that I am incorrect. This is Scheme anyway. In general, objects persist as long as you are able to reference them. Wait, do grobs have a reference to the context? No, or this would cause the contexts to persist until the end of typesetting. I know you can use \applyOutput to process grobs at a given moment in time, and that provides you access to both the grobs and the context. And my snippet showed using an engraver to achieve something similar. But within, say, a stencil procedure, it seems like you only have the grob to work with. Is there some ly:grob-context method that I have been overlooking? You wrote "it is my understanding that grobs do not persist the entire context within which they were created". "persist" is an intransitive verb, so your statement was about the duration of grobs, not of contexts. Wiktionary disagrees. The fourth definition is computing-specific and allows "persist" to be transitive: "to *cause* to be persisted, made permanent" (emphasis mine). But who cares what some crowd-sourced site says. If you prefer "persist" only to be intransitive, then we need another verb or phrasing. How about: "Grobs do not maintain their own copy nor reference to the context in which they were created." Is that an accurate statement? -- Aaron Hill
Re: Scheme: get current beam-thickness
Aaron Hill writes: > On 2020-01-25 11:40 am, David Kastrup wrote: >> Aaron Hill writes: >>> I am unaware of any simpler approach, as it is my understanding that >>> grobs do not persist the entire context within which they were >>> created. >> How would they then make it to the page? Suicided grobs have their >> properties deleted prematurely, but those are not the rule. >> >>> Mind you, I would love to be shown that I am incorrect. >> This is Scheme anyway. In general, objects persist as long as you >> are >> able to reference them. > > Wait, do grobs have a reference to the context? No, or this would cause the contexts to persist until the end of typesetting. > I know you can use \applyOutput to process grobs at a given moment in > time, and that provides you access to both the grobs and the context. > And my snippet showed using an engraver to achieve something similar. > But within, say, a stencil procedure, it seems like you only have the > grob to work with. Is there some ly:grob-context method that I have > been overlooking? You wrote "it is my understanding that grobs do not persist the entire context within which they were created". "persist" is an intransitive verb, so your statement was about the duration of grobs, not of contexts. -- David Kastrup
Re: Scheme: get current beam-thickness
On 2020-01-25 11:40 am, David Kastrup wrote: Aaron Hill writes: I am unaware of any simpler approach, as it is my understanding that grobs do not persist the entire context within which they were created. How would they then make it to the page? Suicided grobs have their properties deleted prematurely, but those are not the rule. Mind you, I would love to be shown that I am incorrect. This is Scheme anyway. In general, objects persist as long as you are able to reference them. Wait, do grobs have a reference to the context? I know you can use \applyOutput to process grobs at a given moment in time, and that provides you access to both the grobs and the context. And my snippet showed using an engraver to achieve something similar. But within, say, a stencil procedure, it seems like you only have the grob to work with. Is there some ly:grob-context method that I have been overlooking? -- Aaron Hill
Re: Scheme: get current beam-thickness
Thank you for the responses - I'll look into Aaron's suggestion, which looks like it may do the trick.
Re: Scheme: get current beam-thickness
Aaron Hill writes:
> On 2020-01-25 10:39 am, David Stephen Grant wrote:
>> I'm trying to create a custom flag stencil, and would like to get the
>> current _beam_ thickness. As a first step, in the following example
>> I would
>> expect 0.5, then 1, to be printed to the console. Is there a way of
>> doing
>> this?
>
> With a little bit of encouragement, yes:
>
>
> \version "2.19.83"
>
> BeamThicknessToFlag_engraver = #(lambda (...)
> `((acknowledgers
> (flag-interface . ,(lambda (engraver grob source-engraver)
> (ly:grob-set-property! grob 'beam-thickness
> (ly:assoc-get 'beam-thickness
> (ly:context-grob-definition
> (ly:translator-context engraver)
> 'Beam
>
> customFlag = #(lambda (grob)
> (let ((bt (ly:grob-property grob 'beam-thickness)))
> (grob-interpret-markup grob #{ \markup #(number->string bt) #})))
>
> \new Voice
> \with { \consists \BeamThicknessToFlag_engraver }
> {
> \override Flag.stencil = \customFlag
>
> c'8 r8
>
> \override Beam.beam-thickness = #0.5
> c'8 r8
>
> \override Beam.beam-thickness = #1.0
> c'8 r8
>
> \revert Beam.beam-thickness
> c'8 r8
> }
>
>
> I am unaware of any simpler approach, as it is my understanding that
> grobs do not persist the entire context within which they were
> created.
How would they then make it to the page? Suicided grobs have their
properties deleted prematurely, but those are not the rule.
> Mind you, I would love to be shown that I am incorrect.
This is Scheme anyway. In general, objects persist as long as you are
able to reference them.
--
David Kastrup
Re: Scheme: get current beam-thickness
On 2020-01-25 10:39 am, David Stephen Grant wrote:
I'm trying to create a custom flag stencil, and would like to get the
current _beam_ thickness. As a first step, in the following example I
would
expect 0.5, then 1, to be printed to the console. Is there a way of
doing
this?
With a little bit of encouragement, yes:
\version "2.19.83"
BeamThicknessToFlag_engraver = #(lambda (...)
`((acknowledgers
(flag-interface . ,(lambda (engraver grob source-engraver)
(ly:grob-set-property! grob 'beam-thickness
(ly:assoc-get 'beam-thickness
(ly:context-grob-definition
(ly:translator-context engraver)
'Beam
customFlag = #(lambda (grob)
(let ((bt (ly:grob-property grob 'beam-thickness)))
(grob-interpret-markup grob #{ \markup #(number->string bt) #})))
\new Voice
\with { \consists \BeamThicknessToFlag_engraver }
{
\override Flag.stencil = \customFlag
c'8 r8
\override Beam.beam-thickness = #0.5
c'8 r8
\override Beam.beam-thickness = #1.0
c'8 r8
\revert Beam.beam-thickness
c'8 r8
}
I am unaware of any simpler approach, as it is my understanding that
grobs do not persist the entire context within which they were created.
Mind you, I would love to be shown that I am incorrect.
-- Aaron Hill
Re: Scheme: get current beam-thickness
Am Sa., 25. Jan. 2020 um 19:40 Uhr schrieb David Stephen Grant
:
>
> I'm trying to create a custom flag stencil, and would like to get the current
> _beam_ thickness. As a first step, in the following example I would expect
> 0.5, then 1, to be printed to the console. Is there a way of doing this?
>
> Thanks,
> David
>
> \version "2.19.83"
> #(define (my-flag)
> (lambda (grob)
> (format #t "~a"
> ;;; GET THE CURRENT BEAM-THICKNESS
> )
> empty-stencil))
> {
> \override Flag.stencil = #(my-flag)
> \override Beam.beam-thickness = #0.5
> c'8 r8
> \override Beam.beam-thickness = #1.0
> c'8 r8
> }
Hi,
your example prints no Beams, actually no Beam-grob is created.
Thus any override for Beam will not find the grob to apply, in
consequence you can't read the grob-properties of a non-existing grob
from a different grob.
May I ask how your Flag will look? We have some code implemented in
the source which may help...
Cheers,
Harm
