Sorry, I was still a bit asleep, my first reply was incomplete.
2009/7/9 John Mandereau :
> 2009/7/9 Graham Percival :
>> 1) Could you check Documentation/GNUmakefile,
>> Documentation/user/GNUmakefile, and
>> Documentation/essay/GNUmakefile?
>
> IMO, an .itely file that contains all the actual c
2009/7/9 Graham Percival :
> Is anybody familiar with the monstrosity that is the
> makefiles/stepmake build system in LilyPond?
>
> I've split the essay away from LM 1, because it never belonged
> there, and the website redesing had a nice place for it on its
> own. I hacked up the GNUmakefile un
On wo, 2009-07-08 at 15:56 -0700, Graham Percival wrote:
> On Tue, Jul 07, 2009 at 10:49:00AM +0200, Jan Nieuwenhuizen wrote:
> > On di, 2009-07-07 at 01:16 -0700, Patrick McCarty wrote:
> > > On Tue, Jul 07, 2009 at 01:01:22AM -0700, Graham Percival wrote:
> > > > Hi Patrick-the-incredible-helper,
Is anybody familiar with the monstrosity that is the
makefiles/stepmake build system in LilyPond?
I've split the essay away from LM 1, because it never belonged
there, and the website redesing had a nice place for it on its
own. I hacked up the GNUmakefile until it compiled, but I'm not
certain I
On Wed, Jul 08, 2009 at 11:01:06AM -0700, Mark Polesky wrote:
>
> Should we add a "Known issues and warnings" somewhere in
> NR 1.4 (Repeats) for this issue?
>
> % bad (don't put \relative inside \repeat)
> { \repeat unfold 2 \relative { c d e f } }
>
> % good
> \relative { \repeat unfold 2 { c
Yes, that patch is the only thing needed to fix it. However, does
this patch apply cleanly, without disrupting any regtests? It's
possible that some (badly written) regtests require the
intermediate files to be built. If so, we'd need to add a build
rule to add the -d option to enable intermedia
Since this contains a patch, I forward it to lilypond-devel. Does
anybody think it looks reasonable?
Cheers,
- Graham
On Mon, Jul 06, 2009 at 11:08:42PM +, Thomas Morgan wrote:
> Consider this input:
>
> \version "2.13.2"
> \markup {
> \column {
> \concat { "a" \bracket { "b"
On Wed, Jul 08, 2009 at 11:14:08AM -0600, Carl D. Sorensen wrote:
> On 7/8/09 8:41 AM, "John Mandereau" wrote:
>
> > 009/7/7 Graham Percival :
> >> I'd just like to fix that one area, plus any new items.
> >
> > I'm not sure what you mean; do you expect somebody to quickly add word
> > boundarie
On Tue, Jul 07, 2009 at 10:49:00AM +0200, Jan Nieuwenhuizen wrote:
> On di, 2009-07-07 at 01:16 -0700, Patrick McCarty wrote:
> > On Tue, Jul 07, 2009 at 01:01:22AM -0700, Graham Percival wrote:
> > > Hi Patrick-the-incredible-helper,
> > >
> > > When you build something in GUB, what build number
2009/7/8 Carl D. Sorensen :
> Such a function would ease the writing of *new* rules, which is what I think
> Graham's main emphasis is.
>
> I believe that it's clearly *not* worth it to fix old rules; there is *no*
> benefit to fixing old rules if they're not breaking. If they do break, we
> can f
I'm interested in helping to get flams, accents and diddles (drummode) to
come through in MIDI output. Can anyone point me in the right direction? Or
is anyone currently working on this?
Only the first flam seems to come through. I've tried on version 2.13.4 and
2.12.1. When generating output I ge
Should we add a "Known issues and warnings" somewhere in
NR 1.4 (Repeats) for this issue?
% bad (don't put \relative inside \repeat)
{ \repeat unfold 2 \relative { c d e f } }
% good
\relative { \repeat unfold 2 { c d e f } }
- Mark
___
l
On 7/8/09 8:41 AM, "John Mandereau" wrote:
> 009/7/7 Graham Percival :
>> I'm not, but almost all updates are in the form
>> \\oldCommand -> \\newCommand
>>
>> I suppose that somebody might have tried to speed up convert-ly
>> processing by doing
>> \\old -> \\new
>> and leaving the "Comman
009/7/7 Graham Percival :
> I'm not, but almost all updates are in the form
> \\oldCommand -> \\newCommand
>
> I suppose that somebody might have tried to speed up convert-ly
> processing by doing
> \\old -> \\new
> and leaving the "Command" out (thereby using one rule, instead of
> two rules), b
Hi Folks,
I've spoken at L.C.A a couple of times on topics that include
LilyPond, but I think it's time for some of the more core people to
give it a go. I think that the Lilypond community is unique in the
way it operates, particularly in the importance it places on
documentation, and in
On di, 2009-07-07 at 17:00 -0700, Patrick McCarty wrote:
> Okay, thanks Jan. :-) This doesn't achieve what I was hoping for though.
>
> Is there a method to remove a package from GUB so that a rebuild is
> triggered only for that package and packages that depend on it?
No. A packages' up-to-d
Marc Hohl schrieb:
Carl D. Sorensen schrieb:
On 7/7/09 12:20 PM, "Marc Hohl" wrote:
[...]
I don't particularly mind breaking existing scores (as long as
there is
a convert-ly rule to at least warn about the problem), but I
don't think
the situation in the patch is particularly frien
Carl D. Sorensen schrieb:
On 7/7/09 12:20 PM, "Marc Hohl" wrote:
[...]
I don't particularly mind breaking existing scores (as long as there is
a convert-ly rule to at least warn about the problem), but I don't think
the situation in the patch is particularly friendly. We've a long
tr
Carl D. Sorensen schrieb:
[...]
3) move the existing predefined tunings from scm/output-lib.scm
into tablature.scm, where I can add my new tunings as well;
Yes, I agree with this.
Should the definitions for fret-number-tablature-format
and fret-number-tablature-format-banjobe move
19 matches
Mail list logo
