2009/7/24 Graham Percival gra...@percival-music.ca:
On Thu, Jul 23, 2009 at 08:55:21PM -0600, Carl Sorensen wrote:
Please remove the docs tags from the following snippets:
Specifying context with beatGrouping
Using beatLength and beatGrouping
Copy those snippets (the two files from
On Fri, Jul 24, 2009 at 08:36:50AM +0200, Valentin Villenave wrote:
2009/7/24 Graham Percival gra...@percival-music.ca:
On Thu, Jul 23, 2009 at 08:55:21PM -0600, Carl Sorensen wrote:
Please remove the docs tags from the following snippets:
Specifying context with beatGrouping
Hi Valentin,
Greetings,
here is how to achieve what you're looking for (it has been added to
the documentation snippets as well, since this notation is indeed
common):
http://lsr.dsi.unimi.it/LSR/Item?id=620
Thanks for adding this to the snippets. Maybe I'll post a better
explanation later.
Here's one way of doing it (from within a music block).
Very nice! Perhaps this can be wrapped into an even more convenient
function so that a user just have to say, for example,
\getAncestry { grob }
at the place where grobs have to be manipulated.
Definitely very useful stuff!
Werner LEMBERG wrote:
Very nice! Perhaps this can be wrapped into an even more convenient
function so that a user just have to say, for example,
\getAncestry { }
at the place where grobs have to be manipulated.
Definitely very useful stuff!
Werner,
I reformatted the output
2009/7/23 Michael Käppler xmichae...@web.de:
Thanks for adding this to the snippets. Maybe I'll post a better explanation
later. Anyway, wouldn't it be better to add this to the font?
For a single vertical line, I suspect this would be overkill – Unless
we officialy include it alongside the
2009/7/24 Werner LEMBERG w...@gnu.org:
Definitely very useful stuff!
... and it would be a shame to lose track of it :-)
What do you guys would like to do with it? LSR? Docs? Anywhere else?
Regards,
Valentin
___
lilypond-devel mailing list
2009/7/24 Valentin Villenave v.villen...@gmail.com:
Another point is the horizontal position: If the line is placed above the
stem, it seems better to me to have both in one horizontal position (not
centered above the NoteHead), though I can't recognize any clear conventions
for it up to now.
Valentin Villenave wrote:
What do you guys would like to do with it? LSR? Docs? Anywhere else?
In a weird way, I don't think either is appropriate. Sometimes I wish
there was something like an LSRD (for developers). You know, snippets
showing how to trace grob-parents, how to sort objects by
2009/7/24 Maximilian Albert maximilian.alb...@googlemail.com:
It's not correct that articulations are always centered with the note head.
See
http://code.google.com/p/lilypond/issues/detail?id=218
and the examples attached there. This is precisely what
toward-stem-shift was introduced
2009/7/24 Mark Polesky markpole...@yahoo.com:
In a weird way, I don't think either is appropriate. Sometimes I wish
there was something like an LSRD (for developers). You know, snippets
showing how to trace grob-parents, how to sort objects by specific
properties, how to know when to use #'(0
Mark Polesky wrote Friday, July 24, 2009 3:16 AM
One wrinkle is that compiling and testing things with make doc
is (at the moment) out of the question on the computer that I
currently have access to. Which means that I can't definitively
prove that my patches don't break anything, even though
On Thu, Jul 23, 2009 at 9:11 PM, Mark Poleskymarkpole...@yahoo.com wrote:
Does a grob-type always have the same set of parent-types?
Not necessarily; It often depends on how the context that the grob
originates from is nested into the rest of the contexts. Check the
source code for
On 7/22/09 4:15 PM, joenee...@gmail.com joenee...@gmail.com wrote:
I think this is pretty much ready to commit
http://codereview.appspot.com/88155/diff/3101/4032
File lily/beam-scheme.cc (right):
http://codereview.appspot.com/88155/diff/3101/4032#newcode2
Line 2: beam-scheme.cc --
Le jeudi 23 juillet 2009 à 14:11 -0700, Mark Polesky a écrit :
I assume that a comprehensive visual parent-web demonstrating
all such relationships would be too convoluted to have any
practical value, and too difficult to generate to even justify
trying such a thing
It might be doable to draw
Okay to apply?
- Mark
0001-IR-3-Backend-More-auto-sorting.patch
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Thanks for adding this to the snippets. Maybe I'll post a better
explanation later. Anyway, wouldn't it be better to add this to the
font?
For a single vertical line, I suspect this would be overkill –
Unless we officialy include it alongside the other articulation
marks. Werner,
I reformatted the output (slightly) to minimize duplicates. Do you
prefer this version or the earlier one?
The more compact solution is the better one. A minor nit: Please
start the output with a newline: I get this on the TTY:
Interpretation der Musik...
Vorverarbeitung der grafischen
2009/7/24 Graham Percival gra...@percival-music.ca:
Bad idea, since we eventually *will* be releasing another 2.12,
and it wouldn't be a bad idea to update lsr in it. It's not worth
changing them back now, but as a general rule, don't do this.
I'm not too bothered if this happens, since
2009/7/24 Mark Polesky markpole...@yahoo.com:
Okay to apply?
Not quite:
+ (map ref-ify
indentation
+ (sort
whitespace/indentation
+ (map symbol-string
+ (hashq-ref
2009/7/23 Valentin Villenave v.villen...@gmail.com:
do you want me to open a Started page in the tracker to keep track
of this patch?
Cheers for the offer, but I don't think it's necessary. Once I've
dealt with Carl's comments on the latest patch, I think it'll be ready
for pushing. Then we
2009/7/24 Carl Sorensen c_soren...@byu.edu:
type check also for settings?
Settings needs a list? type check, and I haven't seen one available
in c++. It shouldn't segfault, because we do a pair check before we
use it.
ly_is_list (which is a wrapper for scm_list_p) (but see below)
I
Reviewers: joeneeman,
http://codereview.appspot.com/96083/diff/1/8
File lily/pango-font.cc (right):
http://codereview.appspot.com/96083/diff/1/8#newcode351
Line 351: // options.
On 2009/07/21 18:43:10, joeneeman wrote:
Could you please have a look at this? (after applying this patch, if
you
Neil Puttock wrote:
Not quite:
indentation
whitespace/indentation
missing ref-ify
indentation
Thanks, Neil. My editor does confusing things with tabs.
I hate them. Who would object if I just started running
tabs-spaces on the source docs? I think we should have
a strict no-tabs rule. And
I've uploaded the patch for review at
http://codereview.appspot.com/97119
It's pretty huge, but many of the changes are just due to changes in the
properties that control vertical spacing. Also, annotate-spacing is
broken, but the fixes for that should be confined to scm/page.scm.
Joe
We all okay with this patch?
Of course it's a new command and a syntax change; I don't know if
that means some special process has to be taken; updating the
parser, etc. I have no idea, actually. Let me know.
Thanks.
- Mark
0001-Add-dynamic-script-f-update-docs.patch
Description:
I've uploaded the patch for review at
http://codereview.appspot.com/97119
Since I don't understand the code at all, I've only a minor comment:
Please use two spaces after a full stop in documentation strings for
consistence.
Thanks for your hard work!
Werner
On Fri, Jul 24, 2009 at 06:15:31PM -0700, Mark Polesky wrote:
Thanks, Neil. My editor does confusing things with tabs.
I hate them. Who would object if I just started running
tabs-spaces on the source docs? I think we should have
a strict no-tabs rule. And I'm in good company:
Graham Percival wrote:
On Fri, Jul 24, 2009 at 06:15:31PM -0700, Mark Polesky wrote:
Thanks, Neil. My editor does confusing things with tabs.
I hate them. Who would object if I just started running
tabs-spaces on the source docs? I think we should have
a strict no-tabs rule. And I'm in
On Fri, Jul 24, 2009 at 10:30:30PM -0700, Graham Percival wrote:
On Fri, Jul 24, 2009 at 06:15:31PM -0700, Mark Polesky wrote:
Thanks, Neil. My editor does confusing things with tabs.
I hate them. Who would object if I just started running
tabs-spaces on the source docs? I think we should
30 matches
Mail list logo
