Thanks Keith - checked and pushed to origin/master.
Trevor
- Original Message -
From: "Keith OHara"
To: ; ;
; ;
; ;
Cc: ;
Sent: Thursday, December 23, 2010 11:02 PM
Subject: Re: DOC: NR Dynamics context and postfix dynamics
(issue3743045)
Origin
;t change shape.
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
I agree. The predefined commands that exist are
useful because the preceding direction indicator
may be omitted, but it may not be omitted from a
\markup.
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
mean
either
"down" or "left" and either "up" or "right", but in this table
we're
*only* documenting objects that are aligned vertically!
I think I wrote the heading as it is because down stems are on the
left
and up stems on
tindex fn
I think it is to get round the vagaries of @syncodeindex. See
http://lists.gnu.org/archive/html/lilypond-devel/2006-05/msg00275.html
Graham might remember ...
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists
Phil Holmes wrote Friday, December 17, 2010 10:12 AM
From: "Trevor Daniels"
64 bit vista. 6 Gigs RAM. The odd 1 Gig for a VM has no effect
:-)
Lucky you ! It certainly does on my 3Gb laptop (at its maximum).
Trevor
___
lily
ing hammered
all the time. So, to answer your question, doc work under Windows
works best, at least for me, and is easier to set up and use.
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
grep rhythms
produces
Documentation/de/notation/rhythms.itely
Documentation/es/notation/rhythms.itely
Documentation/fr/notation/rhythms.itely
Documentation/notation/rhythms.itely
Replacing -o with -or gives the same output.
Is this as you would expect?
Trevor
___
You could argue
that this should be in a separate test, but why not
combine them?
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
vertical
whitespace between the skylines of two items, measured in
staff-spaces.
Carl Sorensen wrote:
I prefer 2.
Trevor Daniels wrote:
2, but is "skylines" explained anywhere in the docs? If
it is, it is not indexed.
Interesting. I just assumed you'd both prefer #1, be
amount of vertical whitespace
between the skylines of two items, measured in staff-spaces.
2, but is "skylines" explained anywhere in the docs? If it is, it
is not
indexed.
Trevor
___
lilypond-devel mailing list
lilypond-devel@gn
Neil
http://codereview.appspot.com/3406041/diff/6001/Documentation/notation/spacing.itely#newcode1297
Documentation/notation/spacing.itely:1297: c4 c c~ | \break %
this
\break works
On 2010/12/02 08:34:52, Trevor Daniels wrote:
indent; needs another c
adding another c will make the break
te to push
the most recent history once passwords and all that jazz is
working
again.
Looks like Valentin is best placed to do this.
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
nt experts,
who might be working on critical problems, diverted
to sort out bugs in new code. Branching 2.14 now
would prevent new, relatively untested, code going
into it, while not holding up development in 2.15.
Trevor
___
lilypond-devel maili
ly in 2011. Announce (to development) a target date
for releasing 2.14.0, say 15 Jan 2011, to encourage work on
bugs, translations, docs, etc over this period.
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/ma
Graham Percival wrote Saturday, November 27, 2010 12:59 AM
On Fri, Nov 26, 2010 at 11:31:06PM +0100, Valentin Villenave
wrote:
On Fri, Nov 26, 2010 at 10:41 PM, Trevor Daniels
wrote:
> OK; I agree. Patch looks good.
Thanks! I've pushed this patch, and merged translation onto
sn't the 0 fingering in the Staff equally incorrect?
As it is impossible to determine whether the pitch
or the fingering is wrong this should really be
classed as a syntax error - the combination is invalid.
Trevor
___
lilypond-devel mailin
ensures
bad breaks can't occur, even if the name is quite short.
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Valentin Villenave wrote Friday, November 26, 2010 10:31 PM
Thanks! I've pushed this patch, and merged translation onto master
Great! Appreciated!
On Fri, Nov 26, 2010 at 10:41 PM, Trevor Daniels
wrote:
Ideally, yes. But who is going to look manually through
all the docs?
ugh
all the docs? Better to do it automatically first, then
fix up any that stand out as poor when we notice them.
Otherwise we might have some names running over the right
margin in 2.14. Don't forget we've now lost the ones
tha
Valentin Villenave wrote Friday, November 26, 2010 5:51 PM
On Fri, Nov 26, 2010 at 4:47 PM, Trevor Daniels
wrote:
Long entries are those who contain either more than one dash or
more
that :)
than one slash (not counting "../").
Er, are you suggesting that
@file{this/is/a/very
@seealso sections should not contain @/
escaping,
no matter how long they are.]
Tick
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
to address it as
quickly
and discretely as possible, and pushed it elsewhere than master.
It's already been merged into master :(
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
ntDefinition #"tenor"
#`(( ... )
(instrumentCueName . "Tenor")
( ... ))
... % use "Tenor"
\set instrumentCueName = "Ten."
... % use "Ten."
\unset instrumentCueName
... % use "Tenor"
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
tch 1
0 0))
{...}
Would it not be better to define these properties using
\addInstrumentDefinition #"flute" ...
and then simply refer to "flute" in \cueDuring, as
\instrumentSwitch does?
Trevor
___
lilypond-devel mailing
ssible and acceptable with the
usual overrides. There is an example of the use of
cues for this purpose in the Musical cues section of
recent versions of NR 2.1.6 Vocal music.
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.o
Trevor Daniels wrote Sunday, November 21, 2010 11:58 PM
Graham Percival wrote Sunday, November 21, 2010 11:18 PM
On Sun, Nov 21, 2010 at 09:38:42AM -, Trevor Daniels wrote:
Graham Percival wrote Saturday, November 20, 2010 8:40 PM
>Who wants to edit the CG for this? James is a
Graham Percival wrote Sunday, November 21, 2010 11:18 PM
On Sun, Nov 21, 2010 at 09:38:42AM -, Trevor Daniels wrote:
Graham Percival wrote Saturday, November 20, 2010 8:40 PM
>Who wants to edit the CG for this? James is away for a few
>days,
>so there's no point l
lease check the commit to be sure you're happy
with this. bf4298556820ead4deff2d667c362c2d7d045e67
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Graham Percival wrote Saturday, November 20, 2010 8:40 PM
On Sat, Nov 20, 2010 at 08:29:35AM -, Trevor Daniels wrote:
Graham Percival Saturday, November 20, 2010 12:44 AM
>@itemize
>@item
>foo far
This is best, but I'd prefer a blank line before and after every
@item
Trevor Daniels wrote Saturday, November 20, 2010 8:29 AM
Graham Percival Saturday, November 20, 2010 12:44 AM
On Fri, Nov 19, 2010 at 08:55:26AM -0800, Mark Polesky wrote:
CG 4.3.6 says:
"Always put �...@item’ on its own line, and separate
consecutive items with a blank line."
I
emize
@item foo
far
No, I don't like this. Too cluttered.
or
@itemize
@item
foo far
This is best, but I'd prefer a blank line before and after every
@item
including the first one (IOW after @itemize as well) as long as this
looks OK in info. That
Valentin Villenave wrote Wednesday, November 17, 2010 10:47 AM
On Wed, Nov 17, 2010 at 10:41 AM, Trevor Daniels
wrote:
Sounds like a good candidate for an enhancement request.
my brain seems to be in low-power mode today, could you help me
rephrase this request so I can add it to the
This is the second time this has come up recently.
Sounds like a good candidate for an enhancement request.
Trevor
- Original Message -
From: "jakob lund"
To:
Sent: Wednesday, November 17, 2010 9:22 AM
Subject: music function
Hi
I have two questions that I hope someon
even-header-markup
odd-footer-markup
even-footer-markup
Hopefully this doesn't require much discussion.
I'd do it now if there is no objection.
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
appear once:
That may be so, but it's a standard term in the IR
and the documentation. See IR 3.1 which is called
All layout objects.
Grob is the name of those layout objects that actually
deal with something pictorial rather than positional.
No big deal, though.
Trevor
___
hat do you think?
All LGTM. Time to get this launched, I think.
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Trevor Daniels wrote Tuesday, October 19, 2010 8:34 PM
Keith E OHara wrote Monday, October 18, 2010 11:40 PM
I suggest (diff attached) removing the part about
instrumentCueName in favor of a fuller example for \killCues.
The manual teaches markup elsewhere; the challenge with cue-note
e one more option -- just remove the "withingroup"
prefix altogether:
\override StaffGrouper #'staff-staff-spacing
\override StaffGrouper #'staffgroup-staff-spacing
Thoughts?
LGTM
(As I've said before, I admire your persistence :)
Trevor
_
Valentin Villenave wrote Monday, November 08, 2010 11:16 AM
On Mon, Nov 8, 2010 at 11:13 AM, Trevor Daniels
wrote:
There might even be an argument for adding something
which made compilation fail - in a way that clearly
indicated the problem, of course.
Bold idea... or insane, I can&#
Reinhold Kainhofer wrote Monday, November 08, 2010 12:09 AM
Am Sonntag, 7. November 2010, um 20:46:54 schrieb Trevor Daniels:
I think this would be an improvement, but I don't think it's
essential. The file will be left in an erroneous state so
the user will be forced in
Mark Polesky wrote Monday, November 08, 2010 1:24 AM
Instead of these two:
withingroup-staff-staff-spacing
staffgroup-staff-spacing
Let's stay with these.
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gn
tial. The file will be left in an erroneous state so
the user will be forced into further investigation anyway,
and the usual LilyPond error messages will indicate what is
wrong.
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lis
Graham Percival wrote Sunday, November 07, 2010 12:50 PM
On Sun, Nov 07, 2010 at 12:26:59PM -, Trevor Daniels wrote:
Valentin Villenave wrote Sunday, November 07, 2010 10:35 AM
>I'm not sure if we've ever used convert-ly to insert comments in
>.ly
>files, but I do
nce
2) initial-distanceminimum-distance
3) basic-separation minimum-separation
4) initial-separation minimum-separation
Alexander:
Carl:
David:
Joe:
Mark: 1
Trevor: 4
Valentin:
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
the 2 choices
above. I've already entered mine.
Carl:
David:
James:
Jan:
Jean-Charles:
Joe:
Keith:
Mark: 1
Trevor: 2
Valentin: 1*
Werner: 2
*was 2, then changed it to 1? Which one is it?
Trevor
___
lilypond-devel mailing list
lilypond-devel@gn
so I can't vouch for
the
accuracy of this, but I agree with inserting a comment when these
lines
are removed.
I guess this would also remove a user-defined engraver-group context
named Dynamics too, but maybe there aren't many of those and the
comment at least will raise a flag.
it
should remain open and transparent to the end.
Trevor
- Original Message -
From: "Mark Polesky"
To: "lilypond-devel" ; "Carl Sorensen"
; "Trevor Daniels"
Cc: "Joe Neeman"
Sent: Sunday, November 07, 2010 8:59 AM
Subject: Re: Renaming th
want is a but a touch more padding from
Lyrics to any non-associated grobs on the next staff.
Maybe right, but has anyone really tested all the different forms of
lyrics yet?
There might be no unique best default settings.
Trevor
___
lilypond-
separation? I prefer both to use the same noun.
Yes, it would.
I think the choice between the two comes down to how
the descriptive text looks. At present I have no
clear preference.
Trevor
___
lilypond-devel mailing list
lilypond-devel@gn
ot; is "having a relationship".
All that said, I'm not going to protest against any of the recent
proposals;
they're all an improvement over existing wording. All I have is a
preference,
nothing stronger. Others have other preferences, and, having stated
my
case, I'm happy t
* longer but describes the meaning more accurately
now we have an item-item-spacing format
I vote for 8 or 9.
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Valentin Villenave wrote Saturday, November 06, 2010 12:00 AM
On Sat, Nov 6, 2010 at 12:44 AM, David Kastrup
wrote:
"Trevor Daniels" writes:
I'd prefer to see your image in the docs rather than text.
Just be sure you look your best.
ROTFL!
Me too! Nice one, Da
Good work, Mark.
I'd prefer to see your image in the docs rather than text.
Trevor
- Original Message -
From: "Mark Polesky"
To: "lilypond-devel"
Sent: Friday, November 05, 2010 11:17 PM
Subject: solved: reference points for non-staff lines
In case an
Valentin Villenave wrote Thursday, November 04, 2010 12:10 AM
> On Thu, Nov 4, 2010 at 12:58 AM, Trevor Daniels wrote:
>>> Renaming proposals, round 3:
>>>
>>> CURRENT NAME PROPOSED NAMETD's PREFERENCE
>>> -
Carl Sorensen wrote Wednesday, November 03, 2010 11:00 PM
On 11/3/10 2:49 PM, "Mark Polesky" wrote:
Trevor wrote:
I wonder if affinity/nonaffinity are optimal. Are they
better than relatedstaff/unrelatedstaff?
Or target/opposite, reference/opposite, refstaff/oppstaff?
Actua
y a large margin.
Sorry Carl! (:
2) all the ideas for "between-staff" so far:
* names consistent with the item1-item2 format
a) groupstaff-groupstaff (Trevor)
b) groupedstaff-groupedstaff (Trevor)
c) grouped-staff-staff (Mark)
* shorter names
d)
acing between ungrouped staves too, but it doesn't. I'm
proposing 'inside-staffgroup-spacing, which is clearer (I
think) but not consistent with the "item1-item2-spacing"
format.
groupstaff-groupstaff-spacing ?
groupedstaff-groupedstaff-spacing ?
But I'm not unhappy
ect, now.
We probably should. I don't see it affecting the
fixing of the remaining critical issues much, as many
of us are unable to contribute to those anyway.
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
a way of introducing the improved syntax this LGTM.
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
wouldn't get bar-check warnings
displayed in this case?
The sentence was added by Carl on 9 Jul 2008, commit
86b87221fd0edf9a495e512247cb708cd6f4217a
Maybe he can remember why.
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
Valentin Villenave wrote Wednesday, October 20, 2010 7:48 PM
On Wed, Oct 20, 2010 at 7:20 PM, Trevor Daniels
wrote:
Many thanks for your comments. At first glance they all seem
pertinent.
I'll have a look at fixing them up tomorrow.
I've taken the liberty to apply James&#x
ead and comment down to 2.1.7.
Trevor
- Original Message -
From: "James Bailey"
To: ; "Trevor Daniels"
Sent: Wednesday, October 20, 2010 5:55 PM
Subject: NR 2.1 suggestions
These are just some things that I noticed.
2.1.1 Entering Lyrics.
Lyrics are entered in
Keith E OHara wrote Tuesday, October 19, 2010 10:34 PM
On Tue, 19 Oct 2010 13:34:05 -0700, Trevor Daniels wrote:
If no one objects soon I shall push it.
James Lowe made comments that you might not have seen yet. I see
where he is coming from, but I hope my answer explained the
purpose of
Trevor Daniels wrote Tuesday, October 19, 2010 9:35 PM
Keith E OHara wrote Tuesday, October 19, 2010 12:21 AM
Suggestions attached as a diff,
I'm happy to push this as is. Many thanks Keith.
Pushed to git pretty well as you suggested, Keith, and snippet
updated
in git.
Ch
\once \override TextScript #'direction = $dir
s1*0-\markup { \tiny $name }
$music
}
#}
)
I'm happy to push this as is. Many thanks Keith.
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
CueDuring might have been wrong
(or I interpreted it wrongly) in the case of transposing
instruments.
My suggested replacement comes from experiment and inspection of
quote-iterator.cc.
Happy to take this.
Trevor
___
lilypond-devel mailing list
Valentin Villenave wrote Monday, October 18, 2010 1:47 PM
On Mon, Oct 18, 2010 at 12:03 PM, Trevor Daniels
wrote:
There's a TODO in vocal.itely that I don't understand:
902 @c TODO: document \new Staff << Voice \lyricsto >> bug
If it really is a bug then we shoul
Valentin
There's a TODO in vocal.itely that I don't understand:
902 @c TODO: document \new Staff << Voice \lyricsto >> bug
If it really is a bug then we shouldn't be documenting
it anyway, but I'd like to know what it means first.
Do you know which
Valentin Villenave wrote Sunday, October 17, 2010 4:57 PM
On Tue, Sep 7, 2010 at 1:01 AM, Trevor Daniels
wrote:
Looks good to me. I'll confirm when the GUB
2.13.33 for Windows is available.
sorry for bumping this discussion, but: where are we wrt this
problem?
Whoops, sorry, I f
David Kastrup wrote Thursday, October 14, 2010 10:05 AM
"Trevor Daniels" writes:
Although this is a good point, the problem is not as
stark as this might suggest. There are many situations
when writing LilyPond code when score-wide settings are
inappropriate. This is ju
d a footnote
the names of the new spacing parameters would naturally
follow the new naming pattern, although I think that change
is unlikely to happen.
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Valentin Villenave wrote Wednesday, October 13, 2010 4:03 PM
Hi Trevor, here's a minor patch for Vocal music. Nothing too
extraordinary so far, I quite like what you've done!
I've done about a third of the file, I plan to work on the rest
later
(though it may have to w
ft out an image
for system, as this is defined wrt the width of the
page, which is not well-defined in the docs (the image
width is less than the page width, and the page width
is variable in html).
Trevor
___
lilypond-devel mailing list
lilypond-dev
he staves which are
grouped together. Conductor scores will usually have
one system per page; vocal scores of SATB plus piano
reduction will usually have two systems per page.
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
thinking about it in abstract.
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
te.
Next up are the 19 TODOs, and I'd like to work through them before
inviting a review of the whole chapter, although if you or anyone
else wishes to comment on the work so far I'd be happy with that
too.
Trevor
___
lilypond-devel
Mark Polesky wrote Wednesday, October 06, 2010 4:46 PM
I also think the name 'space is misleading; I propose
'default-distance. Opinions?
I'd be happy with that change too.
Mark
Trevor
___
lilypond-devel mailin
Arno Waschk wrote Wednesday, October 06, 2010 1:27 PM
why does the following:
[snip>
give a small piano part (which i expected) but a normal sized
bassPart Staff?
It does give a small bassPart here (2.13.34).
What do you have in bassPart?
Tre
eases rather than two.
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Two earlier examples use autobeaming in their cadenzas, so I
marked the two affected lines below, but this detail is not worth
much effort.
I fixed them anyway as you suggested
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
ed to as "title".
[snip]
Regardless, I prefer the consistency and predictability of
the proposed names.
Comments appreciated, thanks!
Looks a good suggestion to me, but discussion is better
deferred until GLISS is launched. Don't lose it!
Trevor
__
if there is a good
reason for the difference.
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
y
an amount y, y = sum(dy's) = -dF sum(s's)
sum(s's) is known, a constant, so that gives dF, and
then all the separate dy's can be calculated from (1).
Units are irrelevant, as it's only the ratios of the
s's that are important.
Trevor
]
otherwise the whole thing is placed in a \relative block,
which doesn't work with \score.
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
essibility, I
feel that the @example is immediately readable without the
code clutter. I'll remove it if you feel strongly.
As this is the only point of this small section
I'd prefer to keep the @example.
Okay to push?
OK by me.
Trevor
__
ainly \with clause.
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
remain available in the archives
where it can be found by others.
[Graham: I know this is, or at least was, the policy, but I don't
see it in the CG.]
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
here?
Also, if it is to go in the NR it needs a separate
section heading. At the moment it appears under
"The double backslash construct", whereas it applies
equally to explicitly instantiated voices. Maybe
something like "Voice order"?
Trevor
w this new advice! Should it be
reworked also?
[1] I like the list of voices. Also doesn't @enumerate
introduce blank lines between items? That would spoil
it.
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/m
is even more entertaining!
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Valentin Villenave wrote Wednesday, September 15, 2010 12:42 AM
On Tue, Sep 14, 2010 at 6:11 PM, Graham Percival
wrote:
On Tue, Sep 14, 2010 at 4:27 PM, Trevor Daniels
wrote:
You know, after rebuffs like this it's hardly
surprising you don't get many people offering to
help y
e to ignore this.
You know, after rebuffs like this it's hardly
surprising you don't get many people offering to
help you. Seeing this, anyone thinking of offering
will likely think again.
Trevor
___
lilypond-devel mailing list
lilypo
address can do this, and anyone can easily get a
gmail address.
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Mark Polesky wrote Sunday, September 12, 2010 7:45 PM
Is there a way to bypass the automatic "obscuring" of email
addresses on any of the mailing list servers?
There may be, but I think the recent discussions about
the mailing lists have made it pretty clear that the
LilyPond lists are not
Graham Percival wrote Saturday, September 11, 2010 8:30 PM
On Sat, Sep 11, 2010 at 9:08 AM, Trevor Daniels
wrote:
2.1.8 Opera and stage musicals ready for review
Err... 2.1.6 in today's current git? ok, doing so. I've
forgotten
anything else we've discussed about
Graham Percival wrote Saturday, September 11, 2010 8:36 PM
Does anybody deal with lilypond source code on windows itself,
instead
of lilybuntu? Trevor?
I do _all_ my doc work on Windows, with a Windows
git repository. I have ubuntu available in a
VM, but it causes a significant slow-down
Trevor Daniels Thursday, August 26, 2010 10:41 PM
Trevor Daniels wrote Thursday, August 19, 2010 6:40 PM
I've finished and pushed the first pass through 2.1.7 Choral.
I'll begin work on 2.1.9 Chants hymns and psalms next.
First pass through 2.1.9 Chants etc done.
I'll look
Graham Percival wrote Friday, August 27, 2010 9:54 PM
Pointing a psalm
- I got a bit lost here. Could you add a @lilypond to illustrate
some
(or all) of those points (no pun intended)?
I've just pushed an expanded version of this section
with several illustrative examples.
T
Trevor Daniels wrote Wednesday, September 08, 2010 12:15 AM
Graham Percival wrote Tuesday, September 07, 2010 8:14 PM
On Wed, Sep 01, 2010 at 09:15:26AM +0100, Trevor Daniels wrote:
Graham Percival wrote Friday, August 27, 2010 9:54 PM
>- can't you do \layout { \context { \dy
801 - 900 of 1867 matches
Mail list logo
