On Thu, Aug 06, 2009 at 12:12:59AM +0100, Ian Hulin wrote:
> This is AU section 3.2.1
--
> If ‘filename.ly’ contains more than one \score block, then the rest of the
> scores will be output in numbered files, starting with ‘filename-1.pdf’.
--
> This is a regression: you need to use \book
On Wed, Aug 05, 2009 at 08:06:43PM +0200, John Mandereau wrote:
> I'm currently updating master with changes in current web-gop
> (d6a6b62af6b8d92dea7d8b6ab02cdc99eb6c5dd3). Please no longer push new
> changes to this branch; note I made many adjustments in file paths and
> in Texinfo stuff for pr
2009/8/5 John Mandereau :
> dots.ly before
> dots.ly after
>
> collision-mesh.ly before
> collision-mesh.ly after
I think even this simple case might fail if the dots were placed in
the Voice context:
<< c''4. \\ b'4. >>
In the example that Mark found, the non-aligned notes are certainly
superior
Neil Puttock wrote:
> Try running `collision-mesh.ly' to see what happens. :)
Okay, so dots.ly looks better and collision-mesh.ly looks worse.
So what's the solution? This is probably ridiculous, but if there
were some way to test for meshing, so that the Dot_column_engraver
would stay in Staff..
Hello,
I need this patch to run ./autogen.sh with the latest Autoconf version
(2.64). The only earlier version I am able to test is 2.63, which
works fine with the patch.
The warnings I am seeing and workarounds are here:
http://www.gnu.org/software/hello/manual/autoconf/Expanded-Before-Require
> I am top posting.
This is an example of something that should be sent to lilypond-devel,
rather than to the frogs list. There are many developers who are not on the
frogs list.
Therefore, I've forwarded this to the -devel list.
Thanks,
Carl Sorensen
On 8/5/09 5:12 PM, "Ian Hulin" wrote:
Le mercredi 05 août 2009 à 22:13 +0100, Neil Puttock a écrit :
> Try running `collision-mesh.ly' to see what happens. :)
Indeed :-P
dots.ly before
dots.ly after
collision-mesh.ly before
collision-mesh.ly after
John
<><><><>
signature.asc
Description: Ceci est une partie de message numé
2009/8/5 Mark Polesky :
> Then is there a way to access the current (not default) layout?
I don't think so. Even ly:grob-layout seems to return the default layout.
> Or are you saying that (context-has-engraver? ctx sym) isn't
> possible?
It works fine unless you use \with, then it won't pick
Mark Polesky wrote:
> > > Try running `collision-mesh.ly' to see what happens. :)>
> > Where's that?
>
> Oh, I see, it's a regression test. How do I run a regression test?
Oh, right.
I think I'm going to stop now, since I'm clearly just being stupid.
Sorry.
- Mark
Mark Polesky wrote:
> > Try running `collision-mesh.ly' to see what happens. :)>
> Where's that?
Oh, I see, it's a regression test. How do I run a regression test?
- Mark
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.
2009/8/5 Mark Polesky :
> Where's that?
http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=blob;f=input/regression/collision-mesh.ly;h=53b02aa4cbda8e1c8834a72046b980d500a5a975;hb=HEAD
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lis
Neil Puttock wrote:
> Try running `collision-mesh.ly' to see what happens. :)
Where's that?
- Mark
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Neil Puttock wrote:
> Unfortunately, this doesn't seem particularly useful, since you need
> access to the correct output-def: $defaultlayout won't pick up a
> Span_arpeggio_engraver in the Staff context if it's been added using
> \with.
Then is there a way to access the current (not default) la
2009/8/5 Mark Polesky :
> I didn't, but unfortunately my system can hardly do anything these
> days... If someone else would like to run the regtests with this
> change, that would be great.
Try running `collision-mesh.ly' to see what happens. :)
Regards,
Neil
_
2009/8/5 Mark Polesky :
> Is it possible to write a scheme procedure to test if a given
> context contains a particular engraver? Like...
> (context-has-engraver? context 'Span_arpeggio_engraver)
>From engraver-doc-string:
(if in-which-contexts
(let* ((layout-alist (ly:output-descr
Han-Wen Nienhuys wrote:
> > I'm
> > thinking that Dot_column_engraver may be better suited in the
> > Voice context than in the Staff context.
>
> I suspect that this will give many collisions (dots on top of
> noteheads) when this is combined with polyphonic chords. Did you
> runthis through t
Reinhold Kainhofer wrote:
> Have you entered a wrong password more than three times? If the server runs
> denyhosts, it will then add the IP address to /etc/hosts.deny and you won't
> be
> able to connect...
I don't ever recall entering a password anywhere except at
savannah.gnu.org. How can
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am Mittwoch, 5. August 2009 22:07:16 schrieb Trevor Daniels:
> Mark Polesky wrote Wednesday, August 05, 2009 8:21 PM
>
> > I've not been able to connect to git via SSH since Saturday,
> > and nothing I've tried
> > has worked. I'd like to take care of
Mark Polesky wrote Wednesday, August 05, 2009 8:21 PM
I've not been able to connect to git via SSH since Saturday,
and nothing I've tried
has worked. I'd like to take care of
that first, but I'm out of ideas.
Can you remind us what you have tried
so far?
Re-boot (obviously yes?)
Obtain fre
On Wed, Aug 5, 2009 at 12:46 PM, Mark Polesky wrote:
> On the user list, Nick Payne shed light on a potential problem
> with the Dot_column_engraver.
> http://lists.gnu.org/archive/html/lilypond-user/2009-08/msg00132.html
>
> Looking at an example from Ted Ross (see attached png), I'm
> thinking th
Le mercredi 05 août 2009 à 09:09 +0100, Trevor Daniels a écrit :
> Any further thoughts?
At least one of the terms listed by Mark is introduced in the Learning
Manual: "grob" in 4.1.2 Objects and interfaces. I see this glossary
could be a quick reference that briefly defines each term and gives
c
Valentin Villenave wrote:
> Mark, can you make this change on your own, modify the documentation
> accordingly (don't forget NEWS), and make sure it doesn't break
> anything (esp. wrt regtests)? If you do all of this, I think it should
> be safe for you to push the change (if any problem occurs l
Carl Sorensen wrote Wednesday, August 05, 2009 3:07 PM
On 8/5/09 7:22 AM, "Trevor Daniels" wrote:
I think it was a pity that the groundwork
for a more generic approach was not laid
down right away, so we could have easily
added the aliases for all the other uses
of crossheads
I'll try to g
Le lundi 03 août 2009 à 22:32 -0700, Graham Percival a écrit :
> The general steps are:
> 1) copy snippet from Documentation/snippets/ to new/
> 2) remove any non-english texidoc?? items from the \header
> 3) edit file at will
> 4) run makelsr.py without arguments
>
> I'm not certain if these step
The web site in Texinfo is on master now, except the examples (see my
other email). All of what I could think of the technical status and
to-do is in the commmit message. There are many regressions compared to
the output , but my goal is to have no regressions (and even bugfixes)
compared to the
2009/8/5 Mark Polesky :
> Looking at an example from Ted Ross (see attached png), I'm
> thinking that Dot_column_engraver may be better suited in the
> Voice context than in the Staff context.
Mark, can you make this change on your own, modify the documentation
accordingly (don't forget NEWS), and
The new directory Documentation/examples that was proposed to host
examples for the web site plays a duplicate role of input/ and
input/mutopia. What about cleaning up these two directories (that is,
deleting unused input files and cleaning up makefiles) and use input/
instead of creating a new di
Hello all,
I want to [automagically] conditionally eliminate lyric extenders when
(1) the end of the syllable which has the extender is after
[i.e., to the right of] the melisma's last note; and,
(2) the distance to the following syllable is less than the
minimum extender length [plus
dem...@suffolk.lib.ny.us schrieb:
Please dont rename the cross head, it has a name, predating any usage
stemming from rock musicians jargon. That name is further 'blessed' by
the unicode standard, "Musical Symbol X Notehead", 1D143.
I think Lilypond should propose both, the "official", s
> Looking at an example from Ted Ross (see attached png), I'm
> thinking that Dot_column_engraver may be better suited in the
> Voice context than in the Staff context.
Good idea.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
htt
This question is already buried in this post:
http://lists.gnu.org/archive/html/lilypond-devel/2009-08/msg00154.html
I'm starting a new thread to make it more visible.
Is it possible to write a scheme procedure to test if a given
context contains a particular engraver? Like...
(context-has-engra
On Wed, Aug 5, 2009, Carl Sorensen said:
>
>
>
> On 8/5/09 7:22 AM, "Trevor Daniels" wrote:
>
>>>
>>> In the meantime, we can move forward on tablature.
>>>
>>> As I see it, the current decision causes problems only if we were
>>> to change
>>> to xHead in the future and eliminate deadNote
Mark Polesky writes:
> On the user list, Nick Payne shed light on a potential problem
> with the Dot_column_engraver.
> http://lists.gnu.org/archive/html/lilypond-user/2009-08/msg00132.html
>
> Looking at an example from Ted Ross (see attached png), I'm
> thinking that Dot_column_engraver may be
On the user list, Nick Payne shed light on a potential problem
with the Dot_column_engraver.
http://lists.gnu.org/archive/html/lilypond-user/2009-08/msg00132.html
Looking at an example from Ted Ross (see attached png), I'm
thinking that Dot_column_engraver may be better suited in the
Voice contex
On 8/5/09 7:22 AM, "Trevor Daniels" wrote:
>>
>> In the meantime, we can move forward on tablature.
>>
>> As I see it, the current decision causes problems only if we were
>> to change
>> to xHead in the future and eliminate deadNote. And I see no plans
>> in the
>> future to eliminate dead
Trevor Daniels wrote Wednesday, August 05, 2009 9:09 AM
Trevor Daniels wrote Thursday, July 30, 2009 9:16 PM
Mark Polesky wrote Thursday, July 30, 2009 7:06 PM
It would be nice to have some central place that explains some
"internals" concepts.
...
It would be nice to have a LilyPond-speci
Carl Sorensen wrote Wednesday, August 05, 2009 1:42 PM
On 8/5/09 2:44 AM, "Trevor Daniels" wrote:
Carl, Marc
After the long discussion about naming the
new cross-head function and associated predefs
I see you have retained deadNote as the base
name.
I thought the outcome of the discussion
Carl Sorensen wrote Wednesday, August 05, 2009 1:42 PM
On 8/5/09 2:44 AM, "Trevor Daniels" wrote:
Carl, Marc
After the long discussion about naming the
new cross-head function and associated predefs
I see you have retained deadNote as the base
name.
I thought the outcome of the discussion
On 8/5/09 2:44 AM, "Trevor Daniels" wrote:
> Carl, Marc
>
> After the long discussion about naming the
> new cross-head function and associated predefs
> I see you have retained deadNote as the base
> name.
>
> I thought the outcome of the discussion
> was to use xHead or crossHead for the b
Trevor Daniels schrieb:
Carl, Marc
After the long discussion about naming the
new cross-head function and associated predefs
I see you have retained deadNote as the base
name.
I thought the outcome of the discussion
was to use xHead or crossHead for the base
name with deadNote being defined to
2009/8/5 Graham Percival :
> Ok, I think we have enough positive, and no negative, responses.
> Valentin, could add this to the tracker, so that we can lose it?
"So that we _can_ lose it"? :-)
There you go: http://code.google.com/p/lilypond/issues/detail?id=825
Regards,
Valentin
__
Carl, Marc
After the long discussion about naming the
new cross-head function and associated predefs
I see you have retained deadNote as the base
name.
I thought the outcome of the discussion
was to use xHead or crossHead for the base
name with deadNote being defined to invoke
the base function
Trevor Daniels wrote Thursday, July 30, 2009 9:16 PM
Mark Polesky wrote Thursday, July 30, 2009 7:06 PM
It would be nice to have some central place that explains some
"internals" concepts. Here are examples of things that a new
developer
might have to ask about, or perhaps spend a long time
43 matches
Mail list logo
