Re: Beam direction property

[David Nalesnik]

On Wed, Jul 13, 2016 at 6:09 PM, Andrew Bernard
 wrote:
> Hi David,
>
> Fantastic. This function should be widely publicised to any who dare
> to undertake the dangerous journey through the dark and enchanted
> forests of Lilypond Tweaking.
>

Unfortunately, public Scheme functions don't get automatically
documented, so functions like this are nicely tucked away.  A while
ago I was playing around with getting them into the docs, but I forgot
all about it apparently.  Anyway, you can get a list of what's in the
code base -- along with the doc strings...such as they are -- with the
routine here:

http://www.mail-archive.com/lilypond-user%40gnu.org/msg100337.html

Oh, I remember what stopped me.  How do you get at the parameters of a
curried function?  Also, the thought of how horrible that list of
DOCME, DOCME, DOCME would look in official documentation.

David

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Beam direction property

[Andrew Bernard]

Hi David,

Fantastic. This function should be widely publicised to any who dare
to undertake the dangerous journey through the dark and enchanted
forests of Lilypond Tweaking.

Most appreciated.

Andrew

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Beam direction property

[David Nalesnik]

On Wed, Jul 13, 2016 at 5:53 PM, tisimst  wrote:
> On Wed, Jul 13, 2016 at 4:36 PM, Andrew Bernard [via Lilypond] <[hidden
> email]> wrote:
>>
>> Hi Abraham,
>>
>> Thanks for the suggestion. Since lilypond internals are not documented
>> nicely, in terms of plain examples and behaviour, you just have to use trial
>> and error to code these things (unless there is a Secret Book I am unaware
>> of…). Using the beam seems to work better for the right hand case nad for my
>> way of doing it, for reasons too long to explain just here. I still need to
>> know what the Beam.direction property is, and why it can’t be set, and what
>> it represents. It is this sort to information that that NR and IR lack,
>> frustratingly,
>>
>> Things like knowing a beam has a stems object. How does one find out about
>> things like this, without reading al the source code, and trying to figure
>> that out?
>>
>> I do need the beam information and understanding because there are other
>> beam modifications I want to make as well involving changing the beam shape
>> in certain ways.
>
>
> Believe me, I understand your frustration. Here are a couple of things I've
> learned about the IR:
>
> 1. The "Standard Settings" table on grob's web page are all grob properties
> that have been defined in "define-grobs.scm" or internally in the C++ source
> code.
> 2. At the top of each grob's web page is shows which engraver(s) creates the
> grob. Clicking on the engraver links leads to a page that shows engraver
> properties that you can modify to adjust the engraver's procedure.
> 3. At the bottom of each grob's web page it shows the interface(s) that
> affect the grob, including generic ones (e.g., font-interface) and some
> grob-specific ones (e.g., beam-interface) though the grob may not know how
> to use all user-settable properties in each of these interfaces. Clicking on
> the interface link(s) leads to more grob properties that you can
> access/change via ly:grob-property and ly:grob-set-property!, respectively.
> Towards of the bottom of the interface web page will be a "Interface
> Properties" table that lists various objects that the grob has access to.
> This is where you find out that a Beam grob has a 'stems object you can
> access via ly:grob-object.
>
> In this particular case, you can access the 'stems from the Beam grob or,
> vice-versa, the 'beam from the Stem grob. You pick.
>

A function which you might find useful is grob::display-objects.  From
the commit message:

"Issue 4328: Add means to display objects accessible from a grob

A convenient way to display the grobs and grob-objects pointed to by
various internal properties of a given grob would be very helpful for
debugging and development purposes.  For example, it would facilitate the
creation of advanced tweaks, which frequently require "lateral" access
to other grobs.

The output of the function 'grob::display-objects' shows all of the grobs
accessible to a given grob through ly:grob-object together with the relevant
interfaces and properties.  It includes properties which are empty: not all
properties within an interface may be set for or used by a grob supporting
that interface."



You'd simply call it with the grob as argument.

Hope this is helpful--
David

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Beam direction property

[tisimst]

