Re: some tiny care for the Sponsoring page

Federico Bruni writes: > During a recent discussion I suggested few ideas to make the > sponsoring page more visible: > https://lists.gnu.org/archive/html/lilypond-devel/2015-10/msg00131.html > > But after reading this old thread: >

Re: Assertion failed

Andrew Bernard writes: > Using 2.19.30, hoping to avoid the core dumps from 2.19.29, I get the > following error on my moderately large score: > > Preprocessing graphical objects...lilypond: >

Re: MelismaEvent?

On 27.10.2015 14:08, Simon Albrecht wrote: On 27.10.2015 14:00, Simon Albrecht wrote: On 27.10.2015 02:04, Thomas Morley wrote: 2015-10-27 0:00 GMT+01:00 Simon Albrecht : Hello, I’ve taken the liberty of creating

Re: MelismaEvent?

On 27.10.2015 02:04, Thomas Morley wrote: 2015-10-27 0:00 GMT+01:00 Simon Albrecht : Hello, I’ve taken the liberty of creating , but I’m not quite sure if it will be agreed to be a valid request. Please give your

Re: MelismaEvent?

On 27.10.2015 14:00, Simon Albrecht wrote: On 27.10.2015 02:04, Thomas Morley wrote: 2015-10-27 0:00 GMT+01:00 Simon Albrecht : Hello, I’ve taken the liberty of creating , but I’m not quite sure if it will be

Re: some tiny care for the Sponsoring page

Il giorno mar 27 ott 2015 alle 9:00, David Kastrup ha scritto: - Sponsoring page: update the statistics (reminder for Phil), see: https://sourceforge.net/p/testlilyissues/issues/2086/ Well, some basics would certainly not be amiss, yes. I'm not overly enthused about these

Re: some tiny care for the Sponsoring page

On Tue, Oct 27, 2015 at 09:00:48AM +0100, David Kastrup wrote: > There has been an offer by the FSF to collect and disburse donations for > LilyPond. They are taking a 10% cut if I remember correctly, but it > would allow credit card processing, donation buttons and some other > fairly standard

three small bugs

Hello, I would like to report three small bugs I found: - no. 1: when two parts contain manual beams and slurs at the same point and one uses \partcombine, some warnings are outputs in the console: "unterminated beam" and "unterminated slur". It does output the music correctly though. I

[2.19.30] Segmentation fault

Hi there, I got a segmentation fault using lilypond version 2.19.30 and thought you might want to take a look into it. Included is the gdb backtrace and here is a temporary link to the core dump if you're interested. http://bylight.net/Yfo05iTgmf Thanks -- Pierre-Luc Gauthier

Re: [2.19.30] Segmentation fault

Pierre-Luc Gauthier writes: > Hi there, > > I got a segmentation fault using lilypond version 2.19.30 and thought > you might want to take a look into it. > > Included is the gdb backtrace and here is a temporary link to the core > dump if you're interested. That looks

Re: Bad clef change collision when alternating piano staves

Oops, sorry, too fast reading... How about : \version "2.19.22" \new PianoStaff << \new Staff = "RH" \relative a' { \clef treble a8 \change Staff = "LH" \clef treble a_1 \change Staff = "RH" a \change Staff = "LH" \tweak X-extent

Bad clef change collision when alternating piano staves

Hello all, I believe there is a bug in making space for clef changes. You can find the MWE here: http://lilybin.com/gs2oks/7 The notes labeled 1 and 2 on the lower LH staff are both notated in treble clef. But because space wasn't made for the bass clef change, the bass clef misleadingly appears

Re: Bad clef change collision when alternating piano staves

Hi Ophir, Try : \once\override Staff.Clef.X-extent = #'(0 . 3.5) \clef bass Cheers, ~Pierre 2015-10-27 22:05 GMT+01:00 Ophir Lifshitz : > Hello all, > > I believe there is a bug in making space for clef changes. You can find the > MWE here:

Re: Bad clef change collision when alternating piano staves

And so in that case, probably something like \hideNotes r ... \unHideNotes will be sufficient. Ophir On Tue, Oct 27, 2015 at 6:10 PM, Ophir Lifshitz wrote: > Hello again, > > Yes, thank you Pierre. I believe that will work temporarily, but I'm still > mostly

Re: Bad clef change collision when alternating piano staves

Hi Pierre, I'm afraid that override only makes the issue worse by shifting the clef left. I might have been unclear, but the clef change belongs after note 2 and directly before the sharped note 3, and not in the small space between notes 1 and 2. Shifting it left makes it look like note 2 is

Re: Bad clef change collision when alternating piano staves

Hello again, Yes, thank you Pierre. I believe that will work temporarily, but I'm still mostly convinced it's a bug that needs to be fixed. For example, change the space s4. near the bottom of the file between three eighth rests r r r (clef change is – mostly – properly spaced) and two rests