Re: How to develop Emacs mode?

[Richard Shann]

On Sat, 2010-06-19 at 12:00 -0400, lilypond-devel-requ...@gnu.org wrote:
 From: Laura Conrad lcon...@laymusic.org
 Subject: Re: How to develop Emacs mode?
 To: Nicolas Sceaux nicolas.sce...@gmail.com
 Cc: David Kastrup d...@gnu.org, lilypond-devel@gnu.org
 Message-ID: 87wrtvazky@laymusic.org
 Content-Type: text/plain; charset=us-ascii
 
  Nicolas == Nicolas Sceaux nicolas.sce...@gmail.com writes:
 
 Nicolas Several years ago, I used a midi keyboard to enter the
 notes: one hand
 Nicolas on the midi keyboard, and one hand on the computer
 keyboard, to set
 Nicolas durations, because I'm a lame keyboard player.  But it
 turned out that
 Nicolas (in my case) that method was not quicker (or practical)
 than full computer
 Nicolas keyboard entry.
 
 I do use that method still.  I find it's not a lot quicker, 
FWIW:

What *is* a lot quicker is playing in the rhythm of the piece using
the computer keyboard and then playing the notes over the top, using the
MIDI keyboard. You get to leverage your sight-reading ability, and can
enter music in the time it takes you to play it thru twice. This is
*not* trying to guess the rhythm from your timing, but entering the
rhythm via the LilyPond names 0, 1, 1., 2, 2. etc which appear as a kind
of drum track. So you can slow down a bit if it gets too quick, but you
can follow the music because you naturally enter the durations
rhythmically as you read the music.
Of course, you need Denemo to do this:)
In the upcoming version 0.8.18 this will be possible out-of-the-box,
without setting any modes and so on.

I realize this won't be much use to those with a lot of skills built up
using other entry methods, but there are always newcomers.

Richard Shann


 but is a
 bit less error prone, for my purposes.  When I do relative entry
 from the computer keyboard, I make a lot of octavation errors.
 
 But I agree with David that it needs better intelligence about
 enharmonic notes -- if I weren't doing Renaissance music, which has a
 lot higher percentage of white notes than later styles, I might well
 decide that fixing the enharmonics was taking as much time as I was
 saving on the octavation errors.
 
 Another thing I'd really like added to this input method is a way to
 hear the MIDI notes.  
 
 -- 
 Laura   (mailto:lcon...@laymusic.org)
 (617) 661-8097  233 Broadway, Cambridge, MA 02139   
 http://www.laymusic.org/ http://www.serpentpublications.org


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Figured bass inside a staff collides with articulations...

[Richard Shann]

Unfortunately the suggested text gives the figures shifted up if one of
the notes is very high, as originally noted by Reinhold.
I would love to see a fix for this too, I am thinking of allowing over
the note bass figures in the Denemo output.

Richard Shann

On Mon, 2010-09-27 at 12:00 -0400, lilypond-devel-requ...@gnu.org wrote:
 ate: Mon, 27 Sep 2010 17:53:45 +0200
 From: Patrick Schmidt p.l.schm...@gmx.de
 Subject: Re: Figured bass inside a staff collides with
 articulations...
 To: Reinhold Kainhofer reinh...@kainhofer.com
 Cc: Lilypond Bugreports bug-lilyp...@gnu.org, LilyPond Development
 lilypond-devel@gnu.org
 Message-ID: f84adbd9-1f0c-4ef7-af67-8bfe8ce02...@gmx.de
 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
 
 
 Am 27.09.2010 um 17:32 schrieb Reinhold Kainhofer:
 
  Bass figures can be either added as a separate FiguredBass context  
  (which has
  the drawback that all figures will be shifted up if one of the  
  notes in the
  staff is very high), or directly inside a staff.
 
  In the latter case, all figures will collide with articulations  
  like accents,
  fermatas, etc. The figures are properly shifted up to avoid note  
  heads, not
  not to avoid articulations.
 
  Simple test case is attached.
 
  Any idea how to fix that problem?
 
 This works:
 
 \version 2.13.34
 
 \score {

  \new FiguredBass {
\figuremode { 3 42 2 6 | 3 5 7}
  }
  \new Staff = test {
  \relative c' { \clef bass c2 d,- | e'\fermata f }
  }

 }
 
 Cheers,
 patrick
 
 


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Byzantine chant and microtones

[Richard Shann]

In this connection, you may like to note that the upcoming Denemo
release will allow you to play back via an internal synth using
microtonal accidentals and, of course, print out using whatever LilyPond
syntax you program Denemo to use.
An example in Denemo's git at the moment uses the mechanism to shift the
temperament as a piece modulates, equivalent to having split sharps on a
keyboard (as in some 17th c. Italian clavivcembali)

Richard Shann

On Thu, 2010-11-11 at 23:12 -0500, lilypond-devel-requ...@gnu.org wrote:
 Message: 2
 Date: Thu, 11 Nov 2010 09:47:49 -0800
 From: Erich Enke erich.e...@gmail.com
 Subject: Re: Byzantine chant and microtones
 To: lilypond-devel@gnu.org
 Message-ID:
 aanlktiky6cut8ehudjqffz_w6a-0kwmbfrs8lf5xy...@mail.gmail.com
 Content-Type: text/plain; charset=ISO-8859-1
 
  If you like, you might start using staff notation alone: there are
 similar
  scales in oriental (Persian/Arab/Turkish) music. One then introduces
 some
  microtonal accidentals.
 
  I have looked through some Byzantine scales, and can see more or
 less how to
  do it. You might use E72 or E53, the latter if you learn Graham
 Breed's
  implementation.
 
 Thank you for the pointers.  Since translation to Western notation
 remains a goal of mine, it would make sense to develop the staff
 notation.  The responses were encouraging enough that I'll begin
 looking into implementing this in lilypond.
 
 Thanks,
 Erich
 


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: MIDI remapping

[Richard Shann]

On Sat, 2011-01-22 at 12:00 -0500, lilypond-devel-requ...@gnu.org wrote:
  I am wondering if there is a way to hack the source to change the
 midi
  pitch values which are output when it renders.  I want to do this so
  that I can remap those values to arbitrary frequencies for
 microtonal
  playback in a retunable software synth like puredata.

I guess you are aware that Denemo (the GUI front end to LilyPond) has
commands to control the pitch frequencies in its MIDI output? The last
release has an example of playing back in quarter comma meantone with a
shift from A-sharp to B-flat during the course of the piece.

Richard Shann


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Interactive compiling

[Richard Shann]

On Fri, 2012-12-07 at 12:00 -0500, lilypond-devel-requ...@gnu.org wrote:
 Hi team,
 
 Most lilypond GUI projects (Frescobaldi, Denemo) I have seen implement
 a wrapper in lilypond. I am investigating the possibility to transform
 lilypond in a more interactive compiler. 

FWIW Denemo is currently able to continuously re-typeset as you enter
the music (with user control over the amount of the music being
re-typeset). This is enabling WYSIWYG operations such as dragging the
beaming, rehearsal marks etc, and re-shaping slurs.
With a fast machine the fact that a mind-boggling amount of processing
is being done is hardly noticeable. And setting the context to just a
few bars/staffs around the cursor makes it practicable on more modest
machines.

Richard Shann


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

Re: Interactive compiling

[Richard Shann]

On Mon, 2012-12-10 at 18:53 -0500, lilypond-devel-requ...@gnu.org wrote:
 
 David, Richard, Graham, Jan,
 
 On Fri, Dec 7, 2012 at 3:07 PM, Joao E. Pereira Jr joao...@gmail.com
 wrote:
  David,
 
  On Fri, Dec 7, 2012 at 2:10 PM, David Kastrup d...@gnu.org wrote:
  Joao E. Pereira Jr joao...@gmail.com writes:
 
  Hi team,
 
  Most lilypond GUI projects (Frescobaldi, Denemo) I have seen
 implement
  a wrapper in lilypond. I am investigating the possibility to
 transform
  lilypond in a more interactive compiler. I have little
 understanding
  of the code for now, and noticed that before start to parse
  Lily_parser executes a huge amount of code loading init.ly and his
  sons. Could that loading process be isolated, pre executed and
  maintained in memory to serve posterior requests?
 
  You might want to look at how LilyPond deals with multiple files on
 the
  command line and the -djob-count option.
 
  I haven't noticed difference in the output of the following comands,
  maybe wasn't exactly what you meant:
 
  out/bin/lilypond ../input/regression/clef-octavation.ly
  ../input/regression/chromatic-scales.ly
 
  out/bin/lilypond -djob-count ../input/regression/clef-octavation.ly
  ../input/regression/chromatic-scales.ly
 
 
 I figured out. I was missing the value of job-count attribute. My
 attached gdb session shows that both childs start to execute the
 init.ly loading code. I know that job-count saves the repeated
 execution of main_with_guile(). My goal now is understand how many
 percent of whole parsing process this loading code represent, and how
 the complexity of isolating this and maintain in memory. Why this
 loading init.ly is called from parse_file() ? and why it should be
 called for every file to parse?
 
 
  Following the same thinking line could the data structure
 (contexts,
  music, property, graphical objects) be maintained in memory and
  changed as user input changes. Some user changes would affect only
 one
  graphical object and maybe trigger a reformatting, others would
 affect
  a property object and trigger a partial recompiling, others would
  affect the ly file and require compiling from scratch.
 
  The bookkeeping for that kind of thing would likely be
 prohibitively
  expensive.
 
 This is almost becoming a Ph.D research plan. It's about how a backend
 to Scorio.com is supposed to be. I think that it would need many big
 machines to achieve scalable human interactive time response. I'll
 take a more detailed look in Denemo, 
What Denemo is doing is checking every, say, 1/10th second for changes
to the score and, if there are any, re-generating the LilyPond output
for a few measures/staffs around the cursor (a few measures can the the
entire score) and then spawning a new lilypond invocation, reading the
output pdf into a pdf display widget. 
The implementation is very simple - no optimization - but is even so
quite usable. Things like re-angling beaming are much better done by
drawing directly over the output pdf than by trial-and-error entering of
numbers into the LilyPond source, and things like re-shaping slurs are,
I would guess, only really feasible done that way (unless you can
visualize Bezier curves from the coordinates of the control points :)
Even simple operations such as suggesting a page break become more
natural when you can click on the link that LilyPond provides in the pdf
output and issue the page break command, even though all that is really
happening is that the LilyPond link is returning Denemo's cursor to the
correct place in the score and the command is just the same one you
would have issued looking at the input music display. It is just that
you are looking at the final typeset score while you do it, and,
depending on the score size and machine speed, there will be a gulp
before you see the effect. That gulp is, of course, the price you pay
for having LilyPond make almost all the decisions for you. One or two
tweaks are all I need for a typical score, often times none.

Richard Shann








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

Semantics of X-offset Y-offset

[Richard Shann]

The values for X-offset Y-offset when applied to the trill sign or the
coda sign refer to different places on the glyph. For the trill it
refers to the bottom right and for the coda the center right. (I have
found this by trial-and-error).
This causes a problem for dragging these signs on the final typeset pdf
(which you can do in Denemo) because the user expects the symbol to be
dropped centered on the pointer yet there is no consistent offset that
can be applied to achieve this.

Question: where in the LilyPond source tree is the information about
where the origin of the glyph is with respect to the center of the
bounding rectangle of the glyph?

Any help is much appreciated.

Richard Shann



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

Re: Semantics of X-offset Y-offset

[Richard Shann]

On Mon, 2013-04-15 at 10:38 +0200, Janek Warchoł wrote:
 Hi,
 
 2013/4/15 Richard Shann richard.sh...@virgin.net:
  Question: where in the LilyPond source tree is the information about
  where the origin of the glyph is with respect to the center of the
  bounding rectangle of the glyph?
 
  Any help is much appreciated.
 
 Interesting coincidence.  See
 http://code.google.com/p/lilypond/issues/detail?id=3273 and the
 conversation linked there.
 
 hth,

It does indeed help; it raises a different possibility which I had not
really thought about: instead of teaching Denemo where the reference
points are I can let the user turn on the red dots at the reference
points and the user can click on them to achieve accurate positioning -
more accurate than clicking in the middle of the object.
I have tested this using
\new Staff \with { \printRefpoint ##f #'all-grobs }
but it will be easier to have a single switch to turn the red dots on
for all the staffs, indeed for all the \score blocks. I'll try and dig
deeper into the code provided by Harm to see how to do this, but if
anyone can easily tell me what to insert globally I will be eternally
grateful.


 Janek



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

Re: Semantics of X-offset Y-offset

[Richard Shann]

On Mon, 2013-04-15 at 17:25 +0200, Janek Warchoł wrote:
 Hi,
 [...] and the user can click on them to achieve accurate positioning -
  more accurate than clicking in the middle of the object.
 
 Sounds like a good idea.
 
  I have tested this using
  \new Staff \with { \printRefpoint ##f #'all-grobs }
  but it will be easier to have a single switch to turn the red dots on
  for all the staffs, indeed for all the \score blocks. I'll try and dig
  deeper into the code provided by Harm to see how to do this, but if
  anyone can easily tell me what to insert globally I will be eternally
  grateful.
 
 Looks like using
 
   \layout {
 \context {
   \Score
   \printRefpoint ##f #'all-grobs
 }
   }
 
 inserts refpoint dots for all grobs in a Score.

Yes, thanks, that worked perfectly straight off, the wysiwyg positioning
is now working with pinpoint precision in Denemo. I'll create a video
demo when I have the code in git.

Richard



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

Re: Semantics of X-offset Y-offset

[Richard Shann]

On Mon, 2013-04-15 at 23:06 +0200, Janek Warchoł wrote:
 2013/4/15 Richard Shann richard.sh...@virgin.net:
  On Mon, 2013-04-15 at 17:25 +0200, Janek Warchoł wrote:
  Looks like using
 
\layout {
  \context {
\Score
\printRefpoint ##f #'all-grobs
  }
}
 
  inserts refpoint dots for all grobs in a Score.
 
  Yes, thanks, that worked perfectly straight off, the wysiwyg positioning
  is now working with pinpoint precision in Denemo. I'll create a video
  demo when I have the code in git.

This is a quick demonstration of tweaking the position of a trill sign
by dragging on the LilyPond pdf image in Denemo:

https://vimeo.com/64131774

Thank you very much for making this possible so quickly.

Richard


 
 cool!
 Janek



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

Re: LilyPond 2.18.0 released

[Richard Shann]

... and to prove that 2.18 has arrived, here is perhaps the first
published score typeset with it:

http://imslp.org/wiki/8_Solos,_Op.1_%28Stanley,_John%29#IMSLP309222

I have had to update Denemo to use the new \bar syntax, but otherwise
everything went smoothly.
Congratulations on the new release.

Richard


On Mon, 2013-12-30 at 17:50 +0100, David Kastrup wrote:
 Some of you might have seen this on the lilypond-announce list, but I
 repeat it here since not everybody may read the announce list.  The big
 announcement to all the non-LilyPond lists will happen in a few days if
 we don't get major complaints.
 
 Here it goes:
 
 We are proud to announce the release of GNU LilyPond 2.18.0 - the new
 stable release. LilyPond is a music engraving program devoted to
 producing the highest-quality sheet music possible. It brings the
 aesthetics of traditionally engraved music to computer printouts.
 
 Among the numerous improvements and changes, the following might be
 most visible:
 
 * Many items are now positioned using their actual outline rather than
 a rectangular bounding box. This greatly reduces the occurrence of
 unsightly large gaps.
 * Sets and overrides can now use a simpler syntax
 * Triplets with a given group length can now be written using a more
 user-friendly syntax
 
 A full list of noteworthy new features is given in:
 http://lilypond.org/doc/v2.18/Documentation/changes/index.html
 
 Great thanks go to the large number of LilyPond enthusiasts whose
 financial backing enabled one core developer, David Kastrup, to focus
 exclusively on LilyPond during the entire development cycle.
 
 LilyPond 2.18 has been brought to you by
 
 Main Developers:
 Bertrand Bordage, Trevor Daniels, Colin Hall, Phil Holmes, Ian Hulin,
 Reinhold Kainhofer, David Kastrup, Jonathan Kulp, Werner Lemberg, John
 Mandereau, Patrick McCarty, Joe Neeman, Han-Wen Nienhuys, Jan
 Nieuwenhuizen, Graham Percival, Mark Polesky, Neil Puttock, Mike
 Solomon, Carl Sorensen, Francisco Vila, Valentin Villenave, Janek
 Warchol
 
 Core Contributors:
 Aleksandr Andreev, Frédéric Bron, Torsten Hämmerle, Marc Hohl, James
 Lowe, Andrew Main, Thomas Morley, David Nalesnik, Keith OHara, Benko
 Pál, Anders Pilegaard, Julien Rioux, Johannes Rohrer, Adam Spiers,
 Heikki Tauriainen
 
 Documentation Writers:
 Frédéric Bron, Federico Bruni, Colin Campbell, Urs Liska, James Lowe,
 Thomas Morley, Jean-Charles Malahieude, Guy Stalnaker, Martin
 Tarenskeen, Arnold Theresius, Rodolfo Zitellini
 
 Bug Squad:
 Colin Campbell, Eluze, Marc Hohl, Phil Holmes, Marek Klein, Ralph Palmer
 
 Support Team:
 Colin Campbell, Eluze, Marc Hohl, Marek Klein, Kieren MacMillan, Urs
 Liska, Ralph Palmer
 
 Translators:
 Federico Bruni, Luca Rossetto Casel, Felipe Castro, Pavel Fric,
 Jean-Charles Malahieude, Till Paala, Yoshiki Sawada
 and numerous other contributors.
 



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

Re: [Denemo-devel] lily 2.16, 2.18 zombies on darwin when ran via glib g_spawn

[Richard Shann]

On Fri, 2014-01-17 at 05:34 +0100, David Kastrup wrote:
 Jeremiah Benham jjben...@chicagoguitar.com writes:
 
  I am having an issue running lilypond via glib when cross compiled for 
  darwin.  
 
  This is when cross compiled for darwin using the same gub snapshot:
  Version/Status
  2.14.2 works fine
  2.16.2 created pdf and .ps but goes into a zombie state on exit
  2.18.0 does not create anyting and immediately goes zombie
 
 Are you using zombie state in the official meaning here (a process
 that has terminated without its parent waiting for it, listed in a ps
 a listing as Z)?  Or just as a colloquial description?
 
  Now all of the above versions are executable. I inserted a printf of
  the lilypond arguments before g_spawn was launched. Then I copied
  and executed it at the command line. Each time it was a success on all
  three tested versions. Why is it not working via g_spawn...? I have
  cross compiled all the above for mingw and have never had this
  problem. I am begining to diff through versions 2.14 and 2.18. Does
  anyone have any idea as to what is causing this?
 
 At some point of time, the terminal output was not routed through
 whatever Guile considered to be its current-error-output but rather
 through file descriptor 2.  If you have a blocking pipe or similar on
 that 

is that here file descriptor 2 or current-error-output ?

The Guile you mention here is guile invoked by LilyPond I assume.
Denemo asks GLib to capture the stdout and stderr of the spawned
process ...

Richard


 in your process environment, this might be good for problems.
 



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

Re: Shape of individual ties in chords

[Richard Shann]

Thanks for this - while playing around with it I noticed the mysterious
synatx q that appears. I tried looking this up in the two indices
without success. It causes a syntax error after a note but repeats a
chord when placed after a chord. I wonder what exactly it is all about
and why I can't find it documented...

Richard



On Thu, 2014-01-23 at 08:01 -0600, David Nalesnik wrote:
 Hi,
 
 
 On Wed, Jan 22, 2014 at 4:55 PM, Thomas Morley
 thomasmorle...@gmail.com wrote:
  
 Below some coding just to show that it can be done.
 It's a very first sketch, several issues are present (p.e.
 linebreak)
 Might be a starting point, though.
 
 
 
 There's also the attached file (which comes
 from 
 http://www.mail-archive.com/lilypond-devel@gnu.org/msg47432/shape-tie-columns.ly)
  which will work with broken ties.
 
 
 HTH,
 David



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

Re: Shape of individual ties in chords

[Richard Shann]

On Fri, 2014-01-24 at 10:26 +0100, David Kastrup wrote:
 Simon Bailey si...@bailey.at writes:
 
  hi,
 
  On Fri, Jan 24, 2014 at 10:16 AM, Richard Shann rich...@rshann.plus.com 
  wrote:
  Thanks for this - while playing around with it I noticed the mysterious
  synatx q that appears. I tried looking this up in the two indices
  without success. It causes a syntax error after a note but repeats a
  chord when placed after a chord. I wonder what exactly it is all about
  and why I can't find it documented...
 
  http://lilypond.org/doc/v2.18/Documentation/notation/single-voice#chord-repetition
 
  there's a few things which are only documented in the learning
  manual. :)
 
 Not this one, though.

