Doc: NR 2.2.1 keyboards, staff changes

Friends of LilyPond, I am suggesting a new @knownissues for the Notation Reference 2.2.1. The corresponding bug tracker issues are 1043, 439, and 36. If issue 1043 is solved, the second paragraph of my suggestion will become obsolete. I wrote the text below based on observed behavior of Lil

Docs, keyboards, staff changes, workaround

Friends of LilyPond, I am suggesting a new @knownissues for the Notation Reference 2.2.1. The corresponding bug tracker issues are 1043, 439, and 36. If issue 1043 is solved, the second paragraph of my suggestion would be come obsolete. I wrote the text below based on observed behavior of

Re: NR 2.2.1 keyboards, staff changes

On Mon, 20 Sep 2010 08:09:42 -0700, Trevor Daniels wrote: Although this would seem to be a valuable addition to the Notation Reference, the policy is not to add bugs which are in the bug tracker to @knownissues. [...] as they would need to be removed as soon as they were fixed, often within

docs addition, beaming cadenzas

Dear documentation editors, In the existing @knownissues for cadenzaOn, I suggest adding one sentence (in context below) encouraging manual beams. Users might *think* autobeaming works through cadenzas, and it does for a while, but it will not through longer cadenzas. There is a related lo

Re: anybody understand the instrumentCueName docs?

On mailing list lilypond-user, Trevor Daniels wrote: Keith E OHara wrote Wednesday, October 06, 2010 9:40 AM I no longer see any reason to use instrumentCueName for the labels that identify the instrument playing cue notes. OK. I'll see what you suggest. I suggest (diff att

Re: anybody understand the instrumentCueName docs?

On Mon, 18 Oct 2010 15:40:54 -0700, Keith E OHara wrote: Corresponding suggestions for vocal.itely will follow shortly. One thing worth discussing is that I use the verb "to cue" differently from the original author. I believe that to cue is to *give* a signal for someone els

Re: anybody understand the instrumentCueName docs?

On Tue, 19 Oct 2010 00:33:25 -0700, James wrote: Sorry for jumping in here, I have read the thread prior to this and while I agree the Cue Notes section is sketchy, I am not sure how this is an improvement and this seems more complicated. What are we achieving here? Thank you for jumping in

Re: anybody understand the instrumentCueName docs?

On Tue, 19 Oct 2010 13:34:05 -0700, Trevor Daniels wrote: If no one objects soon I shall push it. James Lowe made comments that you might not have seen yet. I see where he is coming from, but I hope my answer explained the purpose of the changes well enough. (For future reference, please

Re: non-technical help for spacing issues

On Tue, 26 Oct 2010 05:12:16 -0700, wrote: On Tue, 26 Oct 2010 00:47:01 -0700, Graham wrote: This is directed at people saying "I can't do anything to help..." You sent this to -devel; did you intend -user ? Basically, just try compiling your scores (and any problematic scores reported by u

Re: non-technical help for spacing issues

On Wed, 27 Oct 2010 00:24:33 -0700, Graham Percival wrote: On Tue, Oct 26, 2010 at 01:23:01PM -0700, Keith E OHara wrote: However, I have no familiarity with how vocal music is supposed to look, and I tend to avoid tweaks myself. Graham's request seems quite easy for a few peop

Re: Doc: NR 4.4.1: Rewrite. (issue2642043)

On Fri, 29 Oct 2010 01:17:00 -0700, Ian Hulin wrote: On 29/10/10 05:12, Keith wrote: Documentation/notation/spacing.itely:1513: * Inter-system spacing properties:: Within-system You said: inter = between, intra = within [...] or do you mean the original "Inter-system spacing" should have re

Re: non-technical help for spacing issues

On Thu, 28 Oct 2010 05:13:03 -0700, wrote: There is now a small set of over-rides is posted on -user, vertical spacing only so far, hopefully to be tried out by others over the weekend : On one thing might surprise -dev

Re: renaming "vertical spacing inside systems" props

On Fri, 29 Oct 2010 21:04:06 -0700, wrote: Mark Polesky wrote Friday, October 29, 2010 11:27 PM I've thought about it, and I think I slightly favor the term "loose line" over "non-staff line" [...] Also loose-staff-spacing sounds too much like something that gives staves a loose spacing (

Re: non-technical help for spacing issues

On Wed, 27 Oct 2010 00:24:33 -0700, Graham Percival wrote: >On Tue, 26 Oct 2010 00:47:01 -0700, Graham wrote: >This is directed at people saying "I can't do anything to help..." > I need a committing, not necessarily committed, partner to close this. I attach a patch corresponding to the st

Re: renaming "vertical spacing inside systems" props

On Sat, 06 Nov 2010 18:20:08 -0700, wrote: Renaming proposals, round 4: CURRENT NAME PROPOSED NAME - next-staff staff-staff default-next-staff default-staff-staff inter-staffnonstaff-relatedstaff inter-loose-line nonstaff-nonstaff non-affin

Re: renaming "vertical spacing inside systems" props

On Sat, 06 Nov 2010 20:08:06 -0700, Mark Polesky wrote: Keith E OHara wrote: I had imagined you would simultaneously change staff-affinity (UP / DOWN / CENTER) toreference-direction (UP / DOWN / CENTER) so we can remember that this direction tells us which staff is which between

Re: non-technical help for spacing issues

On Sun, 07 Nov 2010 01:58:58 -0700, Trevor Daniels wrote: Keith E OHara wrote Sunday, November 07, 2010 1:19 AM 2a) Lyrics get less space in the new system, but all the choral-music folk seem to want is a but a touch more padding from Lyrics to any non-associated grobs on the next staff

Re: renaming "vertical spacing inside systems" props

On Sun, 07 Nov 2010 07:57:33 -0800, Mark Polesky wrote: Can we have one last vote among these two choices? 1) within-group-staff-staff-spacing 2) withingroup-staff-staff-spacing Keith: either Both are usable. We will use this in context that makes that first qualifier almost redundant :

