On 21 July 2011 19:27, wrote:
> Really? The NR (section 5.3.6 "Modifying alists" as well as 4.4.1
> "Flexible vertical spacing within systems") only gives examples of the
> form #'staff-staff-spacing #'basic-distance... I didn't even know that
> the list syntax was there, let alone that it is th
On 20 July 2011 16:36, m...@apollinemike.com wrote:
> I'm starting to doubt the viability of my local build...the regtests went off
> without a hitch.
I wouldn't worry about that. Uninitialized members often work fine;
it might depend on your architecture.
> I'll look into emending the pure h
On 14 July 2011 15:59, wrote:
> LGTM.
>
> Careful thinking about how to handle this. Great job, Neil!
Thanks. It took several drafts before I was happy with the explanation. :)
(pushed: bebd93c2dd0d7363f311d912ec1ed1f7dfcb36ba)
Cheers,
Neil
___
li
On 19 July 2011 09:10, m...@apollinemike.com wrote:
> After making several round-trips around the source this morning, I can't put
> off composition any longer, but I fear that all I will compose today are
> songs about the Axis_group_interface if I don't understand how this works.
> I believe
2011/7/18 Janek Warchoł :
> My friend and I, having some spare time, wanted to fix a bug
> http://code.google.com/p/lilypond/issues/detail?id=1301. It's related
> to planning distribution of music notes and other signs, so we need
> some overview how the whole process works. Comments in the sour
2011/7/18 Janek Warchoł :
> Btw,
>
>> [/home/jlowe/lilypond-git/build/out/share/lilypond/current/scm/document-markup.scm]
>> Writing "internals.texi"...ERROR: In procedure procedure-name:
>> ERROR: Wrong type argument in position 1: #f
>> make[1]: *** [out/internals.texi] Error 1
>> rm out/weblink
On 18 July 2011 22:00, wrote:
> Ok I tried
>
> \relative c' {
> >
>> 1 } for myself and it works but I get two indicators and two footnotes
>
> on each note inside the chord. So is this a special case? If so then I
> can add a snippet or another @lilypond to illustrate this.
See the documentat
2011/7/18 Neil Puttock :
> No, the problem is that the code doesn't account for differences in
> font-size between heads; all the hard-coded shifts it calculates
> (split equally between heads; heads move away from each other by the
> same amount) are based on the assumption t
2011/7/18 Janek Warchoł :
> i don't see anything called "stencil-width" in grob.cc...
78 if (get_property_data ("X-extent") == SCM_EOL)
79 set_property ("X-extent", Grob::stencil_width_proc);
The C++ name is Grob::stencil_width; the addition of _proc uses the
exported scheme version.
> I
2011/7/17 Janek Warchoł :
> I've searched in note-head.cc, note-column.cc, note-heads-engraver.cc
> but found nothing...
You don't need to know this (though if you're curious, any grob
without a default is set to ly:grob::stencil-width; see the
constructor in grob.cc).
If you want to know the ext
On 15 July 2011 23:00, Neil Puttock wrote:
> Axis_group_interface::add_element () sets the DynamicLineSpanner as
> X-parent (depends on 'axes setting).
This should read `as Y-parent'.
___
lilypond-devel mailing list
lilypond-dev
On 15 July 2011 18:28, wrote:
> I've now gone on a quest for parental loops in the source, and I've found
> some:
>
> chord-repetition.ly
> chord-tremolo-articulations.ly
> dynamics-alignment-breaker.ly
> dynamics-alignment-no-line.ly
> dynamics-glyphs.ly
> dynamics-line.ly
> dynamics-rest-posit
On 14 July 2011 21:01, m...@apollinemike.com wrote:
> I'll run the regtests tonight or tomorrow and report back.
I've just tried this and I think you've got an infinite loop somewhere
(I had to kill the process and reboot).
Edit: it's from tie-pitched-trill.ly; segfaults due to stack overflow.
On 13 July 2011 21:03, Neil Puttock wrote:
> On 13 July 2011 20:51, m...@apollinemike.com wrote:
>
>> Was I too narrow in my original fix? I can work on something cleaner to
>> address the segfault that doesn't lead to cyclical dependencies so that this
>> doesn
On 13 July 2011 20:51, m...@apollinemike.com wrote:
> Was I too narrow in my original fix? I can work on something cleaner to
> address the segfault that doesn't lead to cyclical dependencies so that this
> doesn't perturb future generations of regtests.
That would be great.
BTW, like James,
On 13 July 2011 11:22, m...@apollinemike.com wrote:
> You're right - they would have been the same. I think this error may have
> been introduced in a recent patch, in which case it is a regression. I'd
> have to run git-bisect to figure it out, though, but all of my CPU is being
> eaten up
2011/7/11 Janek Warchoł :
> Sorry, i didn't notice.
> Attached is a nicely described patch.
Thanks, pushed to master.
Cheers,
Neil
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
2011/7/11 Janek Warchoł :
> 2011/7/11 Graham Breed :
>> Is that me? I'm supposed to do something? Here's a patch
>
> Perfect!
>
> Mike: please push this.
Please don't push without adding a commit message.
Thanks,
Neil
___
lilypond-devel mailing list
On 10 July 2011 23:34, Carl Sorensen wrote:
> Ahh, thanks. Fixed now:
>
> {
> \new Voice \with {
> \consists Ambitus_engraver
> \consists Mensural_ligature_engraver
Heh, you didn't have to do this; I meant the missing quotation marks
around the engraver names. :)
(and now you've added
On 7 July 2011 23:22, wrote:
> On 2011/07/07 16:12:08, Neil Puttock wrote:
>>
>> LGTM, though the regtest is still a bit messy.
>
> What do you consider messy about the regtest?
Just a few nitpicks:
+\score{
+ \context Staff="default" {
+ \context{
+ \consis
On 8 July 2011 04:37, Carl Sorensen wrote:
> The grob has everything that is necessary to create the printed output. You
> can't apply a music function to a grob, but you can apply a scheme function
> to the music contents of the grob. So rather than translate the chord (a
> music event), you'l
On 8 July 2011 21:09, David Nalesnik wrote:
> So to refine the original question: Is there any way to do this
> without multi-voice trickery?
I'm afraid this is a bug in the Horizontal_bracket_engraver, so until
it's fixed your only other option would be to roll you own engraver in
Scheme. I've
On 5 July 2011 04:48, wrote:
> LGTM
Thanks, Carl.
Pushed: d5766025a1573c709dfa3c9663c1c6b903abec24
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On 7 July 2011 19:09, Wols Lists wrote:
> Which I probably didn't understand :-) BUT from what I remember did you
> think that feeding a chord of, say, C into the formatter should chuck
> out A as its result? Which is NOT what this does - it has to chuck out
> both C *and* A. Bear in mind - that
On 7 July 2011 12:02, wrote:
>
> http://codereview.appspot.com/4654090/diff/1/lily/context.cc
> File lily/context.cc (right):
>
> http://codereview.appspot.com/4654090/diff/1/lily/context.cc#newcode496
> lily/context.cc:496: properties_dict ()->set (sym, val);
> else if (do_internal_type_checking
On 6 July 2011 16:07, wrote:
> I now debugged that problem and the issue is that ALL events created by
> \breakDynamicSpan are sent to the engraver before any dynamic event is
> sent. In particular, for c1\<\breakDynamicSpan the order of events heard
> by the dynamic span engraver is:
> 1) break
On 5 July 2011 21:26, m...@apollinemike.com wrote:
> Thanks Neil! I should have been clearer before: what I don't understand is
> not the function call (pardon the double negative), but rather how the layout
> block evades setting do_internal_type_checking_global and/or how layout
> blocks ar
On 5 July 2011 08:26, m...@apollinemike.com wrote:
> Just to get the ball rolling on this, were I to start on a patch that
> implements this sort of settings checking, where would be a good place to
> start?
> I know where the context mods are set and where the properties are set, but I
> don'
On 4 July 2011 21:57, wrote:
> The original way you suggested was to have two internal_has_interface ()
> calls; this one only adds one.
But for the invalid heads, all three calls would be made (and of
course, for a NoteHead itself only the first interface check will ever
happen, so the other c
On 4 July 2011 21:33, wrote:
> Where is set_property defined?
lily/include/lily-guile-macros.hh
The actual type-checking occurs in Context::internal_set_property ().
Cheers,
Neil
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.
On 4 July 2011 15:31, Carl Sorensen wrote:
> Would a redundant check of settings from default context definitions be a
> problem? I can't imagine that such a check would take 1% of the processing
> time.
I don't know, though I agree is unlikely to be a significant overhead.
> Plus, I don't thin
On 4 July 2011 13:53, m...@apollinemike.com wrote:
> I didn't realize this was the real issue :)
> Any tips as to how one would go about fixing this? Anything that happens
> before engravers kick in (dispatchers, parsers, etc.) remains a mystery to
> me...
Context_def::add_context_mod () is w
ession/dynamics-alignment-breaker-linebreak.ly#newcode12
> input/regression/dynamics-alignment-breaker-linebreak.ly:12:
> c1_\dim\breakDynamicSpan
> On 2011/07/03 20:14:56, Neil Puttock wrote:
>>
>> redundant \breakDynamicSpan
>
> I don't think so. This \breakDynamicSpan
On 3 July 2011 19:04, Neil Puttock wrote:
> It works fine if you use an after-line-breaking callback and set Y
> directly via ly:grob-set-nested-property! (though judging by Han-Wen's
> comments, this is an invalid solution.)
Hah, it also works fine if you use left/right-bo
On 3 July 2011 18:09, m...@apollinemike.com wrote:
> Thanks for the info! I had no idea this was the case - otherwise I would
> have looked at it manually. Perhaps this is worth noting in the
> contributor's guide?
The CG does mention bounding boxes, so it is noted in a roundabout way.
> Th
On 3 July 2011 14:39, Graham Percival wrote:
> On Sun, Jul 03, 2011 at 02:25:12PM +0100, Neil Puttock wrote:
>> Matrix (vsize rows, vsize columns, T const &t)
>> - : data_(rows * columns, t)
>> + : data_ (rows *columns, t)
>>
>> misinterpreted multipli
On 2 July 2011 22:16, m...@apollinemike.com wrote:
> The original code broke LilyPond in a very bad way - all documents printed
> glissandi as if they had the Y-extent of the first glissando in a piece. I
> have no clue why this happened, but the new code doesn't do this, and I've
> modified
On 3 July 2011 12:49, Graham Percival wrote:
> I've spent a few minutes skimming through it without finding
> anything disagreeable.
A few fishy looking changes:
int lily_cookie_fprintf (void *file, char const *format, ...)
-__attribute__ ((format (printf, 2, 3)));
+ __attribute__ ((for
On 3 July 2011 13:18, Carl Sorensen wrote:
> On 7/3/11 5:49 AM, "Graham Percival" wrote:
>
>> On Sun, Jul 03, 2011 at 01:43:40AM -0700, Keith OHara wrote:
>>> On Sat, 02 Jul 2011 19:41:15 -0700, wrote:
>>>
Can you make it possible for us to see the diff caused by applying this
script t
On 30 June 2011 16:10, Phil Holmes wrote:
> I knew about that - just wasn't sure why an extra warning was added to
> volume-equaliser and one removed from -dynamics.
It's the same thing that causes the festival regtests to switch
between builds: it depends on the order of compilation when
lilypo
On 30 June 2011 12:18, David Santamauro wrote:
> ... when does
>
> if (c->is_alias (ly_symbol2scm ("Voice")))
>
> ever return false?
When it acknowledges an Audio_key. The Key_performer is the only
other performer contained by a Staff context in midi; see
ly/performer-init.ly for the context d
On 30 June 2011 14:40, Phil Holmes wrote:
> Official regtests: pretty clean. Not sure about:
>
> +warning: MIDI channel wrapped around
> +warning: remapping modulo 16
> warning: MIDI channel wrapped around
> warning: remapping modulo 16
> warning: MIDI channel wrapped around
>
> in midi-volume-eq
On 26 June 2011 17:09, Colin Campbell wrote:
> Just jumping in unwisely, before the coffee hits the brainstem: is a slur an
> instance of spanner?
Yes.
> This discussion sounds a good bit like the problems
> reported with slurs (ties?) over line breaks.
I'm afraid not. This is an alignment pr
On 13 June 2011 12:03, wrote:
> My goal is to bypass the default calculation and replace it with this one,
> and it is easier to harvest the information about Y placement relative to the
> staff before line breaking happens. Currently, there is no mechanism in
> Line_spanner::calc_bound_info
On 26 June 2011 13:02, Reinhold Kainhofer wrote:
> Hmm, again the problem is that the parts after a line break of broken dynamic
> spanners (text / hairpin) do not have any parent set any more... Now, the
> function write-system-signature (subfunction found-grob, stencil.scm) calls
> ly:grob-exte
On 24 June 2011 15:40, wrote:
> I found this 10-month old patch of mine laying around. It still seems
> relevant, so I'm sending it to the list. Lemme know what y'all think.
http://lists.gnu.org/archive/html/lilypond-devel/2010-08/msg00065.html
Cheers,
Neil
_
On 25 June 2011 22:56, Reinhold Kainhofer wrote:
> The previous commit 7bcdd37be15ece09cd97841137b075a576bbe696 ("Fixes issue
> 1706, issues a programming error at old assert error.") by Mike Solomon breaks
> make check, as the regtest issues lots of programming_error calls:
>
> beam-skip.ly:17:33
On 22 June 2011 22:48, m...@apollinemike.com wrote:
> In this present case, I could see the bound info being calculated via a
> callback that fetches the 'quantized position property for the Y values, but
> the X values would still need to be calculated by consulting the normal stems
> à la li
On 16 June 2011 08:18, wrote:
> left-bound-info and right-bound-info are calculated at the beginning of
> Line_spanner::print, so this setting of Beam properties, albeit late in
> the game, would be in keeping with the stage at which these properties
> are calculated in the Line_spanner.
They'r
On 16 June 2011 17:28, wrote:
> I won't bother with an issue tracker item for this; I think it's
> simple+clear enough that it can be pushed without a full "patch
> countdown".
Thanks, pushed: eb307731804e61efcb62a13ebbf13da5bb050f3f
Cheers,
Neil
__
On 18 June 2011 20:33, Graham Percival wrote:
> Looks fine, please push.
Pushed: 295ad53e7b4e3e2b2a0a612f46b184f79c3cc7ce
Cheers,
Neil
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
uilds.
OK to push?
Cheers,
Neil
From 6e4e3f1ae76c824e69596c18e34763dbd2f34dee Mon Sep 17 00:00:00 2001
From: Neil Puttock
Date: Sat, 18 Jun 2011 18:47:03 +0100
Subject: [PATCH] Compile fix for FreeBSD builds.
* lily/multi-measure-rest.cc (measure_duration_log):
log2(3) isn't supported in older FreeBSD version
On 14 June 2011 19:40, m...@apollinemike.com wrote:
> I see that the line-spanner print function looks for something that is called
> anchor-alignment (git blame insinuates that it was Joe who added this). This
> alignment, so far as I can see, is used nowhere in the code (nor is its use
> do
On 15 June 2011 16:36, Phil Holmes wrote:
> Strikes me we shouldn't be having examples in the documentation that throw
> errors in the compilation, though?
Ideally, no. Carl's suggested workaround looks fine.
Cheers,
Neil
___
lilypond-devel mailing
On 15 June 2011 15:11, Carl Sorensen wrote:
> I'll see if I can get the bug down to a tiny example.
It's issue 630 again, which is a long-standing regression (see
property-grace-polyphony.ly).
Cheers,
Neil
___
lilypond-devel mailing list
lilypond-dev
On 14 June 2011 22:57, Graham Percival wrote:
> On Tue, Jun 14, 2011 at 09:43:56PM +, n.putt...@gmail.com wrote:
>> To save time fixing indentation, if you have emacs installed there's a
>> script which will nitpick the code:
>>
>> scripts/auxiliar/fixcc.py
>>
>> http://lilypond.org/doc/v2.15/
On 6 June 2011 11:13, wrote:
> Thanks again, Neil !
> I applied these.
Thanks.
There's one more static_cast here:
+ length = static_cast (pow (2, -i));
Cheers,
Neil
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailm
On 10 June 2011 08:05, Keith OHara wrote:
> I think it is a documentation issue. Sometimes we need to turn off the new
> automatic collision avoidance by beams.
>
> \version "2.12"
> <<
> c'2
> \new Staff <<
> %% The cross-staff chord below worked until about 2.13.50,
> %% but now we ne
On 3 June 2011 20:04, Graham Percival wrote:
> Hmm. So if I wanted to write this information to a line, I'd have
> to use some stateful variable to store the latest value of the
> (Override), then use that info whenever I saw a (text-span-event)
> ? That seems like a step backwards for maintabi
On 1 June 2011 20:31, Graham Percival wrote:
> However, I'm confused/concerned about getting the text value of
> text spanners. I'm currently doing:
>
> #(define (format-textspan engraver event)
> (let* ((context (ly:translator-context engraver))
> (moment (ly:context-current-moment c
On 31 May 2011 19:07, m...@apollinemike.com wrote:
> I actually tried this, but the issue is that when new grobs are made outside
> of an engraver context (i.e. broken spanners), there is no way to keep track
> of them. This seems the only way to catch every grob made during a session.
> Unl
On 26 May 2011 17:29, Joe Neeman wrote:
> The attached patch fixes issue 1300, but I'm wary of it because
> define-grobs.scm:23 says " WARNING: don't use anonymous functions for
> initialization." Does anyone know why that is?
Nope. Perhaps it's something to do with documentation generation.
On 11 May 2011 19:11, wrote:
> The issue is that, for the chord bracket and chord slur (and Bertrand's
> eventual chord brace, which hypothetically varies significantly in its X
> dimension as it gets larger), the width of the grob is dependent on knowing
> the extremal note head positions, w
On 11 May 2011 15:18, m...@apollinemike.com wrote:
> There is a note in arpeggio.cc saying that width cannot be gleaned from the
> print function because it triggers a vertical alignment when arpeggios are
> cross-staff. By turning the function into an internal function and calling
> it form
On 9 May 2011 19:44, Carl Sorensen wrote:
> There's no guarantee that the notes will be in decreasing string number
> order.
>
> That's the general case, but it's not required.
>
> In absolute mode I can write a C major chord as
>
>
>
> or
>
>
>
> and as far as I know, we have no requirement th
On 3 May 2011 23:44, m...@apollinemike.com wrote:
> Back to http://codereview.appspot.com/4438092/, it seems as if this doesn't
> screw up the harmonics problem.
But they're already screwed (probably since the Tab_harmonic_engraver
was removed and the harmonics moved to the TabNoteHead print
func
On 3 May 2011 23:27, m...@apollinemike.com wrote:
> On May 3, 2011, at 2:14 PM, n.putt...@gmail.com wrote:
>
>> On 2011/05/03 03:56:15, MikeSol wrote:
>>> A better approach to the TabVoice glissando problem, although I'm
>> still not
>>> quite sure why it works, but it seems to work!
>>
>> The def
On 28 April 2011 14:13, m...@apollinemike.com wrote:
> Thanks. Pushed as 09f09c054a7c985424925605c237c78b9adb4047.
>
> We have our first 2.15.0 regtest. w00t!
Mike, you can't do this. There's no 2.15 branch yet, which means the
version string will break compilation (since it's in advance of
ma
On 18 April 2011 15:30, wrote:
> On 2011/04/18 14:09:52, hanwenn wrote:
>> In that case, it would probably be cleaner to
>> hook into the event listener framework directly, without having an
>> engraver in between. The Scheme engraver mechanism is really for
>> creating formatted output rather
On 10 March 2011 10:06, m...@apollinemike.com wrote:
> On Mar 9, 2011, at 10:17 PM, n.putt...@gmail.com wrote:
>> Does `annotation-whiteout' do anything special? If not, the existing
>> property `whiteout' should suffice.
>>
>
> It puts a whiteout only around the annotation instead of whiting ou
On 22 March 2011 22:48, m...@apollinemike.com wrote:
> Would an acceptable alternative be giving the TrillPitchAccidental the
> inline-accidental-interface?
Sounds good to me.
Cheers,
Neil
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http:
On 21 March 2011 01:59, Han-Wen Nienhuys wrote:
> The intention of the fix is incorrect, but can you make the logic
> explicit? That is, add an interface symbol for "normal" accidentals
> (normal-accidental-interface, inline-accidental-interface, ... ?) and
> acknowledge that explicitly? If not,
On 22 March 2011 12:59, Colin Campbell wrote:
> @dev: Ed's question comes from the recent changes to percent repeats and
> beat slashes: is it possible to revert the double slash now used for short
> (<1/8) notes and mixed note patterns, to a single slash as used prior to
> 2.13.51?
Yes:
\relat
On 22 March 2011 17:20, David Kastrup wrote:
> This.
>
> http://codereview.appspot.com/4311041>
>
> Please improve/discuss. This looks totally insane but does not actually
> change the existing absurd realities for single-digit unsigned numbers.
I'm afraid I can't even get as far as running `ma
On 16 March 2011 10:43, m...@apollinemike.com wrote:
> Can anyone suggest a clean way to get the output name into a scheme constant?
> My brief attempt this morning resulted in a segfault, which is my cue to ask
> for help.
foo = #(ly:parser-output-name parser)
Cheers,
Neil
On 14 March 2011 23:26, m...@apollinemike.com wrote:
> backtrace from valgrind, also after balloon.ly
[snip]
Interesting. I was on the right track, but it appears to be deleting
something which has already been deleted:
Audio_staff*
Staff_performer::new_audio_staff (string voice)
{
Audio_st
On 14 March 2011 22:19, Graham Percival wrote:
> On Mon, Mar 14, 2011 at 03:27:06PM -0400, m...@apollinemike.com wrote:
>> I am having trouble getting a clean baseline from the regtests, and trying
>> to grep the culprit is, for some odd reason, taking several minutes. Could
>> someone please r
On 10 March 2011 21:04, Jan Nieuwenhuizen wrote:
> I see, whenever a new channel is opened (for a new voice)
> by the staff-performer, it should also set the instrument
> there. Actually, that's nicer than doing it in
> Staff_performer::process_music ()
Doesn't that still fall foul of the lack
On 10 March 2011 19:57, Jan Nieuwenhuizen wrote:
> It works for me, and I think Neil also could not confirm this, so]
I'm afraid I can now (I was puzzled by Keith's report initially since
I'd only tested midiInstrument settings on a single stave).
All staves default to channel 0 for midi instru
On 9 March 2011 00:09, Keith OHara wrote:
> In 2.13.53, I cannot find a way to make midiInstrument have effect.
I can't confirm this; apart from instruments which my MIDI output
doesn't seem to support, every instrument I've tried works fine.
Can you post a snippet showing the problem?
Cheers,
On 7 March 2011 21:11, emw wrote:
> If anyone can help me write a Scheme tweak for this, I'd appreciate it. Even
> pointing me to a tweak that does some of the same things would be helpful
> (i.e. tweaking output across an entire Staff in a StaffGroup, etc).
Each Staff context contains a groupin
7 Mon Sep 17 00:00:00 2001
From: Neil Puttock
Date: Mon, 7 Mar 2011 00:28:27 +
Subject: [PATCH] Possible fix for #1506.
---
lily/staff-symbol.cc |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/lily/staff-symbol.cc b/lily/staff-symbol.cc
index d1629df..8cf7be4
On 6 March 2011 23:30, m...@apollinemike.com wrote:
> It's dirt simple, and perhaps breaks other things, but it works.
Judging by the original commit
(http://repo.or.cz/w/lilypond/mirror.git/commit/2f47e632d869f7adfffa656b79a6f76cfa31a11e?f=lily/staff-symbol.cc),
it will break this snippet:
http
On 6 March 2011 17:33, David Kastrup wrote:
> James Lowe writes:
>
>> The google tracker issue does work in as much as the main point of this is
>> to split the Lilypond score into 'lines' and each line is exported to an
>> EPS file - this bit is done by Lilypond (IIR) you can then manually put
>
On 5 March 2011 14:38, Mike Solomon wrote:
> Done - thanks for bearing with me as I learn about break-visibility. It is a
> corner of the code that I never had to deal with directly, so I'm still
> getting my sea legs.
I suggest you remove the fallback value from
inherit-x-parent-visibility (
On 5 March 2011 12:57, Mike Solomon wrote:
> Patch attached. The stuff that comes from your comments regarding
> break-visibility is implemented in Balloon_interface::is_visible.
> The patch currently represents about 85% of the original, omitting the 15%
> that Han Wan had previously identified
On 4 March 2011 22:56, m...@apollinemike.com wrote:
> I think that the commit with SHA1 ID b02ea152073d11899bb17eecabe4d47a6009756d
> may have caused this:
>
> Writing "internals.texi"...ERROR: In procedure procedure-name:
> ERROR: Wrong type argument in position 1: #f
>
> I'm not sure, though, a
On 2 March 2011 16:48, Phil Holmes wrote:
> full-measure-rest-fermata.ly - this shows that markup attached to a note is
> kept within the music, but not markup attached to a FMR. I'd suggest this
> is a bug, although not a regression. Anyone other views?
Markup attached to a full-bar rest is a
On 1 March 2011 22:28, Mike Solomon wrote:
> Got this during a build.
>
> msgfmt -o out/nl.mo nl.po
> nl.po:946: `msgid' and `msgstr' entries do not both end with '\n'
> msgfmt: found 1 fatal error
> make[1]: *** [out/nl.mo] Error 1
> make: *** [install] Error 2
>
> I think this comes from the mos
On 28 February 2011 23:02, Mike Solomon wrote:
> I can use either (cross-staff . #t) , (Y-extent . #f) , or both depending on
> what floats people's boats.
(Y-extent . #f) is less hackish.
> Sorry - I've since fixed it in line 65-66 of balloon.cc . Sometimes,
> parent-spanner is not set (this
> http://codereview.appspot.com/4213042/diff/34032/lily/footnote-engraver.cc#newcode119
> lily/footnote-engraver.cc:119: "Footnote ",
> On 2011/02/27 22:42:24, Neil Puttock wrote:
>>
>> "Footnote "
>> "FootnoteSpanner ",
>
>> Perh
On 28 February 2011 21:06, m...@apollinemike.com wrote:
> I found a problem w/ my footnote work. Check out the 2nd example in bad.ly
> and bad.pdf . Why do you think the annotation is placed so far to the left
> here but not in other cases?
You're setting the spanner bounds to a NonMusicalPa
On 25 February 2011 22:53, wrote:
> On 2011/02/25 20:37:37, Neil Puttock wrote:
>>
>> This reinvents the wheel a bit. :)
>
>> (define-markup-command (draw-hline layout props)
>> ()
>> #:category graphic
>> #:properties ((draw-line-markup)
>&g
Hi Han-Wen,
I'm using an unoptimized binary and get an assertion failure following
the beam collision changes you've pushed:
Processing `remove-empty-staves-auto-knee.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 pa
On 15 February 2011 18:36, wrote:
> Whether bar-lines avoiding lyrics is good thing or not, no-one is likely
> to ever see it in anything longer than a couple bars.
That's exactly what I thought too (and was borne out in every snippet I tested).
> Does this argument put the patch in LGTM state
On 15 February 2011 20:02, m...@apollinemike.com wrote:
> I've uploaded a patch that takes grace notes (and other beams) into account.
> Keith - I'm not sure if this is the case. Currently, both my algorithm &
> Han-Wen's get the attached result without a modification to the beam
> collision eng
On 12 February 2011 09:14, -Eluze wrote:
>
> in the snippet "Printing a repeat sign at the beginning of a piece" (in NR
> and Snippets) *span-bar* is mentioned twice:
>
> \once \override Score.BreakAlignment #'break-align-orders =
> #(make-vector 3 '(instrument-name
> left-edge
> ambitus
> span-ba
On 13 February 2011 02:32, Graham Percival wrote:
> Hey guys, could you push your patches that have passed review?
> 1426 Better support for beat slashes
Done.
Cheers,
Neil
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/m
2011/2/9 Xavier Scheuer :
> %% Reported by 胡海鹏 - Hu Haipeng
> %% http://lists.gnu.org/archive/html/lilypond-user/2011-02/msg00179.html
> %%
> %% [empty] Dynamics context prevents \RemoveEmptyStaves to work
> %%
> %% We should have a way to remove empty Dynamics contexts as well
> %% and \RemoveEmpt
On 9 February 2011 14:56, Xavier Scheuer wrote:
> Is this the same issue as #631?
> http://code.google.com/p/lilypond/issues/detail?id=631
> AFAICS #631 does not have a Dynamics context but the problem seems to
> be the same (misalignment of dynamic attached to a skip).
> I do not see in #631 c
101 - 200 of 1080 matches
Mail list logo