On Wed, Jul 13, 2016 at 4:36 PM, Andrew Bernard [via Lilypond] <
ml-node+s1069038n192676...@n5.nabble.com> wrote:

> Hi Abraham,
>
> Thanks for the suggestion. Since lilypond internals are not documented
> nicely, in terms of plain examples and behaviour, you just have to use
> trial and error to code these things (unless there is a Secret Book I am
> unaware of…). Using the beam seems to work better for the right hand case
> nad for my way of doing it, for reasons too long to explain just here. I
> still need to know what the Beam.direction property is, and why it can’t be
> set, and what it represents. It is this sort to information that that NR
> and IR lack, frustratingly,
>
> Things like knowing a beam has a stems object. How does one find out about
> things like this, without reading al the source code, and trying to figure
>  that out?
>
> I do need the beam information and understanding because there are other
> beam modifications I want to make as well involving changing the beam shape
> in certain ways.
>

Believe me, I understand your frustration. Here are a couple of things I've
learned about the IR:

1. The "Standard Settings" table on grob's web page are all grob properties
that have been defined in "define-grobs.scm" or internally in the C++
source code.
2. At the top of each grob's web page is shows which engraver(s) creates
the grob. Clicking on the engraver links leads to a page that shows
engraver properties that you can modify to adjust the engraver's procedure.
3. At the bottom of each grob's web page it shows the interface(s) that
affect the grob, including generic ones (e.g., font-interface) and some
grob-specific ones (e.g., beam-interface) though the grob may not know how
to use all user-settable properties in each of these interfaces. Clicking
on the interface link(s) leads to more grob properties that you can
access/change via ly:grob-property and ly:grob-set-property!, respectively.
Towards of the bottom of the interface web page will be a "Interface
Properties" table that lists various objects that the grob has access to.
This is where you find out that a Beam grob has a 'stems object you can
access via ly:grob-object.

In this particular case, you can access the 'stems from the Beam grob or,
vice-versa, the 'beam from the Stem grob. You pick.

HTH,
Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Beam-direction-property-tp192655p192677.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: Beam direction property

[Andrew Bernard]

Hi Abraham,

Thanks for the suggestion. Since lilypond internals are not documented
nicely, in terms of plain examples and behaviour, you just have to use
trial and error to code these things (unless there is a Secret Book I am
unaware of…). Using the beam seems to work better for the right hand case
nad for my way of doing it, for reasons too long to explain just here. I
still need to know what the Beam.direction property is, and why it can’t be
set, and what it represents. It is this sort to information that that NR
and IR lack, frustratingly,

Things like knowing a beam has a stems object. How does one find out about
things like this, without reading al the source code, and trying to figure
 that out?

I do need the beam information and understanding because there are other
beam modifications I want to make as well involving changing the beam shape
in certain ways.


Andrew
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Beam direction property

[tisimst]

On Wed, Jul 13, 2016 at 9:03 AM, Andrew Bernard [via Lilypond] <
ml-node+s1069038n192657...@n5.nabble.com> wrote:

> Hi Urs,
>
> I am sorry my email is confusing. I don’t want to adjust beams or stem
> directions here, I merely wantt to find out whether the beam is up or down.
> It seems Beam.direction gets set to random, or unintelligible, that is,
> impossibe to predict,  values.
>
> Along the debugging trail, I noticed the crashing behaviour of trying to
> set Beam. direction.
>

Why don't you override the Stem stencil instead, like in the original
snippet? I guess I can see why you want to put the \override before the
entire group, but anyway. Alternatively, you can access all the stems on
the beam with