Re: renaming "vertical spacing inside systems" props

On Mon, 08 Nov 2010 11:14:11 -0800, Mark Polesky wrote: Similarly, I think the two 'staff-staff-spacing properties would be intuitive and easy enough to keep separate, mentally: % space between consecutive staves in a system \override VerticalAxisGroup #'staff-staff-spacing % space bet

Re: PATCH: applied default spacing rules provided by Keith O Hara

On Fri, 12 Nov 2010 09:00:02 -0800, wrote: On Fri, Nov 12, 2010 at 7:04 AM, Reinhold Kainhofer What I don't really understand why the stretchability [...] in staves/scores contexts seems to have a completely different unit than the stretchability defined in the \paper block. I used to be

Re: manual convert-ly: minimum-Y-extent (1298+1299). (issue3212041)

On Fri, 19 Nov 2010 09:00:02 -0800, wrote: Keith: ok, I'll produce a git patch for this, but could you try following the instructions here:http://lilypond.org/doc/v2.13/Documentation/contributor/using-lily_002dgit The instructions for using lily-git.tcl worked just fine for me, even on Wind

Re: 2.13.40 regtests

On Sun, 28 Nov 2010 21:10:03 -0800, Graham Percival wrote: les-nerides: this is definitely an improvement. I'm surprised to see that the old version involved a collision between fingering and a slur in different staves, though! (end of bar 2) Could somebody look into whether this is a known bu

version 2.18 versus 2.16

While testing the tempo-marks patch, I compiled an orchestral score using both version 2.16 and current, which is probably close to what 2.18 will be. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://li

tracking down a crash

I was getting crashes while testing the page-layout changes on a big set of files, which went away when I set just one input file. It will take a while before I narrow it down to a small example. I can reproduce by taking + running

Re: tracking down a crash

On Wed, 20 Nov 2013 23:48:47 -0800, David Kastrup wrote: So one suspicion would be that iter_ points to a non-operative iterator. Maybe set it to zero in Sequential_iterator::do_quit () That change, on master, did not clear the crash. release/2.18 gives good output on

Re: tracking down a crash

On Fri, 22 Nov 2013 01:32:19 -0800, David Kastrup wrote: Argh. How about this one (should likely apply using git am): That clears the crash, resolves the problem with extra barlines, and leaves no similar problems in my test case so far as I can see. __

order of layout operations, and \shapeII

There have been a couple bug-reports (3669 3677) coming from users wanting to access LilyPond's layout decisions, in order to adjust those decisions. The surprises come from LilyPond being at an intermediate stage in the decision-making process when the user function is activated. Issue 3677 i

updated doc snippets on LSR

Two snippets used a function make-simple-closure. No-one understands the purpose of that function anymore, so we stopped recommending it in the docs with issue 3993. I re-entered these two snippets in form that avoids make-simple closure http://lsr.di.unimi.it/LSR/Item?id=948 http://lsr.di.uni

compiling on Debian on an ARMv7

I getting used to the BeagleBone Black, so I though I'd try compiling Lilypond. It runs Debian, but on an ARM. LilyPond hasn't provided a precompiled binary for ARM for a decade. Similar to what Trevor found, http://lists.gnu.org/archive/html/lilypond-devel/2014-02/msg00212.html setting up on De