Re: Determining what parameters exist for an item

[David Kastrup]

Kieren MacMillan  writes:

> Hi Carl,
>
>> 4) Going to one of these interfaces […]
>> provides a list of user-settable properties for that interface
>
> Yes, but unless I’m missing something, you can’t find the default
> value(s) there, right?

Interfaces don't have default values.  Grobs have.

> I personally would love to be able to get, for any grob, a list of
> every settable value (“native” or “interfaced”) *including the default
> value for each setting*.

You mean, something like


3.1.24 ChordName


ChordName objects are created by: *note Chord_name_engraver::.

   Standard settings:

 ‘after-line-breaking’ (boolean):
  ‘ly:chord-name::after-line-breaking’

  Dummy property, used to trigger callback for
  ‘after-line-breaking’.

 ‘extra-spacing-height’ (pair of numbers):
  '(0.2 . -0.2)

  In the horizontal spacing problem, we increase the height of
  each item by this amount (by adding the ‘car’ to the bottom of
  the item and adding the ‘cdr’ to the top of the item).  In
  order to make a grob infinitely high (to prevent the
  horizontal spacing problem from placing any other grobs above
  or below this grob), set this to ‘(-inf.0 . +inf.0)’.

 ‘extra-spacing-width’ (pair of numbers):
  '(-0.5 . 0.5)

  In the horizontal spacing problem, we pad each item by this
  amount (by adding the ‘car’ on the left side of the item and
  adding the ‘cdr’ on the right side of the item).  In order to
  make a grob take up no horizontal space at all, set this to
  ‘(+inf.0 . -inf.0)’.

 ‘font-family’ (symbol):
  ‘'sans’

  The font family is the broadest category for selecting text
  fonts.  Options include: ‘sans’, ‘roman’.

 ‘font-size’ (number):
  ‘1.5’

  The font size, compared to the ‘normal’ size.  ‘0’ is
  style-sheet’s normal size, ‘-1’ is smaller, ‘+1’ is bigger.
  Each step of 1 is approximately 12% larger; 6 steps are
  exactly a factor 2 larger.  If the context property ‘fontSize’
  is set, its value is added to this before the glyph is
  printed.  Fractional values are allowed.

 ‘stencil’ (stencil):
  ‘ly:text-interface::print’

  The symbol to print.

 ‘word-space’ (dimension, in staff space):
  ‘0.0’

  Space to insert between words in texts.

 ‘Y-extent’ (pair of numbers):
  ‘# >’

  Extent (size) in the Y direction, measured in staff-space
  units, relative to object’s reference point.

-- 
David Kastrup

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

Re: Blank bars for scribbling in

[Schneidy]

Hi Richard,

You can use 'proportionalNotationDuration' e.g.:

\version "2.19.35"

\relative {
  %% example 1
  c' d e f
  \set Score.proportionalNotationDuration = #(ly:make-moment 1/64)
  \hideNotes
  %% Notes are kwnown but won't be shown
  g a b c
  \unset Score.proportionalNotationDuration
  \unHideNotes
  c b a g
  
  %% example 2
  \break
  c d e f
  \set Score.proportionalNotationDuration = #(ly:make-moment 1/1)
  %% Unknown notes
  s1
  \unset Score.proportionalNotationDuration
  c4 b a g
}

Cheers,
Pierre



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Blank-bars-for-scribbling-in-tp186334p186335.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

Blank bars for scribbling in

[Richard Shann]

In some contexts people want music interspersed with blank bars to be
filled in later by hand. Spacer rests achieve this, but I can't track
down any straight-forward way of controlling the size of the blank bar.
Anyone any ideas on this?

Richard



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

Re: Blank bars for scribbling in

[Schneidy]

e.g. :

\version "2.19.35"

blankBar =
#(define-music-function (my-duration notes) (integer? ly:music?)
  #{
  \set Score.proportionalNotationDuration = #(ly:make-moment 1 my-duration)
  \hideNotes
  #notes
  \unHideNotes
  \unset Score.proportionalNotationDuration
#})

\relative {
  %% example 1
  c' d e f
  %% Notes are known but won't be shown
  \blankBar #64 { g a b c }
  c b a g
 
  %% example 2
  \break
  c d e f
  %% Unknown notes 
  \blankBar #1 { s1 }
  c4 b a g
} 

Cheers,
~Pierre



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Blank-bars-for-scribbling-in-tp186334p186337.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: Blank bars for scribbling in

[Schneidy]

... and of course, this can be included in a music function:
http://www.lilypond.org/doc/v2.19/Documentation/extending/intermediate-substitution-functions.html

~Pierre



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Blank-bars-for-scribbling-in-tp186334p186336.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: Blank bars for scribbling in

[Urs Liska]

Am 24.01.2016 um 10:55 schrieb Richard Shann:
> In some contexts people want music interspersed with blank bars to be
> filled in later by hand. Spacer rests achieve this, but I can't track
> down any straight-forward way of controlling the size of the blank bar.
> Anyone any ideas on this?
>
> Richard

Try

 \override MultiMeasureRest #'minimum-length = #15

Maybe you have to use a real rest and hide it, like

\once \override MultiMeasureRest #'minimum-length = #15
\once \hide MultiMeasureRest
R1

HTH
Urs

>
>
>
> ___
> 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

Re: Edition-engraver: Multiple editions in same file

[Ben Strecker]

Thank you Jan-Peter and Kieren,

That helps clear up a lot of my confusion.

Ben

> On Jan 24, 2016, at 2:24 PM, Jan-Peter Voigt  wrote:
> 
> Hi Ben,
> 
> I was about to write about the three dimension to watch. But I have to think 
> about it, if I can change this.
> For now there will one set of editiontags per compilation. So every call to 
> \addEdition and \removeEdition will affect the list of active 
> modification-layers for the whole run. The compilation of a file is done in 
> multiple steps. The called commands act on in the first step, the actual 
> typesetting is done in another step.
> In my use-cases, I always have one edition-set per file, e.g. full-score or 
> part for single instruments. But your use-case looks reasonable. I attached 
> your example slightly modified, where the first score is modified, but not 
> the second. To achieve this, I used \applyContext, so that the \removeEdition 
> command is performed, when beginning typesetting th second score. The command 
> could be wrapped inside a little helper command.
> This technique has the pro, that it matches your use-case, but a big con, in 
> that it remixes content and design again.
> So I would not recommend this over the solution, you already found.
> Perhaps another solution is found another day ;-)
> 
> HTH for now
> Cheers
> Jan-Peter
> 
> Am 22.01.2016 um 22:00 schrieb Ben Strecker:
>> I’m working on a project that would have the same melody appearing in 
>> different ranges in the same document.  Each range has its own set of 
>> modifications through the edition-engraver, but using \removeEdition 
>> anywhere in the file appears to remove that edition for all of the scores.  
>> What is the best practice for managing multiple editions in the same file?  
>> 
>> I have attached a very simple example where I have two scores:  one that 
>> should have a color modification applied, and another that should not have 
>> any editionMods applied.
>> 
>> Thanks,
>> Ben
>> 
>> 
>> 
>> ___
>> 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

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