(ly:grob-object grob 'stems)

>From that, you should be able to navigate to the correct one and determine
its direction, which is really what you want, but it would probably be
easier to just explicitly override the stencil of the last stem, but at
least you've got a couple of options.

--
Abraham Lee




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Beam-direction-property-tp192655p192658.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: Beam direction property

[Andrew Bernard]

Hi Urs,

I am sorry my email is confusing. I don’t want to adjust beams or stem
directions here, I merely wantt to find out whether the beam is up or down.
It seems Beam.direction gets set to random, or unintelligible, that is,
impossibe to predict,  values.

Along the debugging trail, I noticed the crashing behaviour of trying to
set Beam. direction.

Andrew
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Beam direction property

[Urs Liska]

Not sure about all the implications, but actually you don't want to flip
the BEAM but the STEM. So \override Stem.direction = -1 will do what you
want.


Am 13.07.2016 um 16:19 schrieb Andrew Bernard:
> Hello all,
>
> While writing my right hand side slash function for beams, when
> modifying the beam stencil to add a slash on the right I need to
> determine if the beam is up or down (on top or below the notes) and
> the beam slope, for my geometry calculations to work. I had thought
> that the ‘direction’ property of a Beam indicates whether it is up or
> down, but on careful examination I appear to be getting values I
> cannot understand. My minimal working example to debug this works
> perfectly, but my scheme code seems to produce unpredictable (to me)
> results. So the first question I have is: what is Beam.direction, in
> point of fact? I I set Beam.direction to 1, -1, or 0 with an override
> beams move an amount that I cannot understand but the beam stays on
> top or on the bottom.
>
> The IR says:
>
> direction (direction):
> ly:beam::calc-direction
> If side-axis is 0 (or X), then this property determines whether the
> object is placed LEFT, CENTER or RIGHT with respect to the other
> object. Otherwise, it determines whether the object is placed UP,
> CENTER or DOWN. Numerical values may also be used: UP=1, DOWN=-1,
> LEFT=-1, RIGHT=1, CENTER=0.
>
> But what does this really mean for beams? Using \override
> Beam.direction = 1 or -1 or 0 produces an error:
>
> \version "2.19.45"
>
> {
>   c''8[ e'' g'' c'']
>
>   \override Beam.direction = -1
>   c''8[ e'' g'' c'']
>
> }
>
> …
> Parsing...
> Interpreting music...
> Preprocessing graphical objects...
> programming error: Grob direction requested while calculation in progress.
> continuing, cross fingers
> programming error: Grob direction requested while calculation in progress.
> continuing, cross fingers
> programming error: Grob direction requested while calculation in progress.
> continuing, cross fingers
> programming error: Grob direction requested while calculation in progress.
> continuing, cross fingers
> Finding the ideal number of pages...
> Fitting music on 1 page...
> Drawing systems...
> Layout output to `/tmp/lilypond-rOxJao'…
> …
>
>
>
> Andrew
>
>
>
>
>
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Beam direction property

[Andrew Bernard]

Hello all,

While writing my right hand side slash function for beams, when modifying
the beam stencil to add a slash on the right I need to determine if the
beam is up or down (on top or below the notes) and the beam slope, for my
geometry calculations to work. I had thought that the ‘direction’ property
of a Beam indicates whether it is up or down, but on careful examination I
appear to be getting values I cannot understand. My minimal working example
to debug this works perfectly, but my scheme code seems to produce
unpredictable (to me) results. So the first question I have is: what is
Beam.direction, in point of fact? I I set Beam.direction to 1, -1, or 0
with an override beams move an amount that I cannot understand but the beam
stays on top or on the bottom.

The IR says:

direction (direction):
ly:beam::calc-direction
If side-axis is 0 (or X), then this property determines whether the object
is placed LEFT, CENTER or RIGHT with respect to the other object.
Otherwise, it determines whether the object is placed UP, CENTER or DOWN.
Numerical values may also be used: UP=1, DOWN=-1, LEFT=-1, RIGHT=1,
CENTER=0.

But what does this really mean for beams? Using \override Beam.direction =
1 or -1 or 0 produces an error:

\version "2.19.45"

{
  c''8[ e'' g'' c'']

  \override Beam.direction = -1
  c''8[ e'' g'' c'']

}

…
Parsing...
Interpreting music...
Preprocessing graphical objects...
programming error: Grob direction requested while calculation in progress.
continuing, cross fingers
programming error: Grob direction requested while calculation in progress.
continuing, cross fingers
programming error: Grob direction requested while calculation in progress.
continuing, cross fingers
programming error: Grob direction requested while calculation in progress.
continuing, cross fingers
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Layout output to `/tmp/lilypond-rOxJao'…
…



Andrew
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user