So is this a bug with the documentation (incomplete indexing)?

Richard




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

Re: Shape of individual ties in chords

[Richard Shann]

On Fri, 2014-01-24 at 10:31 +0100, David Kastrup wrote:
 Richard Shann rich...@rshann.plus.com writes:
 
  On Fri, 2014-01-24 at 10:26 +0100, David Kastrup wrote:
  Simon Bailey si...@bailey.at writes:
  
   hi,
  
   On Fri, Jan 24, 2014 at 10:16 AM, Richard Shann 
   rich...@rshann.plus.com wrote:
   Thanks for this - while playing around with it I noticed the mysterious
   synatx q that appears. I tried looking this up in the two indices
   without success. It causes a syntax error after a note but repeats a
   chord when placed after a chord. I wonder what exactly it is all about
   and why I can't find it documented...
  
   http://lilypond.org/doc/v2.18/Documentation/notation/single-voice#chord-repetition
  
   there's a few things which are only documented in the learning
   manual. :)
  
  Not this one, though.
 
  So is this a bug with the documentation (incomplete indexing)?
 
 Well, we don't have c, cis, ces... indexed, either.  Admittedly, we do
 have r, s, and R in the index.

yes, I was thinking about that - there is the language include file that
would affect some of those, but to be practical, I don't recall ever
noticing q in the past ten years or so of watching and using LilyPond
(well, I virtually never have to write chords myself so perhaps it is
not surprising)

Richard



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

Re: Figured Bass support

[Richard Shann]

Han-Wen Nienhuys wrote:


[EMAIL PROTECTED] writes:
 

(a first attempt to post seemed to go into a black hole ... try again 
...)

The figured bass support in lilypond (wonderful!) is a little tricky 
to use
for three reasons:
1) The figures have to be entered in the reverse order (that is a 
six-four
chord is entered 4 6). Of course, this assumes that you do call it 
that and
not a four-six chord, but I *think* is universally so.
  


In dutch, c' f' a'  (absolute pitches) is called a 4-6 chord, not
6-4; that's what you mean, right? 

yes


I'm not sure about the proper names
in English.

Can you do some more research to find out what is the Right Way?


yes - with classic anglo-saxon myopia I referred to the English 
nomenclature as universal ...
the research for the Right Way turned out to be very easy - typing six 
four chord into Google yielded 137 hits and  four six chord  yielded 
7 hits. For example:

Six-four chord (siks for kord) A chord consisting of three notes, the 
bass note, the interval of a fourth above the bass note, and a sixth 
above the bass note. ...
from this site
www.music.vt.edu/musicdictionary/texts/Six-fourchord.html

and likewise for four six chord, though less common.