Re: Controlling hairpin length

[David Sumbler]

On Sat, 2016-01-23 at 13:27 +0100, Thomas Morley wrote:
> 2016-01-21 16:54 GMT+01:00 David Sumbler :
> 
> >
> > Unfortunately I am still getting some over-long hairpins.  I think that
> > perhaps this has nothing to do with myHairpinMinimumLength, because I
> > was getting these long hairpins before you ever sent it to me - this is
> > one of the reasons I was going to set about tweaking hairpin lengths in
> > the piece.
> >
> > The 2 bars I quoted before are:
> >
> > % bar 14
> > g8\< a b cs( ~ cs\mf\> b) d,\mp cs |
> > g8\< g a g fs4\mf\> r\invP |
> > d8\< e fs e as,(\mf\> b) r4\invP |
> > e2\< d4\mf\> fs8(-\ten\mp fs)-\ten |
> > % bar 15
> > b8 cs\< d e fs-\ten\> fs\! e d \time 3/2 |
> > b,8\mp as\< b cs as-\ten\> b\! r4 \time 3/2 |
> > r2 cs8-\ten\mf\> b\! r4 \time 3/2 |
> > g8 e\< fs e fs-\ten\> d\! r4 \time 3/2 |
> >
> > This is in \parallelMusic for a string quartet.
> 
> 
> If I compile it with the following code, without(!!) any override I
> get the attached image.
> 
> \parallelMusic #'(E F G H) {
> % bar 14
> g8\< a b cs( ~ cs\mf\> b) d,\mp cs |
> g8\< g a g fs4\mf\> r\invP |
> d8\< e fs e as,(\mf\> b) r4\invP |
> e2\< d4\mf\> fs8(-\ten\mp fs)-\ten |
> % bar 15
> b8 cs\< d e fs-\ten\> fs\! e d \time 3/2 |
> b,8\mp as\< b cs as-\ten\> b\! r4 \time 3/2 |
> r2 cs8-\ten\mf\> b\! r4 \time 3/2 |
> g8 e\< fs e fs-\ten\> d\! r4 \time 3/2 |
> }
> 
> \new StaffGroup <<
>   \new Staff \E
>   \new Staff \F
>   \new Staff \G
>   \new Staff \H
> >>
> 
> \new Staff \E
> \new Staff \F
> \new Staff \G
> \new Staff \H
> 
> Ofcourse there are some too short Hairpins, but I can't see any too long.
> 
> 
> Nevertheless I changed `my-hairpin-minimum-length' to
> 
> #(define (my-hairpin-minimum-length grob)
> "Sets @code{minimum-length} for @code{Hairpin}, if their left bound is not the
> @code{NoteColumn}.
> The visible length is actually the one, specified by an additional override 
> for
> @code{minimum-length} or the default.
> If left bound is @code{NoteColumn}, default or specified @code{minimum-length}
> will take over."
>   (let* ((bound-left (ly:spanner-bound grob LEFT))
>  (bound-right (ly:spanner-bound grob RIGHT))
>  (sys (look-up-for-parent 'System Y grob))
>  (left-x-ext (ly:grob-extent bound-left sys X))
>  (not-note-column?
>(lambda (g)
>  (not (and (ly:grob? g)
>(grob::has-interface g 'note-column-interface))
>  (if (and (not-note-column? bound-left)
>   (interval-sane? left-x-ext)
>   (> (abs (cdr left-x-ext))
>  (ly:grob-property-data grob 'minimum-length)))
>  (ly:grob-set-property! grob 'minimum-length
>(+
>   (ly:grob-property-data grob 'minimum-length)
>   (* (if (not-note-column? bound-right) 2 1) (cdr 
> left-x-ext)))
> 
> Applying it as before I get the second attached png.
> 
> Looks quite ok to me.
> Though please be aware, all I can do is to provide a more or less
> workable work around issue 2207.
> 
> There are a lot of things which determine actual Hairpin length.
> I doubt I can reasonable cover them.
> 
> I think you should do
> \revert Hairpin.before-line-breaking
> in cases where `myHairpinMinimumLength' doesn't return acceptable
> results and tweak manually.
> 
> 
> HTH,
>   Harm

I am utterly mystified by what is going on here.  I have tried the new
routine on both my string quartet and also on the code you provided.

In both cases I find that setting minimum-length to the value 2 gives
acceptable results.  (In the case of the full string quartet, I have
closely inspected only the two bars included in your code.)

If I set minimum-length to a value less than 2, then I get some hairpins
that are too short - hardly surprising.

But if I use any value of minimum-length greater than 2 up to about 6,
then again I get hairpins that are too short.  Indeed, with values
between about 2.5 and 5, I also get "decrescendo too small" warnings.

With values from about 7 upwards, the short hairpins are OK, but others
are too long.

In other words, the only value that I can find less than 6 or 7 and
which provides acceptable results is 2 - no more, and no less.

Incidentally, do you know what triggers the "decrescendo too small" and
similar warnings?  It does not seem to happen simply when the actual
hairpin is less than the minimum-length setting.

David


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

Re: Determining what parameters exist for an item

[Kieren MacMillan]

Hi David,

> Interfaces don't have default values.  Grobs have.

That’s my point.

> You mean, something like
> 3.1.24 ChordName

Well, that’s *those* values…
Those are the ones Charles and I (and, I assume, others) know how to find 
easily.

What, though, is the default value for ChordName.baseline-skip [via 
text-interface]? And all the other values for settings available via 
chord-name-interface, font-interface, grob-interface, item-interface, 
outside-staff-interface, rhythmic-grob-interface and text-interface?

Thanks,
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


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

Re: Determining what parameters exist for an item

[David Kastrup]

Kieren MacMillan  writes:

> Hi David,
>
>> Interfaces don't have default values.  Grobs have.
>
> That’s my point.
>
>> You mean, something like
>> 3.1.24 ChordName
>
> Well, that’s *those* values…
> Those are the ones Charles and I (and, I assume, others) know how to
> find easily.
>
> What, though, is the default value for ChordName.baseline-skip [via
> text-interface]?

Uh, unset?  It's not listed.  Cf

\new ChordNames
\chordmode
{
  \applyOutput ChordNames.ChordName #(lambda (g c p) (display (ly:grob-property 
g 'baseline-skip)))
  c1
}

which outputs () as expected.

> And all the other values for settings available via
> chord-name-interface, font-interface, grob-interface, item-interface,
> outside-staff-interface, rhythmic-grob-interface and text-interface?

Unset?  I don't really know what you are talking about.  Layout
properties rather than grob properties?  Those are, unless overriden by
a grob, global.  But their values may well depend on stuff like the
current staff size and your preferred style sheets so there is not
really a lot that could actually be listed with some confidence.

-- 
David Kastrup

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

Slashed grace with long slur

[Ralph Palmer]

Hi, All -

I'm running Ly 2.19.33 under Win7.

