2009/7/24 Graham Percival :
> 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 input/lsr/) into
On Thu, Jul 23, 2009 at 10:15:09PM -0600, Carl Sorensen wrote:
>
> On 7/23/09 9:47 PM, "Graham Percival" wrote:
>
> > 2) modify the input/new/ file to say:
> > \markup{ this snippet has been deprecated and will be removed in 2.14}
> > and delete the rest of the file. (other than the header)
>
Werner LEMBERG wrote:
> > Instead of documenting this in the IR, maybe it would be better to
> > write a section in the CG about how to find a grob's parent, the
> > parent's parent, etc. with GDB?
>
> Hmm. Any chance to have this in Scheme?
Werner,
Here's one way of doing it (from within a musi
> Instead of documenting this in the IR, maybe it would be better to
> write a section in the CG about how to find a grob's parent, the
> parent's parent, etc. with GDB?
Hmm. Any chance to have this in Scheme?
Werner
___
lilypond-devel mailing l
On 7/23/09 9:47 PM, "Graham Percival" wrote:
> 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
>
> See below.
>
>> They will be
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
See below.
> They will be obsolete for 2.13.4 and cause problems in making documentation.
On Thu, Jul 23, 2009 at 07:21:54PM -0700, Mark Polesky wrote:
>
> Patrick McCarty wrote:
> > Instead of documenting this in the IR, maybe it would be better
> > to write a section in the CG about how to find a grob's parent,
> > the parent's parent, etc. with GDB?
>
> I know nothing about GDB...
Dear LSR editors (Neil or Valentin, IIRC),
Please remove the docs tags from the following snippets:
Specifying context with beatGrouping
Using beatLength and beatGrouping
They will be obsolete for 2.13.4 and cause problems in making documentation.
This shows a very interesting problem. We onl
On Thu, Jul 23, 2009 at 07:16:24PM -0700, Mark Polesky wrote:
> Since I'm relatively new to the whole pushing to git thing, I've
> been intentionally stepping cautiously, running every little patch
> by you guys, so as not to break anything. I've attached a totally
> trivial patch, and I'm wonderin
Patrick McCarty wrote:
> Depending on the situation, grobs may change parents.
Darn.
> Instead of documenting this in the IR, maybe it would be better
> to write a section in the CG about how to find a grob's parent,
> the parent's parent, etc. with GDB?
I know nothing about GDB...
> Plus, I c
Since I'm relatively new to the whole pushing to git thing, I've
been intentionally stepping cautiously, running every little patch
by you guys, so as not to break anything. I've attached a totally
trivial patch, and I'm wondering if you guys would rather I just
apply small things like this without
Hi Mark,
On Thu, Jul 23, 2009 at 02:11:47PM -0700, Mark Polesky wrote:
>
> Does a grob-type always have the same set of parent-types?
No, I don't think so. [see below]
> For example, does an Accidental grob always have X-parent
> AccidentalPlacement and Y-parent NoteHead?
Yes, this appears to
Carl Sorensen byu.edu> writes:
>
> Somehow I've broken the build on my system. It used to work, but
> now it
> fails when it tries to build the lexer.
>
It turns out that somehow my config.make got rebuilt. When that
happened, the FLEXLEXER_FILE variable went back to
/usr/include/FlexLex
Does a grob-type always have the same set of parent-types?
For example, does an Accidental grob always have X-parent
AccidentalPlacement and Y-parent NoteHead? If so, could this
information be incororated into the IR? It took me a while
before I was able to figure this sort of thing out:
Valentin Villenave wrote:
> 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
Wow,
an hour and a half from request to snippet. Nice work. I al
On Wed, Jul 22, 2009, David Kastrup said:
> writes:
>
>> On Wed, Jul 22, 2009, Trevor Daniels said:
> There are instrument-dependent "thresholds of pain" involved: singers'
> clefs will just not change in midpiece. ...
actually, speaking as a singer with decades experience, they do change f
Somehow I've broken the build on my system. It used to work, but now it
fails when it tries to build the lexer.
I've used git to go back to known-good source trees, e.g.
git checkout 062046e74d6995b99bb7669e4cd6490ba8b18656
which I have built before.
But now,
make clean
make
exits with the
2009/7/15 Neil Puttock :
> A new patch set is available here:
>
> http://codereview.appspot.com/8874/show
Hi Neil,
do you want me to open a "Started" page in the tracker to keep track
of this patch?
Regards,
Valentin
___
lilypond-devel mailing list
li
2009/7/23 Michael Käppler :
> after transcribing some baroque vocal and instrumental pieces I noticed that
> one articulation sign is used very often, but not provided by lilypond. It
> looks simply like a line, vertically placed above the note head.
Greetings,
here is how to achieve what you're l
Hi all,
after transcribing some baroque vocal and instrumental pieces I noticed
that one articulation sign is used very often, but not provided by
lilypond. It looks simply like a line, vertically placed above the note
head. One could confuse it with the \staccatissimo symbol, which looks
more
20 matches
Mail list logo