Re: Issue 1298 in lilypond: minimum-Y-extent might be obsolete?
On Thu, Nov 18, 2010 at 5:58 AM, Keith E OHara k-ohara5...@oco.net wrote: One affected item is a Snippet. Fortunately, the modified snippet complies the same under stable and development versions, so I put it right away in the LSR. Thanks, I've updated the snippet. I'll need to do an LSR tarball update soon. Cheers, Valentin. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 1412 in lilypond: programming error: Going back in MIDI time
Status: Accepted
Owner:
Labels: Type-Other
New issue 1412 by RalphBugList: programming error: Going back in MIDI time
http://code.google.com/p/lilypond/issues/detail?id=1412
MIDIback.ly
\version 2.13.35
music = \new Staff {
\tempo 4 = 120
\time 2/4
\set Staff.midiInstrument = church organ
\key a \minor
\relative c'' {
\acciaccatura gis'8 a4 e8. d16 |
}
}
\score {
\music
\layout {}
}
\score {
\music
\midi {}
}
---
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1333 in lilypond: Enhancement: beamed acciaccaturas should be printed with a slash
Comment #2 on issue 1333 by x.scheuer: Enhancement: beamed acciaccaturas should be printed with a slash http://code.google.com/p/lilypond/issues/detail?id=1333 Hi! I just wanted to make sure that slashed beamed acciaccaturas won't become the default behaviour. I hope this would require a \set slashedBeamedAcciaccatura = ##t % default is ##f or something like that to be activated. I did not find such mechanism in your patch but as I already mentioned: I am not a programmer. Cheers, Xavier ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: programming error: Going back in MIDI time
On 18 Nov 2010, at 12:37, Ralph Palmer wrote: Thanks for your report. This has been accepted as Issue 1412 : http://code.google.com/p/lilypond/issues/detail?id=1412 Fine. Pondly (as Valentin would say), Pond-lily Yours, Hans ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1055 in lilypond: guile 2.0
Comment #19 on issue 1055 by ianhuli...@gmail.com: guile 2.0
http://code.google.com/p/lilypond/issues/detail?id=1055
Another thing to think of when we move to Guile 2.0. At the moment we have
been relying in on Guile AUTOCOMPILE to create .go files on-the-fly in a
private Guile directory.
This means that we are compiling scm/*.scm files as and when they are
referenced in lily.scm. Guile itself compiles its scm files as part of its
build using
guile-tools compile. There is an interface for this nin the Guile
repl ,compile-file, but there is currently nothing we can call from within
a .scm file, so we can't tweak ly:load or write a similar procedure to do
the compile the .go for us dynamically if it doesn't already exist,
If we do need to compile .scm files during the build }}shudder{{, where
would be write the .go files, out/scm? I.e. scm/lily-library.scm compiles
to out/scm/lily-library.go, or would we do as the guile build does and put
the .go files into the source directory scm/lily-library.scm -
scm/lily-library.go?
I'm thinking about this as we already need to revise the load order to fix
T1349.
Cheers
Ian
Cheers,
Ian
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1333 in lilypond: Enhancement: beamed acciaccaturas should be printed with a slash
lilyp...@googlecode.com writes: Comment #2 on issue 1333 by x.scheuer: Enhancement: beamed acciaccaturas should be printed with a slash http://code.google.com/p/lilypond/issues/detail?id=1333 Hi! I just wanted to make sure that slashed beamed acciaccaturas won't become the default behaviour. I hope this would require a \set slashedBeamedAcciaccatura = ##t % default is ##f or something like that to be activated. Why? There is no sense to use the same notation as an appoggiatura by default since both duration and onset of the two are different. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1333 in lilypond: Enhancement: beamed acciaccaturas should be printed with a slash
Comment #3 on issue 1333 by v.villenave: Enhancement: beamed acciaccaturas should be printed with a slash http://code.google.com/p/lilypond/issues/detail?id=1333 Hi Xavier, it already exists, only it's called \appoggiatura :-) ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
lilypond-book 2.39 fails on Windows not on Mac
Hi, The following lytex file fails on Windows but not on Mac. The errors i noticed were: 1) Running lilypond...GNU LilyPond 2.13.39 programming error: file name not normalized: C:\\Users\\Marc\\Documents\\tmpdir\\snippet-names--213547792.ly 2) Missing set(['ec/lily-5e700a3e.txt', 'ec/lily-5e700a3e.ly', 'ec/lily-5e700a3e-systems.count']) Removing `C:\Users\Marc\Documents\lilypond.tex' Note that the files ec/lily-5e700a3e.* exist in the tempDir lilypond.lytex Description: Binary data -Marc___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: imperfect convert-ly rules
On Thu, 18 Nov 2010 12:40:08 -0800, Neil Puttock n.putt...@gmail.com wrote: On 18 November 2010 06:21, Keith E OHara k-ohara5...@oco.net wrote: The attached text contains replacement rules for that section that have been working for me. I'm afraid these changes are too naïve, Keith. But I *like* being naive, Neil. The ugly truth is the units for vertical spacing changed from mm to staff spaces. The current convert-ly rule also fails to convert to the new units, in cases where units are not specified, which is the subset of cases that it catches. My request is that between-system-padding = 5\mm be converted to system-system-spacing #'padding = 5\mm Having convert-ly preserve my *intentions* about request space, while converting to the new syntax, is useful, although not perfect. Now that you have opened my eyes, I want more! Let's also change paper-defaults-init.ly so that \mm really means millimetres : mm = #(/ 1.0 staff-space) in = #(* 25.4 mm) ... or something like that. I remain naive about what staff-space, ly:unit, and output-scale actually mean. -Keith ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Point-and-Click URIs not properly formed (see text at end of message)
On Wed, Nov 17, 2010 at 12:26 PM, Mike Bagneski bagneskim...@gmail.com wrote: On Wed, Nov 17, 2010 at 12:21 PM, Patrick McCarty pnor...@gmail.com wrote: On Wed, Nov 17, 2010 at 9:13 AM, Mike Bagneski bagneskim...@gmail.com wrote: Using Lilypad 2.12.3, PDF files generated using command: lilypond -dpoint-and-click filename results in URIs in the form: /home/mb/lilypond/string:6:6:12 Everything looks okay, except the actual file name. In its place is input. Hmm, that's quite odd. :) Can you send me a .ly file that I can test? I can't reproduce this on my end... Here you go. Hope you spot something. Hi Mike, Thanks for sending this. Just so everyone else knows, Mike sent me the file off-list. I can indeed reproduce the issue. I'm seeing URIs like /path/to/string:row:col:offset, which is not good. You make extensive use of music functions in your file, so I'm guessing that might be causing the URI corruption... I can't look too closely at this right now, but can you submit a smaller example that has the same problem? If not, I will try to extract a snippet small enough from your example when I have the time so that I can file a tracker issue. Thanks, Patrick ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1055 in lilypond: guile 2.0
Comment #20 on issue 1055 by pnorcks: guile 2.0 http://code.google.com/p/lilypond/issues/detail?id=1055 Ian, I think we should consider compiling .scm files as part of the build process, since it is unsightly (to say the least) to watch Guile autocompile LilyPond's .scm files. When we are closer to full compatibility with Guile 2.0 (if we can), then we can look into this. Regarding the output dir, I would think the .go files should be in out/scm, or possibly in scm/out with a out/scm being a symlink to this directory. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Tie like a slur
On Wed, Nov 17, 2010 at 10:33 AM, Phil Holmes m...@philholmes.net wrote:
Patrick McCarty pnor...@gmail.com wrote:
On Wed, Nov 17, 2010 at 9:43 AM, Phil Holmes m...@philholmes.net wrote:
I've been setting some music with something like the following:
\new Staff {
\time 6/8
\clef treble
a''8 a''8 a''8 a''8 a''8 a''8
}
\new Staff {
\time 6/8
\clef bass
\voiceOne
a c' f'4. ~ b c' e'4.
}
Lily sets this as shown in the attached image - to my eyes this looks more
like a slur than a tie. Bug? Issue 139?
Looks like a bug.
It could be issue 139, or maybe issue 962.
http://code.google.com/p/lilypond/issues/detail?id=962
I reckon it's 139, since it's a tie outside a chord, rather than one inside
a chord.
Thanks for pointing that out. I think 139 is more likely then.
Looking at the bug list, though, it would seem that tie placement
could do with a review in the next full release. I'm tempted to push 139
to high, and add this, since it's real world and very confusing with
standard musical notation.
Looking at the tracker issue, I see its priority has changed from
Low-Medium, and then from Medium-Low. But this was four years ago,
too.
I think it's a great idea to add your example to the tracker, but I
don't know if changing the priority is going to give it that much more
attention. However, this is just my perspective on things.
Thanks,
Patrick
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: imperfect convert-ly rules
On Thu, 18 Nov 2010 14:15:49 -0800, Keith E OHara wrote:
Let's also change paper-defaults-init.ly so that \mm really means millimetres :
mm = #(/ 1.0 staff-space)
Gosh, no. That was a mistake, because 'indent' and 'top-margin' and such
things are still entered in mm (quite sensibly). The current definitions of
mm, in, etc., need to stay as they are, for use with these variables.
My request is that
between-system-padding = 5\mm
be converted to
system-system-spacing #'padding = 5\mm
I take that back as well. I don't actually *want* to express these spaces in
mm; I was only following the old manual.
Now I see the value in a non-naive conversion that would produce something like
:
between-system-padding = 5\mm
system-system-spacing #'padding = #(/ between-system-padding staff-space)
If this gets into the tracker, the extension below of Neil's example would be a
good test-case. If we can fix the spurious warnings about minimum-Y-extent at
the same time, then the snippet below should convert-ly with no error messages.
--8--
\version 2.13.9
\paper {
between-system-padding = 10\mm
between-system-space = 0
}
\score {
\relative c'' {
c1 \break
c1
}
\layout { \context { \Lyrics
\override LyricText #'minimum-Y-extent = #'(-1 . 2)
}}}
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
staff-staff padding all appears after the last nonstaff
Fellow bug-chasers,
In the new rod-and-spring vertical spacing system, rods sometimes appear in
surprising places.
If we have two staves on either side of a non-staff, such as Dynamics or
Lyrics, the new system ensures that the requested padding between staves
appears as a clearance below the last of the non-staff lines. Also, any
staff-staff minimum-distance in excess of that required to avoid collisions, is
placed below the lowest intervening non-staff.
The intention, I think, was to let whichever requires the most room --
intervening non-staffs, padding between notes on the staves themselves, or
minimum-distance between staves -- determine the staff spacing. Then the
non-staff lines should be spaced between the staves according to the options
such as UP/DOWN/CENTER that we chose for them.
The override in this example makes the issue more obvious. With no overrides
we notice only that the centered dynamics are not quite centered, but a little
high because the default staff-staff padding of 1 staff-space is placed below
the dynamics.
-Keith
--8--
\version 2.13.39
\new PianoStaff \with {
\override StaffGrouper #'staff-staff-spacing #'minimum-distance = #12
}
{g' b b g'}
\new Dynamics { s\ s\ s s\!}
{d'' b'' b'' d''}
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1298 in lilypond: minimum-Y-extent might be obsolete?
Comment #13 on issue 1298 by percival.music.ca: minimum-Y-extent might be obsolete? http://code.google.com/p/lilypond/issues/detail?id=1298 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 Windows is supported, and it should be fairly painless to get things working. If there _are_ some problems with these instructions, then I'd like to find out before we begin the next contributor recruitment drive. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1311 in lilypond: New spacing code affects user-created pseudo-staff contexts
Comment #5 on issue 1311 by k-ohara5...@oco.net: New spacing code affects user-created pseudo-staff contexts http://code.google.com/p/lilypond/issues/detail?id=1311 In the full example attached to this issue, the LyricStaff did nothing. It had no \accepts Lyrics, so 2.12 placed the Lyrics below the LyricStaff and then made LyricStaff silently disappear. Hard to see how convert-ly could have helped in this case. That example does produce a 'vertical spacing has changed' NOT_SMART message, due to the use of minimum-Y-extent to try to change staff-like spacing, but this was directed toward a ChordNames not the LyricStaff. That warning will help some users. Would it be wise to suggest one consider staff-affinity wherever convert-ly sees \type Engraver_Group? The only Engraver_Group defined in the .ly files at mutopiaproject.org is Dynamics, which is auto-converted. Can anyone estimate whether such a message would cause more enlightenment than confusion? ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1298 in lilypond: minimum-Y-extent might be obsolete?
Comment #14 on issue 1298 by percival.music.ca: minimum-Y-extent might be obsolete? http://code.google.com/p/lilypond/issues/detail?id=1298 Patch now online: http://codereview.appspot.com/3212041/ ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1299 in lilypond: ly/gregorian.ly needs minimum-Y-extent updated
Comment #3 on issue 1299 by percival.music.ca: ly/gregorian.ly needs minimum-Y-extent updated http://code.google.com/p/lilypond/issues/detail?id=1299 This patch has been included in the one for issue 1298. http://codereview.appspot.com/3212041/ ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 1413 in lilypond: add ly_display_scm to CG
Status: Accepted Owner: Labels: Type-Other Priority-Medium Frog Maintainability New issue 1413 by percival.music.ca: add ly_display_scm to CG http://code.google.com/p/lilypond/issues/detail?id=1413 Good beginning patch for a new frog: http://lists.gnu.org/archive/html/lilypond-devel/2010-11/msg00382.html ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
