On 2009-08-14, Neil Puttock wrote:
>
> Two issues have caught my eye (one minor, the other more serious):
>
> 1. After a break, I think there's too little space between key
> signature alterations and a continuation (though this also applies to
> ties, so it's probably a more general issue): at l
"dem...@suffolk.lib.ny.us" wrote:
> a b c d\lefty e f g
>
> (above) \lefty has an intuitive association with the d.
>
> a b c \righty d e f g
>
> (above) \righty is intuitivly ambiguous,
> (below), \righty has a false intuitive association with the 'c'
>
> a b c\righty d
This is an interesti
Patrick McCarty wrote:
> I've decided to dive into deep waters (the slur code) and try to fix
> the popular "ugly slur" bugs, #379 and #427.
>
> See the attached patch for the progress I've made. Also attached is
> an image of Mark Polesky's example from the bug tracker:
>
> http://code.google.
Werner LEMBERG writes:
>> FWIW, I used to think that this would be a very important feature;
>> now I'm not so sure. There are certainly a few cases (eg. slurs,
>> hairpins, treble clefs) where having more accurate outlines would
>> help.
>
> It would also help in improved positioning of accident
On Thu, Aug 13, 2009 at 10:22 PM, Andrew Hawryluk wrote:
> On Thu, Aug 13, 2009 at 7:33 AM, David Kastrup wrote:
>> Andrew Hawryluk writes:
>>
>>> On Thu, Aug 13, 2009 at 3:11 AM, David Kastrup wrote:
Andrew Hawryluk writes:
> Hi all,
>
> Long ago I noticed that the text in
On Thu, Aug 13, 2009 at 7:33 AM, David Kastrup wrote:
> Andrew Hawryluk writes:
>
>> On Thu, Aug 13, 2009 at 3:11 AM, David Kastrup wrote:
>>> Andrew Hawryluk writes:
>>>
Hi all,
Long ago I noticed that the text in our PDF manuals is fully black,
which results in rough-looking
The attached patch fixes general.pdf. The texinfo manual suggests
that if you're having problems with macros with texi2dvi (and
texi2pdf), adding the -E macro expansion can fix it. I tried it,
and it fixed it.
However, I recall that this came up in the past, and somebody said
that we shouldn't u
2009/8/14 Neil Puttock :
> Will report back once I've given the patch a whirl.
This is already very impressive, as far as I can tell.
I've just run `make check' and there are no important changes visible,
but I imagine that's due to the fact we haven't got any tests which
really exercise this is
On Thu, Aug 13, 2009 at 05:25:57PM +0200, John Mandereau wrote:
> Le jeudi 13 août 2009 à 01:31 +0200, Jan Nieuwenhuizen a écrit :
> > That's a nice way of putting it... I do like the new web site,
> > but I'd feel bad if what we now have goes life, so I put in
> > some effort to help this time ;-
2009/8/14 Patrick McCarty :
> I've decided to dive into deep waters (the slur code) and try to fix
> the popular "ugly slur" bugs, #379 and #427.
Hurrah! :)
You've already made more progress than I have tackling this; I spent
far too much time fiddling around inside
Slur_engraver::stop_translati
Graham Breed wrote:
> Oh, I didn't realize Google were covering this. I've done some work
> with Lilypond and microtonality. Somebody said I should add something
> to the snippets repository, but I've been lazy, so I haven't done
> that. There are examples in this bundle:
>
> http://x31eq.com/m
2009/8/14 Neil Puttock :
> 2009/8/12 Carl Sorensen :
>
>> Redundant is OK by me.
>>
>> If I think of having a checklist for a developer to submit a change, it
>> would include the following:
>>
>> 1) New or revised code.
>> 2) convert-ly rule for revisions (new functions don't need convert-ly rule)
On 8/13/09 5:02 PM, "Graham Percival" wrote:
> On Thu, Aug 13, 2009 at 10:01:31PM +0200, Werner LEMBERG wrote:
>>
>> [about Makefiles]
>>
>>> Don't waste your time understanding them, as their timelife is now
>>> known to be very limited.
>>
>> Are you sure that SCons is the right choice?
On Thu, 2009-08-13 at 23:46 +0100, Neil Puttock wrote:
> 2009/8/12 Michael Käppler :
>
> > hmm... somehow I'm completely stuck at this moment. Why does the affected
> > output-def contain no paper-width / paper-height etc.? I don't really know
> > how this can be triggered by my patch since it clo
On Thu, Aug 13, 2009 at 10:01:31PM +0200, Werner LEMBERG wrote:
>
> [about Makefiles]
>
> > Don't waste your time understanding them, as their timelife is now
> > known to be very limited.
>
> Are you sure that SCons is the right choice? What about cmake?
I used cmake for a project approximate
Hello,
I've decided to dive into deep waters (the slur code) and try to fix
the popular "ugly slur" bugs, #379 and #427.
See the attached patch for the progress I've made. Also attached is
an image of Mark Polesky's example from the bug tracker:
http://code.google.com/p/lilypond/issues/detail?i
2009/8/12 Michael Käppler :
> hmm... somehow I'm completely stuck at this moment. Why does the affected
> output-def contain no paper-width / paper-height etc.? I don't really know
> how this can be triggered by my patch since it clones the output-def and
> modifies only the margin and line-width
2009/8/13 Reinhold Kainhofer :
> That patch changed the grob type from TextScript (?) to MultiMeasureText, so
The grob type hasn't changed: if you add a markup to a multi-bar rest,
the function `script-to-mmrest-text' converts the ScriptEvent to a
MultiMeasureTextEvent.
> yes, it changed the pri
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am Donnerstag, 13. August 2009 23:04:32 schrieb Werner LEMBERG:
> >> As can be seen in the attached image, the text markup gets a higher
> >> `inside' priority than the fermata. I think this is wrong, since
> >> in most cases there is nothing between
On 8/13/09 2:42 PM, "Mark Polesky" wrote:
> Carl Sorensen wrote:
>> This is *exactly* the same issue.
>
> Is it accurate to say that the parser is a LilyPond interpreter in
> the same sense that guile is a scheme interpreter? If so, is it
> also accurate to say that the parser temporarily han
2009/8/12 Joe Neeman :
> IWBN if it were possible to extract the staff-refpoints of a marked up
> system in a grob callback (in which case we could write a less fragile
> Y-offset callback), but I'm not sure if it is. In the meantime, I'd
> suggest changing the snippet to include the Y-extent over
2009/8/13 Mark Polesky :
> I'm guessing something is wrong with my understanding because the
> hash (#) doesn't appear anywhere in the "LilyPond grammar",
> appendix, and I'm thinking of it as a unary operator meaning
> "interpret the following as a scheme-expression using guile".
You're looking
>> As can be seen in the attached image, the text markup gets a higher
>> `inside' priority than the fermata. I think this is wrong, since
>> in most cases there is nothing between a rest and the fermata above
>> it. BTW, this problem doesn't happen if you replace the rests with
>> notes in the
2009/8/13 Carl Sorensen :
> One could also do
> #(define scheme-only-music-expresson #{ \relative e' { e8 f g g e2 } #})
You can also use quoted strings,
"music-expression" = \relative e' { e8 f g g e2 }
but they can't be used in music blocks since the lexer will only
recognize letters:
143 N
Carl Sorensen wrote:
> This is *exactly* the same issue.
Is it accurate to say that the parser is a LilyPond interpreter in
the same sense that guile is a scheme interpreter? If so, is it
also accurate to say that the parser temporarily hands over
control to guile when it sees the # operator? It g
> FWIW, I used to think that this would be a very important feature;
> now I'm not so sure. There are certainly a few cases (eg. slurs,
> hairpins, treble clefs) where having more accurate outlines would
> help.
It would also help in improved positioning of accidentals.
> But the list is fairly
[about Makefiles]
> Don't waste your time understanding them, as their timelife is now
> known to be very limited.
Are you sure that SCons is the right choice? What about cmake?
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
htt
2009/8/13 Joseph Wakeling :
> A few comments on the proposed patches for microtonal arrow notation.
> I've already noted these on the Google Code Issue dedicated to this topic:
> http://code.google.com/p/lilypond/issues/detail?id=694
Oh, I didn't realize Google were covering this. I've done some
On 8/13/09 10:37 AM, "Mark Polesky" wrote:
> Carl Sorensen wrote:
>
>> Hope this helps. It was instructional to me to write it.
>
> Wow, thanks - that was a lot of info. I'm still trying to wrap my
> brain around it. But in the meantime, I've noticed something else
> confusing, and I'm wond
On 8/13/09 11:07 AM, "John Mandereau" wrote:
> Le jeudi 13 août 2009 à 10:52 -0600, Carl Sorensen a écrit :
>> I try not to look at any of the make files; it's hopeless for me to
>> understand them.
>
> I can understand, I used to be hopeless too. Don't waste your time
> understanding them,
On 8/13/09 11:21 AM, "Michael Käppler" wrote:
> Hi Carl,
>>> Am I right you suggest to modify the output-def just once but permanent?
>>>
>>
>> I meant to change the paper-def so that it would be consistent for the rest
>> of the processing (it would eliminate multiple warnings).
>>
> O
Le jeudi 13 août 2009 à 09:56 -0700, Mark Polesky a écrit :
> c) change the English version and expect them to see the change
>on their own, or
If the changes are not spread across different files, translators will
notice them; this is the preferred option for changes in text in English
outsid
Le jeudi 13 août 2009 à 10:52 -0600, Carl Sorensen a écrit :
> I try not to look at any of the make files; it's hopeless for me to
> understand them.
I can understand, I used to be hopeless too. Don't waste your time
understanding them, as their timelife is now known to be very limited.
> Is th
John Mandereau wrote:
> A general rule for handling translations could be, if there are changes
> that can be done in all languages -- moving sections, updating @lilypond
> snippets -- then mao do it for all languages. I know this is much of a
> burden for the guy who does it, so drop a note on -
On 8/13/09 10:42 AM, "John Mandereau" wrote:
> Le mardi 11 août 2009 à 21:19 -0600, Carl Sorensen a écrit :
>> And if makelsr.py hasn't been done, LilyPond will get the snippet from
>> Documentation/snippets/new instead of Documentation/snippets.
>
> This is wrong --
Thank you for the clari
Carl Sorensen wrote:
> Hope this helps. It was instructional to me to write it.
Wow, thanks - that was a lot of info. I'm still trying to wrap my
brain around it. But in the meantime, I've noticed something else
confusing, and I'm wondering if you'd like to make any additional
comments on this.
Le mardi 11 août 2009 à 21:19 -0600, Carl Sorensen a écrit :
> And if makelsr.py hasn't been done, LilyPond will get the snippet from
> Documentation/snippets/new instead of Documentation/snippets.
This is wrong -- see LILYPOND_BOOK_INCLUDES in make/lilypond-vars.make
-- and not needed anyway: any
Le jeudi 13 août 2009 à 01:31 +0200, Jan Nieuwenhuizen a écrit :
> That's a nice way of putting it... I do like the new web site,
> but I'd feel bad if what we now have goes life, so I put in
> some effort to help this time ;-)
Very very cool! I left this a bit over as my LilyPond time is complt
On Thu, Aug 13, 2009, Graham Percival said:
> On Thu, Aug 13, 2009 at 09:28:02AM +0200, Marc Hohl wrote:
>> I mean, we code and read music from left to right, so
>> it seems nore natural to me to have the command changing
>> the behaviour of a note in front of it.
Some like postscript and HP ca
Le mercredi 12 août 2009 à 17:27 -0700, Graham Percival a écrit :
> I was talking about @lilypond stuff, not snippets. i.e. if
> Documentation/fr/notation/rhythms.itely
> contains some old autobeaming stuff requring a NOT_SMART rule,
> what happens? We can't leave it alone, since that would bre
Graham Percival schrieb:
On Thu, Aug 13, 2009 at 09:28:02AM +0200, Marc Hohl wrote:
Graham Percival schrieb:
Yes, this is planned. It's been on my list of discussions to
introduce when the website/build stuff is finished, for about two
months now.
Sorry to interrupt, but what
Le mardi 11 août 2009 à 21:01 -0700, Graham Percival a écrit :
> This changed the message, but the underlying problem is still
> there. I tried another "make lilypond", without deleting
> anything. (a few commits changed Documentation/general/ and css
> stuff, but nothing else happened on master)
On 8/13/09 12:44 AM, "Mark Polesky" wrote:
> Would anyone like to take a little time to look over this
> highly confusing situation and try to explain to me why it
> is this way?
>
> I would find it quite helpful.
Most of your confusion comes from the failure to distinguish *LilyPond*
variab
Dear Maximilian and others,
A few comments on the proposed patches for microtonal arrow notation.
I've already noted these on the Google Code Issue dedicated to this topic:
http://code.google.com/p/lilypond/issues/detail?id=694
... but obviously the -devel list is the place for serious discussion
Andrew Hawryluk writes:
> On Thu, Aug 13, 2009 at 3:11 AM, David Kastrup wrote:
>> Andrew Hawryluk writes:
>>
>>> Hi all,
>>>
>>> Long ago I noticed that the text in our PDF manuals is fully black,
>>> which results in rough-looking text when printed:
>>> http://lists.gnu.org/archive/html/lilypo
On Thu, Aug 13, 2009 at 3:11 AM, David Kastrup wrote:
> Andrew Hawryluk writes:
>
>> Hi all,
>>
>> Long ago I noticed that the text in our PDF manuals is fully black,
>> which results in rough-looking text when printed:
>> http://lists.gnu.org/archive/html/lilypond-devel/2008-10/msg00059.html
>>
>
Andrew Hawryluk writes:
> Hi all,
>
> Long ago I noticed that the text in our PDF manuals is fully black,
> which results in rough-looking text when printed:
> http://lists.gnu.org/archive/html/lilypond-devel/2008-10/msg00059.html
>
> Attached is a patch which corrects this, and the printed outpu
On Thu, Aug 13, 2009 at 09:28:02AM +0200, Marc Hohl wrote:
> Graham Percival schrieb:
>> Yes, this is planned. It's been on my list of discussions to
>> introduce when the website/build stuff is finished, for about two
>> months now.
>
> Sorry to interrupt, but what's wrong with prefix notation
"Trevor Daniels" writes:
> Andrew Hawryluk wrote Thursday, August 13, 2009 4:18 AM
>>
>> Long ago I noticed that the text in our PDF manuals is fully black,
>> which results in rough-looking text when printed:
>> http://lists.gnu.org/archive/html/lilypond-devel/2008-10/msg00059.html
The message
Andrew Hawryluk wrote Thursday, August 13, 2009 4:18 AM
Long ago I noticed that the text in our PDF manuals is fully
black,
which results in rough-looking text when printed:
http://lists.gnu.org/archive/html/lilypond-devel/2008-10/msg00059.html
Attached is a patch which corrects this, and th
Would anyone like to take a little time to look over this
highly confusing situation and try to explain to me why it
is this way?
I would find it quite helpful.
Thanks!
- Mark
\version "2.13.4"
% music expression variables can be defined with "=" or scheme-style,
% but all variable names must b
Graham Percival schrieb:
On Wed, Aug 12, 2009 at 08:51:42PM +0100, Trevor Daniels wrote:
Carl Sorensen wrote Wednesday, August 12, 2009 7:32 PM
And if we're ever going to move it to a postfix operator (which is one
of
the goals of the GLISS project), now is the time, before we get a
52 matches
Mail list logo
