Re: fret-diagram layout question

[Jacques Menu]

Hello Aaron,

Fine, thanks. Can user-specific fret-diagrams be obtained with a FretBoards  
context, though?

JM

> Le 17 janv. 2020 à 06:01, Aaron Hill  a écrit :
> 
> On 2020-01-16 8:38 pm, Jacques Menu wrote:
>> Hello Aaron,
>> Thanks a lot for the hint, I’ll look into FretBoards contexts.
> 
> Oops, I forgot to paste in the code I wanted to include:
> 
> 
> \version "2.19.83"
> 
> theChords = { 4  }
> 
> <<
>  \new ChordNames \with { chordChanges = ##t }
>\chordmode { c4 d:m }
>  \new FretBoards { \theChords }
>  \new Staff { \clef "treble_8" \theChords }
> 
> 
> 
> -- Aaron Hill
> 

Re: compiling 2.19.83 needs guile-config < 1.9.0

[Michael Käppler]

Am 16.01.2020 um 22:47 schrieb Thomas Morley:

Am Do., 16. Jan. 2020 um 21:29 Uhr schrieb Bric :

I think this was discussed before, but i'm not sure how to downgrade guile on 
Ubuntu 18.04.2 LTS

I tried building guile-1.8.0, guile-1.8.4, guile-1.8.5, but the build fails for 
all three.

lilypond ./configure error:

ERROR: Please install required programs: guile-config < 1.9.0 (installed: 
2.2.3) (guile-devel, guile-dev or libguile-dev package) libguile (libguile-dev, 
guile-devel or guile-dev package). GUILE-with-rational-bugfix

You likely need to point configure to guile and guile-config

../configure GUILE_CONFIG=/path/to/guile-config GUILE=/path/to/guile


Sorry, did accidentally forget to reply also to the list.
What I was unsure from the your post, Bric, is what "... the build fails
for all three" means.
Either
a) You could not build guile, neither 1.8.0, 1.8.4, nor 1.8.5
b) You did successfully build three different versions of guile, but
haven't had success with none of them in compiling lilypond.

In any case it would be good to know
a) Which version of LP are you trying to compile? From current master?
b) If building guile is the problem, how does the build actually fail?

Michael

Re: fret-diagram layout question

[Aaron Hill]

On 2020-01-16 8:38 pm, Jacques Menu wrote:

Hello Aaron,

Thanks a lot for the hint, I’ll look into FretBoards contexts.



Oops, I forgot to paste in the code I wanted to include:


\version "2.19.83"

theChords = { 4  }