I'm trying to transcribe a slashed grace note with a long slur, as in the
attachment
slur.png.
I've been unable to get the slur to stay up. I've tried
\slurUp
in conjunction with both
\slashedGrace
and
\acciaccatura
with no success.
The attached .ly and .pdf files show the results. \slurUp does not work on
a normal acciaccatura, either.

Is my only option to use
\shape   ?
Using \shape should work, I believe, but will probably mean a *lot* of
adjustment - I need to produce almost forty of these.

I'm grateful for any assistance,

Ralph

-- 
Ralph Palmer
Brattleboro, VT
USA
palmer.r.vio...@gmail.com
\version "2.19.33"

\language "english"

slashedGraceWithSlur = 
\relative c'' {
  
  %% using \slashedGrace  %%%
  \slurUp
  b16(^"Using \slashedGrace" cs d8) \slurUp \slashedGrace { e8( } d b) b4 b | 
  \break
  
    using \acciaccatura  %
  \slurUp
  b16(^"Using \acciaccatura" cs d8) \acciaccatura {e8(} d b) \acciaccatura {e8(} d b) b4 b |
}

\score {
  \slashedGraceWithSlur
}

slashed grace with slur test.pdf
Description: Adobe PDF document
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Slashed grace with long slur

[Kristin Rollins]

It worked for me to move the \slurUp command inside the \shlashedGrace, as in:

\slashGrace { \slurUp e8( } d b)

Kristin



On Sun, Jan 24, 2016, at 08:51 AM, Ralph Palmer wrote:
> Hi, All -
>
> I'm running Ly 2.19.33 under Win7.
>
> I'm trying to transcribe a slashed grace note with a long slur, as in
> the attachment slur.png. I've been unable to get the slur to stay up.
> I've tried \slurUp in conjunction with both \slashedGrace and
> \acciaccatura with no success. The attached .ly and .pdf files show
> the results. \slurUp does not work on a normal acciaccatura, either.
>
> Is my only option to use \shape   ? Using \shape should work, I
> believe, but will probably mean a *lot* of adjustment - I need to
> produce almost forty of these.
>
> I'm grateful for any assistance,
>
> Ralph
>
> --
> Ralph Palmer Brattleboro, VT USA palmer.r.vio...@gmail.com
> _
> lilypond-user mailing list lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user Email had 3
> attachments:


>  * slashed grace with slur test.ly  1k (text/lilypond-source)
>  * slashed grace with slur test.pdf  55k (application/pdf)
>  * Slur.png  4k (image/png)
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Blank bars for scribbling in

[Richard Shann]

