Thanks for the comments!
Below I have a question about commonx - the other fix will be easy to
implement.
http://codereview.appspot.com/4237057/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reviewers: hanwenn,
Message:
Thanks for the comments!
Below I have a question about commonx - the other fix will be easy to
implement.
http://codereview.appspot.com/4237057/diff/1/lily/beam.cc
File lily/beam.cc (right):
http://codereview.appspot.com/4237057/diff/1/lily/beam.cc#newcode173
lily/
Janek Warchoł wrote Wednesday, March 09, 2011 11:11 PM
next thing is to decide what the output of { c32 c[ c] c64 c[ c] }
should
be.
Currently the stems of unbeamed notes are lenghtened to middle
line only
("current output.png").
In my opinion this looks weird, i'd suggest something like
"s
Hi guys,
I used to use the attached script to help me merging master and
lilypond/translation (and I'm using it to build fresh binaries and docs
to have a look at notes on the build system). Use and adapt at your own
risk (you may need to create appropriate directories for build dir and
log files
Il giorno ven, 04/03/2011 alle 12.16 +, Graham Percival ha scritto:
> There is widespread dissatisfaction with our current build system.
> Replacing it is estimated to take at least 200 hours, but that's a
> total shot in the dark. However, a few people have expressed interest
> in working on
On Mar 9, 2011, at 10:17 PM, n.putt...@gmail.com wrote:
> Hi Mike,
>
> I've only given this a quick look so far, but it's looking great. :)
>
> Here are a few thoughts:
>
> The patch doesn't apply without rebasing `paper-defaults-init.ly'.
Fixed (I think).
>
> Does `annotation-whiteout' do a
2011/3/10 John Mandereau :
> Hi guys,
>
> I used to use the attached script to help me merging master and
> lilypond/translation (and I'm using it to build fresh binaries and docs
> to have a look at notes on the build system). Use and adapt at your own
> risk (you may need to create appropriate d
Gardner Read is unequivocal on stem length:
"For all note heads that lie higher than the second added space above the
staff, a downward stem touches the middle staff line".
Ditto the same rule for upward stems with note heads under the staff. So the
proposal is against his "rule".
Kurt Stone
On Mar 9, 2011, at 6:38 PM, bordage.bertr...@gmail.com wrote:
> Hi Mike,
>
> Nice job, as usual !
>
> However, I noticed some obvious problems. You probably already know
> them.
>
> Here, the padding :
> \markup {
> \footnote b c
> \footnote e f
> }
>
This is kinda sorta fixed.
> Here, the
Gardner Read does not deal much with beam placement. Kurt Stone says that the
beam in this case should straddle the middle line, which Lily does (see image).
He says that for double and multiple beams, stems are usually lengthened by
half a space for each additional beam, but when 3 or more be
> Gardner Read does not deal much with beam placement. Kurt Stone
> says that the beam in this case should straddle the middle line,
> which Lily does (see image). He says that for double and multiple
> beams, stems are usually lengthened by half a space for each
> additional beam, but when 3 or
There is still a vertical spacing bug in the footnotes :
\markup {
\footnote e e
\footnote e ef
}
There should be a fixed distance between the baseline and the number.
For the thin space, I meant in-text words and numbers :
Cromorne ²
Which is more elegant than :
Cromorne ²
or
Cromorne²
Rega
- Original Message -
From: "Werner LEMBERG"
To:
Cc: ;
Sent: Thursday, March 10, 2011 10:54 AM
Subject: Re: shortened flags affair, part 5 - length of notes extending far
from staff
Gardner Read does not deal much with beam placement. Kurt Stone
says that the beam in this case s
"m...@apollinemike.com" writes:
> 10 is the magic threshold for cataclysmic footnote failure. There is
> currently no sure fire way to get LilyPond to anticipate a footnote's
> eventual width and to deal w/ it accordingly.
>
> I don't think this is a prohibitive gotchya, but it is super annoying
On Mar 10, 2011, at 12:02 PM, bordage.bertr...@gmail.com wrote:
> There is still a vertical spacing bug in the footnotes :
> \markup {
> \footnote e e
> \footnote e ef
> }
> There should be a fixed distance between the baseline and the number.
>
The problem is that Lilypond processes graphical
>> I think: We are talking about stem lengths for notes with three or
>> more ledger lines.
>
> As far as I can see from the books, that makes almost no difference.
> Stems for unbeamed notes still touch the middle staff line.
I agree. Sorry for being imprecise: I was talking about the beamed
st
- Original Message -
From: "Werner LEMBERG"
To:
Cc: ;
Sent: Thursday, March 10, 2011 11:46 AM
Subject: Re: shortened flags affair, part 5 - length of notes extending far
from staff
I think: We are talking about stem lengths for notes with three or
more ledger lines.
As far as I
- Original Message -
From: "Werner LEMBERG"
To:
Cc: ;
Sent: Thursday, March 10, 2011 12:09 PM
Subject: Re: shortened flags affair, part 5 - length of notes extending far
from staff
As far as I can see from the books, that makes almost no difference.
Stems for unbeamed notes still
On Thu, Mar 10, 2011 at 10:56:01AM +0100, John Mandereau wrote:
> Il giorno ven, 04/03/2011 alle 12.16 +, Graham Percival ha scritto:
> > There is widespread dissatisfaction with our current build system.
> > Replacing it is estimated to take at least 200 hours, but that's a
> > total shot in t
Il giorno gio, 10/03/2011 alle 12.25 +, Graham Percival ha scritto:
> IMO
>
> $(outdir)/%.gif: %.xpm
> xpmtoppm $< | ppmtogif > $@
>
> counts as "difficult".
Right, it's not complicated but as you pointed out it's cryptic.
> So does
>
> ls $(OUT)/$$l/*.html | xargs
On 11-03-10 02:56 AM, John Mandereau wrote:
How much interest is there in having a very general picture (possibly
without quoting directly the makefiles) about the stepmake layer (i.e.
makefiles build, recursive make (both inside same directory and in
dubdirectories)), about the flaws (and desire
Ok, time's over with no objections. Could you please push this?
http://codereview.appspot.com/4253061/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Hello,
---tiny example---
\version "2.13.53"
{ c1^\markup { \sans "word" } }
---snip---
Gives the following error in the log
# -*-compilation-*-
Processing `C:/Users/james/Desktop/test.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...
Finding the ideal number o
On Thu, Mar 10, 2011 at 02:27:33PM +, James Lowe wrote:
> ---tiny example---
Perfect!
> \version "2.13.53"
>
> { c1^\markup { \sans "word" } }
>
> ---snip---
>
> Gives the following error in the log
Bug Squad: priority-critical, type-build.
Cheers,
- Graham
_
>>> As far as I can see from the books, that makes almost no difference.
>>> Stems for unbeamed notes still touch the middle staff line.
>>
>> I agree. Sorry for being imprecise: I was talking about the beamed
>> stems.
>>
>>
>> Werner
>>
>
> Again - makes no difference, once the note mean is b
pkx166h wrote:
>
>
> \version "2.13.53"
>
> { c1^\markup { \sans "word" } }
>
>
>
> ---snip---
>
>
>
> Gives the following error in the log
>
>
>
no problem over here (windows vista. lp-version 2.13.53)!
--
View this message in context:
http://old.nabble.com/using-%5Csans-on-Windows
Hello
)-Original Message-
)From: lilypond-devel-bounces+james.lowe=datacore@gnu.org
)[mailto:lilypond-devel-bounces+james.lowe=datacore@gnu.org] On
)Behalf Of -Eluze
)Sent: 10 March 2011 15:13
)To: lilypond-devel@gnu.org
)Subject: Re: using \sans on Windows gives 'gs' error (2.13.5
- Original Message -
From: "-Eluze"
To:
Sent: Thursday, March 10, 2011 3:13 PM
no problem over here (windows vista. lp-version 2.13.53)!
Ditto. Vista. Possibly a problem with which fonts are installed?
--
Phil Holmes
___
lilypond-dev
I'm wondering if we really need translated html pages for Internals
Reference, which contain only untranslated material.
with 209Mb, internals/ directory is the biggest in
out-www/offline-root/Documentation/ but it contains copies for every
language, which differ only at localized footers. A PDF
2011/3/10 Francisco Vila :
> I'm wondering if we really need translated html pages for Internals
> Reference, which contain only untranslated material.
>
> with 209Mb, internals/ directory is the biggest in
> out-www/offline-root/Documentation/ but it contains copies for every
> language, which dif
Dear Mr Klein,
forwarding your request to the development community.
> Could I ask you for other improvement? I need two new mensural clef glyphs,
> which you can see in this picture:
> http://gregoriana.sk/gg/wp-content/uploads/p1020924.png
> The G and C clefs are what I am interested in.
>
> If
Hello
)-Original Message-
)From: lilypond-devel-bounces+james.lowe=datacore@gnu.org
)[mailto:lilypond-devel-bounces+james.lowe=datacore@gnu.org] On
)Behalf Of Phil Holmes
)Sent: 10 March 2011 16:41
)To: -Eluze; lilypond-devel@gnu.org
)Subject: Re: using \sans on Windows gives 'gs'
On 3/10/11 10:39 AM, "Benkő Pál" wrote:
> Dear Mr Klein,
>
> forwarding your request to the development community.
>
>> Could I ask you for other improvement? I need two new mensural clef glyphs,
>> which you can see in this picture:
>> http://gregoriana.sk/gg/wp-content/uploads/p1020924.png
>
Jan,
Commits e5380f2 and 8dc343b break the MIDI output from all the examples in the
documentation that use midiInstrument, and the regtest
‘midi-volume-equaliser.ly’. The midi output is much less useful for
proofreading, because all the voices sound the same.
The problem is that the all sett
Keith OHara schreef op do 10-03-2011 om 10:40 [-0800]:
> Commits e5380f2 and 8dc343b break the MIDI output from all the
> examples in the documentation that use midiInstrument, and the regtest
> ‘midi-volume-equaliser.ly’. The midi output is much less useful for
> proofreading, because all the
http://codereview.appspot.com/4248081/
Doc: Added @knownissue to NR for fingering
By default double-digit fingering (i.e. >9) is not possible using
normal fingering markups. There is an LSR that has been posted for approval
at the time of this patch, and will be included in the snippet link in th
On 10 March 2011 19:57, Jan Nieuwenhuizen wrote:
> It works for me, and I think Neil also could not confirm this, so]
I'm afraid I can now (I was puzzled by Keith's report initially since
I'd only tested midiInstrument settings on a single stave).
All staves default to channel 0 for midi instru
Neil Puttock schreef op do 10-03-2011 om 20:11 [+]:
> On 10 March 2011 19:57, Jan Nieuwenhuizen wrote:
> All staves default to channel 0 for midi instruments (since channel_
> is never set).
I see, whenever a new channel is opened (for a new voice)
by the staff-performer, it should also set
LGTM.
http://codereview.appspot.com/4248081/diff/1/Documentation/notation/editorial.itely
File Documentation/notation/editorial.itely (right):
http://codereview.appspot.com/4248081/diff/1/Documentation/notation/editorial.itely#newcode217
Documentation/notation/editorial.itely:217: By default, n
>>> Could I ask you for other improvement? I need two new mensural clef glyphs,
>>> which you can see in this picture:
>>> http://gregoriana.sk/gg/wp-content/uploads/p1020924.png
>>> The G and C clefs are what I am interested in.
>>>
>>> If you could do it, I can offer you to pay for it. Would it b
LGTM
Trevor
http://codereview.appspot.com/4248081/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
On 10 March 2011 21:04, Jan Nieuwenhuizen wrote:
> I see, whenever a new channel is opened (for a new voice)
> by the staff-performer, it should also set the instrument
> there. Actually, that's nicer than doing it in
> Staff_performer::process_music ()
Doesn't that still fall foul of the lack
James Lowe writes:
> http://codereview.appspot.com/4248081/
>
> Doc: Added @knownissue to NR for fingering
>
> By default double-digit fingering (i.e. >9) is not possible using
> normal fingering markups. There is an LSR that has been posted for approval
> at the time of this patch, and will be i
On Thu, 10 Mar 2011 14:11:43 -0800, James Lowe wrote:
\noBreak does little or nothing and trying to expand the MMR does
virtually nothing until I use ridiculous numbers and then it just springs
the two bars on a line on their own.
Golly gee!
\noBreak and/or 'line-break-permission had the des
On Thu, 10 Mar 2011 11:57:48 -0800, Jan Nieuwenhuizen wrote:>
Commits e5380f2 and 8dc343b break the MIDI output from all the
examples in the documentation that use midiInstrument, and the regtest
‘midi-volume-equaliser.ly’.
It works for me, [...]
Oh! Thanks for checking.
Maybe your midi p
On 2011/03/07 19:48:23, J_lowe wrote:
Layout wise - Looks fine.
Colin,
From: Colin Campbell [mailto:c...@shaw.ca]
Sent: 10 March 2011 13:57
To: James Lowe
Subject: Fwd: part combine doc patch
Good morning, James
Attached is a patch which needs pushing, if you would oblige
---
Pu
On Thu, 10 Mar 2011 14:11:43 -0800, James Lowe wrote:
I can only describe this as like nailing jelly to a wall.
It's wrecked a load of my scores, and I've taken hours more time getting
what was pretty good in 2.13.40 back to a 'still a bit rubbish' in 2.13.51.
It is probably not worth the ef
47 matches
Mail list logo