<<
  \new ChordNames \with { chordChanges = ##t }
\chordmode { c4 d:m }
  \new FretBoards { \theChords }
  \new Staff { \clef "treble_8" \theChords }






-- Aaron Hill

Re: Slur across alternate ending - with example

[Aaron Hill]

On 2020-01-15 3:54 pm, Pastor Jim Neubauer wrote:

So I figured out how to make and adjust a slur on my own. I am really
wondering though if there is a more elegant way like how simple it is
to do \repeatTie.


Sorry for the delay.  Your approach seems perfectly reasonable.

I was going to suggest something like this:


\version "2.18.2"
\language "english"

\relative c'' {
  \key d \major
  \time 4/4
  \repeat volta 2 {
| d4 d8 d8~ d8 a4 d8(
  }
  \alternative {
{
  | e4. d8~ d8 cs4) a8
  | a4 a8 fs'8~ fs8 e4 d8
  -\tweak dash-definition
#'((0 0.3 0 0) (0.3 1 1 1))
  (
\bar ":|."
}
{
  | e4.
% -\tweak control-points
%   #'((-1 . 3.1) (3 . 3.6) (8 . 3.4) (10 . 1.5))
% (
d8~ d8 cs8) fs8 fs8~
}
  }
}


This works because you happen to have a note at the right pitch to 
attach the slur to.  If the music were different in the end of the first 
volta, I would have needed to use a hidden note.



-- Aaron Hill

Re: fret-diagram layout question

[Jacques Menu]

Hello Aaron,

Thanks a lot for the hint, I’ll look into FretBoards contexts.

JM

> Le 17 janv. 2020 à 05:33, Aaron Hill  a écrit :
> 
> On 2020-01-16 8:18 pm, Jacques Menu wrote:
>> [ . . . ]
>> How can this be displayed with the two fret diagrams on one and the
>> same horizontal line?
>> Uncommenting the SpacingSpanner.base-shortest-duration override is a
>> bit artificial, maybe there’s a better way?
> 
> \textLengthOn will help a little; but the resulting diagrams are not quite 
> vertically aligned in my testing.  If that is a problem, then consider 
> putting the chords into a FretBoards context instead of as markup.
> 
> 
> -- Aaron Hill
> 

Re: fret-diagram layout question

[Aaron Hill]

On 2020-01-16 8:18 pm, Jacques Menu wrote:

[ . . . ]
How can this be displayed with the two fret diagrams on one and the
same horizontal line?
Uncommenting the SpacingSpanner.base-shortest-duration override is a
bit artificial, maybe there’s a better way?


\textLengthOn will help a little; but the resulting diagrams are not 
quite vertically aligned in my testing.  If that is a problem, then 
consider putting the chords into a FretBoards context instead of as 
markup.



-- Aaron Hill

fret-diagram layout question

[Jacques Menu]

Hello folks,

This snippet is adapted from the LPNR, with whole notes replaced by quarter 
notes:

\version "2.19.83"

<<
  \new ChordNames {
  \set chordChanges = ##t
  \chordmode {
  c4 d:m
}
  }
  \new Staff {
\clef "treble_8"
4^\markup {
  \fret-diagram #"6-x;5-3;4-2;3-o;2-1;1-o;"
}
4^\markup {
  \fret-diagram #"6-x;5-x;4-o;3-2;2-3;1-1;"
}
  }
>>

\layout {
  \context {
\Score
   % \override SpacingSpanner.base-shortest-duration = #(ly:make-moment 1/64)
  }
}



How can this be displayed with the two fret diagrams on one and the same 
horizontal line?
Uncommenting the SpacingSpanner.base-shortest-duration override is a bit 
artificial, maybe there’s a better way?

Thanks for your help!

JM

Re: Distance of a grob from its reference point

[Aaron Hill]

On 2020-01-16 4:01 pm, Paolo Prete wrote:
This gives a clearer overview, thanks, but I would not use it, even if 
it

produces the wanted result.


Sorry if I implied otherwise, but I thought I was clear that this code 
was not intended for practical use.  This is only test code to 
demonstrate the underlying mechanisms are actually working properly.  I 
wanted to address what I consider a flawed premise that things are 
broken.  Rather, what should be clear is that things are complicated.  
And I am uncomfortable with so casually equating the two.



I did not omit them, given that I did not want to reset any property, 
as I
explained in other posts. In practice, you are only making reset of all 
the
properties that add more space between the grob and the reference 
point. At
the end, considering that you have to add a .46 value, you get even a 
worse
procedure than \override Y-offset, while using the same logic (which 
is:
distance from a reference point, and not *offset the result*). So: I 
think

it's better to use a ruler from the middle of the staff.
No other way, if you want to preserve the avoid-collision algo.


There is no "offset the result" apart from extra-offset.  There are many 
ways to *influence* the positioning of a grob, but only extra-offset 
operates on the final computed position.  Everything else works within 
the magic that is LilyPond's layout logic, which seems to be designed 
around keeping as much in relative terms as opposed to absolute terms.


With that in mind, say you want to move an object upward on the page.  
That is fine, but it is an absolute adjustment.  To convert it to a 
relative one, you must answer why you need to move the object.  Is it 
because it is too close to something?  Is it because it does not line up 
nicely with something else?  Is it because the decomposing remains of a 
donut you forgot about have become sentient and are whispering dark 
thoughts?


Once you have clarified why something needs to move, then you can best 
determine which tool is the right one for the job.  The goal is to move 
the object once, and not have to revisit it after other things change.  
Encoding the logic behind why something needs to move lets LilyPond do 
it for you.  Padding can help with adjusting how near or far objects are 
from one another, but sometimes alignment suffers.  Alignment of grobs 
requires working from a common reference point, and one will need to 
consider what constructs exist within LilyPond that can help with this.  
The Dynamics context, for instance, does not have to be used only for 
dynamics.  Of course, sometimes relative adjustments are just not 
suitable and you may end up needing to use the absolute extra-offset.  
As for the donut, that is beyond my pay grade, and I wish you only the 
best of luck.


(Future headline: Krispy Kreme responsible for zombie outbreak with 
Halloween-inspired glazed, "raised-from-the-dead" donuts.)


Of course, the tools and constructs available in LilyPond are certainly 
not exhaustive.  Given the discussion, it seems we could benefit greatly 
with the introduction of a so-called "outside-staff-offset" which moves 
grobs away from the staff by an absolute amount--think extra padding but 
only on the side nearest the staff.


If that sounds interesting, know that you can approximate it with a 
combination of outside-staff-padding and extra-offset to achieve 
outside-staff-offset.  It just takes a little grade-school math:



\version "2.19.83"
notes = \fixed c''' { \mark "mark" \ottava 1 f8( 8) 4 \ottava 0 f,2 }

{
  \omit Staff.Clef \omit Staff.TimeSignature
  \override Score.RehearsalMark.self-alignment-X = #LEFT

  % Default behavior.
  \notes

  % Try moving the bracket up by two staff spaces.
  \override Staff.OttavaBracket.outside-staff-padding = 2.46
  \notes

  % Oops, the mark moved too far.
  % Split the difference between padding and offset.
  \override Staff.OttavaBracket.outside-staff-padding = 1.46
  \override Staff.OttavaBracket.extra-offset = #'(0 . 1)
  \notes
}


But what happens when outside-staff-padding is *not* the defining 
property controlling the vertical position?  Consider a bracket whose 
effective Y-offset is large enough that it is positioned too far away 
from other outside-staff grobs.


This could be handled as followed:


\version "2.19.83"

#(define (addRuler color left right)
  (grob-transformer 'stencil (lambda (grob orig)
(ly:stencil-add
  (grob-interpret-markup grob #{
\markup \with-dimensions-from \null
\with-color #color \path #0.1 #`(
  (moveto ,left 0) (lineto ,right 0)
  (moveto ,left 1) (lineto ,right 1)
  (moveto ,left 2) (lineto ,right 2)
) #})
  orig

notesI = \fixed c''' { \mark "mark" \ottava 1 d8 8 4 \ottava 0 d,2 }
notesII = \fixed c''' { \mark "mark" \ottava 1 a8( 8) 4 \ottava 0 a,2 }

shiftOttavaBracket = #(define-music-function (amount) (number?)
  (let ((half (/ amount 2)))
#{
 

Re: Distance of a grob from its reference point

[Paolo Prete]

On Fri, Jan 17, 2020 at 12:31 AM Aaron Hill 
wrote:

>
> This time, you omitted the overrides to prevent padding and
> staff-padding from influencing the test:
>


> \version "2.19.45"
> notes = \fixed c''' { \ottava 1 f4 4 4 \ottava 0 f, }
>
> {
>% Make sure these properties do not influence
>% anything while testing outside-staff-padding.
>\override Staff.OttavaBracket.padding = 0
>\override Staff.OttavaBracket.staff-padding = 0
>
>\override Staff.OttavaBracket.outside-staff-padding = 0.56
>\notes
>
>\revert Staff.OttavaBracket.outside-staff-padding
>\override Staff.OttavaBracket.extra-offset = #'(0 . 0.1)
>\notes
> }
> 
>
>
This gives a clearer overview, thanks, but I would not use it, even if it
produces the wanted result.
I did not omit them, given that I did not want to reset any property, as I
explained in other posts. In practice, you are only making reset of all the
properties that add more space between the grob and the reference point. At
the end, considering that you have to add a .46 value, you get even a worse
procedure than \override Y-offset, while using the same logic (which is:
distance from a reference point, and not *offset the result*). So: I think
it's better to use a ruler from the middle of the staff.
No other way, if you want to preserve the avoid-collision algo.

Best,
Paolo

Re: Getting readline to work in scheme-sandbox

[Knute Snortum]

That did it!  Thanks!

---
Knute Snortum
(via Gmail)
On Thu, Jan 16, 2020 at 1:06 PM Michael Käppler  wrote:
>
> Am 16.01.2020 um 19:45 schrieb Knute Snortum:
> > I used "make install" to install libguilereadline.
> >
> > I've attached config.log and libguilereadline.dump.
> >
> > ---
> > Knute Snortum
> > (via Gmail)
> Ok, seems that your libguilereadline-v-17 has been built correctly
> against the readline-8.0 library, which you provided with
> libreadline-dev. Fine.
> Please rename
> /home/knute/lilypond/lilypond-2.19.83/lilypond/usr/lib/libguilereadline-v-17.so.17.0.3
> to libguilereadline-v-17.so.17.0.3.old and put the corresponding file from
> /home/knute/guile-1.8/guile-readline/.libs/ in there.
>
> Then test again, if it fails, please do a strace.
>
> Michael
>
> >
> > On Thu, Jan 16, 2020 at 12:51 AM Michael Käppler  wrote:
> >> Am 15.01.2020 um 23:55 schrieb Knute Snortum:
> >>> Okay, I built guile 1.8.7 after installing GNU MP and flex, but I get
> >>> the same error:
> >>>
> >>> guile> (use-modules (ice-9 readline))
> >>> ERROR: readline is not provided in this Guile installation
> >>> ABORT: (misc-error)
> >>>
> >>> So I redid the strace and I attached the log file.
> >> Which way of "installing" libguilereadline did you choose?
> >> Did you run "make install" or did you copy
> >> libguilereadline-v-17.so.17.0.3 to
> >> /home/knute/lilypond/lilypond-2.19.83/lilypond/usr/lib ?
> >> Could you please send me your config.log from guile-1.8/guile-readline
> >> and additionately do a
> >>
> >> objdump -x
> >> ~/guile-1.8/guile-readline/.libs/libguilereadline-v-17.so.17.0.3 >
> >> libguilereadline.dump
> >> and attach the resulting file, too?
> >>
> >> Thanks for your patience,
> >> Michael
> >>
> >>> ---
> >>> Knute Snortum
> >>> (via Gmail)
> >>>
> >>> On Wed, Jan 15, 2020 at 12:29 PM Michael Käppler  
> >>> wrote:
>  Do you have "gettext" installed? If not, please install and retry.
> 
>  Am 15.01.2020 um 18:38 schrieb Knute Snortum:
> > I didn't get past autogen:
> >
> > autoreconf: Entering directory `.'
> > autoreconf: configure.ac: not using Gettext
> > autoreconf: running: aclocal --force -I m4
> > configure.ac:905: warning: macro 'AM_GNU_GETTEXT' not found in library
> > autoreconf: configure.ac: tracing
> > autoreconf: configure.ac: adding subdirectory guile-readline to 
> > autoreconf
> > autoreconf: Entering directory `guile-readline'
> > autoreconf: running: aclocal --force
> > autoreconf: running: libtoolize --copy --force
> > libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, '.'.
> > libtoolize: copying file './ltmain.sh'
> > libtoolize: Consider adding 'AC_CONFIG_MACRO_DIRS([m4])' to 
> > configure.ac,
> > libtoolize: and rerunning libtoolize and aclocal.
> > libtoolize: Consider adding '-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
> > autoreconf: running: /usr/bin/autoconf --force
> > autoreconf: running: /usr/bin/autoheader --force
> > autoreconf: running: automake --add-missing --copy --force-missing
> > configure.ac:18: installing './compile'
> > configure.ac:19: installing './config.guess'
> > configure.ac:19: installing './config.sub'
> > configure.ac:13: installing './install-sh'
> > configure.ac:13: installing './missing'
> > Makefile.am:29: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS'
> > (or '*_CPPFLAGS')
> > Makefile.am: installing './depcomp'
> > autoreconf: Leaving directory `guile-readline'
> > libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, 'build-aux'.
> > libtoolize: copying file 'build-aux/ltmain.sh'
> > libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
> > libtoolize: copying file 'm4/libtool.m4'
> > libtoolize: copying file 'm4/ltoptions.m4'
> > libtoolize: copying file 'm4/ltsugar.m4'
> > libtoolize: copying file 'm4/ltversion.m4'
> > libtoolize: copying file 'm4/lt~obsolete.m4'
> > configure.ac:905: warning: macro 'AM_GNU_GETTEXT' not found in library
> > configure.ac:932: error: possibly undefined macro: AM_GNU_GETTEXT
> >  If this token and others are legitimate, please use 
> > m4_pattern_allow.
> >  See the Autoconf documentation.
> > autoreconf: /usr/bin/autoconf failed with exit status: 1
> >
> >
> > ---
> > Knute Snortum
> > (via Gmail)
> >
> > On Wed, Jan 15, 2020 at 12:24 AM Michael Käppler  
> > wrote:
> >> Ok, seems that guile-2.2-libs does not provide libguilereadline...
> >>
> >> I think the remaining option is to build guile-1.8 from scratch.
> >> First make sure that you have libreadline-dev installed, then, in your
> >> home directory, do:
> >>
> >> git clone -b branch_release-1-8 --single-branch
> >> https://git.savannah.gnu.org/git/guile.git guile-1.8
> >> cd guile-1.8
> >> ./autogen.sh
> >> ./configure --disable-error-on-warning 

Re: Distance of a grob from its reference point

[Aaron Hill]

On 2020-01-16 2:43 pm, Paolo Prete wrote:

On Thu, Jan 16, 2020 at 11:35 PM Aaron Hill 
wrote:




You forgot to \revert outside-staff-padding *before* applying
extra-offset.


Right, But even with \revert, the issue remains, because in any case 
the

value of 0.56 for outside-staff-padding doesn't produce a shift. See:


This time, you omitted the overrides to prevent padding and 
staff-padding from influencing the test:



\version "2.19.45"
notes = \fixed c''' { \ottava 1 f4 4 4 \ottava 0 f, }

{
  % Make sure these properties do not influence
  % anything while testing outside-staff-padding.
  \override Staff.OttavaBracket.padding = 0
  \override Staff.OttavaBracket.staff-padding = 0

  \override Staff.OttavaBracket.outside-staff-padding = 0.56
  \notes

  \revert Staff.OttavaBracket.outside-staff-padding
  \override Staff.OttavaBracket.extra-offset = #'(0 . 0.1)
  \notes
}



font-style="italic" font-size="2.2001" text-anchor="start" 
fill="currentColor">

8va


font-style="italic" font-size="2.2001" text-anchor="start" 
fill="currentColor">

8va



Mind you, this is all purely a test scenario, not a practical one.  In 
practice, you'll have all of the spacing properties to contend with.  
While it might be possible to adjust a single property to effect the 
change you need in one spot, that same property might be not be 
sufficient in other situations.



-- Aaron Hill

Re: Distance of a grob from its reference point

[Paolo Prete]

On Thu, Jan 16, 2020 at 11:35 PM Aaron Hill 
wrote:

>
>
> You forgot to \revert outside-staff-padding *before* applying
> extra-offset.
>
>
Right, But even with \revert, the issue remains, because in any case the
value of 0.56 for outside-staff-padding doesn't produce a shift. See:

%%


\version "2.19.45"
{

\override Staff.OttavaBracket.outside-staff-padding = #0
  \ottava #1 f''' f''' f''' \ottava #0 f''

\override Staff.OttavaBracket.outside-staff-padding = #0.56
  \ottava #1 f''' f''' f''' \ottava #0 f''

\revert Staff.OttavaBracket.outside-staff-padding

\override Staff.OttavaBracket.extra-offset = #'(0 . 0.1)
  \ottava #1 f''' f''' f''' \ottava #0 f''

}

%

Re: Distance of a grob from its reference point

[Thomas Morley]

Am Do., 16. Jan. 2020 um 23:12 Uhr schrieb David Nalesnik
:
>
> On Thu, Jan 16, 2020 at 3:42 PM David Nalesnik  
> wrote:
> >
> > Hi Robin,
> >
> > On Thu, Jan 16, 2020 at 1:02 PM Robin Bannister  wrote:
> > >
> > > Paolo Prete wrote:
> > >
> > > > This is *precious* info. Please, can you tell/confirm  if
> > > >
> > > > 1) you are referring to \offset command ?
> > >
> > > No.  That would be premature in this case.
> > >
> > >
> > > > 2) is it applicable as a replacement for "\offset Y-offset" for *every*
> > > > grob that support Y-offset ?
> > >
> > > Well, I have trouble following your trains of thought.
> > > I won't try to understand that question.
> > >
> > > And I'm puzzled why you focus directly on the property Y-offset.
> > >
> > >
> > > As regards the \offset command:
> > > The section 'Properties which may be offset' at
> > > http://lilypond.org/doc/v2.19/Documentation/notation/the-offset-command
> > > says the property must have a default setting in define-grobs.scm.
> > >
> > > OttavaBracket has the property outside-staff-padding because it supports
> > > the outside-staff-interface.
> > > http://lilypond.org/doc/v2.19/Documentation/internals/outside_002dstaff_002dinterface
> > > but define-grobs.scm doesn't set it.
> > >
> > > So you can't use \offset in this case until that is amended.
> >
> > This is an argument for adding these hidden default values directly to
> > define-grobs.scm.
> >
>
> Actually, you can set a default value from which \offset will work.
> It relies on the combination \override and \once \offset:
> \version "2.19.80"
>
> {
>   \override Staff.OttavaBracket.outside-staff-padding = 0.46 % set me
> to default first!
>   \ottava #1
>   c''4 e'' d'' f''
>   \ottava #0
>   c''1
>   \once \offset outside-staff-padding #2 Staff.OttavaBracket
>   \ottava #1
>   c''4 e'' d'' f''
>   \ottava #0
> }
>
> Uh oh, now I've opened a can of worms :)
>
> David
>

And another one:
(To summarize;) It seems impossible to always get the actual used
values for properties with an unpure-pure-container. (Thus \offset has
problems in certain cases).
The actual used values are settled too late.

Though, (the other can of worms) we have the ´page-post-process´-hook.
See "Application Usage".

May lead to the code below.
Values are read after the _page_ is done, then used in a second run.
Thougn there's still some inaccuratesse, ~1/3-line-thickness, i.e.
~0.003, no idea where it comes from...

NB, It's nothing more then a proof-of-concept!
Tbh, I'd not try to make it really work ...

Anyway:

\version "2.19.83"

\paper { ragged-right = ##t }

test =
#(define-music-function (y) (number?)

   (define (proc grob)
 (let* ((orig (ly:grob-property grob 'stencil))
(sten
  (grob-interpret-markup grob
#{
   \markup
 \with-dimensions-from \stencil #orig
 \overlay {
   \stencil #orig
   \with-color #red
   \translate #(cons 0 (- y))
   \path #0.1
 #`((moveto -1 ,y)
(lineto 1 ,y)
(moveto 0 ,y)
(lineto 0 0)
(moveto -1 0)
(lineto 1 0)
(moveto -0.5 1)
(lineto 0 0)
(lineto 0.5 1))
 }
#})))

   (ly:grob-set-property! grob 'stencil sten)))

   #{ \override Staff.OttavaBracket.after-line-breaking = #proc #})


#(define (get-ottava-y-offs layout pages)
  (let* ((lines (map (lambda (page) (ly:prob-property page 'lines)) pages))
 (systems
   (append-map
 (lambda (line)
   (append-map
 (lambda (l)
   (let ((system-grob (ly:prob-property l 'system-grob)))
 (if (not (null? system-grob))
 (list system-grob)
 system-grob)))
 line))
 lines))
  (system-elts
(map ly:grob-array->list
  (map (lambda (sys) (ly:grob-object sys 'all-elements)) systems)))
  (ottava-grobs
(map
  (lambda (elt-list)
 (filter
   (lambda (elt)
 (grob::has-interface elt 'ottava-bracket-interface))
   elt-list))
  system-elts))
  (y-off-list
(map
  (lambda (sub-list)
(map
  (lambda (ottava-grob)
(let* ((staff-symbol
 (ly:grob-object ottava-grob 'staff-symbol))
   (sys (ly:grob-system ottava-grob))
   (centered-staff-symbol-y-ext
 (interval-center
   (ly:grob-robust-relative-extent

Re: Distance of a grob from its reference point

[Aaron Hill]

On 2020-01-16 2:09 pm, Paolo Prete wrote:
I'm sorry to say that I made additional tests and the +0.46 method 
doesn't

seem to work.
You can check here:

%%

\version "2.19.45"
{

\override Staff.OttavaBracket.outside-staff-padding = #0
  \ottava #1 f''' f''' f''' \ottava #0 f''

\override Staff.OttavaBracket.outside-staff-padding = #0.56
  \ottava #1 f''' f''' f''' \ottava #0 f''

\override Staff.OttavaBracket.extra-offset = #'(0 . 0.1)
  \ottava #1 f''' f''' f''' \ottava #0 f''

}

%

0.56 s exactly the quantity corresponding to extra-offset to 0.1.   But 
if
you produce a SVG file, and open it with a text editor, you will see 
three

pairs of coordinates:


You forgot to \revert outside-staff-padding *before* applying 
extra-offset.



\version "2.19.45"
notes = \fixed c''' { \ottava 1 f4 4 4 \ottava 0 f, }

{
  % Make sure these properties do not influence
  % anything while testing outside-staff-padding.
  \override Staff.OttavaBracket.padding = 0
  \override Staff.OttavaBracket.staff-padding = 0

  \override Staff.OttavaBracket.outside-staff-padding = 0
  \notes

  \override Staff.OttavaBracket.outside-staff-padding = 0.56
  \notes

  \revert Staff.OttavaBracket.outside-staff-padding
  \override Staff.OttavaBracket.extra-offset = #'(0 . 0.1)
  \notes
}



-- Aaron Hill

Re: Distance of a grob from its reference point

[Paolo Prete]

On Thu, Jan 16, 2020 at 11:09 PM Paolo Prete  wrote:

>
> %
>
> 0.56 s exactly the quantity corresponding to extra-offset to 0.1.   But if
> you produce a SVG file, and open it with a text editor, you will see three
> pairs of coordinates:
>
> (first bracket)
> 
> (second bracket)
> 
> (third bracket)
> 
> As you can see, only the third bracket (corresponding to the extra-offset
> property) is correctly shifted by 0.1
>
> I also checked that the same issue happens with DynamicLineSpanner.
> There's a value aroud 0.46, but not exactly 0.46 as the default offset.
> And it seems to be the same for both OttavaBracket and
> DynamicLineSpanner
> Where did you pick the 0.46 value? I did grep on the whole tree src, and
> even if it's set as  default_outside_staff_padding_
> (axis_group_interface.cc) it must have overridden by something else...
>
> Best,
> Paolo
>

Well, I think I got the issue.
You don't have to consider the default 0.46 value.
outside-staff-padding's behavior is similar to Y-offset's one (I'm talking
about \override, NOT \offset command). It only differs for the reference
point. Third line in Y-offset, first line in outside-staff-padding.
So, you can use it only with a ruler starting from the ref point.
Even if uncomfortable, it makes sense.

HTH
Paolo

Re: Distance of a grob from its reference point

[David Nalesnik]

On Thu, Jan 16, 2020 at 3:42 PM David Nalesnik  wrote:
>
> Hi Robin,
>
> On Thu, Jan 16, 2020 at 1:02 PM Robin Bannister  wrote:
> >
> > Paolo Prete wrote:
> >
> > > This is *precious* info. Please, can you tell/confirm  if
> > >
> > > 1) you are referring to \offset command ?
> >
> > No.  That would be premature in this case.
> >
> >
> > > 2) is it applicable as a replacement for "\offset Y-offset" for *every*
> > > grob that support Y-offset ?
> >
> > Well, I have trouble following your trains of thought.
> > I won't try to understand that question.
> >
> > And I'm puzzled why you focus directly on the property Y-offset.
> >
> >
> > As regards the \offset command:
> > The section 'Properties which may be offset' at
> > http://lilypond.org/doc/v2.19/Documentation/notation/the-offset-command
> > says the property must have a default setting in define-grobs.scm.
> >
> > OttavaBracket has the property outside-staff-padding because it supports
> > the outside-staff-interface.
> > http://lilypond.org/doc/v2.19/Documentation/internals/outside_002dstaff_002dinterface
> > but define-grobs.scm doesn't set it.
> >
> > So you can't use \offset in this case until that is amended.
>
> This is an argument for adding these hidden default values directly to
> define-grobs.scm.
>

Actually, you can set a default value from which \offset will work.
It relies on the combination \override and \once \offset:
\version "2.19.80"

{
  \override Staff.OttavaBracket.outside-staff-padding = 0.46 % set me
to default first!
  \ottava #1
  c''4 e'' d'' f''
  \ottava #0
  c''1
  \once \offset outside-staff-padding #2 Staff.OttavaBracket
  \ottava #1
  c''4 e'' d'' f''
  \ottava #0
}

Uh oh, now I've opened a can of worms :)

David

Re: Distance of a grob from its reference point

[Paolo Prete]

Hi Robin,

On Thu, Jan 16, 2020 at 10:05 PM Robin Bannister  wrote:

> Paolo Prete wrote:
>
> > And I really thank you. Offsetting brackets is a *very*, *very* important
> > feature in professional music engraving.
>
> You're welcome.




I'm sorry to say that I made additional tests and the +0.46 method doesn't
seem to work.
You can check here:

%%

\version "2.19.45"
{

\override Staff.OttavaBracket.outside-staff-padding = #0
  \ottava #1 f''' f''' f''' \ottava #0 f''

\override Staff.OttavaBracket.outside-staff-padding = #0.56
  \ottava #1 f''' f''' f''' \ottava #0 f''


\override Staff.OttavaBracket.extra-offset = #'(0 . 0.1)
  \ottava #1 f''' f''' f''' \ottava #0 f''

}

%

0.56 s exactly the quantity corresponding to extra-offset to 0.1.   But if
you produce a SVG file, and open it with a text editor, you will see three
pairs of coordinates:

(first bracket)

Re: compiling 2.19.83 needs guile-config < 1.9.0

[Thomas Morley]

Am Do., 16. Jan. 2020 um 21:29 Uhr schrieb Bric :
>
> I think this was discussed before, but i'm not sure how to downgrade guile on 
> Ubuntu 18.04.2 LTS
>
> I tried building guile-1.8.0, guile-1.8.4, guile-1.8.5, but the build fails 
> for all three.
>
> lilypond ./configure error:
>
> ERROR: Please install required programs: guile-config < 1.9.0 (installed: 
> 2.2.3) (guile-devel, guile-dev or libguile-dev package) libguile 
> (libguile-dev, guile-devel or guile-dev package). GUILE-with-rational-bugfix

You likely need to point configure to guile and guile-config

../configure GUILE_CONFIG=/path/to/guile-config GUILE=/path/to/guile

Cheers,
  Harm

Re: Distance of a grob from its reference point

[David Nalesnik]

Hi Robin,

On Thu, Jan 16, 2020 at 1:02 PM Robin Bannister  wrote:
>
> Paolo Prete wrote:
>
> > This is *precious* info. Please, can you tell/confirm  if
> >
> > 1) you are referring to \offset command ?
>
> No.  That would be premature in this case.
>
>
> > 2) is it applicable as a replacement for "\offset Y-offset" for *every*
> > grob that support Y-offset ?
>
> Well, I have trouble following your trains of thought.
> I won't try to understand that question.
>
> And I'm puzzled why you focus directly on the property Y-offset.
>
>
> As regards the \offset command:
> The section 'Properties which may be offset' at
> http://lilypond.org/doc/v2.19/Documentation/notation/the-offset-command
> says the property must have a default setting in define-grobs.scm.
>
> OttavaBracket has the property outside-staff-padding because it supports
> the outside-staff-interface.
> http://lilypond.org/doc/v2.19/Documentation/internals/outside_002dstaff_002dinterface
> but define-grobs.scm doesn't set it.
>
> So you can't use \offset in this case until that is amended.

This is an argument for adding these hidden default values directly to
define-grobs.scm.

Best,
David

Re: Getting readline to work in scheme-sandbox

[Michael Käppler]

Am 16.01.2020 um 19:45 schrieb Knute Snortum:

I used "make install" to install libguilereadline.

I've attached config.log and libguilereadline.dump.

---
Knute Snortum
(via Gmail)

Ok, seems that your libguilereadline-v-17 has been built correctly
against the readline-8.0 library, which you provided with
libreadline-dev. Fine.
Please rename
/home/knute/lilypond/lilypond-2.19.83/lilypond/usr/lib/libguilereadline-v-17.so.17.0.3
to libguilereadline-v-17.so.17.0.3.old and put the corresponding file from
/home/knute/guile-1.8/guile-readline/.libs/ in there.

Then test again, if it fails, please do a strace.

Michael



On Thu, Jan 16, 2020 at 12:51 AM Michael Käppler  wrote:

Am 15.01.2020 um 23:55 schrieb Knute Snortum:

Okay, I built guile 1.8.7 after installing GNU MP and flex, but I get
the same error:

guile> (use-modules (ice-9 readline))
ERROR: readline is not provided in this Guile installation
ABORT: (misc-error)

So I redid the strace and I attached the log file.

Which way of "installing" libguilereadline did you choose?
Did you run "make install" or did you copy
libguilereadline-v-17.so.17.0.3 to
/home/knute/lilypond/lilypond-2.19.83/lilypond/usr/lib ?
Could you please send me your config.log from guile-1.8/guile-readline
and additionately do a

objdump -x
~/guile-1.8/guile-readline/.libs/libguilereadline-v-17.so.17.0.3 >
libguilereadline.dump
and attach the resulting file, too?

Thanks for your patience,
Michael


---
Knute Snortum
(via Gmail)

On Wed, Jan 15, 2020 at 12:29 PM Michael Käppler  wrote:

Do you have "gettext" installed? If not, please install and retry.

Am 15.01.2020 um 18:38 schrieb Knute Snortum:

I didn't get past autogen:

autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force -I m4
configure.ac:905: warning: macro 'AM_GNU_GETTEXT' not found in library
autoreconf: configure.ac: tracing
autoreconf: configure.ac: adding subdirectory guile-readline to autoreconf
autoreconf: Entering directory `guile-readline'
autoreconf: running: aclocal --force
autoreconf: running: libtoolize --copy --force
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, '.'.
libtoolize: copying file './ltmain.sh'
libtoolize: Consider adding 'AC_CONFIG_MACRO_DIRS([m4])' to configure.ac,
libtoolize: and rerunning libtoolize and aclocal.
libtoolize: Consider adding '-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
autoreconf: running: /usr/bin/autoconf --force
autoreconf: running: /usr/bin/autoheader --force
autoreconf: running: automake --add-missing --copy --force-missing
configure.ac:18: installing './compile'
configure.ac:19: installing './config.guess'
configure.ac:19: installing './config.sub'
configure.ac:13: installing './install-sh'
configure.ac:13: installing './missing'
Makefile.am:29: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS'
(or '*_CPPFLAGS')
Makefile.am: installing './depcomp'
autoreconf: Leaving directory `guile-readline'
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, 'build-aux'.
libtoolize: copying file 'build-aux/ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
libtoolize: copying file 'm4/libtool.m4'
libtoolize: copying file 'm4/ltoptions.m4'
libtoolize: copying file 'm4/ltsugar.m4'
libtoolize: copying file 'm4/ltversion.m4'
libtoolize: copying file 'm4/lt~obsolete.m4'
configure.ac:905: warning: macro 'AM_GNU_GETTEXT' not found in library
configure.ac:932: error: possibly undefined macro: AM_GNU_GETTEXT
 If this token and others are legitimate, please use m4_pattern_allow.
 See the Autoconf documentation.
autoreconf: /usr/bin/autoconf failed with exit status: 1


---
Knute Snortum
(via Gmail)

On Wed, Jan 15, 2020 at 12:24 AM Michael Käppler  wrote:

Ok, seems that guile-2.2-libs does not provide libguilereadline...

I think the remaining option is to build guile-1.8 from scratch.
First make sure that you have libreadline-dev installed, then, in your
home directory, do:

git clone -b branch_release-1-8 --single-branch
https://git.savannah.gnu.org/git/guile.git guile-1.8
cd guile-1.8
./autogen.sh
./configure --disable-error-on-warning --prefix=/usr/local
make
make install
ldconfig

If you do not want to install your self-compiled guile-1.8 globally with
"make install" it should be also sufficient to
rename
/home/knute/lilypond/lilypond-2.19.83/lilypond/usr/lib/libguilereadline-v-17.so.17.0.3
to
libguilereadline-v-17.so.17.0.3.old and put the corresponding file from
/home/knute/guile-1.8/guile-readline/.libs/
in there.

Then try with scheme-sandbox.ly again. Please report if it succeeds now.

Michael




Am 15.01.2020 um 00:05 schrieb Knute Snortum:

I'm not in a vanilla setup, so I changed the commands to: (just for posterity)

$ export 
LD_LIBRARY_PATH="/home/knute/lilypond/lilypond-2.19.83/lilypond/usr/lib"
$ strace -o readlinedebug.log
/home/knute/lilypond/lilypond-2.19.83/lilypond/usr/bin/lilypond
scheme-sandbox.ly

The log file is attached.

---
Knute Snortum
(via 

Re: Distance of a grob from its reference point

[Robin Bannister]

Paolo Prete wrote:


And I really thank you. Offsetting brackets is a *very*, *very* important
feature in professional music engraving.


You're welcome.

I hope you don't run foul of the disadvantages too soon.
See Kieren's last comment in
https://lists.gnu.org/archive/html/lilypond-user/2020-01/msg00237.html



Cheers,
Robin

compiling 2.19.83 needs guile-config < 1.9.0

[Bric]

 
 
  
   I think this was discussed before, but i'm not sure how to downgrade guile on Ubuntu 18.04.2 LTS
   
  
  
   
  
  
   I tried building guile-1.8.0, guile-1.8.4, guile-1.8.5, but the build fails for all three. 
   
   
  
  
   lilypond ./configure error:
   
  
  
   
  
  
   ERROR: Please install required programs: guile-config < 1.9.0 (installed: 2.2.3) (guile-devel, guile-dev or libguile-dev package) libguile (libguile-dev, guile-devel or guile-dev package). GUILE-with-rational-bugfix
   
 

Re: Distance of a grob from its reference point

[Paolo Prete]

On Thu, Jan 16, 2020 at 8:01 PM Robin Bannister  wrote:

> Paolo Prete wrote:
>



> So this 0.46 is just for outside-staff-padding.
>


And I really thank you. Offsetting brackets is a *very*, *very* important
feature in professional music engraving.

Best,
Paolo

Re: Distance of a grob from its reference point

[Paolo Prete]

On Thu, Jan 16, 2020 at 7:22 PM Carl Sorensen  wrote:


> My testing found that \offset didn’t work with outside-staff-padding for
> OttavaBracket grobs.
>

That's great, because with this method the user is not forced to use a
ruler. Then, the best one. I just tested it and now we can say that, in
order to shift vertically a bracket, the user should follow this rule:

1) \override + outside-staff-padding increased of 0.46   (if you want to
preserve the automatic collision avoidance)

OR

2) extra-offset (as a final tuning, if you don't need automatic collision
avoidance)

OR

3)  \override X/Y-offset with a ruler with staff-space units and a starting
set on the middle of the staff (if you need automatic collision avoidance)



> It is **very** unlikely that you will find a single approach that will
> work with **every** grob.  You may be able to find approaches that will
> work with classes of grobs.  You may need to have individual approaches
> that apply to specific grobs.
>

Yeah, no surprise for me. But I asked. You never know...


> It appears that much or your dissatisfaction is because you thought you
> had found a trivial solution (i.e. use \offset Y-offset) only to find that
> it doesn’t work.
>

You are wrong. Not only I'm not dissatisfied: I'm seeing that all these
work even better  than I could imagine some days ago. Really great and
powerful. What made me upset is that there's not a clear blacklist of the
unpredictable properties for a given grob. Nor this is documented or
warned. Then I think we all had headache in discovering the right ones for
the Bracket. Please don't misunderstand these words: it's not a criticism
at all for Lilypond. I work every day with open source projects, and this
kind of issues are absolutely normal for them. We are all volunteers. The
more the project is complex, the more you find issues or undocumented
features.
If you felt that I wanted to blame a behavior of Lilypond, please delete
this idea.

HTH
Paolo

Re: Distance of a grob from its reference point

[Robin Bannister]

Paolo Prete wrote:


This is *precious* info. Please, can you tell/confirm  if

1) you are referring to \offset command ? 


No.  That would be premature in this case.



2) is it applicable as a replacement for "\offset Y-offset" for *every*
grob that support Y-offset ?


Well, I have trouble following your trains of thought.
I won't try to understand that question.

And I'm puzzled why you focus directly on the property Y-offset.


As regards the \offset command:
The section 'Properties which may be offset' at
http://lilypond.org/doc/v2.19/Documentation/notation/the-offset-command
says the property must have a default setting in define-grobs.scm.

OttavaBracket has the property outside-staff-padding because it supports 
the outside-staff-interface.

http://lilypond.org/doc/v2.19/Documentation/internals/outside_002dstaff_002dinterface
but define-grobs.scm doesn't set it.

So you can't use \offset in this case until that is amended.

As to the default value used for outside-staff-padding when neither 
define-grobs.scm sets it or any other code overrides it, see

https://lists.gnu.org/archive/html/lilypond-user/2020-01/msg00181.html

So this 0.46 is just for outside-staff-padding.



Cheers,
Robin

Re: Getting readline to work in scheme-sandbox

[Knute Snortum]

I used "make install" to install libguilereadline.

I've attached config.log and libguilereadline.dump.

---
Knute Snortum
(via Gmail)

On Thu, Jan 16, 2020 at 12:51 AM Michael Käppler  wrote:
>
> Am 15.01.2020 um 23:55 schrieb Knute Snortum:
> > Okay, I built guile 1.8.7 after installing GNU MP and flex, but I get
> > the same error:
> >
> > guile> (use-modules (ice-9 readline))
> > ERROR: readline is not provided in this Guile installation
> > ABORT: (misc-error)
> >
> > So I redid the strace and I attached the log file.
> Which way of "installing" libguilereadline did you choose?
> Did you run "make install" or did you copy
> libguilereadline-v-17.so.17.0.3 to
> /home/knute/lilypond/lilypond-2.19.83/lilypond/usr/lib ?
> Could you please send me your config.log from guile-1.8/guile-readline
> and additionately do a
>
> objdump -x
> ~/guile-1.8/guile-readline/.libs/libguilereadline-v-17.so.17.0.3 >
> libguilereadline.dump
> and attach the resulting file, too?
>
> Thanks for your patience,
> Michael
>
> >
> > ---
> > Knute Snortum
> > (via Gmail)
> >
> > On Wed, Jan 15, 2020 at 12:29 PM Michael Käppler  wrote:
> >> Do you have "gettext" installed? If not, please install and retry.
> >>
> >> Am 15.01.2020 um 18:38 schrieb Knute Snortum:
> >>> I didn't get past autogen:
> >>>
> >>> autoreconf: Entering directory `.'
> >>> autoreconf: configure.ac: not using Gettext
> >>> autoreconf: running: aclocal --force -I m4
> >>> configure.ac:905: warning: macro 'AM_GNU_GETTEXT' not found in library
> >>> autoreconf: configure.ac: tracing
> >>> autoreconf: configure.ac: adding subdirectory guile-readline to autoreconf
> >>> autoreconf: Entering directory `guile-readline'
> >>> autoreconf: running: aclocal --force
> >>> autoreconf: running: libtoolize --copy --force
> >>> libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, '.'.
> >>> libtoolize: copying file './ltmain.sh'
> >>> libtoolize: Consider adding 'AC_CONFIG_MACRO_DIRS([m4])' to configure.ac,
> >>> libtoolize: and rerunning libtoolize and aclocal.
> >>> libtoolize: Consider adding '-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
> >>> autoreconf: running: /usr/bin/autoconf --force
> >>> autoreconf: running: /usr/bin/autoheader --force
> >>> autoreconf: running: automake --add-missing --copy --force-missing
> >>> configure.ac:18: installing './compile'
> >>> configure.ac:19: installing './config.guess'
> >>> configure.ac:19: installing './config.sub'
> >>> configure.ac:13: installing './install-sh'
> >>> configure.ac:13: installing './missing'
> >>> Makefile.am:29: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS'
> >>> (or '*_CPPFLAGS')
> >>> Makefile.am: installing './depcomp'
> >>> autoreconf: Leaving directory `guile-readline'
> >>> libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, 'build-aux'.
> >>> libtoolize: copying file 'build-aux/ltmain.sh'
> >>> libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
> >>> libtoolize: copying file 'm4/libtool.m4'
> >>> libtoolize: copying file 'm4/ltoptions.m4'
> >>> libtoolize: copying file 'm4/ltsugar.m4'
> >>> libtoolize: copying file 'm4/ltversion.m4'
> >>> libtoolize: copying file 'm4/lt~obsolete.m4'
> >>> configure.ac:905: warning: macro 'AM_GNU_GETTEXT' not found in library
> >>> configure.ac:932: error: possibly undefined macro: AM_GNU_GETTEXT
> >>> If this token and others are legitimate, please use 
> >>> m4_pattern_allow.
> >>> See the Autoconf documentation.
> >>> autoreconf: /usr/bin/autoconf failed with exit status: 1
> >>>
> >>>
> >>> ---
> >>> Knute Snortum
> >>> (via Gmail)
> >>>
> >>> On Wed, Jan 15, 2020 at 12:24 AM Michael Käppler  
> >>> wrote:
>  Ok, seems that guile-2.2-libs does not provide libguilereadline...
> 
>  I think the remaining option is to build guile-1.8 from scratch.
>  First make sure that you have libreadline-dev installed, then, in your
>  home directory, do:
> 
>  git clone -b branch_release-1-8 --single-branch
>  https://git.savannah.gnu.org/git/guile.git guile-1.8
>  cd guile-1.8
>  ./autogen.sh
>  ./configure --disable-error-on-warning --prefix=/usr/local
>  make
>  make install
>  ldconfig
> 
>  If you do not want to install your self-compiled guile-1.8 globally with
>  "make install" it should be also sufficient to
>  rename
>  /home/knute/lilypond/lilypond-2.19.83/lilypond/usr/lib/libguilereadline-v-17.so.17.0.3
>  to
>  libguilereadline-v-17.so.17.0.3.old and put the corresponding file from
>  /home/knute/guile-1.8/guile-readline/.libs/
>  in there.
> 
>  Then try with scheme-sandbox.ly again. Please report if it succeeds now.
> 
>  Michael
> 
> 
> 
> 
>  Am 15.01.2020 um 00:05 schrieb Knute Snortum:
> > I'm not in a vanilla setup, so I changed the commands to: (just for 
> > posterity)
> >
> > $ export 
> > LD_LIBRARY_PATH="/home/knute/lilypond/lilypond-2.19.83/lilypond/usr/lib"
> > $ strace 

Re: Distance of a grob from its reference point

[Aaron Hill]

On 2020-01-16 8:46 am, Carl Sorensen wrote:

On 1/16/20, 9:34 AM, "Robin Bannister"  wrote:

 3) make outside-staff-padding 0.46 more than needed vertical shift
e.g. 2.46


Could you just \offset outside-staff-padding by 2?


Unfortunately, no.  outside-staff-padding does not have a specific 
default value defined for any type of grob.  This is the main limitation 
of \offset.


Internally, Axis_group_interface::default_outside_staff_padding_ is 
0.46, but \offset has no knowledge of that value.  Instead, it will see 
the grob property as unset and will not be able to perform the desired 
arithmetic.



-- Aaron Hill

Re: Distance of a grob from its reference point

[Carl Sorensen]

From: Paolo Prete 
Date: Thursday, January 16, 2020 at 10:24 AM
To: Robin Bannister 
Cc: Michael Gerdau , Lilypond-User Mailing List 
, Carl Sorensen 
Subject: Re: Distance of a grob from its reference point



On Thu, Jan 16, 2020 at 5:33 PM Robin Bannister 
mailto:r...@dabble.ch>> wrote:


OR

3) make outside-staff-padding 0.46 more than needed vertical shift
e.g. 2.46

Cheers,
Robin

This is *precious* info. Please, can you tell/confirm  if


  1.  you are referring to \offset command ?

My testing found that \offset didn’t work with outside-staff-padding for 
OttavaBracket grobs.


  1.  is it applicable as a replacement for "\offset Y-offset" for *every* grob 
that support Y-offset ?


No.  outside-staff-padding is a different property than Y-offset.  Grobs that 
live in the staff are largely controlled by Y-offset.  Grobs that live outside 
of the staff are placed outside the staff grobs by at least 
outside-staff-padding when all of the properties that control the automatic 
placement are considered.

It is *very* unlikely that you will find a single approach that will work with 
*every* grob.  You may be able to find approaches that will work with classes 
of grobs.  You may need to have individual approaches that apply to specific 
grobs.

The music layout problem is very complex.  Lilypond treats it as such.  Once 
the layout is accomplished, you can manually move grobs with extra-offset, but 
you are then responsible for resolving collisions.  Providing bias that causes 
fixed incremental motion of individual grobs in the collision-resolved output 
is not a trivial problem, as you have discovered.  It appears that much or your 
dissatisfaction is because you thought you had found a trivial solution (i.e. 
use \offset Y-offset) only to find that it doesn’t work.

I am completely confident that there is *no* trivial solution.  There may be a 
*set* of trivial solutions, each of which applies to a family of grobs.  But 
finding those solutions will require individually checking how each grob is 
affected.  You can get the list of grobs in the NR (All layout objects).

Carl.

Re: Distance of a grob from its reference point

[Paolo Prete]

On Thu, Jan 16, 2020 at 5:33 PM Robin Bannister  wrote:


> OR
>
> 3) make outside-staff-padding 0.46 more than needed vertical shift
> e.g. 2.46
>
> Cheers,

Robin
>

This is *precious* info. Please, can you tell/confirm  if

1) you are referring to \offset command ?

2) is it applicable as a replacement for "\offset Y-offset" for *every*
grob that support Y-offset ?

thanks.

Best,
Paolo

Re: Distance of a grob from its reference point

[Carl Sorensen]

On 1/16/20, 9:34 AM, "Robin Bannister"  wrote:

Paolo Prete wrote:

> I simply wanted to understand how to offset a bracket.
> And the conclusion is: avoid \offset + X/Y-offset and use
> 
> 1) extra-offset (if you don't need automatic collision-avoidance)
> 
> OR
> 
> 2) \override X/Y-offset with a ruler (if you need automatic
> collision-avoidance)


OR

3) make outside-staff-padding 0.46 more than needed vertical shift
e.g. 2.46


Could you just \offset outside-staff-padding by 2?

Carl
 

Re: Distance of a grob from its reference point

[Robin Bannister]

Paolo Prete wrote:


I simply wanted to understand how to offset a bracket.
And the conclusion is: avoid \offset + X/Y-offset and use

1) extra-offset (if you don't need automatic collision-avoidance)

OR

2) \override X/Y-offset with a ruler (if you need automatic
collision-avoidance)



OR

3) make outside-staff-padding 0.46 more than needed vertical shift
   e.g. 2.46



Cheers,
Robin

Re: Override a StaffSymbol property outside \new Staff { ... } context

[Paolo Prete]

On Thu, Jan 16, 2020 at 1:43 PM Simon Albrecht 
wrote:

> Hi Paolo,
>
> it seems like you have some very specific setup of lilypond files and
> framework and need a solution that works within that, but you’re trying
> to avoid explaining the whole setup either because it’s too much effort
> or for privacy or similar.


Sorry. I just explained all in the previous post, in reply to Aaron. Wrong
topic/question.
I think now all is clear.
Best,
Paolo

Re: Override a StaffSymbol property outside \new Staff { ... } context

[Paolo Prete]

On Thu, Jan 16, 2020 at 4:49 AM Aaron Hill  wrote:

>
> However, why jump through such Scheme hoops when LilyPond syntax is more
> direct?
>
>
Thank you Aaron. I used a misleading topic, sorry. I wanted a set of layout
properties which is shared by all the scores I edit. So I can simply import
it with \include.
I thought that it was necessary to replicate these props in all the layout
blocks of all the scores. Then I asked for a "Scheme solution"
But this is not true:

%%%
\version "2.19.45"
\layout {
  \context {
\Staff
  \override StaffSymbol.color = #red
  }
}

\layout {
  \context {
\Staff
  \override StaffSymbol.line-count = 3
  }
}

<< \new Staff { b'4 } \new Staff { b'4 } >>
%%%

Re: Override a StaffSymbol property outside \new Staff { ... } context

[Simon Albrecht]

Hi Paolo,

it seems like you have some very specific setup of lilypond files and 
framework and need a solution that works within that, but you’re trying 
to avoid explaining the whole setup either because it’s too much effort 
or for privacy or similar. From my experience, when I get into that kind 
of situation I have usually ended up in some kind of ‘rabbit hole’ and 
the problem would be easier solved with a different setup in the first 
place.


Can you describe the reason why you need this?

Best, Simon

On 16.01.20 03:41, Paolo Prete wrote:
I need to override a property of StaffSymbol, for every staff, outside 
any music expression/block context. Probably I'm not using the right 
words even now.
But what I need is a sort of a "global" variable which is set for any 
staff without having to put it into some music expression (like 
\layout {\context {...}} , or \new Staff \with { ... } etc.).

This is why I asked if is there a Scheme solution

Re: Distance of a grob from its reference point

[Paolo Prete]

On Thu, Jan 16, 2020 at 11:45 AM Michael Gerdau  wrote:

>
>
> FWIW: Prior to reading this thread I wasn't even aware, that \offset
> might not do what I want in all situations. I use it occasionally and
> like it - works for me.
>
> Claiming it is completely broken seems way over the top to me.
>


Hi MIchael,

Please read carefully the thread.
I did not say that *\offset is completely broken*. I said that *the
combination \offset + YX-offset is broken*
Note also that broken features are very common to *any* software. Even to
the most perfect one.


> 
> No offence intended
> 
> Reading your posts on this topic has given me the impression that you
> had a view on how things would/should work inside LP and are now
> struggling with the revelation that at least \offset isn't as
> deterministic as you expected it to be.
>
>
No, this is not true, sorry.
I simply wanted to understand how to offset a bracket.
And the conclusion is: avoid \offset + X/Y-offset and use

1) extra-offset (if you don't need automatic collision-avoidance)

OR

2) \override X/Y-offset with a ruler (if you need automatic
collision-avoidance)

I think this is useful as documentation for users, so they won't have weird
results if they use \offset X/Y-offset.
I don't see any case where \offset X/Y-offset can be useful. Please,
provide one if I'm wrong.

Best,
P

Re: Distance of a grob from its reference point

[Michael Gerdau]

Dear Paolo,

> Yes, but, it's necessary too to add a *warning* on the Lilypond output.
> This is much more clear for the user than the documentation.

while you correctly point out that \offset sometimes leads to
random/unpredicted values it quite often gives the expected result.
At least for me.

FWIW: Prior to reading this thread I wasn't even aware, that \offset
might not do what I want in all situations. I use it occasionally and
like it - works for me.

Claiming it is completely broken seems way over the top to me.


No offence intended

Reading your posts on this topic has given me the impression that you
had a view on how things would/should work inside LP and are now
struggling with the revelation that at least \offset isn't as
deterministic as you expected it to be.

Of course this impression may be totally wrong.

Kind regards,
Michael
-- 
 Michael Gerdau   email: m...@qata.de
 GPG-keys available on request or at public keyserver



signature.asc
Description: OpenPGP digital signature

Re: Syntax highlighting

[Craig Dabelstein]

The pygments LilyPond lexer is actually going ok. I'm still copying over
the info from python-ly, but I've worked it out and so far it's working
without errors. I will have to learn some regex tricks in the next few
days. Perhaps another week and it will be ready for some testing.

Craig

On Wed., 15 Jan. 2020, 12:16 pm Craig Dabelstein, <
craig.dabelst...@gmail.com> wrote:

> Federico,
>
> Is it just me or is the documentation for Pygments really hard to
> understand? I can't even find anywhere they discuss the setup.py file.
>
> I've opened a repo (https://github.com/craigdab/pygments-lilypond-test)
> and cut and paste from other peoples repositories as a start, but I really
> have no idea what I'm doing.
>
> Craig
>
>
> On Wed, 15 Jan 2020 at 10:38, Craig Dabelstein 
> wrote:
>
>> Thank you gentlemen,
>>
>> I'll have a go at taking the python-ly work and seeing if I can use it
>> work to make syntax highlighting with pygments. It's highly possible that I
>> will totally fail, but I'll give it a try.
>>
>> Craig
>>
>>
>> On Tue, 14 Jan 2020 at 23:38, Federico Bruni  wrote:
>>
>>> Il giorno mar 14 gen 2020 alle 12:34, Urs Liska 
>>> ha scritto:
>>> > Pygments is also what Pandoc uses for its syntax highlighting, so that
>>> > would also make sense for that (e.g. generating PDF documentation from
>>> > Markdown).
>>>
>>> Are you sure?
>>> I think that pygments is the name of the default style in Pandoc, but
>>> the highlight library is a Haskell library called skylighting:
>>> https://pandoc.org/MANUAL.html#syntax-highlighting
>>> https://github.com/jgm/skylighting
>>>
>>> It seems Wilbert contributed the definitions for lilypond syntax:
>>>
>>> https://github.com/KDE/syntax-highlighting/blob/master/data/syntax/lilypond.xml
>>>
>>> About 10 days ago I wanted to share this in the open issue in
>>> Frescobaldi tracker but I forgot to do it.
>>> I remember I found the lilypond file definition somewhere else...
>>>
>>>
>>>
>>>
>>
>> --
>> Craig Dabelstein
>> Owner
>> Maxime's Music
>> M: 0404884173
>> A: 19 Twelfth Ave,  Kedron QLD 4031, Australia
>> W: concertbandmusicstore.com E:
>> cr...@concertbandmusicstore.com 
>> 
>> 
>>
>> 
>>
>>
>
>
> --
> Craig Dabelstein
> Owner
> Maxime's Music
> M: 0404884173
> A: 19 Twelfth Ave,  Kedron QLD 4031, Australia
> W: concertbandmusicstore.com E:
> cr...@concertbandmusicstore.com 
> 
> 
>
> 
>
>

Re: Getting readline to work in scheme-sandbox

[Michael Käppler]

Am 15.01.2020 um 23:55 schrieb Knute Snortum:

Okay, I built guile 1.8.7 after installing GNU MP and flex, but I get
the same error:

guile> (use-modules (ice-9 readline))
ERROR: readline is not provided in this Guile installation
ABORT: (misc-error)

So I redid the strace and I attached the log file.

Which way of "installing" libguilereadline did you choose?
Did you run "make install" or did you copy
libguilereadline-v-17.so.17.0.3 to
/home/knute/lilypond/lilypond-2.19.83/lilypond/usr/lib ?
Could you please send me your config.log from guile-1.8/guile-readline
and additionately do a

objdump -x
~/guile-1.8/guile-readline/.libs/libguilereadline-v-17.so.17.0.3 >
libguilereadline.dump
and attach the resulting file, too?

Thanks for your patience,
Michael



---
Knute Snortum
(via Gmail)

On Wed, Jan 15, 2020 at 12:29 PM Michael Käppler  wrote:

Do you have "gettext" installed? If not, please install and retry.

Am 15.01.2020 um 18:38 schrieb Knute Snortum:

I didn't get past autogen:

autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force -I m4
configure.ac:905: warning: macro 'AM_GNU_GETTEXT' not found in library
autoreconf: configure.ac: tracing
autoreconf: configure.ac: adding subdirectory guile-readline to autoreconf
autoreconf: Entering directory `guile-readline'
autoreconf: running: aclocal --force
autoreconf: running: libtoolize --copy --force
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, '.'.
libtoolize: copying file './ltmain.sh'
libtoolize: Consider adding 'AC_CONFIG_MACRO_DIRS([m4])' to configure.ac,
libtoolize: and rerunning libtoolize and aclocal.
libtoolize: Consider adding '-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
autoreconf: running: /usr/bin/autoconf --force
autoreconf: running: /usr/bin/autoheader --force
autoreconf: running: automake --add-missing --copy --force-missing
configure.ac:18: installing './compile'
configure.ac:19: installing './config.guess'
configure.ac:19: installing './config.sub'
configure.ac:13: installing './install-sh'
configure.ac:13: installing './missing'
Makefile.am:29: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS'
(or '*_CPPFLAGS')
Makefile.am: installing './depcomp'
autoreconf: Leaving directory `guile-readline'
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, 'build-aux'.
libtoolize: copying file 'build-aux/ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
libtoolize: copying file 'm4/libtool.m4'
libtoolize: copying file 'm4/ltoptions.m4'
libtoolize: copying file 'm4/ltsugar.m4'
libtoolize: copying file 'm4/ltversion.m4'
libtoolize: copying file 'm4/lt~obsolete.m4'
configure.ac:905: warning: macro 'AM_GNU_GETTEXT' not found in library
configure.ac:932: error: possibly undefined macro: AM_GNU_GETTEXT
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
autoreconf: /usr/bin/autoconf failed with exit status: 1


---
Knute Snortum
(via Gmail)

On Wed, Jan 15, 2020 at 12:24 AM Michael Käppler  wrote:

Ok, seems that guile-2.2-libs does not provide libguilereadline...

I think the remaining option is to build guile-1.8 from scratch.
First make sure that you have libreadline-dev installed, then, in your
home directory, do:

git clone -b branch_release-1-8 --single-branch
https://git.savannah.gnu.org/git/guile.git guile-1.8
cd guile-1.8
./autogen.sh
./configure --disable-error-on-warning --prefix=/usr/local
make
make install
ldconfig

If you do not want to install your self-compiled guile-1.8 globally with
"make install" it should be also sufficient to
rename
/home/knute/lilypond/lilypond-2.19.83/lilypond/usr/lib/libguilereadline-v-17.so.17.0.3
to
libguilereadline-v-17.so.17.0.3.old and put the corresponding file from
/home/knute/guile-1.8/guile-readline/.libs/
in there.

Then try with scheme-sandbox.ly again. Please report if it succeeds now.

Michael




Am 15.01.2020 um 00:05 schrieb Knute Snortum:

I'm not in a vanilla setup, so I changed the commands to: (just for posterity)

$ export 
LD_LIBRARY_PATH="/home/knute/lilypond/lilypond-2.19.83/lilypond/usr/lib"
$ strace -o readlinedebug.log
/home/knute/lilypond/lilypond-2.19.83/lilypond/usr/bin/lilypond
scheme-sandbox.ly

The log file is attached.

---
Knute Snortum
(via Gmail)

On Tue, Jan 14, 2020 at 8:47 AM Michael Käppler  wrote:

This is weird. Seems that strace does not recognize the shebang in the
lilypond script.
Could you please to try to execute the steps in the startup script directly?
I assume you used the vanilla lilypond installer and installed to your
home directory
/home/knute/:

export LD_LIBRARY_PATH="/home/knute/lilypond/usr/lib"
strace -o readlinedebug.log /home/knute/lilypond/usr/bin/lilypond
scheme-sandbox.ly



Am 14.01.2020 um 16:36 schrieb Knute Snortum:

It looks like I get an error in strace.  The sandbox is never executed:

execve("/home/knute/bin/lilypond", ["lilypond", "scheme-sandbox.ly"],
0x7ffe4792c428 /* 53 vars