However, it occurs to me that I've started us thinking along the wrong 
lines here - what matters is what people who may want to write figured 
basses into lilypond will find most natural. I jumped to the conclusion 
that the reason I write 6 followed by 4 when writing out figured basses 
was because I call it a six four chord. In fact, since the figures are 
always aligned at the top there is a much stronger reason why, when 
writing out the figures you start at the top and work downwards, and 
hence why you write them out as six followed by four (to continue the 
example). If you didn't write downwards, you would have to guess where 
to start writing the figures, judging by how many figures you had to 
fill in.
This all presupposes that figured basses are indeed aligned horizontally 
at the top: I am sure this is always so, based on sampling Italian, 
French, English and German 17th  18th c. sonatas from my bookshelf and 
thirty odd years of knocking round in early music circles. In fact, I 
think anything else would appear outlandish, because the commonest 
figures (a # or b or a six on their own) would have to be placed at some 
distance from the bass note, depending on the maximum number of figures 
to be found on any one note in the piece. A # would then frequently 
appear to be associated with some note on the next line, which usually 
either means that the editor thinks *that* note should be sharpened (or 
if ornamented, the ornament should be sharpened). (I feel perhaps I'm 
labouring the point now ...).


I've added #'direction for the BassFigure grob, so you can the
stacking direction. (1.7 cvs)


The default should be the normal direction else we risk creating another 
standard in figured bass notation!

Best regards,

Richard Shann




___
Lilypond-devel mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/lilypond-devel

midi2ly struggles with lilypond's midi output.

[Richard Shann]

(I posted this some while back to bug-lilypond but once more it vanished 
without trace ...)
Dear All,

I've noticed that if I use lilypond to output midi and then use midi2ly 
to translate back to lilypond notation a part can go missing. I'm using

midi2ly (GNU LilyPond) 1.6.5
GNU LilyPond 1.6.5

on a RedHat 8.0 setup. A simple example is the following snippet:

-- file test.ly --
trackBchannelA = \notes\relative c {
d''16
}
trackB = 
\context Voice = channelA \trackBchannelA

trackCchannelB = \notes\relative c {
b'4c4b4c8
}
trackC = 
\context Voice = channelB \trackCchannelB

\score {

  \context Staff=trackB \trackB
  \context Staff=trackC \trackC

\midi {}
\paper {}
}

---end of test.ly ---

when the output of lilypond -m is given to midi2ly the resultant .ly 
file (attached) ends with
\score {

  \context Staff=trackB \trackB


which is missing the second part of the original.
Peering at the code in midi2ly I see that if the function 
track_first_item, which is defined as:

def track_first_item (track):
  for thread in track:
  return thread_first_item (thread)

is replaced by the following definition:

def track_first_item (track):
  for thread in track:
  item = thread_first_item (thread)
  if item != 0:
  return item
  return item

Then the lost part returns (one is reminded of the Lost Chord of Arthur 
Sullivan...)
Now I don't want to pretend that this is a fix - I've not tested it on 
anything but this example - but the very strangeness of the original 
definition of this function (with its one-shot for...in loop) is 
suspicious. I would like to understand this script better - I can see 
that some of the information from a given channel is being moved to 
channel 0, but I'm unsure of the general strategy for mapping the midi 
information onto lily format that has been adopted.



% Lily was here -- automatically converted by midi2ly from lygentest.midi


trackAchannelA = \notes {
 
 % [TEXT_EVENT] Creator: GNU LilyPond 1.6.5
 
 % [TEXT_EVENT] Generated automatically by: GNU LilyPond 1.6.5
 
 % [TEXT_EVENT] at Fri Dec 27 12:05:20 2002 
 
 % [TEXT_EVENT] from musical definition: test.ly:22:3
 
 % [SEQUENCE_TRACK_NAME] Track 0
 
}

trackA = 
 \context Voice = channelA \trackAchannelA



 



trackBchannelA = \notes\relative c {
 
 % [SEQUENCE_TRACK_NAME] trackB
 
 \tempo 4 = 60 
 
 % [INSTRUMENT_NAME] bright acoustic
 
 \time 4/4 
 d''16 
}

trackB = 
 \context Voice = channelA \trackBchannelA



 



trackCchannelA = \notes {
 
 % [SEQUENCE_TRACK_NAME] trackC
 
 \tempo 4 = 60 
 
 % [INSTRUMENT_NAME] bright acoustic
 
 \time 4/4 
 
}

trackCchannelB = \notes\relative c {
 b'4 c b c8 
}

trackC = 

 \clef bass
 
 \context Voice = channelA \trackCchannelA
 \context Voice = channelB \trackCchannelB



 



\score {
 
   \context Staff=trackB \trackB
 
}


% Lily was here -- automatically converted by midi2ly from lygentest.midi


trackAchannelA = \notes {
  
  % [TEXT_EVENT] Creator: GNU LilyPond 1.6.5
  
  % [TEXT_EVENT] Generated automatically by: GNU LilyPond 1.6.5
  
  % [TEXT_EVENT] at Fri Dec 27 12:05:20 2002 
  
  % [TEXT_EVENT] from musical definition: test.ly:22:3
  
  % [SEQUENCE_TRACK_NAME] Track 0
  
}

trackA = 
  \context Voice = channelA \trackAchannelA



trackBchannelA = \notes\relative c {
  
  % [SEQUENCE_TRACK_NAME] trackB
  
  \tempo 4 = 60 
  
  % [INSTRUMENT_NAME] bright acoustic
  
  \time 4/4 
  d''16 
}

trackB = 
  \context Voice = channelA \trackBchannelA



trackCchannelA = \notes {
  
  % [SEQUENCE_TRACK_NAME] trackC
  
  \tempo 4 = 60 
  
  % [INSTRUMENT_NAME] bright acoustic
  
  \time 4/4 
  
}

trackCchannelB = \notes\relative c {
  b'4 c b c8 
}

trackC = 

  \clef bass
  
  \context Voice = channelA \trackCchannelA
  \context Voice = channelB \trackCchannelB



\score {
  
\context Staff=trackB \trackB
  
}

___
Lilypond-devel mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/lilypond-devel

Figured Bass support

[Richard Shann]

hi,

The example given in the manual for a figured bass seems to be missing a
\notes directive - if I put it inside a \score {} thus

\score {

\context FiguredBass
  \figures {
   _! 3+ 5- 4
[4 6] 8 
  }
\context Voice { c4 g8 }

\paper {
}
}

then I get an error
warning: Junking request: `Lyric_req': \context Voice { c4 etc...

When I put in the missing \notes directive I get a message
programming error: No StaffSpacing wishes found (Continuing; cross thumbs)

This doesn't always happen depending on the relative lengths of the 
parts I think. Any suggestions for eliminating this would be welcome, 
meanwhile here is a revised example with the \notes and that is more 
realistic

\context Voice \notes { \clef bass dis4  c d ais}

\context FiguredBass
  \figures {
6 4  7 8  6+ [_!] 
6 4 6 5 [3+] 
  }



By the way, I notice that the character $ is allowed after the \ in 
lilypond, is this an old feature - it does not seem to be used for 
anything? I can't see a reference to it in the ChangeLog.  (It is being 
output by denemo, but I don't think it means anything).

Richard Shann




___
Lilypond-devel mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/lilypond-devel

Duration documentation

[Richard Shann]

Hi,

I found it a bit difficult to understand the format of duration in 
lilypond - I think two of the examples
given (in 2.6.5 documentation) are misleading:

the explanation of \partial duration is this:

   Partial measures, for example in upbeats, are entered using the 
|\partial| command:
   \partial 4* 5/16 c'16 c4 f16 a'2. ~ a'8. a'16 | g'1

but I think what was meant was 4* 17/16 for the duration, the example as 
given has the second
note straddling the first bar line. In addition the explanation for 
duration is this:

   You can alter the length of duration by a fraction N/M appending 
`|*|N/M' (or `|*|N' if M=1). This won't affect the appearance of the 
notes or rests produced.
   a'2*2 b'4*2 a'8*4 a'4*3/2 gis'4*3/2 a'4*3/2 a'4

I think the example was meant to be

a'2*2 b'4*2 a'8*4 a'4*4/3 gis'4*4/3 a'4*4/3 a'4

otherwise the final a'4 does not actually start at the beginning of the 
bar (as you can see by putting the bar in manually at this point and 
getting a barcheck failure).

Richard





___
Lilypond-devel mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/lilypond-devel

Re: Figured Bass support

[Richard Shann]

Han-Wen Nienhuys wrote:

For the moment, you could use markup texts. For example:


Thanks for the suggestion - however it is much more important to me that 
the scores I am writing are structurally sound (i.e. the figured basses 
are really figured basses, with their own durations etc - I'm working on 
a graphical editor for LilyPond that understands them) as I won't be 
re-writing the scores later. I really just filed this note about the 
aesthetics of your figured bass output because I understand that you 
want LilyPond to be taken up because the output does not look stiff and 
computer-like. For practical purposes the figures are reasonably easy to 
play from as they are, though overall a bit far away from the notes.

Richard





___
Lilypond-devel mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/lilypond-devel

LilyDev not accepting paste from host clipboard

[Richard Shann]

I've just gone through the steps to install LilyDev in a virtual
machine. I already have a plain Debian O/S installed and have been using
it for some time without problem.
Unfortunately, this new image will not accept paste (e.g.
Shift-Control-v in a terminal, or right mouse click) from the host,
which the Debian virtual machine does.
Has anyone seen this problem/know how to fix it - I guess it has to be
some Ubuntu setting ...

Richard Shann




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

Compact Chord Charts

[Richard Shann]

When chord symbols are displayed on small hand-held devices (e.g.
smartphones) they will be difficult to read unless the elements are
arranged more compactly than the standard LilyPond chord symbols.
There are commercial programs out there that offer this facility.
I have been experimenting with designing these more compact chord
symbols using the chordExceptions mechanism, but to do the job properly
requires modifying LilyPond itself(*).
I have a working prototype and would like to develop this as proper code
that could be included in LilyPond. 
To do this I think I need to have an additional property to be used via
something like this

(if (ly:context-property-where-defined context 'compact)
...

to decide whether to format the chord symbol in a compact fashion or to
use the default formatting.
If this sounds right, could someone advise what the LilyPond syntax
would be needed to trigger this conditional?
I was guessing it might be

\layout {
\context  {
\ChordNames
compact = ##t
}

but whatever I try I just get an empty list for that property.

Richard

(*) as an example, bass inversions are hard-coded to use the same markup
as the root note, but for a compact symbol they need to have the
accidental differently placed.




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

Re: LilyDev not accepting paste from host clipboard

[Richard Shann]

On Fri, 2014-09-19 at 22:30 +0100, James wrote:
 On 19/09/14 19:09, Richard Shann wrote:
  I've just gone through the steps to install LilyDev in a virtual
  machine. I already have a plain Debian O/S installed and have been using
  it for some time without problem.
  Unfortunately, this new image will not accept paste (e.g.
  Shift-Control-v in a terminal, or right mouse click) from the host,
  which the Debian virtual machine does.
  Has anyone seen this problem/know how to fix it - I guess it has to be
  some Ubuntu setting ...
  
  Richard Shann
  
  
  
  
  ___
  lilypond-devel mailing list
  lilypond-devel@gnu.org
  https://lists.gnu.org/mailman/listinfo/lilypond-devel
  
 
 what's the hypervisor? If it's VirtualBox then you can choose how the
 clipboard works. Settings/General/Advanced - shared clipboard.
 
 If it's some other hypervisor like KVM then I don't have any advice.

yes, it's Oracle's VirtualBox. The thing is that it is working for the
Debian stable that I use, so the VirtualBox settings must be ok-ish. I
can only think it is the Ubuntu that is not playing ball. But I'll have
a look (for a long time we were plagued by two different clipboard
systems in Unix/X/whatever that were sometimes synchronized and
sometimes not.
Thanks for the response though - useful to know this isn't something
well-known to you guys that created LilyDev.
Richard

 
 james



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

Re: Compact Chord Charts

[Richard Shann]

On Fri, 2014-09-19 at 21:04 -0700, Paul Morris wrote:
 Richard Shann-2 wrote
 [...] could someone advise what the LilyPond syntax
  would be needed to trigger this conditional?
  I was guessing it might be
  
  \layout {
  \context  {
  \ChordNames
  compact = ##t
  }
  
  but whatever I try I just get an empty list for that property.
 
 As far as I know, to introduce a custom context property like this, you
 first need to add it to the list of:
 
   all-translator-properties
 
 using a procedure like:
 
   translator-property-description
 
 as found in: 
 
   scm/define-context-properties.scm
 
 After that you should be able to set it to #t like you want.

Perfect! It seems that with this I can use ly:context-property without
the where-defined bit.
Thanks for the quick reply.
Richard





 
 HTH,
 -Paul
 
 
 
 --
 View this message in context: 
 http://lilypond.1069038.n5.nabble.com/Compact-Chord-Charts-tp166609p166645.html
 Sent from the Dev mailing list archive at Nabble.com.
 
 ___
 lilypond-devel mailing list
 lilypond-devel@gnu.org
 https://lists.gnu.org/mailman/listinfo/lilypond-devel



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

Re: LilyDev not accepting paste from host clipboard

[Richard Shann]

On Sat, 2014-09-20 at 09:25 +0200, Federico Bruni wrote:
 2014-09-20 8:14 GMT+02:00 Richard Shann rich...@rshann.plus.com:
 yes, it's Oracle's VirtualBox. The thing is that it is working
 for the
 Debian stable that I use, so the VirtualBox settings must be
 ok-ish. I
 can only think it is the Ubuntu that is not playing ball. But
 I'll have
 a look (for a long time we were plagued by two different
 clipboard
 systems in Unix/X/whatever that were sometimes synchronized
 and
 sometimes not.
 Thanks for the response though - useful to know this isn't
 something
 well-known to you guys that created LilyDev.
 
 Richard, maybe you should install linux-headers in your ubuntu guest,
 otherwise guest additions won't work.
 If you still have problems, I can give you the link to the new LilyDev
 iso (not yet official):
 https://code.google.com/p/lilypond/issues/detail?id=2538#c40

Digging around in the VirtualBox docs I see that some OS come with guest
addtions built in, so this must be the case for the Debian (stable) that
I installed a few months back. And it must *not* be the case for the
Ubuntu that you are using for LilyDev. I was beaten back on my first
attempt to install guest additions for this Ubuntu as the relevant .iso
is not present in my VirtualBox package (on the host)

ls /usr/share/virtualbox/
nls  VBox.sh  VBoxSysInfo.s

I *think* this is just the plain Debian package that I installed.

Looking at the thread you referenced, you seem to have a number of
improvements to LilyDev in the pipeline, but I see no mention of guest
additions - I guess everyone will want these? - are they in the newer
version? If so, I will download and give it a test if you can give me
the url (http://www.sixbarsjail.it/tmp/lilydev3.iso gives 404).

Richard









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

Re: LilyDev not accepting paste from host clipboard

[Richard Shann]

On Sat, 2014-09-20 at 11:06 +0200, Federico Bruni wrote:
 Yes, in LilyDev 3.0 guest additions should work out of the box. 
 
 The new url is: http://www.et.byu.edu/~sorensen/lilydev-3.0.iso
 
 http://www.et.byu.edu/~sorensen/lilydev-3.0.iso.md5
 

This installed ok - but this bit of the documentation didn't match:

If you are using LilyDev (see LilyDev) then lily-git is already
installed and ready to run.
  * For those not using LilyDev then lily-git can be obtained by
downloading the software directly. See Manually installing
lily-git.tcl.
  * Finally, lily-git is always part of the LilyPond source code and
is located in ‘$LILYPOND_GIT/scripts/auxillar/lily-git.tcl’.
Note: The rest of this manual assumes that you are using the
command-line within a terminal.

Type (or copypaste) into the Terminal:

lily-git.tcl


as there is no lily-git.tcl in the path at this stage. 
Putting $LILYPOND_GIT/scripts/auxillar in the path fixed this
but then I got this error:

lily-git.tcl
Error in startup script: grab failed: window not viewable
while executing
grab .b
(procedure requestuserdata line 3)
invoked from within
requestuserdata
invoked from within
if {![regexp name $usercheck] || ![regexp email $usercheck]} then {
requestuserdata
tkwait window .b
}
(file /home/rshann/lilypond-git/scripts/auxiliar/lily-git.tcl line
90)

I'm not at all sure about that one...

Richard



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

Re: LilyDev not accepting paste from host clipboard

[Richard Shann]

On Sat, 2014-09-20 at 15:46 +0100, James wrote:
  lily-git.tcl
  
  
  as there is no lily-git.tcl in the path at this stage. 
  Putting $LILYPOND_GIT/scripts/auxillar in the path fixed this
  but then I got this error:
  
  lily-git.tcl
  Error in startup script: grab failed: window not viewable
  while executing
  grab .b
  (procedure requestuserdata line 3)
  invoked from within
  requestuserdata
  invoked from within
  if {![regexp name $usercheck] || ![regexp email $usercheck]}
 then {
  requestuserdata
  tkwait window .b
  }
  (file /home/rshann/lilypond-git/scripts/auxiliar/lily-git.tcl
 line
  90)
  
  I'm not at all sure about that one...
 
 All I can say is that I didn't get that when I tested this with
 Federico.
 
 When you run Lily-Git for the first time it should prompt for your
 email
 and user name (this then applies this to $LILYPOND_GIT/.gitconfig (I
 think - but it's as if you were in $LILYPOND_GIT and run the git
 commands
 
 git config --global user.name John Smith
 git config --global user.email j...@example.com
 
 )
 
 This assumes (I assume!) that you are running this in $LILYPOND_GIT. 

Ah, that is the bit that is missing. After setting the PATH you need

cd $LILYPOND_GIT  lily-git.tcl

and you do indeed get the needed window popping up.
I have now pushed on as far as editing the sources and trying to build
lilypond for the first time - so far so good!

Richard




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

Re: LilyDev not accepting paste from host clipboard

[Richard Shann]

On Sat, 2014-09-20 at 17:27 +0200, Federico Bruni wrote:
 Thanks Richard, I never used it and I ignored its existence. I'll add
 that directory to the path in .bashrc. 
In light of the further steps it isn't useful to add that directory to
the PATH (because the command will not work unless the it is the cwd).
It is just the web page instructions that need updating to read

cd $LILYPOND_GIT  lily-git.tcl

rather than
 Type (or copypaste) into the Terminal:
 
 lily-git.tcl
as at present.
 It's not worth a new iso update IMO. 
right - the iso seems to be working just fine - with guest extensions
working out of the box (and that cyrillic thing too).
BTW my first make failed in the docs - is that expected?
Richard



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

Re: LilyDev not accepting paste from host clipboard

[Richard Shann]

On Sun, 2014-09-21 at 09:14 +0100, James wrote:
 On 21/09/14 08:55, Richard Shann wrote:
  On Sat, 2014-09-20 at 17:27 +0200, Federico Bruni wrote:
  Thanks Richard, I never used it and I ignored its existence. I'll add
  that directory to the path in .bashrc. 
  In light of the further steps it isn't useful to add that directory to
  the PATH (because the command will not work unless the it is the cwd).
  It is just the web page instructions that need updating to read
  
  cd $LILYPOND_GIT  lily-git.tcl
  
  rather than
  Type (or copypaste) into the Terminal:
 
  lily-git.tcl
  as at present.
  It's not worth a new iso update IMO. 
  right - the iso seems to be working just fine - with guest extensions
  working out of the box (and that cyrillic thing too).
  BTW my first make failed in the docs - is that expected?
  Richard
  
  
 Just to check you did a 'make' before you 'make doc' didn't you?

I haven't tried make doc
I just did make
I nearly emailed about it at the time and then I realized that I had
already made the first (small) mod to the code, adding 
 (chordCompact ,boolean? Draw chord symbols in a compact fashion?)
into define-context-properties.scm
and so (as this includes a bit of documentation) I realized that I had
blundered by not doing the make at the outset, before starting to modify
code, so as to be sure that things were good to start with.
I described the problem as being to do with building docs just because
of the error message, but I can't reconstruct this (by doing make on the
master branch) because lilypond.org is down, so I can't get back to the
web page which details the autogen and configure steps needed ... Hence
my diffidence about mentioning this in the first place.

Once the dust has settled I'll come back to it.

Richard



 
 It will fail then otherwise.
 
 James



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

es means ees???

[Richard Shann]

In the lilypond 2.19 installed file

usr/share/lilypond/current/ly/chord-modifiers-init.ly

I see the following at line 27

  c es ges-\markup { \super o } % should be $\circ$ ?


Here, instead of ees, is written es.

I've tried this out, and it appears to be a synonym, but I don't see
this documented. Anyone know what's going on?

Richard
 



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

Re: es means ees???

[Richard Shann]

Thank you to all who replied - I didn't think to look in the note names
in other languages section.
Richard

On Mon, 2014-10-06 at 13:41 +0200, David Kastrup wrote:
 Richard Shann rich...@rshann.plus.com writes:
 
  In the lilypond 2.19 installed file
 
  usr/share/lilypond/current/ly/chord-modifiers-init.ly
 
  I see the following at line 27
 
c es ges-\markup { \super o } % should be $\circ$ ?
 
 
  Here, instead of ees, is written es.
 
  I've tried this out, and it appears to be a synonym, but I don't see
  this documented. Anyone know what's going on?
 
 That's the natural name for it, cf
 URL:http://www.lilypond.org/doc/v2.18/Documentation/music-glossary/pitch-names.
 I don't know where you have looked for the information, but in the
 canonical point of documentation (or, depending on how you view it,
 immediately adjacent and cross-referenced from it), namely
 URL:http://lilypond.org/doc/v2.18/Documentation/notation/writing-pitches#note-names-in-other-languages,
 
 I read
 
 In Dutch, aes is contracted to as, but both forms are accepted in
 LilyPond. Similarly, both es and ees are accepted. This also applies
 to aeses / ases and eeses / eses. Sometimes only these contracted
 names are defined in the corresponding language files.
 
 The sometimes sentence is somewhat hand-waving and it is not clear to
 what it applies.  Dutch as the default note entry mode also intended for
 foreigners and automatic notename generation, is more lenient in its
 forms.  German, IIRC, only accepts the correct contracted forms.
 



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

Is there a test for a pair of numbers?

[Richard Shann]

I am developing compact chord symbols for LilyPond and have added this
property to define-context-properties.scm

 (chordCompactScale ,pair? Draw chord symbols scaled by this
amount)

This works, but I was wondering if there is a more exacting type test
than pair? ?

Richard


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

Re: Is there a test for a pair of numbers?

[Richard Shann]

On Mon, 2014-10-06 at 17:52 +0200, David Kastrup wrote:
 number-pair?
great, thanks!

Richard



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

Compact Chord Symbols Patch

[Richard Shann]

I have created a patch for LilyPond (following the guidelines in the
documentation). I enclose a file that creates a chord chart from this
version, though I realize that it is too verbose for use in documenting
the new functionality. 
I'll be happy to create something smaller if it looks like  the patch
will be welcomed. (This one gives an idea of the output).

Richard


From 8a3569e75d1fdff5318497051bb840e330162e47 Mon Sep 17 00:00:00 2001
From: Richard Shann rich...@rshann.plus.com
Date: Mon, 6 Oct 2014 18:09:51 +0100
Subject: [PATCH] Allow creation of compact chord symbols

Compact chord symbols have the elements of the chord
(the root name, quality and bass-inversion) packed
tightly together so as to allow the creation of fakebooks.
Nowadays these will often be stored on hand held devices.
This patch allows the default chord symbols to be drawn in
such a manner, by defining the context property chordCompactScale.
Where this is not defined, the default behavior is maintained.
---
 scm/chord-ignatzek-names.scm  | 125 ++
 scm/define-context-properties.scm |   1 +
 2 files changed, 100 insertions(+), 26 deletions(-)

diff --git a/scm/chord-ignatzek-names.scm b/scm/chord-ignatzek-names.scm
index 22f54fe..c7671cb 100644
--- a/scm/chord-ignatzek-names.scm
+++ b/scm/chord-ignatzek-names.scm
@@ -88,6 +88,46 @@
   (ly:context-property context 'chordRootNamer)
   ;; name-root
   nn)))
+  (define (compact-name-root pitch scale)
+  (let* ((alt (ly:pitch-alteration pitch)))
+  (make-line-markup
+(list
+  (make-bold-markup
+(make-scale-markup '(0.5 . 1)
+(make-simple-markup
+(vector-ref #(C D E F G A B) (ly:pitch-notename
+pitch)
+  (if (= alt 0)
+(make-hspace-markup 0.1)
+(make-line-markup
+(list
+  (make-hspace-markup 0.1)
+  (make-fontsize-markup -7 (make-raise-markup 1.2 ;(* 1 scale)
+ (alteration-text-accidental-markup alt)))
+  (make-hspace-markup -0.5
+  (define (name-inversion pitch scale)
+(let* ((alt (ly:pitch-alteration pitch)))
+  (make-line-markup
+(list
+   (make-raise-markup 1
+(make-scale-markup '(0.75 . 0.5)
+(make-bold-markup (make-simple-markup /
+  (make-bold-markup
+(make-scale-markup '(0.5 . 0.75)
+(make-simple-markup
+(vector-ref #(C D E F G A B) (ly:pitch-notename
+pitch)
+  (if (= alt NATURAL)
+(make-hspace-markup 2)
+(make-line-markup
+(list
+  (make-hspace-markup 0.1)
+  (make-fontsize-markup -7
+  (if (= alt SHARP)
+(make-raise-markup 0.1
+(alteration-text-accidental-markup alt))
+(make-raise-markup 0.2
+(alteration-text-accidental-markup alt)))
 
   (define (is-natural-alteration? p)
 (= (natural-chord-alteration p) (ly:pitch-alteration p)))
@@ -169,9 +209,42 @@ work than classifying the pitches.
 
 (make-line-markup total)))
 
+(define (markup-formatting sep root-markup prefixes to-be-raised-stuff bass-pitch)
+(define bass-inv #f)
+(define slashsep (ly:context-property context 'slashChordSeparator))
+(define scale (ly:context-property context 'chordCompactScale))
+(if (pair? scale)
+(begin
+(set! bass-inv  (if (ly:pitch? bass-pitch)
+   (name-inversion bass-pitch scale)
+empty-markup))
+ (make-scale-markup scale (make-combine-markup
+(make-line-markup (list root-markup
+(make-scale-markup '(0.4 . 0.6)
+(make-bold-markup (conditional-kern-before (markup-join prefixes sep)
+(and (not (null? prefixes))
+ (= (ly:pitch-alteration root) NATURAL))
+(ly:context-property context 'chordPrefixSpacer
+(make-scale-markup '(0.4 . 0.6) (make-bold-markup to-be-raised-stuff
+(make-raise-markup -2 bass-inv
+(begin
+(set! bass-inv
+(if (ly:pitch? bass-pitch)
+   (list slashsep (name-note bass-pitch #f))
+   '()))
+(make-line-markup

Re: es means ees???

[Richard Shann]

On Tue, 2014-10-07 at 11:04 +0900, Graham Percival wrote:
 On Mon, Oct 06, 2014 at 01:41:30PM +0200, David Kastrup wrote:
  Richard Shann rich...@rshann.plus.com writes:
  
   Here, instead of ees, is written es.
  
  I read
  
  In Dutch, aes is contracted to as, but both forms are accepted in
  LilyPond. Similarly, both es and ees are accepted. This also applies
  to aeses / ases and eeses / eses. Sometimes only these contracted
  names are defined in the corresponding language files.
 
 Yes.  In case anybody was wondering, I deliberately moved the as
 and es contractions from the tutorial into the NR ages ago.  For
 people unfamiliar with that notation, it's easier to remember
 letter name plus -es or -is rather than introducing all the
 contractions.

That was a good idea I think. What is unfortunate is that the default
includes these contractions, with hindsight it might have been better to
have the default be the simplest set of names with those that wanted to
use the contractions including a language specific file (e.g.
nederlands). But this is a very minor thing, perhaps as a matter of
style the ly directory code should avoid the contractions?
This has a connection with the other thread about using the sharp and
flat symbols - they should be in a language neutral file.

Richard


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

Re: es means ees???

[Richard Shann]

On Tue, 2014-10-07 at 09:50 +0200, David Kastrup wrote:
 Richard Shann rich...@rshann.plus.com writes:
 
  On Tue, 2014-10-07 at 11:04 +0900, Graham Percival wrote:
  On Mon, Oct 06, 2014 at 01:41:30PM +0200, David Kastrup wrote:
   Richard Shann rich...@rshann.plus.com writes:
   
Here, instead of ees, is written es.
   
   I read
   
   In Dutch, aes is contracted to as, but both forms are accepted in
   LilyPond. Similarly, both es and ees are accepted. This also applies
   to aeses / ases and eeses / eses. Sometimes only these contracted
   names are defined in the corresponding language files.
  
  Yes.  In case anybody was wondering, I deliberately moved the as
  and es contractions from the tutorial into the NR ages ago.  For
  people unfamiliar with that notation, it's easier to remember
  letter name plus -es or -is rather than introducing all the
  contractions.
 
  That was a good idea I think. What is unfortunate is that the default
  includes these contractions,
 
 Uh, the contractions are the _proper_ names.  The non-contractions are
 not correct note names in any language.

No more than ef is the correct note name in English for e-flat.


 
  with hindsight it might have been better to have the default be the
  simplest set of names with those that wanted to use the contractions
  including a language specific file (e.g.  nederlands).
 
 I disagree.  There is nothing to be gained from using a notename
 language nobody uses.

yes, we do it for English to save typing.

   If we wanted that, we could take numbers.  I see
 ees and aes more as a concession to computer-transliterated music than
 to humans.

that is a very reasonable way to look at it.

   Now of course your main concern via Denemo _is_
 computer-transliterated music but that does not mean that everybody
 else's music should look that way.
 
  But this is a very minor thing, perhaps as a matter of style the ly
  directory code should avoid the contractions?
 
 I'd consider that bad style.  Again, the contractions are not sloppy
 writing or anything.  They are the _proper_ German and Dutch note names.

yes, from that perspective. Well it is 10 years too late, but perhaps
the sharp and flat signs would have been better, with things like s
f is es all available via an included language file. Most
everything else is either Italian or English. But that's life in
language development.

Richard


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

Re: Compact Chord Symbols Patch

[Richard Shann]

On Mon, 2014-10-06 at 20:06 +0100, James wrote:
 Richard,
 
[..]
  
  Richard
 
 I have created
 
 http://code.google.com/p/lilypond/issues/detail?id=4154
 
 I'll help shepherd this patch through via the standard review process
 for this.

Thank you very much. I thought I would follow the instructions for
contributing to LilyPond starting from the top at http://lilypond.org as
I know how useful it is for a fresh pair of eyes to look over stuff like
this. This lead me to the step after creating a patch where it suggested
if you have a mentor email the patch, but didn't say what one was. So
I improvised at this point and emailed the mailing list. I would have
liked to run the regression tests at that stage, but I think I ran out
of step-by-step instructions.

 
 Also See:
 
 http://lilypond.org/doc/v2.19/Documentation/contributor-big-page#commits-and-patches
 
 if you intend (or think you might want) to make further patches for
 other parts of LilyPond in the future

Well, it is about 10 years since I last had to tweak the actual LilyPond
code (at the time you had to type bass figures in the reverse order),
which far exceeds my memory span for how-to-do-it instructions. I just
manage to keep up with the processes for developing the Denemo LilyPond
GUI.

I would have found this development much easier if I could have avoided
the use of a virtual machine for the actual git part of it (that is, if
I had permission to create remote branches such as dev/compact-chords in
the lilypond repository). Then I would only have needed the virtual box
to compile and run the new version. 
As it is, I had to copy and paste from my virtual box out to the real
machine, merge my changes and copy and paste them back, a process
fraught with danger. (I think the LilyDev must have some way of sharing
file systems but I didn't look into that). If I could have created a
remote branch, modified and pushed back and then switched to LilyDev to
pull the remote branch, compile and test that would have been perfect.

Reading over the documentation you quote it seems that you do have
contributors with the limited permission to create branches, but I
didn't immediately see how to register for that...

Richard





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

Re: es means ees???

[Richard Shann]

On Tue, 2014-10-07 at 09:50 +0200, David Kastrup wrote:
 Richard Shann rich...@rshann.plus.com writes:
 
  On Tue, 2014-10-07 at 11:04 +0900, Graham Percival wrote:
  On Mon, Oct 06, 2014 at 01:41:30PM +0200, David Kastrup wrote:
   Richard Shann rich...@rshann.plus.com writes:
   
Here, instead of ees, is written es.
   
   I read
   
   In Dutch, aes is contracted to as, but both forms are accepted in
   LilyPond. Similarly, both es and ees are accepted. This also applies
   to aeses / ases and eeses / eses. Sometimes only these contracted
   names are defined in the corresponding language files.
  
  Yes.  In case anybody was wondering, I deliberately moved the as
  and es contractions from the tutorial into the NR ages ago.  For
  people unfamiliar with that notation, it's easier to remember
  letter name plus -es or -is rather than introducing all the
  contractions.
 
  That was a good idea I think. What is unfortunate is that the default
[...]
 
  But this is a very minor thing, perhaps as a matter of style the ly
  directory code should avoid the contractions?
 
 I'd consider that bad style.

Thinking about it, this bad style is the one recommended by the
LilyPond documentation, since the changes Graham introduced into the NR
ages ago. It lead to me being unable to read a LilyPond file without
consulting the note-names-in-other-languages section, which you don't
expect to need to do when this isn't an other language.

Richard






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

Re: es means ees???

[Richard Shann]

   If that was the focus of LilyPond, we
 would talk to it in MusicXML.
Hmm, I think there is a serious need to puncture the MusicXML bubble -
it is an appalling hotchpotch quite unsuited to representing typeset
music. From a casual look it seems to have been designed, but in fact
the real definition is the output of a proprietary program.
But, I do take your point, that LilyPond is intended to be written and
read by humans. It is designing for both the write and the read to be
easy that is tricky.

Richard




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

Re: Compact Chord Symbols Patch

[Richard Shann]

On Tue, 2014-10-07 at 12:53 +0100, James wrote:
 On 07/10/14 09:08, Richard Shann wrote:
  On Mon, 2014-10-06 at 20:06 +0100, James wrote:
  Richard,
 
  [..]
  Richard
  I have created
 
  http://code.google.com/p/lilypond/issues/detail?id=4154
 
  I'll help shepherd this patch through via the standard review process
  for this.
  Thank you very much. I thought I would follow the instructions for
  contributing to LilyPond starting from the top at http://lilypond.org as
  I know how useful it is for a fresh pair of eyes to look over stuff like
  this. This lead me to the step after creating a patch where it suggested
  if you have a mentor email the patch, but didn't say what one was. So
  I improvised at this point and emailed the mailing list. I would have
  liked to run the regression tests at that stage, but I think I ran out
  of step-by-step instructions.
[...]
  Reading over the documentation you quote it seems that you do have
  contributors with the limited permission to create branches, but I
  didn't immediately see how to register for that...
 
 Probably here
 
 http://lilypond.org/doc/v2.19/Documentation/contributor-big-page.html#commit-access
 
Well this seems to be a rather general access - it warns the user not to
push to master but to staging - perhaps I was wrong thinking you had
another tier of access...

 I think we could improve the notes in the contributor's Guide generally. 

I hasten to say that what you have created is very good, I was able to
get to the submitting a patch stage without any serious problems.

 Having had to help three or four people over the last few months with a 
 patch or two, I get how the instructions are probably rather confusing 
 if not intimidating.
 
 I'll take a look and see what I can come up with.
 
 The structure of the Contributor's Guide is much 'looser' (shall we say) 
 than the manuals on how to use LilyPond. That's not to say it is 
 inaccurate, but that perhaps we could condense some of it down or 
 organize more logically certain aspects.
 
 Anyway, I haven't yet done anything with the Patch simply because I was 
 waiting on if it was really a snippet
Well, I certainly tried to do this without attacking the core code
itself, but I'd love it if there were some point of entry (a scheme
engraver?) that would allow chord symbols to be drawn by a user
generated routine (this is everything, including bass inversions).
  than something that we want to add 
 into the core code. I am not a 'developer' as such (I don't write code - 
 just Doc and manage patches) so don't have any real knowledge of these 
 things.

Thank you very much

Richard




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

Re: Issue 4154: Compact Chord Symbols Patch (issue 153160043 by d...@gnu.org)

[Richard Shann]

On Wed, 2014-10-08 at 17:41 +, d...@gnu.org wrote:
 Reviewers: ,
 
 
 https://codereview.appspot.com/153160043/diff/1/scm/chord-ignatzek-names.scm
 File scm/chord-ignatzek-names.scm (right):
 
 https://codereview.appspot.com/153160043/diff/1/scm/chord-ignatzek-names.scm#newcode98
 scm/chord-ignatzek-names.scm:98: (vector-ref #(C D E F G A
 B) (ly:pitch-notename
 This looks like a bad idea.  It does not obey the various chord name
 languages.  It does not use the same callbacks.  It is a large
 duplication of code not connected with the other code and not using the
 same options, functionality and interfaces.

When I saw this (on the lilypond-devel mailing list) I thought this was
a comment about the existing code. The code quoted is the existing code,
which I haven't changed.
My code does not generate any chord names, so it can't obey any chord
name languages, it just typesets the elements of the chord name in a
more compact fashion.

Sorry for not replying earlier, but I did think that my patch had
sparked a debate about the quality of the original file, not my patch to
it, which is purely concerned with how the markup is created for the
chord names as generated by the existing code.

Richard


 
 Can't you try to integrate this kind of code better with the existing
 code, both regarding the code that is called as well as the naming
 conventions and functionality that are available?
 
 Description:
 Issue 4154: Compact Chord Symbols Patch
 
 Please review this at https://codereview.appspot.com/153160043/
 
 Affected files (+100, -26 lines):
M scm/chord-ignatzek-names.scm
M scm/define-context-properties.scm
 
 
 
 ___
 lilypond-devel mailing list
 lilypond-devel@gnu.org
 https://lists.gnu.org/mailman/listinfo/lilypond-devel



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

Re: Issue 4154: Compact Chord Symbols Patch (issue 153160043 by d...@gnu.org)

[Richard Shann]

On Thu, 2014-10-09 at 11:36 +, d...@gnu.org wrote:
 On 2014/10/09 11:08:16, richard_rshann.plus.com wrote:
  On Wed, 2014-10-08 at 17:41 +, mailto:d...@gnu.org wrote:
   Reviewers: ,
  
  
  
 https://codereview.appspot.com/153160043/diff/1/scm/chord-ignatzek-names.scm
   File scm/chord-ignatzek-names.scm (right):
  
  
 
 https://codereview.appspot.com/153160043/diff/1/scm/chord-ignatzek-names.scm#newcode98
   scm/chord-ignatzek-names.scm:98: (vector-ref #(C D E F G
 A
   B) (ly:pitch-notename
   This looks like a bad idea.  It does not obey the various chord name
   languages.  It does not use the same callbacks.  It is a large
   duplication of code not connected with the other code and not using
 the
   same options, functionality and interfaces.
 
  When I saw this (on the lilypond-devel mailing list) I thought this
 was
  a comment about the existing code. The code quoted is the existing
 code,
  which I haven't changed.
 
 It most certainly isn't the existing code.

Well, that depends what I meant by the existing code - the specific file
I was modifying calls chordRootNamer which is initialized to
note-name-markup which is in chord-names.scm:62, and that is where the
quoted construct exists in the current lilypond code, in fact I see it
is repeated several times in that file.

Richard





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

Re: Issue 4154: Compact Chord Symbols Patch (issue 153160043 by d...@gnu.org)

[Richard Shann]

On Sat, 2014-10-18 at 17:19 +, d...@gnu.org wrote:
 On 2014/10/09 12:02:16, richard_rshann.plus.com wrote:
 
  Well, that depends what I meant by the existing code - the specific
 file
  I was modifying calls chordRootNamer which is initialized to
  note-name-markup which is in chord-names.scm:62, and that is where
 the
  quoted construct exists in the current lilypond code, in fact I see it
  is repeated several times in that file.
 
 Well, pulling code from a different file and functionality in parts into
 a different file where they are basically integrated as flat code into
 some parts of the code while other parts still call the other file --
 that's a total maintenance and reading nightmare.  If the duplicated
 code needs changes or maintenance, it is quite improbable that someone
 working on it will find and change *both* copies as needed.
as I say, it is not a question of both, the construct is quite short
and is repeated several times. But, of course, it makes it worse to
repeat it in a different file. And more to the point, a different (if
more direct) mechanism is used for compact symbols than for the other
cases.
 
 It would be best to extend the code to be able to do both tasks.  If
 that is not reasonably possible, it would be good to factor out common
 elements but keep the code doing the non-common parts in the same file.
 
 https://codereview.appspot.com/153160043/

The problem with doing the compact symbols in the same file as the
others is that there seems to be no access to the context property that
gives the scaling needed. I asked about this on the mailing list,
http://lists.gnu.org/archive/html/lilypond-user/2014-09/msg00525.html

 but it seemed this couldn't be done. It is completely unclear to me why
the creation of markup for a chord symbol is spread over several files
in the first place - it seems to result in the loss of the context
information at the point where the root name markup is being created.

Is there a way in which chordRootNamer can take an extra scale argument,
or is there, indeed a way to access this value as the context property
chordCompactScale ? If so, I could easily move that code back in to
chord-names.scm

Richard








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

Re: Building identifiers algorithmically

[Richard Shann]

On Sun, 2015-03-22 at 08:01 +0100, David Kastrup wrote:
 Trevor Daniels t.dani...@treda.co.uk writes:
 
  Now while this works it seems rather clunky, so I'm wondering if there
  is a more elegant way of doing this.  Symbols look like they might
  help, but so far I've failed to make anything work.  I've also failed
  with macros, but that's likely because I don't understand them yet.
 
 When a function is evaluated, its arguments are read, evaluated, and the
 function is called with the unevaluated

I guess you meant evaluated here???

Richard


  arguments, and the result of
 that call is used.
 
 When a macro is evaluated, its arguments are read, the macro is called
 with the unevaluated arguments, and the result of that call is
 evaluated before use.
 
 It's just a matter of where the evaluation happens.  With a function, it
 is before the call, with a macro, it is after the call.  That's all
 there is to it.
 



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

Re: Reasons why a LilyPond-to-MEI conversion should be developed

[Richard Shann]

On Sat, 2015-10-24 at 01:39 +0200, Simon Albrecht wrote:
> e.g. if LilyPond should consume
> > MEI
> 
> Interesting thought. I should be surprised if MEI were to consent in 
> granting LilyPond this honour (as which I’d consider it). 
I think what was meant was "the lilypond executable should parse MEI
syntax and typeset from it", rather than the LilyPond organization
should take over the MEI one ...
Richard



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

Problem with alignment of Chord Symbols over notes.

[Richard Shann]

Can anyone spot the error in this:
8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><
\version "2.19.25"

\score {
  <<
 \new ChordNames \chordmode {  e4 s4 f:/g8 s8 s4 
   d8:m s8 s8 s8 s8 s8 s8 s8  }
 \new Staff {
 d'4 d' b8 d' f4
 a'8 g' a' g' a' g' a' g' }
  >>
   } 
8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><
run under Frescobaldi (which says version 2.18.2) it gives
warning: Spurious garbage following chord: (#)
and the Dm chord symbol is shifted to the right - without the /g the
positioning is correct.

Richard



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

Re: Problem with alignment of Chord Symbols over notes.

[Richard Shann]

On Sun, 2015-10-18 at 11:19 +0200, David Kastrup wrote:
> Richard Shann <rich...@rshann.plus.com> writes:
> 
> > Can anyone spot the error in this:
> > 8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><
> > \version "2.19.25"
> >
> > \score {
> >   <<
> >  \new ChordNames \chordmode {  e4 s4 f:/g8 s8 s4 
> >d8:m s8 s8 s8 s8 s8 s8 s8  }
> >  \new Staff {
> >  d'4 d' b8 d' f4
> >  a'8 g' a' g' a' g' a' g' }
> >   >>
> >} 
> > 8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><
> > run under Frescobaldi (which says version 2.18.2) it gives
> > warning: Spurious garbage following chord: (#)
> > and the Dm chord symbol is shifted to the right - without the /g the
> > positioning is correct.
> 
> You probably mean f8:/g instead of f:/g8 here.  The error message is
> awful, though.
> 

Thank you! I see that the page
http://www.lilypond.org/doc/v2.18/Documentation/notation/chord-mode
I was looking at was only showing implicit durations so I should have
engaged my brain more with it to understand where the duration should
come...

Richard



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

A bug in event-listener.ly

[Richard Shann]

While developing a Playback View in Denemo (music plays back while
LilyPond-typeset SVG is animated, building on Mathieu Demange's work) I
came across a bug in event-listener.ly:

In this procedure

#(define (format-tempo engraver event)
   (print-line engraver
   "tempo"
   ; get length of quarter notes, in seconds
   (/ (ly:event-property event 'metronome-count)
   (format-moment (ly:duration-length (ly:event-property
   event
   'tempo-unit))

The division should be a multiplication, otherwise \tempo Presto 4=480
and \tempo Presto 2=240 result in different tempi being written out.

Richard



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

Re: SOLVED (Re: stepmake in lilypond)

[Richard Shann]

On Fri, 2015-12-18 at 13:19 +0100, David Kastrup wrote:
> Villum Sejersen  writes:
> 
> > On 18-12-2015 09:31, David Kastrup wrote:
> >
> >> Villum Sejersen  writes:
> >>> [...]
>  Nope. What parts of stepmake LilyPond needs are included in LilyPond
>  itself.
> >>> Well, that's good to know, but where is it documented?
> >> Documenting all non-dependencies would be excessive.
> >
> > Then I suggest that at least 1.9 in INSTALL.txt should be
> > reformulated. As written now it is really confusing, leading - as I
> > did - to expect to have to look for an external dependency.
> 
> It says:
> 
> 1.9 Build system
> 
> 
> We currently use make and stepmake, which is complicated and only used
> by us.  Hopefully this will change in the future.
> 
> "Only used by us" does not sound like an external dependency.  And 1.2.2
> and 1.4.2 deal with dependencies.  Why would you expect information
> about dependencies to come far after compilation instructions?
> 

but "Only used internally" might be clearer. "Only used by us" could be
interpreted as "LilyPond is the only project left on the planet needing
it"

Richard



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

Re: rsvg-view can't display SVG files created by lilypond

[Richard Shann]

On Wed, 2016-06-08 at 18:08 +0200, Federico Bruni wrote:
> EyeOfGnome and Gimp - which use librsvg just like rsvg-view - do not 
> display anything.
> 
> The problem is:
> 
> fill="currentColor"


This use by LilyPond's SVG output of "currentColor" is something I ran
up against when rendering LilyPond's SVG from Denemo. I could not find
any way of making sure that currentColor didn't come out the same as the
background color, so that nothing was seen. I resorted to the LilyPond
code that specifies that the color of all grobs is "black" and then all
was well.
A quick glance at my code suggests that

\applyContext #(override-color-for-all-grobs (x11-color 'black)

will work as a workaround if uploading to Wikipedia.

Would it be a good idea simply to change LilyPond's output, since
"currentColor" seems problematic - LilyPond could use "black" unless it
got overridden by the LilyPond user.

Richard



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

Re: rsvg-view can't display SVG files created by lilypond

[Richard Shann]

On Thu, 2016-06-09 at 10:15 +0200, Werner LEMBERG wrote:
> >> However, there's still a nasty scaling bug that completely ruins
> >> text positioning at larger magnification values.  Sigh.
> > 
> > Is *this* a bug in librsvg, or another LilyPond output problem?
> 
> It's definitely a bug in librsvg AFAICS, cf.
> 
>   https://phabricator.wikimedia.org/T65703

I see on this page that there is a mention of "Fixed in 2.40.13" however
this page

https://www.mirrorservice.org/sites/ftp.gnome.org/pub/GNOME/sources/librsvg/2.40/librsvg-2.40.13.changes

makes no mention of it. Do you happen to know if we could usefully
upgrade Denemo to use librsvg 2.40.13 (it always involves quite a bit of
work upgrading versions so I thought I'd ask first)

Richard




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

Re: rsvg-view can't display SVG files created by lilypond

[Richard Shann]

On Thu, 2016-06-09 at 13:23 +0200, David Kastrup wrote:
> Richard Shann <rich...@rshann.plus.com> writes:
> 
> > On Thu, 2016-06-09 at 12:57 +0200, David Kastrup wrote:
> >> Werner LEMBERG <w...@gnu.org> writes:
> >> 
> >> >>> >> However, there's still a nasty scaling bug that completely ruins
> >> >>> >> text positioning at larger magnification values.  Sigh.
> >> >>> > 
> >> >>> > Is *this* a bug in librsvg, or another LilyPond output problem?
> >> >>> 
> >> >>> It's definitely a bug in librsvg AFAICS, cf.
> >> >>> 
> >> >>>   https://phabricator.wikimedia.org/T65703
> >> >> 
> >> >> I see on this page that there is a mention of "Fixed in 2.40.13"
> >> >
> >> > I think this is only partially correct, cf.
> >> >
> >> >   https://phabricator.wikimedia.org/T65703#1981688
> >> >
> >> >> Do you happen to know if we could usefully upgrade Denemo to use
> >> >> librsvg 2.40.13 (it always involves quite a bit of work upgrading
> >> >> versions so I thought I'd ask first)
> >> >
> >> > Sorry, I can't help here.  Regarding librsvg, I'm an ordinary user,
> >> > not acquainted with SVG at all.
> >> 
> >> Well, we are not in the market for SVG compliance testing.  If there are
> >> reasonably simple changes we can make to LilyPond in order to
> >> avoid/sidestep triggering this librsvg bug,
> >
> > I don't know about *this* bug, but I did test out replacing currentColor
> > with "black" (in quotes) in the LilyPond source code and it worked fine;
> > that seems to me not only a simple but also a fairly sensible change.
> 
> Except that it would make it impossible to draw in colors other than
> black.  That was the rationale for using currentColor in the first
> place.

Oh, if that is the case then I'm misremembering - I thought I found that
explicitly set colors over-rode the value currentColor (or "black" or
whatever you put at that place in the code).

Richard




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

Re: rsvg-view can't display SVG files created by lilypond

[Richard Shann]

On Wed, 2016-06-08 at 23:44 +0200, Werner LEMBERG wrote:
> > A quick glance at my code suggests that
> > 
> > \applyContext #(override-color-for-all-grobs (x11-color 'black)
> > 
> > will work as a workaround if uploading to Wikipedia.
> 
> Indeed, that works, thanks!
> 
> However, there's still a nasty scaling bug that completely ruins text
> positioning at larger magnification values.  Sigh.

Is *this* a bug in librsvg, or another LilyPond output problem?

I didn't look deeply into that - I think I asked here, but I don't
recall getting a clear response...

Richard




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

Re: rsvg-view can't display SVG files created by lilypond

[Richard Shann]

On Thu, 2016-06-09 at 12:57 +0200, David Kastrup wrote:
> Werner LEMBERG  writes:
> 
> >>> >> However, there's still a nasty scaling bug that completely ruins
> >>> >> text positioning at larger magnification values.  Sigh.
> >>> > 
> >>> > Is *this* a bug in librsvg, or another LilyPond output problem?
> >>> 
> >>> It's definitely a bug in librsvg AFAICS, cf.
> >>> 
> >>>   https://phabricator.wikimedia.org/T65703
> >> 
> >> I see on this page that there is a mention of "Fixed in 2.40.13"
> >
> > I think this is only partially correct, cf.
> >
> >   https://phabricator.wikimedia.org/T65703#1981688
> >
> >> Do you happen to know if we could usefully upgrade Denemo to use
> >> librsvg 2.40.13 (it always involves quite a bit of work upgrading
> >> versions so I thought I'd ask first)
> >
> > Sorry, I can't help here.  Regarding librsvg, I'm an ordinary user,
> > not acquainted with SVG at all.
> 
> Well, we are not in the market for SVG compliance testing.  If there are
> reasonably simple changes we can make to LilyPond in order to
> avoid/sidestep triggering this librsvg bug,

I don't know about *this* bug, but I did test out replacing currentColor
with "black" (in quotes) in the LilyPond source code and it worked fine;
that seems to me not only a simple but also a fairly sensible change.

Richard



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

Re: rsvg-view can't display SVG files created by lilypond

[Richard Shann]

On Thu, 2016-06-09 at 14:20 +0200, David Kastrup wrote:
> Richard Shann <rich...@rshann.plus.com> writes:
> 
> > On Thu, 2016-06-09 at 13:23 +0200, David Kastrup wrote:
> >> Richard Shann <rich...@rshann.plus.com> writes:
> >> 
> >> > I don't know about *this* bug, but I did test out replacing
> >> > currentColor with "black" (in quotes) in the LilyPond source code
> >> > and it worked fine; that seems to me not only a simple but also a
> >> > fairly sensible change.
> >> 
> >> Except that it would make it impossible to draw in colors other than
> >> black.  That was the rationale for using currentColor in the first
> >> place.
> >
> > Oh, if that is the case then I'm misremembering - I thought I found
> > that explicitly set colors over-rode the value currentColor (or
> > "black" or whatever you put at that place in the code).
> 
> What is "that place"?

> dak@lola:/usr/local/tmp/lilypond$ git grep currentColor
> Documentation/misc/ChangeLog-2.10:  change black to currentColor 
> everywhere. This fixes color support
> scm/output-svg.scm:  (set-attribute 'fill "currentColor"))

yes "that place" was output-svg.scm, I just did a replace in document
command IIRC, but I didn't notice the entry in the ChangeLog which
indicates that there is some purpose behind using "currentColor".
 My problem was I didn't seem to be able to control what colors librsvg
chose, and it chose to make it white.

Richard




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

Re: rsvg-view can't display SVG files created by lilypond

[Richard Shann]

On Thu, 2016-06-09 at 14:18 +0200, Werner LEMBERG wrote:
> >> Well, we are not in the market for SVG compliance testing.  If
> >> there are reasonably simple changes we can make to LilyPond in
> >> order to avoid/sidestep triggering this librsvg bug,
> > 
> > I don't know about *this* bug,
> 
> BTW, can you reproduce the problem that I've shown in my previous
> e-mail?

Well, I don't seem to have rsvg-view with my librsvg package (from
Debian) but after a bit of a fight I managed to get Denemo to load the
svg image you posted as an icon for a palette button (this is rendered
with librsvg) and it rendered ok. I don't know what scaling is being
done for that though, but I certainly see mangled text when rendering
LilyPond generated SVG with this version of librsvg. Attached is an
example, the instrument name Violin at the start of a staff. By changing
the font size down it gets worse, so it seems to be the bug you are
talking about.

Richard


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

A regression

[Richard Shann]

I have a file that fails to compile with 2.19.43 with this message

Starting lilypond 2.19.43 [junk.ly]...
Processing `/tmp/frescobaldi-PRgtuJ/tmpBD232F/junk.ly'
Parsing...
Interpreting music...[8][16][24][32]
Preprocessing graphical objects...
Interpreting music...[8][16][24][32]
Preprocessing graphical objects...
Interpreting music...[8][16][24]
Preprocessing graphical objects...
Interpreting music...[8][16][24][32][40][48]
Preprocessing graphical objects...
Interpreting music...
Preprocessing graphical objects...
Calculating line breaks... 
Drawing systems... 
Finding the ideal number of pages...
Fitting music on 4 or 5
pages...lilypond: 
/home/gub/NewGub/gub/target/linux-64/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/lily/page-breaking.cc:1040:
 void Page_breaking::line_divisions_rec(vsize, const Line_division&, const 
Line_division&, Page_breaking::Line_division*): Assertion `my_index == 0' 
failed.
Exited with exit status 1.

(this happened after inserting a page break). It compiles ok with
2.18.2. My question is, would it be helpful to anyone to have the file?
(Obviously cutting it down to a minimal example is not an option). I
would have to paste the local includes in (or something) to construct
the non-minimal example, so I ask before doing the work...

Richard







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

Re: ly:one-page-breaking (was: ly:one-line-breaking)

[Richard Shann]

On Mon, 2016-01-18 at 22:51 -0500, Paul Morris wrote:
> > On Jan 9, 2016, at 1:30 PM, Richard Shann <rich...@rshann.plus.com> wrote:
> > 
> > I was wondering if it would be possible to develop a variant of "all on
> > one line", namely "all on one page", where the page height would be
> > automatically adjusted to fit the music, leaving the width as set.
> 
> I’m glad to report that I’ve made some real progress.  

> The code in the attached patch delivers the basic functionality, with a few 
> "known issues".  

> Namely the tagline and any footnotes are not included, 

> and bookparts trigger default page breaking for some reason. 

>  I haven’t tested it extensively but titles (etc.), top level markups, 
> multiple scores, 

> all seem to work just fine.

That's great news! For the application to Denemo taglines and footnotes
are not wanted anyway as it is for creating a score to play from
on-screen.
 I guess it will be some time before this code gets into a release?



> The approach is to temporarily set the page-height to the largest size 
> possible, 

What is the largest size possible? I tried playing around with some
sizes, and some didn't work ...



> do the line breaking and page layout for that page height, then get the 
> vertical position on the page and the height of the lowest system (or top 
> level markup), and use that to calculate and then set the final page height 
> so that it fits the content of the page.

A crude version of this is what will be in the impending Denemo release
- Denemo creates the SVG output and counts the pages and then re-runs
LilyPond at a larger page size.

Richard





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

Documentation bug - wrong identity for default rehearsal mark format.

[Richard Shann]

I came across a documentation error:

http://lilypond.org/doc/v2.19/Documentation/notation/bars#rehearsal-marks


"The file ‘scm/translation-functions.scm’ contains the definitions of
format-mark-numbers (the default format),
 format-mark-box-numbers, format-mark-letters and
format-mark-box-letters." 

the default format is not format-mark-numbers, but format-mark-letters.

Richard Shann



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

LilyPond Segmentation fault on {r:32}

[Richard Shann]

It seems that LilyPond crashes when given a file with a tremolo on a
rest:

\version "2.19.43"
{ r:32 }

This behavior was reported to me for version 2.18.2, here is the
--verbose output:

lilypond --verbose SimpleSymphony3.ly
Log level set to 287
GNU LilyPond 2.19.43
Relocation: is absolute: argv0=/home/rshann/lilypond/usr/bin/lilypond
PATH=/home/rshann/lilypond/usr/bin (prepend)
Setting PATH
to 
/home/rshann/lilypond/usr/bin:/home/rshann/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
Relocation: compile datadir=, new
datadir=/home/rshann/lilypond/usr/share/lilypond//current
Relocation: framework_prefix=/home/rshann/lilypond/usr/bin/..
Setting INSTALLER_PREFIX to /home/rshann/lilypond/usr/bin/..
Relocation
file: /home/rshann/lilypond/usr/bin/../etc/relocate//guile.reloc
GUILE_LOAD_PATH=/home/rshann/lilypond/usr/bin/../share/guile/1.8
(prepend)
Setting GUILE_LOAD_PATH
to /home/rshann/lilypond/usr/bin/../share/guile/1.8
Relocation file: /home/rshann/lilypond/usr/bin/../etc/relocate//gs.reloc
warning: no such
directory: /home/rshann/lilypond/usr/bin/../share/ghostscript/9.15/fonts
for GS_FONTPATH
warning: no such
directory: /home/rshann/lilypond/usr/bin/../share/gs/fonts for
GS_FONTPATH
GS_LIB=/home/rshann/lilypond/usr/bin/../share/ghostscript/9.15/Resource
(prepend)
Setting GS_LIB
to /home/rshann/lilypond/usr/bin/../share/ghostscript/9.15/Resource
GS_LIB=/home/rshann/lilypond/usr/bin/../share/ghostscript/9.15/Resource/Init 
(prepend)
Setting GS_LIB
to 
/home/rshann/lilypond/usr/bin/../share/ghostscript/9.15/Resource/Init:/home/rshann/lilypond/usr/bin/../share/ghostscript/9.15/Resource
Relocation
file: /home/rshann/lilypond/usr/bin/../etc/relocate//fontconfig.reloc
Setting FONTCONFIG_FILE
to /home/rshann/lilypond/usr/bin/../etc/fonts/fonts.conf
Setting FONTCONFIG_PATH to /home/rshann/lilypond/usr/bin/../etc/fonts
PATH=/home/rshann/lilypond/usr/bin/../bin (prepend)
Setting PATH
to 
/home/rshann/lilypond/usr/bin/../bin:/home/rshann/lilypond/usr/bin:/home/rshann/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
Setting GUILE_MIN_YIELD_1 to 65
Setting GUILE_MIN_YIELD_2 to 65
Setting GUILE_MIN_YIELD_MALLOC to 65
Setting GUILE_INIT_SEGMENT_SIZE_1 to 10485760
Setting GUILE_MAX_SEGMENT_SIZE to 104857600

LILYPOND_DATADIR="/usr/share/lilypond/2.19.43"
LOCALEDIR="/usr/share/locale"

Effective prefix: "/home/rshann/lilypond/usr/share/lilypond/current"
FONTCONFIG_FILE="/home/rshann/lilypond/usr/bin/../etc/fonts/fonts.conf"
FONTCONFIG_PATH="/home/rshann/lilypond/usr/bin/../etc/fonts"
GS_LIB="/home/rshann/lilypond/usr/bin/../share/ghostscript/9.15/Resource/Init:/home/rshann/lilypond/usr/bin/../share/ghostscript/9.15/Resource"
GUILE_LOAD_PATH="/home/rshann/lilypond/usr/bin/../share/guile/1.8"
PATH="/home/rshann/lilypond/usr/bin/../bin:/home/rshann/lilypond/usr/bin:/home/rshann/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
[/home/rshann/lilypond/usr/share/lilypond/current/scm/lily.scm]
Guile 1.8
[/home/rshann/lilypond/usr/share/lilypond/current/scm/lily-library.scm]
[/home/rshann/lilypond/usr/share/lilypond/current/scm/output-lib.scm]
[/home/rshann/lilypond/usr/share/lilypond/current/scm/markup-macros.scm]
[/home/rshann/lilypond/usr/share/lilypond/current/scm/parser-ly-from-scheme.scm]
[/home/rshann/lilypond/usr/share/lilypond/current/scm/file-cache.scm]
[/home/rshann/lilypond/usr/share/lilypond/current/scm/define-event-classes.scm]
[/home/rshann/lilypond/usr/share/lilypond/current/scm/define-music-callbacks.scm]
[/home/rshann/lilypond/usr/share/lilypond/current/scm/define-music-types.scm]
[/home/rshann/lilypond/usr/share/lilypond/current/scm/define-note-names.scm]
[/home/rshann/lilypond/usr/share/lilypond/current/scm/c++.scm]
[/home/rshann/lilypond/usr/share/lilypond/current/scm/chord-entry.scm]
[/home/rshann/lilypond/usr/share/lilypond/current/scm/skyline.scm]
[/home/rshann/lilypond/usr/share/lilypond/current/scm/markup.scm]
[/home/rshann/lilypond/usr/share/lilypond/current/scm/define-markup-commands.scm]
[/home/rshann/lilypond/usr/share/lilypond/current/scm/stencil.scm]
[/home/rshann/lilypond/usr/share/lilypond/current/scm/modal-transforms.scm]
[/home/rshann/lilypond/usr/share/lilypond/current/scm/chord-generic-names.scm]
[/home/rshann/lilypond/usr/share/lilypond/current/scm/chord-ignatzek-names.scm]
[/home/rshann/lilypond/usr/share/lilypond/current/scm/music-functions.scm
[/home/rshann/lilypond/usr/share/lilypond/current/scm/define-music-display-methods.scm]
]
[/home/rshann/lilypond/usr/share/lilypond/current/scm/part-combiner.scm]
[/home/rshann/lilypond/usr/share/lilypond/current/scm/autochange.scm]
[/home/rshann/lilypond/usr/share/lilypond/current/scm/define-music-properties.scm]
[/home/rshann/lilypond/usr/share/lilypond/current/scm/time-signature.scm]
[/home/rshann/lilypond/usr/share/lilypond/current/scm/time-signature-settings.scm]
[/home/rshann/lilypond/usr/share/lilypond/current/scm/auto-beam.scm]
[/home/rshann/lilypond/usr/share/lilypond/current/scm/chord-name.scm]

Re: LilyPond Segmentation fault on {r:32}

[Richard Shann]

On Sun, 2017-02-26 at 13:36 -0700, Colin Campbell wrote:
> On 2017-02-26 09:18 AM, Richard Shann wrote:
> > It seems that LilyPond crashes when given a file with a tremolo on a
> > rest:
> >
> > \version "2.19.43"
> > { r:32 }
> >
> > This behavior was reported to me for version 2.18.2, here is the
> > --verbose output:
> Given that tremolo requires actual pitches, should I raise an 
> enhancement request that the error be handled more gracefully, by 
> reporting the error and terminating in a controlled fashion?

yes, that sounds right - the input is nonsense but I would guess that no
input should be capable of triggering a segmentation fault. (Well, that
might be too ideal if we are talking about deliberately constructed
evil-intentioned input).

Richard



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

Re: Patch to fix centering of some bass figures on whole notes and longer.

[Richard Shann]

On Thu, 2017-07-13 at 15:07 +0200, David Kastrup wrote:
> Richard Shann <rich...@rshann.plus.com> writes:
> 
> > On Thu, 2017-07-13 at 12:47 +0100, James wrote:
> >> > I am not top posting
> >> 
> >> This 'patch' does not apply to current master so I could not test it
> >> even if I wanted to
> >
> > Ah, yes, sorry, I looked into what parameters git uses for its diff but
> > didn't think about the directory you would want to run patch from.
> > I've made a git clone of the repository and used git diff now to get the
> > attached patch.
> 
> That doesn't help much I think.  Create an actual commit with commit
> message, then format that using
> 
> git format-patch HEAD~1

ah, ok. That gives the attached.

Richard

From 336daa273929815ecb4b6e1a2be5a56f743b1181 Mon Sep 17 00:00:00 2001
From: Richard Shann <richard.sh...@virgin.net>
Date: Thu, 13 Jul 2017 14:00:48 +0100
Subject: [PATCH] Fix centering of single figures and lone accidentals when
 occurring on whole notes and longer durations

---
 scm/translation-functions.scm | 11 ---
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/scm/translation-functions.scm b/scm/translation-functions.scm
index 0ed0def..cd78d83 100644
--- a/scm/translation-functions.scm
+++ b/scm/translation-functions.scm
@@ -184,13 +184,10 @@ way the transposition number is displayed."
   (set! alt-markup #f)))
 
 
-;; hmm, how to get figures centered between note, and
-;; lone accidentals too?
-
-;;(if (markup? fig-markup)
-;;  (set!
-;;   fig-markup (markup #:translate (cons 1.0 0)
-;;  #:center-align fig-markup)))
+(if (and (>= 0 (ly:duration-log  (ly:event-property event 'duration))) (markup? fig-markup))
+(set!
+fig-markup (markup #:translate (cons 1.0 0)
+#:center-align fig-markup)))
 
 (if alt-markup
 (set! fig-markup
-- 
2.1.4

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

Patch to fix centering of some bass figures on whole notes and longer.

[Richard Shann]

Simon Albrecht suggested I start a new thread for this (apologies for
any confusion)

Attached is a patch that fixes the centering of single bass figures over
notes of duration whole note and more. The duration is tested and a
translate applied horizontally if needed.

A test snippet is this:

8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><
<<

{

\time 4/2 c''\breve c'' c''1 c''

c''4 c'' c'' c''


}

\new FiguredBass {

\figuremode {

<_+>\breve <_-> <3>1 <3+>

<_+>4 <_-> <3> <3+>

}

}

>>
8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><

In version until now the single character figures are placed to the left
of the true center.

Richard



--- ORIG_translation-functions.scm	2017-07-08 12:36:17.716097042 +0100
+++ translation-functions.scm	2017-07-09 14:05:34.084003967 +0100
@@ -184,13 +184,10 @@ way the transposition number is displaye
   (set! alt-markup #f)))
 
 
-;; hmm, how to get figures centered between note, and
-;; lone accidentals too?
-
-;;(if (markup? fig-markup)
-;;  (set!
-;;   fig-markup (markup #:translate (cons 1.0 0)
-;;  #:center-align fig-markup)))
+(if (and (>= 0 (ly:duration-log  (ly:event-property event 'duration))) (markup? fig-markup))
+(set!
+fig-markup (markup #:translate (cons 1.0 0)
+#:center-align fig-markup)))
 
 (if alt-markup
 (set! fig-markup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: A contribution (was Re: snippet to properly align dynamics with expressive text)

[Richard Shann]

On Sun, 2017-07-09 at 13:15 +0200, Malte Meyn wrote:
> 
> Am 09.07.2017 um 12:50 schrieb Richard Shann:
> > Thanks - here is such a small patch then. It fixes the centering of
> > isolated accidentals and digits on whole notes which is currently too
> > far to the left.
> 
>  From your patch:
> 
> +(if (and (eqv? 0 (ly:duration-log  (ly:event-property event 
> 'duration))) (markup? fig-markup))
> 
> Shouldn’t you consider negative duration logs (\breve and longer notes) 
> too, i. e. “>=” instead of “eqv?”?
> 
> (if (and (>= 0 (ly:duration-log  (ly:event-property event 'duration))) 
> (markup? fig-markup))

it seems so, I was unsure what values duration log could take, perhaps
being set sometimes to #f so I used eqv? to be safe.
Attached is the revised patch which works on this:

8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><
<<

{

\time 4/2 c''\breve c'' c''1 c''

c''4 c'' c'' c''


}

\new FiguredBass {

\figuremode {

<_+>\breve <_-> <3>1 <3+>

<_+>4 <_-> <3> <3+>

}

}

>>
8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><

Richard


--- ORIG_translation-functions.scm	2017-07-08 12:36:17.716097042 +0100
+++ translation-functions.scm	2017-07-09 14:05:34.084003967 +0100
@@ -184,13 +184,10 @@ way the transposition number is displaye
   (set! alt-markup #f)))
 
 
-;; hmm, how to get figures centered between note, and
-;; lone accidentals too?
-
-;;(if (markup? fig-markup)
-;;  (set!
-;;   fig-markup (markup #:translate (cons 1.0 0)
-;;  #:center-align fig-markup)))
+(if (and (>= 0 (ly:duration-log  (ly:event-property event 'duration))) (markup? fig-markup))
+(set!
+fig-markup (markup #:translate (cons 1.0 0)
+#:center-align fig-markup)))
 
 (if alt-markup
 (set! fig-markup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Patch to fix centering of some bass figures on whole notes and longer.

[Richard Shann]

On Sun, 2017-07-09 at 18:46 +0200, David Kastrup wrote:
> Richard Shann <rich...@rshann.plus.com> writes:
> 
> > Simon Albrecht suggested I start a new thread for this (apologies for
> > any confusion)
> >
> > Attached is a patch that fixes the centering of single bass figures over
> > notes of duration whole note and more. The duration is tested and a
> > translate applied horizontally if needed.
> 
> Except that the "centering" or not decision then rests on the duration
> of the bass figure rather than any properties of the note column in
> question.
> 
> I think it isn't uncommon to have bass lines where there isn't one
> figure per bass note but there are also intermediate notes without
> figure.

Indeed, there are frequently notes without figures (more often than not
in fact) and there are also multiple figures per note, and figures on
rests. Not sure what any of that has to do with this.

In the current LilyPond the figures are centered (visually speaking - I
don't know how they relate to internals such as note column) for
durations greater than 0 but too far to the left for the others (always
referring here to the case of a single figures on a note).

Richard





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

Re: Centering bass figures on whole notes and longer (issue 325070043 by pkx1...@gmail.com)

[Richard Shann]

On Sat, 2017-07-15 at 01:50 -0700, thomasmorle...@gmail.com wrote:
> On 2017/07/15 08:06:41, richard_rshann.plus.com wrote:
> 
> > So I think you could validly object that you didn't like them being
> > treated differently.
> 
> If you look at the following, namely the colored BassFigures
> 
> cbf = \once \override BassFigure.color = #red
> <<
>\relative c' { c1 c8 d e f g f e d c1 c1 }
>\figures { <_!>2 <_!>2 \cbf <_!>1 <_!>2 <_!>2 \cbf <_!>1 }
> 
> 
> You'll see your patch improves the second colored BassFigure, but the
> first one is turned worse.

Ah, yes I see. If you create a single figure of a duration to cover a
whole series of shorter duration notes you run into trouble. A better
approach to the problem would be needed to avoid you having to re-code
the bass figure duration to match the note it applies to.

Richard



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

Re: Centering bass figures on whole notes and longer (issue 325070043 by pkx1...@gmail.com)

[Richard Shann]

On Sat, 2017-07-15 at 02:09 -0700, thomasmorle...@gmail.com wrote:
> On 2017/07/15 08:55:43, richard_rshann.plus.com wrote:
> > On Sat, 2017-07-15 at 08:51 +0100, Richard Shann wrote:
> > > On Sat, 2017-07-15 at 00:40 -0700, mailto:thomasmorle...@gmail.com
> wrote:
> > > > On 2017/07/15 07:25:37, http://richard_rshann.plus.com wrote:
> > > > > On Sat, 2017-07-15 at 00:09 -0700,
> mailto:thomasmorle...@gmail.com
> > > > wrote:
> > > > > > I'm afraid this patch does not fix the problem as wished.
> > > >
> > > > > You give an example of multiple bass figures on a note, I'm not
> > > sure
> > > > > what you would wish to see for that case,
> > > >
> > > > In
> > > > <<
> > > >\relative c' { c1 c1 }
> > > >\figures { <6+>2 <6+>2 <6+>1 }
> > > >
> > > > I would expect same aligning for first and second BassFigure
> related
> > > to
> > > > the note.
> > > (understood: first and second *group* of bass figures)
> > >
> > > That would be ok, although when you have multiple figures on a note
> > > allowing a bit more space for them can be good sometimes. You could
> > > always move the whole group along by inserting a short duration note
> > > with no figure in the bass figures if there was a particular case
> > > where
> > > this seemed obtrusive (hacky of course).
> > >
> > > So I think you could validly object that you didn't like them being
> > > treated differently.
> > Ha! I think I was being over-generous to your case here :)
> > consider
> 
> > <<
> > \relative c' { c1 c2 }
> > \figures { <_+>2 <6+>2  <_+>4 <4>4}
> 
> >   >>
> 
> > In the current LilyPond the two groups of figures are aligned
> > differently.
> 
> As a debugging-helper I coded a visualization.tool:
> 
> \layout {
>\context {
>  \FiguredBass
>  \override BassFigure.after-line-breaking =
>#(lambda (grob)
>  (let ((line
>  (ly:make-stencil
>(ly:stencil-expr (make-filled-box-stencil '(0 . 0) '(0
> . 10)))
>'(0 . 0)
>'(0 . 0
>  (format #t "\nX-extent:\t~a"
>(interval-length (ly:grob-property grob 'X-extent)))
>  (ly:grob-set-property! grob 'stencil
>(box-stencil
>  (ly:stencil-combine-at-edge
>(ly:stencil-combine-at-edge
>  line Y RIGHT (ly:text-interface::print grob) 0)
>X RIGHT line 0)
>0 0
>}
> }
> 
> After applying it to your example I'm not sure what you mean. I don't
> see a significant difference.

Your visualization tool reveals the problem. They are aligned the same:
the left hand edge of the figure is aligned with the left hand edge of
the note. However, because the whole note is wider visual impression is
that the figure appears centered on the note for the shorter duration
notes but to the left for the whole note.
So the problem is perhaps that the choice of alignment point is
unfortunate.

Richard



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

Re: Centering bass figures on whole notes and longer (issue 325070043 by pkx1...@gmail.com)

[Richard Shann]

On Sat, 2017-07-15 at 00:09 -0700, thomasmorle...@gmail.com wrote:
> I'm afraid this patch does not fix the problem as wished.

It solves the problem of single bass figures and isolated accidentals on
notes of duration longer than whole note as the comment says. 

You give an example of multiple bass figures on a note, I'm not sure
what you would wish to see for that case, but what LilyPond does in that
case is quite readable - I can't suggest any improvement for that case.
I wouldn't want to see the whole group of figures centered on the note
centre since they would seem to start before the note - I'm not sure
what the 19th c academic style might be...

Richard


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

Re: Centering bass figures on whole notes and longer (issue 325070043 by pkx1...@gmail.com)

[Richard Shann]

On Sat, 2017-07-15 at 08:51 +0100, Richard Shann wrote:
> On Sat, 2017-07-15 at 00:40 -0700, thomasmorle...@gmail.com wrote:
> > On 2017/07/15 07:25:37, richard_rshann.plus.com wrote:
> > > On Sat, 2017-07-15 at 00:09 -0700, mailto:thomasmorle...@gmail.com
> > wrote:
> > > > I'm afraid this patch does not fix the problem as wished.
> > 
> > > You give an example of multiple bass figures on a note, I'm not
> sure
> > > what you would wish to see for that case,
> > 
> > In
> > <<
> >\relative c' { c1 c1 }
> >\figures { <6+>2 <6+>2 <6+>1 }
> > 
> > I would expect same aligning for first and second BassFigure related
> to
> > the note.
> (understood: first and second *group* of bass figures)
> 
> That would be ok, although when you have multiple figures on a note
> allowing a bit more space for them can be good sometimes. You could
> always move the whole group along by inserting a short duration note
> with no figure in the bass figures if there was a particular case
> where
> this seemed obtrusive (hacky of course).
> 
> So I think you could validly object that you didn't like them being
> treated differently.
Ha! I think I was being over-generous to your case here :)
consider

<<
   \relative c' { c1 c2 }
   \figures { <_+>2 <6+>2  <_+>4 <4>4}

 >>

In the current LilyPond the two groups of figures are aligned
differently. So, my patch constitutes an improvement to the current
situation, even though it doesn't fix this case, (which, as I said, is
not really a worry - it's quite difficult to spot).

Richard






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

Re: Centering bass figures on whole notes and longer (issue 325070043 by pkx1...@gmail.com)

[Richard Shann]

On Sat, 2017-07-15 at 00:40 -0700, thomasmorle...@gmail.com wrote:
> On 2017/07/15 07:25:37, richard_rshann.plus.com wrote:
> > On Sat, 2017-07-15 at 00:09 -0700, mailto:thomasmorle...@gmail.com
> wrote:
> > > I'm afraid this patch does not fix the problem as wished.
> 
> > You give an example of multiple bass figures on a note, I'm not sure
> > what you would wish to see for that case,
> 
> In
> <<
>\relative c' { c1 c1 }
>\figures { <6+>2 <6+>2 <6+>1 }
> 
> I would expect same aligning for first and second BassFigure related to
> the note.
(understood: first and second *group* of bass figures)

That would be ok, although when you have multiple figures on a note
allowing a bit more space for them can be good sometimes. You could
always move the whole group along by inserting a short duration note
with no figure in the bass figures if there was a particular case where
this seemed obtrusive (hacky of course).

So I think you could validly object that you didn't like them being
treated differently. But that wouldn't justify sticking with the
horrible effect you see when there is a single figure/lone accidental. 

Richard





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

Re: Patch to fix centering of some bass figures on whole notes and longer.

[Richard Shann]

On Thu, 2017-07-13 at 12:47 +0100, James wrote:
> > I am not top posting
> 
> This 'patch' does not apply to current master so I could not test it
> even if I wanted to

Ah, yes, sorry, I looked into what parameters git uses for its diff but
didn't think about the directory you would want to run patch from.
I've made a git clone of the repository and used git diff now to get the
attached patch.

Richard

diff --git a/scm/translation-functions.scm b/scm/translation-functions.scm
index 0ed0def..cd78d83 100644
--- a/scm/translation-functions.scm
+++ b/scm/translation-functions.scm
@@ -184,13 +184,10 @@ way the transposition number is displayed."
   (set! alt-markup #f)))
 
 
-;; hmm, how to get figures centered between note, and
-;; lone accidentals too?
-
-;;(if (markup? fig-markup)
-;;  (set!
-;;   fig-markup (markup #:translate (cons 1.0 0)
-;;  #:center-align fig-markup)))
+(if (and (>= 0 (ly:duration-log  (ly:event-property event 'duration))) (markup? fig-markup))
+(set!
+fig-markup (markup #:translate (cons 1.0 0)
+#:center-align fig-markup)))
 
 (if alt-markup
 (set! fig-markup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Centering bass figures on whole notes and longer (issue 325070043 by pkx1...@gmail.com)

[Richard Shann]

On Sat, 2017-07-15 at 16:15 -0700, thomasmorle...@gmail.com wrote:
> On 2017/07/15 09:13:08, thomasmorley651 wrote:
> 
> > If you try
> > \override BassFigure.X-offset =
> > #ly:self-alignment-interface::centered-on-x-parent
> > you'll see improvements in some cases (others are worse).
> > Therefore I think ly:self-alignment-interface::centered-on-x-parent is
> not the
> > correct tool, but something similiar could do the trick.
> 
> https://sourceforge.net/p/testlilyissues/issues/5154/#ce35
> May be a starting point/proof of concept.

You seem to have things under control with this code. I think
\centerOnNoteColumn
should be the default, I've been scouring the "Golden Age" of engraving
that LilyPond aspires to for examples and I noticed that the failure to
center isolated figures on whole-notes only becomes an eyesore when the
figures are in a small font size, at larger font sizes the figure fills
out the width of the note more. This can be seen, e.g., in Augener's
edition of the Corelli chamber sonatas. I've attached an example from 

Denkmäler deutscher Tonkunst, Erste
Folge; Bd.18
Leipzig: Breitkopf und Härtel, 1904.
Plate D.D.T. XVIII.

which shows them centering the figure under a whole note in the first
bar shown and then aligning the first of two figures with the right edge
of the whole note in the second bar. At this font size it is quite
subtle though.

Richard

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

Re: Centering bass figures on whole notes and longer (issue 325070043 by pkx1...@gmail.com)

[Richard Shann]

On Sun, 2017-07-16 at 10:09 +0100, Richard Shann wrote:
> which shows them centering the figure under a whole note

well, actually, *over* a whole note inthis case. The fact that the whole
note is so far away from the figure (because of its pitch) makes the
effect still more subtle, it becomes more obvious if the figure is right
above/below the note.

Richard



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

Re: GSoC Proposal - SVG Export

[Richard Shann]

On Fri, 2018-11-30 at 22:39 -0500, Étienne Beaulé wrote:
> Hello all!
> 
> I’m Étienne Beaulé and I’ve been making some changes to LilyPond. I
> am also the maintainer of the MediaWiki Score extension which allows
> embedded LilyPond on Wikipedia. I’m currently a bachelor student at
> the Université de Montréal studying computer science and mathematics,
> and Google Summer of Code caught my eye. I’d be interested in doing a
> project if a mentor is available.
> 
> # Improving SVG score output
> 
> ## Summary
> 
> Scalable Vector Graphics (SVG) is a vector graphics format designed
> for use on the internet. LilyPond (LY) is a program which translates
> musical notation syntax into a graphics format, such as SVG. This
> format is important for web publishing, and as a vector format, is
> advantageous over Portable Network Graphics (PNG) file, of which is
> _de facto_ used in this application.
> 
> LY already has SVG output, yet is somewhat broken in many factors.
> Namely in font handling with broken sky-lining #3778 and the use of
> musical symbols as text. Development in fixing these problems may
> offer changes in other backends. This project will focus on the use
> of musical symbols in SVG files and the positioning of text. I have
> previously submitted patches for text-positioning bugs.
> 
> ## Deliverables
> 
> * Self-contained musical SVG files
> * Functioning text sky-lining in SVG
> * Grouping of text for better placement in SVG
> 
> ## Timeline
> 
> _This is the hard part… Non-comprehensive_
> 
> * Analysis of incompatibilities between PostScript (PS) and SVG
> output
>   Important to have a grip on this to not introduce bugs and to keep
> commonalities between backends
> * Deprecation of SVG fonts - embed font into SVG
> 
> — —
> 
> * Reduce size of SVG by enumerating used glyphs
> * Merge glyph functions for text and symbols
> 
> — —
> 
> * Implement use of `` tags and Cascading Style Sheets (CSS)
> for text handling
>   * Will require modification of PS backends
>   * Fix Horizontal Spacing of text
> * Fix SVG text sky-lining in conjunction with character size /
> spacing calculations
> 
> Thoughts?
It is probably a very small thing, but it would be good if you could
improve the SVG output with regard to the use of "current color" which
Lily outputs as the default foreground color rather than black. There
was a plea recently for this:

From:   d_l 
To: lilypond-devel@gnu.org
Subject:Request PATCH to ensure LilyPond SVG compatibility with
Scribus
Date:   Thu, 11 Oct 2018 06:56:34 -0700 (MST) (11/10/18 14:56:34)

and others earlier. Denemo has to work around this quirk - the problem
being the "current color" is frequently white, the same as the
background...

Richard


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

Re: GSoC Proposal - SVG Export

[Richard Shann]

On Sat, 2018-12-01 at 23:21 -0500, Étienne Beaulé wrote:
> Having glyph styling through CSS is one of the goals of this project.
> In the use of « currentColor, » it does seem to follow
> specifications.

Hmm, these specs would seem to allow the SVG to be rendered onto a
background of the same color as currentColor - in my case I use the GDK
Pixbuf library to render the SVG and it seems to choose currentColor to
be white - I can't see any reference in the documentation to changing
this. I don't know what the other people raising this issue were using,
but there seems to be quite a widespread problem...

Richard

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

Re: GSoC Proposal - SVG Export

[Richard Shann]

On Mon, 2018-12-03 at 09:22 -0500, Paul Morris wrote:
> Hi Carl and everyone,
> 
> On 12/2/18 8:02 PM, Carl Sorensen wrote:
> 
> > We used to have black be the color of the glyphs.  We made a very
> > specific and intentional move from black to currentColor.  And it
> > was an improvement, IMO.  That is why I feel strongly about moving
> > away from currentColor.
> 
> currentColor sounds like the right default.
what seems strange is that there seems to be no concept of "backgound
color" in SVG (logical in a way as SVG is about things you can draw)
allowing for the possibility of drawing white on white.
>   It also seems reasonable to 
> allow the user to override that default and set it to black or
> another 
> color, depending on their use case.  Maybe that's already possible?  
yes, you add stuff to the LilyPond input to color everything explicitly
black. IIRC you can specify extra stuff to be included from the command
line too.

Richard


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

Re: min-systems-per-page causes LilyPond to hang 2.20

[Richard Shann]

On Fri, 2020-10-23 at 10:17 +0200, Jean Abou Samra wrote:
> Le 21/10/2020 à 17:58, Jean Abou Samra a écrit :
> > Le 21/10/2020 à 17:37, Richard Shann a écrit :
> > 
> > > I've noticed that having
> > > 
> > > min-systems-per-page  = 2
> > > 
> > > can in some circumstances cause LilyPond to hang. The attached
> > > non-minimal file exhibits this behavior:
> > > 
> > > Starting lilypond 2.20.0 [NonTypesettablePart.ly]...
> > > Processing `/tmp/frescobaldi-
> > > hm6j987d/tmpvp8zypvl/NonTypesettablePart.ly'
> > > Parsing...
> > > Interpreting music...[8][16]
> > > Preprocessing graphical objects...
> > > Interpreting music...[8][16][24][32][40][48][56][64][72]
> > > Preprocessing graphical objects...
> > > Interpreting music...[8][16][24][32]
> > > Preprocessing graphical objects...
> > > Interpreting music...[8][16][24][32][40][48]
> > > Preprocessing graphical objects...
> > > Interpreting music...
> > > Preprocessing graphical objects...
> > > Calculating line breaks...
> > > Drawing systems...
> > > Fitting music on 5 pages...
> > > [hangs ... manual abort]
> > > Aborting lilypond 2.20.0 [NonTypesettablePart.ly]...
> > > 
> > > commenting out the line
> > > min-systems-per-page  = 2
> > > allows it to typeset normally, curiously it does not have an
> > > orphan
> > > line.
> > > 
> > > I just wondered if this is a known issue - I don't see it
> > > mentioned in
> > > the docs
> > > 
> > > https://lilypond.org/doc/v2.20/Documentation/notation/other-paper
> > > -variables#index-min_002dsystems_002dper_002dpage 
> > > 
> > > 
> > > there is a very large amount of irrelevant material in the
> > > attached
> > > lily file which I would be in the best position to excise if that
> > > were
> > > useful, but I wouldn't want to undertake the task if the issue
> > > was
> > > already known about, or there was no-one wanting to work on it
> > > anyway,
> > > or indeed if it wouldn't really help as this bug is not at all
> > > likely
> > > to be due to some typo to be spotted by eye.
> > > Let me know if help would be welcomed.
> > > 
> > > Richard Shann
> > 
> > Hello,
> > 
> > I could not find this bug in the list of current issues,
> > which for your information is available at
> > 
> > https://gitlab.com/lilypond/lilypond/-/issues
> > 
> > It would certainly help if you could boil it down to a
> > minimal example.
> > 
> > Best regards,
> > Jean
> > 
> 
> Any update on this?

I'm afraid I wasn't perhaps clear enough in what I wrote: I was
offering to remove large amounts of irrelevant material from the .ly
file as it is machine-generated (by Denemo) and I understand what can
be dropped without changing the music that LilyPond will try to
typeset. 
However, even this is not an insignificant task and I'm not at all
clear in what debugging scenario this would be useful. Normally when
someone finds a crash asking them to chop down the file to isolate the
bit causing the crash makes perfect sense. The file is hand-written and
often chopping it down will reveal some typo or syntax combination
which triggers the crash. In this case the same bits of syntax have
been generated in thousands of files without trouble except for the
introduction of min-systems-per-page  = 2 which is a new feature in
Denemo. So it is highly likely that it is the combination of this
syntax with \pageBreak that causes LilyPond to hang. It also means that
altering any of the music that will actually be typeset is likely to
trigger the disappearance/re-appearance of the bug - and indeed I found
just this to be the case when I was first trying to track down the
cause of the bug.
So, if someone is wishing to tackle the debugging and needs irrelevant
material to be removed from the exemplar for some specific reason I can
help. But it would only reduce the file by about three quarters. I
suspect debugging this would require detecting the loop that is being
triggered and eyeballing the source code involved to see where it is
being assumed that something will always break out of the loop. For
that sort of work the input is irrelevant.

Richard

output-attributes in 2.20.0

[Richard Shann]

I'm trying to get the annotated SVG output that enables playback with a
scrolling LilyPond score working in 2.20.

In the changes http://lilypond.org/doc/v2.20/Documentation/changes/inde
x.html I read:

"A new output-attributes grob property is now used for svg output
instead of the id grob property. It allows multiple attributes to be
defined as an association list. For example, #'((id . 123) (class .
foo) (data-whatever . “bar”)) will produce the following group tag in
an SVG file:  … "

but I see that the convert-ly changes this:

\override NoteHead.id = #note-id

to this:

\override Score.NoteHead.output-attributes.id = #note-id

which is not an alist.
Moreover, in the code I'm using 
(http://git.savannah.gnu.org/gitweb/?p=denemo.git;a=blob;f=actions/lilypond/live-score.ily;h=5a9d22fe5efe89e9f63a087177d206eab63109f0;hb=HEAD)
 
note-id is a procedure returning a string, which seems to be acceptable to the 
2.18 SVG generator while the 2.20 version gives an error message:

Unsupported SCM value for format: #

and the output in the SVG is an empty string:



while with 2.18

the output was (for example)



where "Note-7-2" is the return value for the particular grob - the line
7 column 2 location information.

What's more, if I write an alist value (following the documentation
above)

\override Score.NoteHead.output-attributes.id = #'((id . "foo"))

I get the error:

Unsupported SCM value for format: ((id . foo))

So what should output-attributes.id be set to - can it take a procedure
as id could in 2.18?

Richard Shann

Re: output-attributes in 2.20.0

[Richard Shann]

On Sun, 2020-08-02 at 14:32 +0200, David Kastrup wrote:
> Richard Shann  writes:
> 
> > I'm trying to get the annotated SVG output that enables playback
> > with a
> > scrolling LilyPond score working in 2.20.
> > 
> > In the changes http://lilypond.org/doc/v2.20/Documentation/changes/
> > inde
> > x.html I read:
> > 
> > "A new output-attributes grob property is now used for svg output
> > instead of the id grob property. It allows multiple attributes to
> > be
> > defined as an association list. For example, #'((id . 123) (class .
> > foo) (data-whatever . “bar”)) will produce the following group tag
> > in
> > an SVG file:  … "
> > 
> > but I see that the convert-ly changes this:
> > 
> > \override NoteHead.id = #note-id
> > 
> > to this:
> > 
> > \override Score.NoteHead.output-attributes.id = #note-id
> > 
> > which is not an alist.
> 
> Why would output-attributes not be an alist?
> 
> > Moreover, in the code I'm using 
> > (http://git.savannah.gnu.org/gitweb/?p=denemo.git;a=blob;f=actions/
> > lilypond/live-
> > score.ily;h=5a9d22fe5efe89e9f63a087177d206eab63109f0;hb=HEAD) 
> > note-id is a procedure returning a string, which seems to be
> > acceptable to the 2.18 SVG generator while the 2.20 version gives
> > an
> > error message:
> > 
> > Unsupported SCM value for format: #
> 
> Callbacks are not supported for subproperties.
> 
> > and the output in the SVG is an empty string:
> > 
> > 
> > 
> > while with 2.18
> > 
> > the output was (for example)
> > 
> > 
> > 
> > where "Note-7-2" is the return value for the particular grob - the
> > line
> > 7 column 2 location information.
> > 
> > What's more, if I write an alist value (following the documentation
> > above)
> 
> You are not following the documentation.  You are presuming that the
> documentation is wrong, substitute what you consider a correction,
> and
> the result does not work.
> 
> > \override Score.NoteHead.output-attributes.id = #'((id . "foo"))
> > 
> > I get the error:
> > 
> > Unsupported SCM value for format: ((id . foo))
> 
> Because you set output-attributes to ((id . ((id . "foo" rather
> than
> to ((id . "foo")).
> 
> > So what should output-attributes.id be set to - can it take a
> > procedure
> > as id could in 2.18?
> 
> output-attributes can take a procedure (which must return a complete
> alist).  id doesn't.

Thank you. By "output-attributes can take a procedure" I guessed you
might mean "can be set equal to a procedure", although I haven't found
where that is documented (*), so I set

\override Score.NoteHead.output-attributes = #note-id

and re-defined the procedure note-id to be

#(define (note-id grob) 
   (let* ((origin (ly:input-file-line-char-column
   (ly:event-property (ly:grob-property grob 'cause) 'origin)))
   (value  (string-concatenate 
(list 
  "Note-" 
  (ly:format "~a-~a"
(cadr origin)
(caddr origin))  
   
  (cons (cons 'id  value) '(

and all is well. There is some more elegant syntax for the alist, but
I'll stop while I'm ahead.

Richard Shann

(*) The documentation says
"SVG output can optionally contain metadata for graphical objects
(grobs) like note heads, rests, etc. This metadata can be standard SVG
attributes like id and class, or non-standard custom attributes.
Specify the attributes and their values by overriding a grob’s output-
attributes property with a Scheme association list (alist). The values
can be numbers, strings, or symbols. For example: "

I suggest

"SVG output can optionally contain metadata for graphical objects
(grobs) like note heads, rests, etc. This metadata can be standard SVG
attributes like id and class, or non-standard custom attributes.
Specify the attributes and their values by overriding a grob’s output-
attributes property with a Scheme association list (alist) or a
procedure returning an alist. The values can be numbers, strings, or
symbols. For example:" 

Re: output-attributes in 2.20.0

[Richard Shann]

On Thu, 2020-08-06 at 11:31 +0200, Jean Abou Samra wrote:
>    > (*) The documentation says "SVG output can optionally contain
>    metadata for graphical objects (grobs) like note heads, rests,
> etc.
>    This metadata can be standard SVG attributes like id and class, or
>    non-standard custom attributes. Specify the attributes and their
> values
>    by overriding a grob’s output- attributes property with a Scheme
>    association list (alist). The values can be numbers, strings, or
>    symbols. For example: " I suggest "SVG output can optionally
> contain
>    metadata for graphical objects (grobs) like note heads, rests,
> etc.
>    This metadata can be standard SVG attributes like id and class, or
>    non-standard custom attributes. Specify the attributes and their
> values
>    by overriding a grob’s output- attributes property with a Scheme
>    association list (alist) or a procedure returning an alist. The
> values
>    can be numbers, strings, or symbols. For example:"
> 
>    This is not specific to output-attributes. Any grob property can
> be set
>    to a callback, that is, a (lambda (grob) ...). This is documented
> here:
>    [1]http://lilypond.org/doc/v2.20/Documentation/extending/callback-
> funct
>    ions

Ah, thank you for that. Does convert-ly normally warn if the
substitution it makes may be wrong? Changing

\override NoteHead.id = #note-id

to

 \override Score.NoteHead.output-attributes.id = #note-id

only works if note-id is *not* a callback as I understand it.

Richard Shann

min-systems-per-page causes LilyPond to hang 2.20

[Richard Shann]

I've noticed that having

min-systems-per-page  = 2

can in some circumstances cause LilyPond to hang. The attached
non-minimal file exhibits this behavior:

Starting lilypond 2.20.0 [NonTypesettablePart.ly]...
Processing `/tmp/frescobaldi-
hm6j987d/tmpvp8zypvl/NonTypesettablePart.ly'
Parsing...
Interpreting music...[8][16]
Preprocessing graphical objects...
Interpreting music...[8][16][24][32][40][48][56][64][72]
Preprocessing graphical objects...
Interpreting music...[8][16][24][32]
Preprocessing graphical objects...
Interpreting music...[8][16][24][32][40][48]
Preprocessing graphical objects...
Interpreting music...
Preprocessing graphical objects...
Calculating line breaks... 
Drawing systems... 
Fitting music on 5 pages...
[hangs ... manual abort]
Aborting lilypond 2.20.0 [NonTypesettablePart.ly]...

commenting out the line
min-systems-per-page  = 2
allows it to typeset normally, curiously it does not have an orphan
line.

I just wondered if this is a known issue - I don't see it mentioned in
the docs

https://lilypond.org/doc/v2.20/Documentation/notation/other-paper-variables#index-min_002dsystems_002dper_002dpage

there is a very large amount of irrelevant material in the attached
lily file which I would be in the best position to excise if that were
useful, but I wouldn't want to undertake the task if the issue was
already known about, or there was no-one wanting to work on it anyway,
or indeed if it wouldn't really help as this bug is not at all likely
to be due to some typo to be spotted by eye.
Let me know if help would be welcomed.

Richard Shann


% LilyPond file generated by Denemo version 2.4.4

%%http://www.gnu.org/software/denemo/

\version "2.20"

CompactChordSymbols = {}
#(define DenemoTransposeStep 0)
#(define DenemoTransposeAccidental 0)
DenemoGlobalTranspose = \void {}
titledPiece = {}
AutoBarline = {}
AutoEndMovementBarline = \bar "|."
#(define DenemoTransposeStep 2)
#(define DenemoTransposeAccidental -1/2)

DenemoGlobalTranspose = #(define-music-function (parser location arg)(ly:music?) #{\transpose c ees#arg #})
#(define denemo-top-margin -5)
tupletBracketToSlur = {
  % Use slur-stencil
  \override TupletBracket.stencil = #ly:slur::print
  %% Use 'thickness from Slur
  \override TupletBracket.thickness = #1.2
  %% 'control-points need to be set
  \override TupletBracket.control-points =
#(lambda (grob)
  (let* ((x-pos (ly:grob-property grob 'X-positions))
 (pos (ly:grob-property grob 'positions))
 (x-ln (interval-length x-pos))
 (dir (ly:grob-property grob 'direction))
 ;; read out the height of the TupletBracket, maybe negative!
 (height (- (cdr pos) (car pos)))
 ;; height-corr is introduced because sometimes the shape of the
 ;; slur needs to be adjusted.
 ;; It is used in the 2nd/3rd control-point.
 ;; The value of 0.3 is found by trial and error
 (height-corr (* 0.3 dir height))
 (edge-height (ly:grob-property grob 'edge-height '(0.7 . 0.7)))
 (pad 1.0))
(list
  ;; first cp
  (cons
(+ (car x-pos) 0.5)
(- (+ (* dir pad) (+ (car pos) (* -1 dir (car edge-height
  (if (= dir -1)
  (if (> height 3)
(/ dir 2.0)
0.0)
  (if (< height -3)
(/ dir 2.0)
0.0
  ;; second cp
  (cons
(+ (car x-pos) (* x-ln 1/4))
(+ (* dir pad) (+ (car pos) (* dir (+ 0.5 height-corr)
  ;; third cp
  (cons
(+ (car x-pos) (* x-ln 3/4))
(+ (* dir pad) (+ (cdr pos) (* dir (- 0.5 height-corr)
  ;; fourth cp
  (cons
(- (cdr x-pos) 0.5)
(+ (* dir pad) (+ (cdr pos) (* -1 dir (cdr edge-height)
)))
  \override TupletBracket.staff-padding = #'()
  #(define (invert-direction x) (if (eq? UP (ly:tuplet-bracket::calc-direction x)) DOWN UP))
\override TupletBracket.direction = #invert-direction
}
\version "2.20.0"
%%% book-titling.ily  -- a titling stylesheet for use in books
%%% 
%%% Author: Nicolas Sceaux 
%%%

%%%
%%% Utility markups

%% vertical space skip
#(define-markup-command (vspace layout props amount) (number?)
  "This produces a invisible object taking vertical space."
  (let ((amount (* amount 3.0)))
(if (> amount 0)
(ly:make-stencil "" (cons -1 1) (cons 0 amount))
(ly:make-stencil "" (cons -1 1) (cons amount amount)

#(define-markup-command (when-property layout props symbol markp) (symbol? markup?)
  (if (chain-assoc-get symbol props)
  (interpret-markup layout props markp)
  (ly:make-stencil '()  '(1 . -1) '(1 . -1

#(define-markup-command (line-width-ratio layout props width-rat

Re: Cairo plans

[Richard Shann]

On Wed, 2021-09-01 at 15:11 +0200, Rene Brandenburger wrote:
> I use the \postscript a lot 

Denemo uses postscript to generate a title page with a border.

Richard Shann

> when typesetting contemporary music e.g. 
> like this:
> 
> \version "2.20.0"
> 
> 
> wave_line = \markup {
>    \with-dimensions #'(0 . 0) #'(0 . 0)
>    \postscript #"0.3 setlinewidth 1 setlinecap [0 1]
>   0 0 0 setrgbcolor  0.00 -3.50 moveto
>   0.23 -3.71   0.47 -3.93   1.00 -4.00 curveto
>   1.53 -4.07   2.36 -4.00   3.00 -3.50 curveto
>   3.64 -3.00   4.11 -2.07   4.50 -1.46 curveto
>   4.89 -0.84   5.22 -0.55   6.00 -0.80 curveto
>   6.78 -1.05   8.03 -1.83   9.00 -1.53 curveto
>   9.97 -1.23  10.66  0.15  11.50  0.50 curveto
> 12.34  0.85  13.32  0.17  14.00 -0.50 curveto
> 14.68 -1.17  15.05 -1.84  16.00 -2.50 curveto
> 16.95 -3.16  18.47 -3.82  20.00 -4.49 curveto
> stroke "
> }
> 
>   \relative c''{
>    s1*5^\wave_line
> }
> 
> 
> regards
> 
> René Brandenburger
> 
> 
> Am 31.08.2021 um 12:37 schrieb Kevin Barry:
> > These changes/improvements are exciting. Thank you and Knut for the
> > hard work!
> > 
> > > > I would say that this step requires going to LilyPond 3.0,
> > > > along with
> > > > removing all the features and commands that cannot be
> > > > implemented in
> > > > the Cairo backend, or that we don't want to.
> > > 
> > > We can discuss this in detail later, but I think a major version
> > > bump
> > > is not warranted, as we're leaving the music input intact.
> > 
> > I would also have been inclined to say this suggests a major
> > version
> > bump. But if what you say is true - that input is completely
> > unchanged
> > - then it may not be necessary. Will the loss of the ps-command
> > affect
> > users?
> > 
> > Kevin
> > 
> 
> 

Re: Cairo plans

[Richard Shann]

On Wed, 2021-09-01 at 16:24 +0200, Jean Abou Samra wrote:
> Le 01/09/2021 à 15:11, Rene Brandenburger a écrit :
> > I use the \postscript a lot when typesetting contemporary music
> > e.g. 
> > like this:
> > 
> > \version "2.20.0"
> > 
> > 
> > wave_line = \markup {
> >   \with-dimensions #'(0 . 0) #'(0 . 0)
> >   \postscript #"0.3 setlinewidth 1 setlinecap [0 1]
> >  0 0 0 setrgbcolor  0.00 -3.50 moveto
> >  0.23 -3.71   0.47 -3.93   1.00 -4.00 curveto
> >  1.53 -4.07   2.36 -4.00   3.00 -3.50 curveto
> >  3.64 -3.00   4.11 -2.07   4.50 -1.46 curveto
> >  4.89 -0.84   5.22 -0.55   6.00 -0.80 curveto
> >  6.78 -1.05   8.03 -1.83   9.00 -1.53 curveto
> >  9.97 -1.23  10.66  0.15  11.50  0.50 curveto
> > 12.34  0.85  13.32  0.17  14.00 -0.50 curveto
> > 14.68 -1.17  15.05 -1.84  16.00 -2.50 curveto
> > 16.95 -3.16  18.47 -3.82  20.00 -4.49 curveto
> > stroke "
> > }
> > 
> >  \relative c''{
> >   s1*5^\wave_line
> > }
> 
> 
> This use case continues to be supported with
> Cairo. Just convert \postscript to \path, wich
> works both in the current PS backend and with Cairo.
> 
> \version "2.22.1"
> 
> wave_line = \markup {
>    \with-dimensions #'(0 . 0) #'(0 . 0)
>    \path #0.5
>  #'((moveto 0.00 -3.50)
>     (curveto 0.23 -3.71 0.47 -3.93 1.00 -4.00)
>     (curveto 1.53 -4.07 2.36 -4.00 3.00 -3.50)
>     (curveto 3.64 -3.00  4.11 -2.07 4.50 -1.46)
>     (curveto 4.89 -0.84 5.22 -0.55 6.00 -0.80)
>     (curveto 6.78 -1.05 8.03 -1.83 9.00 -1.53)
>     (curveto 9.97 -1.23  10.66 0.15 11.50 0.50)
>     (curveto 12.34  0.85  13.32 0.17 14.00 -0.50)
>     (curveto 14.68 -1.17 15.05 -1.84 16.00 -2.50)
>     (curveto 16.95 -3.16  18.47 -3.82 20.00 -4.49))
> }
> 
> { s1*5^\wave_line }
> 
> 
[...]
> 
> > Denemo uses postscript to generate a title page with a border.
> 
>  From a glance at the output of
> 
> git grep "postscript"
> 
> in the Denemo repository, that should be easy to convert
> to \path as above.

it was this paper block I had in mind specifically (though I guess
creating customized ornaments done via eps files would also fail):

\paper {
  bookTitleMarkup = \markup \when-property #'header:title {
 { \postscript #"
gsave
initmatrix
1 setlinewidth 40 40 moveto 517 0 rlineto 0 760 rlineto 
-517 0 rlineto 0 -760 rlineto  stroke
0.5 setlinewidth 45 45 moveto 507 0 rlineto 0 750 rlineto 
-507 0 rlineto 0 -750 rlineto  stroke
grestore" }
 \line { 
\hspace #-1.45 %for some reason the column is centered without this
\column {
  \when-property #'header:poet \vspace #denemo-top-margin
  \when-notproperty #'header:poet  \vspace #(+ 10 denemo-top-margin)
  \fill-line { \fontsize #8 \italic \fromproperty #'header:composer 
}
  \vspace #1
  \when-property #'header:poet  
  \fill-line { \fontsize #8 \italic \fromproperty #'header:poet 
}
  \when-property #'header:poet 
  \vspace #6
  \when-notproperty #'header:poet  \vspace #2
  \fill-line { \scale #'(4 . 4) \fromproperty #'header:title }
  \vspace #1
  \fill-line { \postscript #"-20 0 moveto 40 0 rlineto stroke" }
  \vspace #6
  \fill-line { \fontsize #5 \fromproperty #'header:date }
  \when-property #'header:date \vspace #6
  \when-property #'header:instrumentation 
  \fill-line { \fontsize #5 \italic \fromproperty 
#'header:instrumentation }
\when-property #'header:instrumentation \vspace #4
  \when-property #'header:incipit 
  \fill-line { \fontsize #5 \italic \fromproperty 
#'header:incipit }
  
  \vspace #1 
  \fill-line {
\when-property #'header:arranger \column {
  \vspace #5
  \fill-line { \fontsize #3 \fromproperty #'header:arranger }
}
  }
}
}
  }

Richard

Re: Cairo plans

[Richard Shann]

On Wed, 2021-09-01 at 17:47 +0200, Jean Abou Samra wrote:
> Le 01/09/2021 à 17:22, Richard Shann a écrit :
> > > > Denemo uses postscript to generate a title page with a border.
> > > 
> > >   From a glance at the output of
> > > 
> > > git grep "postscript"
> > > 
> > > in the Denemo repository, that should be easy to convert
> > > to \path as above.
> > 
> > it was this paper block I had in mind specifically
> 
> 
> Similarly, you can convert the \postscript call in that to
> something like this:
> 
> \markup
> \with-dimensions-from \null
> \combine
>    \translate #'(2 . -3)
>    \path #0.2
>  #'((moveto 0 0)
>     (lineto 104 0)
>     (lineto 104 -150)
>     (lineto 0 -150)
>     (closepath))
>    \translate #'(3 . -4)
>    \path #0.1
>  #'((moveto 0 0)
>     (lineto 102 0)
>     (lineto 102 -148)
>     (lineto 0 -148)
>     (closepath))
> 
Thank you! I've managed to get this working, except that the border
drawn runs off the page at right and bottom. I'm now faced with the
challenge of finding out what the page size is in staff spaces - as I
presume the \path command is speaking in staff spaces while the border
box needs to be drawn within the edges of the page ...

Richard

Re: Cairo plans

[Richard Shann]

On Thu, 2021-09-02 at 20:19 +0200, Han-Wen Nienhuys wrote:
> On Thu, Sep 2, 2021 at 4:32 PM Richard Shann  > wrote:
> 
[...]
> > I
> > presume the \path command is speaking in staff spaces while the
> > border
> > box needs to be drawn within the edges of the page ...
> 
> The standard staff size is 20pt, so 5pt to a staffspace, which is
> 1.757mm

Thank you! Previously I just hard-coded values for A4 paper but I would
like to do it properly this time. I notice (peeking in scm/paper.scm)
that there is a Scheme symbol staff-space that holds this value, but I
don't suppose there is a documented way of retrieving this value -
someone writing Lilypond by hand would not need it. In practice the
name is good enough I guess...

Richard

Crash when music of score starts with \pageBreak

[Richard Shann]

I came across a situation where LilyPond crashes caused by a badly
placed \pageBreak. I've chopped most of the music out of the example
but when I tried to remove more the crash stopped.
The error message ends:

Finding the ideal number of pages...
Fitting music on 1 page...lilypond: 
/home/gub/NewGub/gub/target/linux-64/src/lilypond-git.sv.gnu.org--lilypond.git-stable-2.22/lily/page-breaking.cc:1073:
 void Page_breaking::line_divisions_rec(vsize, const Line_division&, const 
Line_division&, Page_breaking::Line_division*): Assertion `my_index == 0' 
failed.
Exited with return code 6.

8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><

\version "2.22.1"
MI = {
  r8 e'' g''8. f''16 e''8 d''16 c'' b'4-\trill 
}

MII = { \time 2/4
 \pageBreak 
 e''8( f'') g''( f'') |
 e''( d'') c''-\trill( b'8) | 
 c''( d'') e''( f'') | 
 e''4-\trill d''4 | 
%5
 e''8 c'' g'' e'' | 
 a'' c''' b'' g'' | 
 a''4 fis''-\trill | 
 g''2 | 
 e''8( f'') g''( f'') | 
%10
 e''( d'') c''( b') | 
 c''( d'') e''( f'') | 
 e''4-\trill d''4 | 
 e''8( c'') g''( e'') | 
 a''( b'') c'''( c'') | 
%15
 d''4 b'-\trill | 
 c''2  \break \bar ":..:" e''8( f'') g''( a'') | 
 g''4 c'''8( b'') | 
 c'''( g'') a''( f'') | 
%20
 e''4-\trill d''4 | 
 e''8( d'') c''( b') | 
 c''( d'') e''( d'') | 
 d''4( c''8-\trill) b'8 | 
 a'2-\trill | 
%25
 b'8( c'') d''( e'') | 
 d''( e'') fis''( g'') | 
 b'4 a'-\trill | 
 g'2 | 
 d''8( e'') c''( e'') | 
%30
 e''( f'') d''( f'') 
}

\score {\MI} 

\score {\MII} 

8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><

I think this bug will not be in some earlier version of LilyPond as the
file is an old one that at one time compiled ok.

Richard

Re: Cairo plans

[Richard Shann]

On Thu, 2021-09-02 at 19:33 +0100, Kevin Barry wrote:
> > This use case continues to be supported with
> > Cairo. Just convert \postscript to \path, wich
> > works both in the current PS backend and with Cairo.
> 
> Is this something that can be done automatically with convert-ly?

No, the suggestion is limited to cases where \postscript is just
introducing some \path commands, and even then the units are absolute
not staff-size relative.

Richard

Re: Cairo plans

[Richard Shann]

On Fri, 2021-09-03 at 09:15 +0100, Richard Shann wrote:
> On Thu, 2021-09-02 at 20:19 +0200, Han-Wen Nienhuys wrote:
> > On Thu, Sep 2, 2021 at 4:32 PM Richard Shann  > om
> > > wrote:
> 
> [...]
> > > I
> > > presume the \path command is speaking in staff spaces while the
> > > border
> > > box needs to be drawn within the edges of the page ...
> > 
> > The standard staff size is 20pt, so 5pt to a staffspace, which is
> > 1.757mm
> 
> Thank you! Previously I just hard-coded values for A4 paper but I
> would
> like to do it properly this time. I notice (peeking in scm/paper.scm)
> that there is a Scheme symbol staff-space that holds this value, but
> I
> don't suppose there is a documented way of retrieving this value -
> someone writing Lilypond by hand would not need it. In practice the
> name is good enough I guess...

No sooner have I written that than I found a heap of documentation
("internals") in which was:

 staff-space (dimension, in staff space)

Amount of space between staff lines, expressed in global staff-
space. 

Not that this makes much sense -  dimension, in staff space ... staff-
space expressed in global staff-space? 

Richard

Changed behavior 2.18.0 to 2.22.1

[Richard Shann]

The following

\version "2.18.0"
{  g'4 f' g'  \mark \default}

compiles ok while

\version "2.22.1"
{  g'4 f' g'  \mark \default}

reports

Starting lilypond 2.22.1 [test22.ly]...
Processing `/tmp/frescobaldi-uljzgf6d/tmpzpa94ikr/test22.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
warning: Found infinity or nan in output.  Substituting 0.0
warning: Found infinity or nan in output.  Substituting 0.0
warning: Found infinity or nan in output.  Substituting 0.0
warning: Found infinity or nan in output.  Substituting 0.0
warning: Found infinity or nan in output.  Substituting 0.0

and the output has no staff lines.

This is just something I noticed, not of any direct importance to me,
but thought you might like to know. I checked convert-ly does not alter
the file.

Richard

Simultaneous \key markings behave differently to \clef or \time.

[Richard Shann]

I've noticed that two \key in succession results in the first being
honored while the opposite is true for everything else I've tested.
Consider:
8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><
\version "2.22.0"

{
  \time 3/4 \time 5/4 c''
}
{
  \clef bass  \clef alto c''
}
{
  c'' \bar "||" \bar ":..:"
}
{
  \key f \major \key d \major c''
}
8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><

Not a problem except when using include files or (as in my case
generating the code programmatically.

Is there a good reason for this, or is it just a wrinkle that could be
fixed?

Richard Shann

Re: Simultaneous \key markings behave differently to \clef or \time.

[Richard Shann]

On Tue, 2022-06-28 at 16:45 +0200, Jean Abou Samra wrote:
> Le 28/06/2022 à 13:36, Richard Shann a écrit :
> > I've noticed that two \key in succession results in the first being
> > honored while the opposite is true for everything else I've tested.
> > Consider:
> > 8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><
> > \version "2.22.0"
> > 
> > {
> >    \time 3/4 \time 5/4 c''
> > }
> > {
> >    \clef bass  \clef alto c''
> > }
> > {
> >    c'' \bar "||" \bar ":..:"
> > }
> > {
> >    \key f \major \key d \major c''
> > }
> > 8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><
> > 
> > Not a problem except when using include files or (as in my case
> > generating the code programmatically.
> > 
> > Is there a good reason for this, or is it just a wrinkle that could
> > be
> > fixed?
> 
> Hi,
> 
> Could you elaborate on your actual problem? 
Well, that's not going to be easy or helpful - it has more to do with
the 20 year history of Denemo than anything else - Denemo gives a
special status to the initial key. 

> I don't immediately se
> why you would want to generate code that has simultaneous key changes
> like this. Similarly, I don't understand the problem with include
> files.

This was just a speculation of my part: if someone had a template file
for a symphony in Dmin and put the opening preamble about clefs and key
in an include file and then had one movement in Dmaj they might want to
override what was in the include file. But I can imagine this is pretty
far fetched as no one has complained about the inconsistency before
(?).

> 
> The wrinkle is actually on the side of \time, \clef and \bar.
> Most stuff warns on duplicated events and accepts the first
> (except if they are exactly the same, which masks this for the
> user in many cases):
> 
> { c'\p\f }
> { \mark "A" \mark "B" c' }
> { \tempo "A" \tempo "B" c' }
> { \tempo 4 = 120 \tempo 4 = 90 c' }
> {
>    c'\tweak bound-details.left.text "rit" \startTextSpan
>  \tweak bound-details.left.text "rall" \startTextSpan
>    c'\stopTextSpan
> }
> 
> The reason \time and \clef don't do this is that they are
> implemented in a peculiar way. They don't use events but
> set context properties. That allows them to work in \with
> and \layout { \context { ... } }. (I have some vague plans
> to allow events to work there, which would allow to make
> \time and \clef more usual.) In the case of \bar, it just
> appears to be a little less convenient than elsewhere due
> to the way it works internally, and therefore not done.
> 
> Personally, I think warning and rejecting the second event
> is a good idea. There are cases where might hope that you'd
> be able to combine those events (like with \mark and \startTextSpan).
> Duplicated events are the result of either a user error, or
> a hope from the user that LilyPond will not be able to fulfill.
> Either way, a warning is helpful.

Well, I guess I should go forward on the assumption that the behavior
may change in the future and try and ensure duplicates are not
emitted...

Thanks for the reply,

Richard