On Sun, 2016-01-24 at 03:29 -0700, Schneidy wrote:
> Hi Richard,
> 
> You can use 'proportionalNotationDuration' e.g.:
> 
> \version "2.19.35"
> 
> \relative {
>   %% example 1
>   c' d e f
>   \set Score.proportionalNotationDuration = #(ly:make-moment 1/64)

Thanks - that works well. I've found this too:

\newSpacingSection
\override Score.SpacingSpanner.spacing-increment = #4

The documentation for this says:

"This is useful when there are sections with a different notions of long
and short notes". 

I wonder what the pros and cons of these are... I guess I'll have to
play around with them.

Richard



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

Re: Blank bars for scribbling in

[Schneidy]

Richard Shann-2 wrote
> [...]
> Thanks - that works well. I've found this too:
> 
> \newSpacingSection
> \override Score.SpacingSpanner.spacing-increment = #4
> [...]

Yep! Much smarter!!

blankBarAlter =
#(define-music-function (span-lgth notes) (number? ly:music?)
  #{
\newSpacingSection
\temporary\override Score.SpacingSpanner.spacing-increment = #span-lgth 
\hideNotes
#notes
\unHideNotes
\newSpacingSection
\revert Score.SpacingSpanner.spacing-increment
  #})

\relative {
  %% example 1
  c'4 d e f
  %% Notes are kwnown but won't be shown
  \blankBarAlter #12.8 { g a b c }
  c b a g
 
  %% example 2
  \break
  c d e f
  %% Unknown notes 
  \blankBarAlter #1.5 { s1 }
  c4 b a g
} 

~Pierre




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Blank-bars-for-scribbling-in-tp186334p186340.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: Determining what parameters exist for an item

[Kieren MacMillan]

Hi David,

> \new ChordNames
> \chordmode
> {
>  \applyOutput ChordNames.ChordName #(lambda (g c p) (display 
> (ly:grob-property g 'baseline-skip)))
>  c1
> }

That’s a helpful funcion — thanks!

> Those are, unless overriden by a grob, global.

Exactly. As far as the user cares, the setting has a value, even if it’s global.

If I don’t override ChordName.baseline-skip, and my ChordName has a column, the 
baseline still skips a certain/exact/known distance. By trial-and-error, I can 
find that the default is likely 3:

%%%  SNIPPET BEGINS
\version "2.19.35"

testing = \chordmode {
  \override ChordName.stencil = #ly:text-interface::print
  \override ChordName.text = \markup \column { first second }
  c1
  \override ChordName.baseline-skip = #5
  c1
  \override ChordName.baseline-skip = #3
  c1
}

\score {
  \new ChordNames \testing
}
%%%  SNIPPET ENDS

> But their values may well depend on stuff like the
> current staff size and your preferred style sheets so there is not
> really a lot that could actually be listed with some confidence.

At that point, I say, "Let the user beware.”

My question is: Is there a way to iterate your property display function (or 
similar) through all available properties of a grob, and output as a single 
list (alphabetically, if possible) the current/default value [e.g., 
ChordName.baseline-skip appears to be 3 by default, or in any case was at the 
time my snippet began compiling]?

Thanks,
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


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

Re: Slashed grace with long slur

[Kristin Rollins]

I'm sorry, I typoed the command both places:

\slashedGrace { \slurUp e8( } d b)

K.

--
Kristin Rollins
kris...@verumsolum.com
Portsmouth, VA
 
 
On Sun, Jan 24, 2016, at 09:08 AM, Kristin Rollins wrote:
> It worked for me to move the \slurUp command inside the \shlashedGrace, as in:
>  
> \slashGrace { \slurUp e8( } d b)
>  
> Kristin
>  
>  
>  
> On Sun, Jan 24, 2016, at 08:51 AM, Ralph Palmer wrote:
>> Hi, All -
>>  
>> I'm running Ly 2.19.33 under Win7.
>>  
>> I'm trying to transcribe a slashed grace note with a long slur, as in the 
>> attachment 
>> slur.png. 
>> I've been unable to get the slur to stay up. I've tried 
>> \slurUp
>> in conjunction with both
>> \slashedGrace
>> and
>> \acciaccatura
>> with no success. 
>> The attached .ly and .pdf files show the results. \slurUp does not work on a 
>> normal acciaccatura, either.
>>  
>> Is my only option to use 
>> \shape   ?
>> Using \shape should work, I believe, but will probably mean a *lot* of 
>> adjustment - I need to produce almost forty of these.
>>  
>> I'm grateful for any assistance,
>>  
>> Ralph
>>  
>> -- 
>> Ralph Palmer
>> Brattleboro, VT
>> USA
>> palmer.r.vio...@gmail.com
>> _
>> lilypond-user mailing list
>> lilypond-user@gnu.org
>> https://lists.gnu.org/mailman/listinfo/lilypond-user
>> Email had 3 attachments:


>>  * slashed grace with slur test.ly
>>   1k (text/lilypond-source)
>>  * slashed grace with slur test.pdf
>>   55k (application/pdf)
>>  * Slur.png
>>   4k (image/png)
>  
> _
> 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

Re: Accessing Grob properties

[Paul Morris]

> Am 22.01.2016 um 21:54 schrieb David Kastrup:
>>> However, from there I don't get any further, and it seems I totally
 don't understand how the Scheme types are matched in C++.
 Any attempt to compare the content of beam_count_prop with a set of
 predefined values seems to fail, and even
 
if (scm_equal_p (ly_symbol2scm ("one"), ly_symbol2scm ("two")))
 
 returns true (using scm_equal_p equally as for the eq and eqv
 versions.
>> It does not return true but SCM_BOOL_F.  Which you then convert to a
>> true C++ boolean since it is non-zero.
>> 
>> You want   if (scm_is_eq (... ))
>> instead: predicates with name xxx_is_yyy return a C (or C++) boolean.
>> Predicates with name xxx_p return an SCM boolean which you need to
>> convert to a C++ boolean using, for example, scm_is_true.
>> 
>> ...
>> 
>> SCM_BOOL_F as a C condition is _true_ rather than false. 
> 
> Thank you for this clear and general explanation that will serve me much
> further than simply solving the problem at hand. Of course this totally
> makes sense - and works perfectly.

This is indeed helpful info.  I checked the CG to see if it covers this kind of 
thing, and it looks like it does, although I didn’t check closely enough to see 
if it covers this exact example.  

http://lilypond.org/doc/v2.19/Documentation/contributor/comparison

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

Re: Determining what parameters exist for an item

[Kieren MacMillan]

Hi David,

> it would be easier if you did not do creative editing in order to
> let everything disappear not meeting your preconceptions.

It’s not clear what you’re talking about… but anyway…

It’s still perfectly clear to me — and, it seems, Charles and others — that 
Lilypond has grobs, and those grobs have properties, and those properties have 
values, and the default values of some of those properties are not easily 
determinable by the [beginning?] user.

Three examples which I just pulled at total random are
Beam.beam-thickness (via beam-interface)
NoteHead.break-visibility (via item-interface)
KeyCancellation.font-size (via font-interface)

I don’t see anywhere in the documentation where I can find what those default 
values are.

Regards,
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


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

Re: Determining what parameters exist for an item

[Simon Albrecht]

On 24.01.2016 18:22, Kieren MacMillan wrote:

Lilypond has grobs, and those grobs have properties, and those properties have 
values,


I think the point is that some properties either do not have values at 
all, or those values are determined during compilation, depending on 
other circumstances.



  and the default values of some of those properties are not easily 
determinable by the [beginning?] user.

Three examples which I just pulled at total random are
 Beam.beam-thickness (via beam-interface)


Beam thickness is certainly a multiple of staff line thickness, so its 
value can’t be told in general.



 NoteHead.break-visibility (via item-interface)


This is clearly a property which is unset, and remains unset, and for 
good reasons: Why would the visibility of a NoteHead depend on line 
breaks? In fact, tests show that a NoteHead is always considered to be 
‘unbroken’ (= mid-line), so \override NoteHead.break-visibility = ##(#t 
#f #t) will make all NoteHeads invisible, and the first and third values 
in the vector don’t matter at all.



 KeyCancellation.font-size (via font-interface)


It turns out that this can’t be overridden at all.

I hope this helps enlighten matters.

Best, Simon

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

Re: Determining what parameters exist for an item

[David Kastrup]

Kieren MacMillan  writes:

> At that point, I say, "Let the user beware.”
>
> My question is: Is there a way to iterate your property display
> function (or similar) through all available properties of a grob, and
> output as a single list (alphabetically, if possible) the
> current/default value [e.g., ChordName.baseline-skip appears to be 3
> by default, or in any case was at the time my snippet began
> compiling]?

Look, it would be easier if you did not do creative editing in order to
let everything disappear not meeting your preconceptions.  You are not
talking about grob properties but markup properties, in this case
inherited from the paper block.

-- 
David Kastrup

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

Re: Slashed grace with long slur

[Ralph Palmer]

On Jan 24, 2016 9:09 AM, "Kristin Rollins" 
wrote:
>
> It worked for me to move the \slurUp command inside the \shlashedGrace,
as in:
>
> \slashGrace { \slurUp e8( } d b)
>
> Kristin

Thanks, Kristin-
I'm not at my computer now, but I'll try it as soon as possible. I thought
I had tried that, but I guess not.
Thanks again,
Ralph
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Slashed grace with long slur

[Simon Albrecht]

On 24.01.2016 15:08, Kristin Rollins wrote:
It worked for me to move the \slurUp command inside the \slashedGrace, 
as in:

\slashedGrace { \slurUp e8( } d b)


Even easier:

{ \slashedGrace { e8^( } d b) }

And, astoundingly this minimal example works here: (but your larger 
example doesn’t)


%%
\version "2.19.35"
{ \slurUp \slashedGrace { e8( } d b) }
%%

Can’t tell why…

Best, Simon

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

Re: Determining what parameters exist for an item

[David Kastrup]

Kieren MacMillan  writes:

> Hi David,
>
>> it would be easier if you did not do creative editing in order to
>> let everything disappear not meeting your preconceptions.
>
> It’s not clear what you’re talking about… but anyway…
>
> It’s still perfectly clear to me — and, it seems, Charles and others —
> that Lilypond has grobs, and those grobs have properties, and those
> properties have values, and the default values of some of those
> properties are not easily determinable by the [beginning?] user.
>
> Three examples which I just pulled at total random are
> Beam.beam-thickness (via beam-interface)

LilyPond internals:

3.1.19 Beam
---

Beam objects are created by: *note Auto_beam_engraver::, *note
Beam_engraver::, *note Chord_tremolo_engraver::, *note
Grace_auto_beam_engraver:: and *note Grace_beam_engraver::.

   Standard settings:

 ‘auto-knee-gap’ (dimension, in staff space):
  ‘5.5’

  If a gap is found between note heads where a horizontal beam
  fits that is larger than this number, make a kneed beam.

 ‘beam-thickness’ (dimension, in staff space):
  ‘0.48’

  Beam thickness, measured in ‘staff-space’ units.

[...]

What do you think that 0.48 is supposed to be?

In the Internals Reference.

> NoteHead.break-visibility (via item-interface)

Unset, so default behavior.  Namely everything's visible.  Not a really
surprising default.

> KeyCancellation.font-size (via font-interface)

Unset, so default behavior.  font-size is documented (in the Internals
Reference) as following a context property fontSize when present.

> I don’t see anywhere in the documentation where I can find what those
> default values are.

-- 
David Kastrup

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

Re: Determining what parameters exist for an item

[Kieren MacMillan]

Hi again,

Here’s a perfect example of what I’m talking about…

For KeyCancellation, the output of Harm’s function includes

 GROB-INTERFACE
X-extent:
(0.0 . 5.82)

But if I look on 
http://www.lilypond.org/doc/v2.19/Documentation/internals/keycancellation, 
there is no entry for the X-extent setting. And if I follow the interface link 
to grob-interface, all it says is

X-extent (pair of numbers)
Extent (size) in the X direction, measured in staff-space units, relative 
to object’s reference point.

with [obviously] no specific setting for KeyCancellation.

Now, if I want to reduce or enlarge KeyCancellation.X-extent, knowing that 
default is (0.0 . 5.82)*** gives me critical information that I can 
actually use as a reference point; without that information, the 
trial-and-error factor increases dramatically.

Thanks again, Harm. This is *extremely* helpful, and exactly solves this 
problem which I’ve asked about on the list several times over the past few 
years.

Best regards,
Kieren.

*** I’m not sure if that strange-looking value 5.82 is the result of some 
calculation that is getting evaluated/resolved in order to be visible in the 
output… but that’s of secondary concern to me as a user/tweaker.



Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


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

Re: Edition-engraver: Multiple editions in same file

[Jan-Peter Voigt]

Hi Ben,

I was about to write about the three dimension to watch. But I have to 
think about it, if I can change this.
For now there will one set of editiontags per compilation. So every call 
to \addEdition and \removeEdition will affect the list of active 
modification-layers for the whole run. The compilation of a file is done 
in multiple steps. The called commands act on in the first step, the 
actual typesetting is done in another step.
In my use-cases, I always have one edition-set per file, e.g. full-score 
or part for single instruments. But your use-case looks reasonable. I 
attached your example slightly modified, where the first score is 
modified, but not the second. To achieve this, I used \applyContext, so 
that the \removeEdition command is performed, when beginning typesetting 
th second score. The command could be wrapped inside a little helper 
command.
This technique has the pro, that it matches your use-case, but a big 
con, in that it remixes content and design again.

So I would not recommend this over the solution, you already found.
Perhaps another solution is found another day ;-)

HTH for now
Cheers
Jan-Peter

Am 22.01.2016 um 22:00 schrieb Ben Strecker:

I’m working on a project that would have the same melody appearing in different 
ranges in the same document.  Each range has its own set of modifications 
through the edition-engraver, but using \removeEdition anywhere in the file 
appears to remove that edition for all of the scores.  What is the best 
practice for managing multiple editions in the same file?

I have attached a very simple example where I have two scores:  one that should 
have a color modification applied, and another that should not have any 
editionMods applied.

Thanks,
Ben



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


\include "editorial-tools/edition-engraver/definitions.ily"

\version "2.19.32"

melody = \relative c' {
  c d e f
}

\layout {
  \context {
\Score
\consists \editionEngraver my.Test
  }
  \context {
\Staff
\consists \editionEngraver ##f
  }
  \context {
\Voice
\consists \editionEngraver ##f 
  }
}

%Red Note
\editionMod red 1 1/4 my.Test.Staff.A \once \override NoteHead #'color = #red

\addEdition red
%this one should have the modification
\score {
  \new Staff { \melody }
}

% how do you get this one to NOT have te modification?
\score {
  \new Staff {
\applyContext #(lambda (context) #{ \removeEdition red #})
\melody
  }
}
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Determining what parameters exist for an item

[Thomas Morley]

2016-01-24 20:03 GMT+01:00 Kieren MacMillan :
> Hi Harm,
>
>> If you really want to see all of the default properties and their
>> values for a certain grob, try the code below.
>
> Now THIS… this is EXACTLY what I wanted; and, I infer, what Charles also 
> wanted.
> Thank you.
>
>> 1. I think you'll agree that we don't want to put it in the docs,
>> repeating it for every single grob …
>
> No, but I offer that putting this FUNCTION in the docs (snippets?) — “If you 
> want to see all properties…”, etc. — would be a wonderful idea.

Maybe LSR, I'll have to test with 2.18.2.

>> 2. It doesn't work for NoteHead.
>
> Do you have any reason to believe it wouldn’t work with any other grob(s)?


Well, it's a brute-force attack on our code.
The functions in output-lib.scm making a problem are
`select-head-glyph' and `note-head::calc-glyph-name'.
Though, while normal compilation style '()/default is handled in
note-head.cc. Only with my coding and others of this kind the error
appears. No idea, if this will happen for other grobs at other places
as well.


Cheers,
  Harm

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

Re: Determining what parameters exist for an item

[Thomas Morley]

Hi Kieren,

2016-01-24 18:22 GMT+01:00 Kieren MacMillan :
> Hi David,
>
>> it would be easier if you did not do creative editing in order to
>> let everything disappear not meeting your preconceptions.
>
> It’s not clear what you’re talking about… but anyway…
>
> It’s still perfectly clear to me — and, it seems, Charles and others — that 
> Lilypond has grobs, and those grobs have properties, and those properties 
> have values, and the default values of some of those properties are not 
> easily determinable by the [beginning?] user.
>
> Three examples which I just pulled at total random are
> Beam.beam-thickness (via beam-interface)

Beam.beam-thickness is in the IR ;)

> NoteHead.break-visibility (via item-interface)
> KeyCancellation.font-size (via font-interface)

These are _not_set!


If you really want to see all of the default properties and their
values for a certain grob, try the code below.
1. I think you'll agree that we don't want to put it in the docs,
repeating it for every single grob ...
2. It doesn't work for NoteHead.
Reason: in output-lib.scm are some procedures doing
(symbol->string style)
without testing whether style may be '()
(Already fixed locally, I'll provide a patch)


\version "2.19.35"

#(define (supported-properties iface)
  (let ((iface-info (hashq-get-handle (ly:all-grob-interfaces) iface)))
(last iface-info)))

#(define (print-all-grob-properties-key-values grob)
  (let ((ifaces (assoc-get 'interfaces (ly:grob-property grob 'meta
(for-each
  (lambda (iface)
(format #t "\n~a\n" (string-upcase (symbol->string iface)))
  (for-each
(lambda (p)
(ly:grob-property grob p)
  (format #t "\n\t~a:\n\t~a" p (ly:grob-property grob p))
  )
(supported-properties iface)))
  ifaces)))
%%{
\new ChordNames
\chordmode
{
  \applyOutput ChordNames.ChordName
#(lambda (grob ctx p)
  (format #t "\n~a in context: ~a:\n" grob ctx)
  (print-all-grob-properties-key-values grob))
  c1
}
%}
%%{
\new Staff
{
  \key cis \major
  c1
  \applyOutput Staff.KeyCancellation
#(lambda (grob ctx p)
  (format #t "\n~a in context: ~a:\n" grob ctx)
  (print-all-grob-properties-key-values grob))

  \key ces \major
  c1
}
%}
%{
\new Staff
{
  \applyOutput Score.NoteHead
#(lambda (grob ctx p)
  (format #t "\n~a in context: ~a:\n" grob ctx)
  (print-all-grob-properties-key-values grob))
  c1
}
%}


Cheers,
  Harm

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

Re: Determining what parameters exist for an item

[Kieren MacMillan]

Hi Harm,

> If you really want to see all of the default properties and their
> values for a certain grob, try the code below.

Now THIS… this is EXACTLY what I wanted; and, I infer, what Charles also wanted.
Thank you.

> 1. I think you'll agree that we don't want to put it in the docs,
> repeating it for every single grob …

No, but I offer that putting this FUNCTION in the docs (snippets?) — “If you 
want to see all properties…”, etc. — would be a wonderful idea.

> 2. It doesn't work for NoteHead.

Do you have any reason to believe it wouldn’t work with any other grob(s)?

Many thanks,
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


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

Font of accidentals changes after line break

[Robert Schmaus]

Dear Lilyponders,

I usually engrave jazz lead sheets using LilyJazz, and I've noticed the 
following odd behaviour: If I tie a note across a manual line break, and 
the note has an accidental, then the LilyJazz font is not applied to the 
accidental of the continued note after the line break.

The following snippet shows this:

% %

\version "2.19.34"
\include "LilyJAZZ.ily" % <-- path to LilyJAZZ file ...

\score {
  \new Staff {

\key ees \major
\time 4/4
\jazzOn

\relative c'' {
  < des e, fis, >1 ~
  \break
  q8
}
  }
}

% %

I tried this (on a Mac) with v2.19.18 and 2.19.34. I also tried it with 
2.18.2, where the issue doesn't come up because the accidentals are not 
shown after the line break.


Does anyone know of a way to fix this? Maybe there's a new additional 
accidental type that I need to set? Right now, I have overrides on the 
objects Staff.Accidental, Staff.AccidentalCautionary, and 
Staff.AccidentalSuggestion. Is there a new one in v2.19? I didn't find 
any in the internals reference ...


If it can't be fixed easily, how can I turn off the accidental after 
break? I tried

\override Staff.Accidental.after-line-breaking = ##f
but that didn't change anything.

Any help would be appreciated!

Thanks,
Cheers, Robert


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

Re: Font of accidentals changes after line break

[Urs Liska]

Am 24. Januar 2016 22:56:56 MEZ, schrieb Robert Schmaus :
>Dear Lilyponders,
>
>I usually engrave jazz lead sheets using LilyJazz, and I've noticed the
>
>following odd behaviour: If I tie a note across a manual line break,
>and 
>the note has an accidental, then the LilyJazz font is not applied to
>the 
>accidental of the continued note after the line break.
>The following snippet shows this:

Did you try the alternative approach using openLilyLib's Stylesheets library?

Urs

>
>% %
>
>\version "2.19.34"
>\include "LilyJAZZ.ily" % <-- path to LilyJAZZ file ...
>
>\score {
>   \new Staff {
>
> \key ees \major
> \time 4/4
> \jazzOn
>
> \relative c'' {
>   < des e, fis, >1 ~
>   \break
>   q8
> }
>   }
>}
>
>% %
>
>I tried this (on a Mac) with v2.19.18 and 2.19.34. I also tried it with
>
>2.18.2, where the issue doesn't come up because the accidentals are not
>
>shown after the line break.
>
>Does anyone know of a way to fix this? Maybe there's a new additional 
>accidental type that I need to set? Right now, I have overrides on the 
>objects Staff.Accidental, Staff.AccidentalCautionary, and 
>Staff.AccidentalSuggestion. Is there a new one in v2.19? I didn't find 
>any in the internals reference ...
>
>If it can't be fixed easily, how can I turn off the accidental after 
>break? I tried
>\override Staff.Accidental.after-line-breaking = ##f
>but that didn't change anything.
>
>Any help would be appreciated!
>
>Thanks,
>Cheers, Robert
>
>
>___
>lilypond-user mailing list
>lilypond-user@gnu.org
>https://lists.gnu.org/mailman/listinfo/lilypond-user

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

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

Re: Determining what parameters exist for an item

[Thomas Morley]

2016-01-24 22:22 GMT+01:00 Thomas Morley :

> Btw, I tested it with 2.18.2, doesn't work with \applyOutput, but with
> \override Grob.after-line-breaking

http://lsr.di.unimi.it/LSR/Item?u=1=1017

Best,
  Harm

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

Re: Font of accidentals changes after line break

[Simon Albrecht]

On 24.01.2016 22:56, Robert Schmaus wrote:
If it can't be fixed easily, how can I turn off the accidental after 
break? I tried

\override Staff.Accidental.after-line-breaking = ##f
but that didn't change anything. 


The after-line-breaking property can be set to a procedure, which will 
then be executed /after line breaking/, hence the name.
In this case you’d just need \once\hide Staff.Accidental at the moment 
of the line break.


Yours, Simon

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

Re: Font of accidentals changes after line break

[Urs Liska]

Am 24.01.2016 um 23:01 schrieb Urs Liska:
>
> Am 24. Januar 2016 22:56:56 MEZ, schrieb Robert Schmaus 
> :
>> Dear Lilyponders,
>>
>> I usually engrave jazz lead sheets using LilyJazz, and I've noticed the
>>
>> following odd behaviour: If I tie a note across a manual line break,
>> and 
>> the note has an accidental, then the LilyJazz font is not applied to
>> the 
>> accidental of the continued note after the line break.
>> The following snippet shows this:
> Did you try the alternative approach using openLilyLib's Stylesheets library?
>
> Urs

OK, just checked it.

Provided you have
- LilyJAZZ "installed" in LilyPond's font directory
- openLilyLib and its /ly subdirectory in LilyPond's include path
then

\include "openlilylib"
\useLibrary Stylesheets
\useNotationFont LilyJAZZ

will make your example work properly. You should remove the \jazzOn.

HTH
Urs

>
>> % %
>>
>> \version "2.19.34"
>> \include "LilyJAZZ.ily" % <-- path to LilyJAZZ file ...
>>
>> \score {
>>   \new Staff {
>>
>> \key ees \major
>> \time 4/4
>> \jazzOn
>>
>> \relative c'' {
>>   < des e, fis, >1 ~
>>   \break
>>   q8
>> }
>>   }
>> }
>>
>> % %
>>
>> I tried this (on a Mac) with v2.19.18 and 2.19.34. I also tried it with
>>
>> 2.18.2, where the issue doesn't come up because the accidentals are not
>>
>> shown after the line break.
>>
>> Does anyone know of a way to fix this? Maybe there's a new additional 
>> accidental type that I need to set? Right now, I have overrides on the 
>> objects Staff.Accidental, Staff.AccidentalCautionary, and 
>> Staff.AccidentalSuggestion. Is there a new one in v2.19? I didn't find 
>> any in the internals reference ...
>>
>> If it can't be fixed easily, how can I turn off the accidental after 
>> break? I tried
>> \override Staff.Accidental.after-line-breaking = ##f
>> but that didn't change anything.
>>
>> Any help would be appreciated!
>>
>> Thanks,
>> Cheers, Robert
>>
>>
>> ___
>> 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

Re: Determining what parameters exist for an item

[Simon Albrecht]

On 24.01.2016 21:28, Simon Albrecht wrote:

On 24.01.2016 21:15, Thomas Morley wrote:
Now, if I want to reduce or enlarge KeyCancellation.X-extent, 
knowing that default is (0.0 . 5.82)*** gives me critical 
information that I can actually use as a reference point; without 
that information, the trial-and-error factor increases dramatically.

Well, we have the \offset-function ...
No clue about possible limitations, though


Oh, it would be great if we could use \offset for such cases. 
Unfortunately it doesn’t work here…
David, is this the case you described in 
, with 
mutable properties?


Test case:

%%%
\version "2.19.35"
{
  \key fis \major
  1
  \once\override Staff.KeyCancellation.X-extent = #'(0 . 5)
  \key b \minor
  1
  \once\offset X-extent #'(0 . 5) Staff.KeyCancellation
  \key g \major
  1
}
%%

– throwing twice ‘warning: the property 'X-extent of #KeyCancellation > cannot be offset’ and printing the KeyCancellation 
_without_ any X-extent.


Yours, Simon

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

Re: Determining what parameters exist for an item

[Thomas Morley]

2016-01-24 21:32 GMT+01:00 Simon Albrecht :
> On 24.01.2016 21:28, Simon Albrecht wrote:
>>
>> On 24.01.2016 21:15, Thomas Morley wrote:

 Now, if I want to reduce or enlarge KeyCancellation.X-extent, knowing
 that default is (0.0 . 5.82)*** gives me critical information that I 
 can
 actually use as a reference point; without that information, the
 trial-and-error factor increases dramatically.
>>>
>>> Well, we have the \offset-function ...
>>> No clue about possible limitations, though
>>
>>
>> Oh, it would be great if we could use \offset for such cases.
>> Unfortunately it doesn’t work here…
>> David, is this the case you described in
>> , with mutable
>> properties?
>
>
> Test case:
>
> %%%
> \version "2.19.35"
> {
>   \key fis \major
>   1
>   \once\override Staff.KeyCancellation.X-extent = #'(0 . 5)
>   \key b \minor
>   1
>   \once\offset X-extent #'(0 . 5) Staff.KeyCancellation
>   \key g \major
>   1
> }
> %%
>
> – throwing twice ‘warning: the property 'X-extent of #> cannot be offset’ and printing the KeyCancellation _without_ any X-extent.
>
> Yours, Simon


Ok, \offset has limitations.
Though, I usually read directly the relevant grob-property and reset
it to my needs:

{
  \key cis \major
  c1
  \once\override Staff.KeyCancellation.after-line-breaking =
#(lambda (grob)
  (write-me "\nX-extent: " (ly:grob-property grob 'X-extent))
  )
  \key ces \major
  c1
}


Prints to terminal:
X-extent: (0.0 . 5.82)

Now I have the actual value and can do what ever I want with it ;)


Cheers,
  Harm

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

Re: Determining what parameters exist for an item

[Kieren MacMillan]

Hi Harm,

> Well, it is the _actual_ default. KeyCancellation _can't_ have
> a general default of X-extent for all possible KeyCancellations…

Obviously.  =)

But the benefits of the function are both general (“Get a list of every 
settable property for this grob.”) and specific (“Get the property values for a 
particular instance of this grob.”) I suppose we could spoonfeed the user more 
by somehow highlighting/mentioning in the output which are general/fixed values 
and which are specific/instance/relative values… but having this function 
already puts us well ahead of where we were a few hours ago.

> Well, we have the \offset-function ...
> No clue about possible limitations, though

The \offset function behaves in a “user-inconsistent” manner — by which I mean, 
there is undoubtedly a perfectly logical/technical reason why it works in 
certain cases and throws errors in others, but users don’t (or at least 
shouldn’t) care why they see “inconsistent” [sic] behaviour.

Simon says:
> Oh, it would be great if we could use \offset for such cases.


+1
But I know it may not be possible.

One case where a lack of \offset-ability drives me crazy is explicit 
system/staff positioning: as far as I know (and queries to the list have 
confirmed), there is no way to “nudge” a system (e.g.) up 1 staff space. So 
there’s a lot of trial-and-error in those situations.

Best,
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


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

Re: Determining what parameters exist for an item

[Thomas Morley]

2016-01-24 20:15 GMT+01:00 Kieren MacMillan :
> Hi again,
>
> Here’s a perfect example of what I’m talking about…
>
> For KeyCancellation, the output of Harm’s function includes
>
>  GROB-INTERFACE
> X-extent:
> (0.0 . 5.82)
>
> But if I look on 
> http://www.lilypond.org/doc/v2.19/Documentation/internals/keycancellation, 
> there is no entry for the X-extent setting. And if I follow the interface 
> link to grob-interface, all it says is
>
> X-extent (pair of numbers)
> Extent (size) in the X direction, measured in staff-space units, relative 
> to object’s reference point.
>
> with [obviously] no specific setting for KeyCancellation.

Well, it is the _actual_ default.
KeyCancellation _can't_ have a general default of X-extent for all
possible KeyCancellations...

> Now, if I want to reduce or enlarge KeyCancellation.X-extent, knowing that 
> default is (0.0 . 5.82)*** gives me critical information that I can 
> actually use as a reference point; without that information, the 
> trial-and-error factor increases dramatically.

Well, we have the \offset-function ...
No clue about possible limitations, though

> Thanks again, Harm. This is *extremely* helpful, and exactly solves this 
> problem which I’ve asked about on the list several times over the past few 
> years.
>
> Best regards,
> Kieren.
>
> *** I’m not sure if that strange-looking value 5.82 is the result of some 
> calculation that is getting evaluated/resolved in order to be visible in the 
> output… but that’s of secondary concern to me as a user/tweaker.

Cheers,
  Harm

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

Re: Determining what parameters exist for an item

[Simon Albrecht]

On 24.01.2016 21:15, Thomas Morley wrote:

Now, if I want to reduce or enlarge KeyCancellation.X-extent, knowing that 
default is (0.0 . 5.82)*** gives me critical information that I can 
actually use as a reference point; without that information, the 
trial-and-error factor increases dramatically.

Well, we have the \offset-function ...
No clue about possible limitations, though


Oh, it would be great if we could use \offset for such cases. 
Unfortunately it doesn’t work here…
David, is this the case you described in 
, with 
mutable properties?


Best, Simon

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

RE: Determining what parameters exist for an item

[Charles O. Lawrence]

Gentlemen,

Thanks for all your replies.  I had no idea such a simple request would stir up 
such a hornet's nest.  I have some good ideas to follow up on now.

Charles


-Original Message-
From: Kieren MacMillan [mailto:kieren_macmil...@sympatico.ca] 
Sent: Sunday, January 24, 2016 2:04 PM
To: Thomas Morley 
Cc: David Kastrup ; Charles O. Lawrence 
; Lilypond-User Mailing List 
; Carl Sorensen 
Subject: Re: Determining what parameters exist for an item

Hi Harm,

> If you really want to see all of the default properties and their 
> values for a certain grob, try the code below.

Now THIS… this is EXACTLY what I wanted; and, I infer, what Charles also wanted.
Thank you.

> 1. I think you'll agree that we don't want to put it in the docs, 
> repeating it for every single grob …

No, but I offer that putting this FUNCTION in the docs (snippets?) — “If you 
want to see all properties…”, etc. — would be a wonderful idea.

> 2. It doesn't work for NoteHead.

Do you have any reason to believe it wouldn’t work with any other grob(s)?

Many thanks,
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


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

Re: Determining what parameters exist for an item

[Thomas Morley]

2016-01-24 22:03 GMT+01:00 Kieren MacMillan :
> Hi Harm,
>
>> Well, it is the _actual_ default. KeyCancellation _can't_ have
>> a general default of X-extent for all possible KeyCancellations…
>
> Obviously.  =)
>
> But the benefits of the function are both general (“Get a list of every 
> settable property for this grob.”)

But please understand: if a property is settable, this does not mean
your setting takes any effect.
I don't speak of user-errors in syntax, missing context, etc, but
sometimes an engraver does not listen to a certain property, maybe
because it's hard-coded or not really needed or for other good
reasons.

Btw, I tested it with 2.18.2, doesn't work with \applyOutput, but with
\override Grob.after-line-breaking

Cheers,
  Harm

> and specific (“Get the property values for a particular instance of this 
> grob.”) I suppose we could spoonfeed the user more by somehow 
> highlighting/mentioning in the output which are general/fixed values and 
> which are specific/instance/relative values… but having this function already 
> puts us well ahead of where we were a few hours ago.
>
>> Well, we have the \offset-function ...
>> No clue about possible limitations, though
>
> The \offset function behaves in a “user-inconsistent” manner — by which I 
> mean, there is undoubtedly a perfectly logical/technical reason why it works 
> in certain cases and throws errors in others, but users don’t (or at least 
> shouldn’t) care why they see “inconsistent” [sic] behaviour.
>
> Simon says:
>> Oh, it would be great if we could use \offset for such cases.
>
>
> +1
> But I know it may not be possible.
>
> One case where a lack of \offset-ability drives me crazy is explicit 
> system/staff positioning: as far as I know (and queries to the list have 
> confirmed), there is no way to “nudge” a system (e.g.) up 1 staff space. So 
> there’s a lot of trial-and-error in those situations.
>
> Best,
> Kieren.
> 
>
> Kieren MacMillan, composer
> ‣ website: www.kierenmacmillan.info
> ‣ email: i...@kierenmacmillan.info
>

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

Re: Font of accidentals changes after line break

[Robert Schmaus]

Hi Simon,

thanks for your repy - I'll keep that in mind as a last resort if I 
can't get any other solution to work ...


Cheers,
Robert

Am 24/01/16 um 23:22 schrieb Simon Albrecht:

On 24.01.2016 22:56, Robert Schmaus wrote:

If it can't be fixed easily, how can I turn off the accidental after
break? I tried
\override Staff.Accidental.after-line-breaking = ##f
but that didn't change anything.


The after-line-breaking property can be set to a procedure, which will
then be executed /after line breaking/, hence the name.
In this case you’d just need \once\hide Staff.Accidental at the moment
of the line break.

Yours, Simon


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

Re: Font of accidentals changes after line break

[Robert Schmaus]

Hi Urs,

You seem to have sent two mails - only got the second one ... strange.

Anyway, thank you for your solution.
I did instal openlilylib during the "Trunkne Lied" project, but haven't 
used it outside of that. I'll try that out asap, but I won't be able to 
do it tonight ...


Best,
Robert


Am 24/01/16 um 23:33 schrieb Urs Liska:



Am 24.01.2016 um 23:01 schrieb Urs Liska:


Am 24. Januar 2016 22:56:56 MEZ, schrieb Robert Schmaus :

Dear Lilyponders,

I usually engrave jazz lead sheets using LilyJazz, and I've noticed the

following odd behaviour: If I tie a note across a manual line break,
and
the note has an accidental, then the LilyJazz font is not applied to
the
accidental of the continued note after the line break.
The following snippet shows this:

Did you try the alternative approach using openLilyLib's Stylesheets library?

Urs


OK, just checked it.

Provided you have
- LilyJAZZ "installed" in LilyPond's font directory
- openLilyLib and its /ly subdirectory in LilyPond's include path
then

\include "openlilylib"
\useLibrary Stylesheets
\useNotationFont LilyJAZZ

will make your example work properly. You should remove the \jazzOn.

HTH
Urs




% %

\version "2.19.34"
\include "LilyJAZZ.ily" % <-- path to LilyJAZZ file ...

\score {
   \new Staff {

 \key ees \major
 \time 4/4
 \jazzOn

 \relative c'' {
   < des e, fis, >1 ~
   \break
   q8
 }
   }
}

% %

I tried this (on a Mac) with v2.19.18 and 2.19.34. I also tried it with

2.18.2, where the issue doesn't come up because the accidentals are not

shown after the line break.

Does anyone know of a way to fix this? Maybe there's a new additional
accidental type that I need to set? Right now, I have overrides on the
objects Staff.Accidental, Staff.AccidentalCautionary, and
Staff.AccidentalSuggestion. Is there a new one in v2.19? I didn't find
any in the internals reference ...

If it can't be fixed easily, how can I turn off the accidental after
break? I tried
\override Staff.Accidental.after-line-breaking = ##f
but that didn't change anything.

Any help would be appreciated!

Thanks,
Cheers, Robert


___
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



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

Re: Determining what parameters exist for an item

[David Nalesnik]

On Sun, Jan 24, 2016 at 2:32 PM, Simon Albrecht 
wrote:

> On 24.01.2016 21:28, Simon Albrecht wrote:
>
>> On 24.01.2016 21:15, Thomas Morley wrote:
>>
>>> Now, if I want to reduce or enlarge KeyCancellation.X-extent, knowing
 that default is (0.0 . 5.82)*** gives me critical information that I
 can actually use as a reference point; without that information, the
 trial-and-error factor increases dramatically.

>>> Well, we have the \offset-function ...
>>> No clue about possible limitations, though
>>>
>>
>> Oh, it would be great if we could use \offset for such cases.
>> Unfortunately it doesn’t work here…
>>
>>
\offset only works on properties that have a default value listed in the
grob pages in the IR (derived from the alist in scm/define-grobs.scm).
There is no default value listed for KeyCancellation.X-extent, hence the
warning.

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