On 2010-10-28 02:30, Ralph Palmer wrote:
On Wed, Oct 20, 2010 at 9:27 AM, Valentin Villenave
mailto:valen...@villenave.net>> wrote:
Hi Alexander,
CC-ing to the bug list just in case.
On Wed, Oct 20, 2010 at 2:39 PM, Alexander Kobel mailto:n...@a-kobel.de>> wrote:
> why does L
2010/10/28 Valentin Villenave
>
> I think Graham already made my point. With Sibelius, I used to spend
> roughly an hour per *system*, tweaking everything, pushing
> accidentals, solving collisions, manually removing tuplet numbers,
> faking stuff using invisible voices that, in turn, caused new
>
On 28 Oct 2010, at 01:01, tdanielsmu...@googlemail.com wrote:
http://codereview.appspot.com/2755041/diff/22001/Documentation/notation/pitches.itely
File Documentation/notation/pitches.itely (right):
http://codereview.appspot.com/2755041/diff/22001/Documentation/notation/pitches.itely#newcode588
On 28 Oct 2010, at 06:03, percival.music...@gmail.com wrote:
http://codereview.appspot.com/2755041/diff/22001/Documentation/notation/pitches.itely#newcode41
Documentation/notation/pitches.itely:41: * Non-Western notations and
tunings::
WTM is "notations" ?
You might use "notation and tuning s
Reviewers: ,
Message:
Okay guys, here's my first draft patch for a rewrite of
NR 4.1 Paper and Pages.
Just to clarify, this is totally unrelated to my rewrite of
NR 4.4.1 Vertical spacing inside a system
(http://codereview.appspot.com/2642043/)
So, I guess this is a big patch. Sorry about that
The "Page formatting" rewrite patch is up. Anyone
interested in following the bleeding-edge spacing
docs can find them below. There still may be some
problems, though. Especially the NR 4.1 patch is
awaiting review, and is not yet verified for
accuracy. However, the level of detail is far more
Hi Patrick,
On 28/10/10 06:32, Patrick McCarty wrote:
> Hi Ian,
>
> On Wed, Oct 27, 2010 at 2:31 PM, Ian Hulin wrote:
>>
>> I've just done some stuff with this file to ensure it compiles OK when
>> running using Guile V1.9.
>>
>> It declares all it stuff in a module (define-module (scm dislplay-l
Reviewers: ,
Message:
Hi everybody,
here's a patch that should allow users to stop worrying about whether to
include fretboard diagrams before or after choosing the note names
language.
I've updated the docs accordingly; hopefully there are no other .ly
optional init files that rely on hardcode
LGTM.
However, I'm a bit nervous about putting bends as well into the
Tab_tie_follow_engraver. Not that the engraver won't work, but that the
Tab_tie_follow_engraver won't be part of the documentation.
Currently, I view Scheme engravers as a way for users (and snippets) to
add engraver function
Valentin,
This looks good to me, but I haven't run make check on it yet. It
certainly shouldn't be pushed without make check being run.
The technique of saving the language at the top of a file to be included
and restoring it at the bottom should be documented, so people know to
do it. It woul
On Thu, Oct 28, 2010 at 7:15 AM, wrote:
> There should be a space between "pitchnames" and "(ly:assoc-get"
Wow, nice catch!
Pfew. Pushed and (hopefully) closed.
Thanks everybody; now comes the documentation work!
Cheers,
Valentin.
___
lilypond-devel
On Wed, Oct 20, 2010 at 9:27 AM, Valentin Villenave
wrote:
> Hi Alexander,
>
> CC-ing to the bug list just in case.
>
> On Wed, Oct 20, 2010 at 2:39 PM, Alexander Kobel wrote:
> > why does LyricText #'font-series default to #'bold-narrow?
> >
> > First, it's counterintuitive to me to have a bold
Mark,
What a lot of work! Thanks for taking this on!
I think that this is a big improvement, because of its thoroughness.
I think that your subheadings need to become nodes (subsubsections?).
I think that it would be nice if the defaults are easily accessible in a
file somewhere to point us t
Hello,
I caught this as it was going via the terminal on a 'make doc'
Changing working directory to: `./out-www'
Processing `orchestra.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
warni
On 10/27/10 11:32 PM, "Werner LEMBERG" wrote:
>> However, I do have the original doc-build error, which would
>> presumably be the same problem as the regtest failure: [...]
>>
>> c7/lily-4bb72c87.ly
>
> The compilation of this file fails? Which snippet is that?
By looking at out/lybook-db
On Thu, Oct 28, 2010 at 3:11 PM, wrote:
> This looks good to me, but I haven't run make check on it yet. It
> certainly shouldn't be pushed without make check being run.
You're quite right.
***testing...***
OK, make check doesn't complain, and there's no difference with the
baseline (only tes
On 10/28/10 7:54 AM, "Carl Sorensen" wrote:
> On 10/27/10 11:32 PM, "Werner LEMBERG" wrote:
>>> However, I do have the original doc-build error, which would
>>> presumably be the same problem as the regtest failure: [...]
>>>
>>> c7/lily-4bb72c87.ly
>>
>> The compilation of this file fails?
I've not reviewed the code but I share Carl's concern about scheme
engravers if there is no way of documenting them in the IR. If the
grobs have any user-servicable properties they must be properly
documented.
Trevor
http://codereview.appspot.com/2191042/
_
Looks OK to me after eyeballing, but not tested.
Trevor
http://codereview.appspot.com/2791041/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Am 28.10.2010 20:34, schrieb tdanielsmu...@googlemail.com:
I've not reviewed the code but I share Carl's concern about scheme
engravers if there is no way of documenting them in the IR. If the
grobs have any user-servicable properties they must be properly
documented.
Ok, I see the point, but in
Am 28.10.2010 14:53, schrieb carl.d.soren...@gmail.com:
LGTM.
However, I'm a bit nervous about putting bends as well into the
Tab_tie_follow_engraver. Not that the engraver won't work, but that the
Tab_tie_follow_engraver won't be part of the documentation.
I think you misunderstood the TODO.
http://codereview.appspot.com/2758042/diff/1/Documentation/notation/spacing.itely
File Documentation/notation/spacing.itely (right):
http://codereview.appspot.com/2758042/diff/1/Documentation/notation/spacing.itely#newcode428
Documentation/notation/spacing.itely:428: @c TODO: Where do
headers/fo
On 10/28/10 1:54 PM, "Marc Hohl" wrote:
> Am 28.10.2010 14:53, schrieb carl.d.soren...@gmail.com:
>> Currently, I view Scheme engravers as a way for users (and snippets) to
>> add engraver functionality, but not as an optimal way to add core
>> functionality.
>
> I understand your argument, but
Hello
On 28/10/2010 23:00, Werner LEMBERG wrote:
>>> \sourcefilename "slur-tuplet.ly"
>>
>> But when I manually compile this regtest, I get: [...]
>>
>> success: Compilation successfully completed
>
> Honestly, I've suspected that. The question is whether Graham has
> observed a Heisenbug, or whe
On 10/28/10 4:00 PM, "Werner LEMBERG" wrote:
>>> \sourcefilename "slur-tuplet.ly"
>>
>> But when I manually compile this regtest, I get: [...]
>>
>> success: Compilation successfully completed
>
> Honestly, I've suspected that. The question is whether Graham has
> observed a Heisenbug, or whe
>> \sourcefilename "slur-tuplet.ly"
>
> But when I manually compile this regtest, I get: [...]
>
> success: Compilation successfully completed
Honestly, I've suspected that. The question is whether Graham has
observed a Heisenbug, or whether the change really triggers the crash
in the build...
> I don't think it's a Heisenburg. The make test fails for me, too.
Me too... Very, very strange. Anybody out here who knows enough
about the Scheme internals to debug it?
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://li
On 10/28/10 4:39 PM, "Werner LEMBERG" wrote:
>
>
>> I don't think it's a Heisenburg. The make test fails for me, too.
>
> Me too... Very, very strange. Anybody out here who knows enough
> about the Scheme internals to debug it?
I'm currently seeing if I can reproduce it by a single com
On Fri, Oct 29, 2010 at 12:15 AM, Carl Sorensen wrote:
> I would *love* to have a way to document Scheme engravers such that we could
> include them in the docs, but at present I have no knowledge of how to do
> so.
>
> Can anybody shed any light on this?
How about basic regrouping all engravers-
On 10/28/10 4:44 PM, "Carl Sorensen" wrote:
>
>
>
>
> On 10/28/10 4:39 PM, "Werner LEMBERG" wrote:
>
>>
>>
>>> I don't think it's a Heisenburg. The make test fails for me, too.
>>
>> Me too... Very, very strange. Anybody out here who knows enough
>> about the Scheme internals to de
On 10/28/10 4:50 PM, "Valentin Villenave" wrote:
> On Fri, Oct 29, 2010 at 12:15 AM, Carl Sorensen wrote:
>> I would *love* to have a way to document Scheme engravers such that we could
>> include them in the docs, but at present I have no knowledge of how to do
>> so.
>>
>> Can anybody shed
On 10/28/10 4:52 PM, "Carl Sorensen" wrote:
> On 10/28/10 4:44 PM, "Carl Sorensen" wrote:
>> On 10/28/10 4:39 PM, "Werner LEMBERG" wrote:
I don't think it's a Heisenburg. The make test fails for me, too.
>>>
>>> Me too... Very, very strange. Anybody out here who knows enough
>>> about t
http://codereview.appspot.com/2758042/diff/1/Documentation/notation/spacing.itely
File Documentation/notation/spacing.itely (right):
http://codereview.appspot.com/2758042/diff/1/Documentation/notation/spacing.itely#newcode209
Documentation/notation/spacing.itely:209: by setting @code{paper-heigh
http://codereview.appspot.com/2642043/diff/1/Documentation/notation/spacing.itely
File Documentation/notation/spacing.itely (right):
http://codereview.appspot.com/2642043/diff/1/Documentation/notation/spacing.itely#newcode1509
Documentation/notation/spacing.itely:1509: available. Then, the
staf
http://codereview.appspot.com/2642043/diff/1/Documentation/notation/spacing.itely
File Documentation/notation/spacing.itely (right):
http://codereview.appspot.com/2642043/diff/1/Documentation/notation/spacing.itely#newcode1662
Documentation/notation/spacing.itely:1662:
@code{after-last-staff-spa
On Thu, Oct 28, 2010 at 04:55:12PM -0600, Carl Sorensen wrote:
>
> On 10/28/10 4:50 PM, "Valentin Villenave" wrote:
>
> > How about basic regrouping all engravers-related Scheme definitions in
> > a `define-scheme-engravers.scm' file, and then document it just like
> > music-functions.scm and de
On Wed, Oct 27, 2010 at 06:39:30PM +, carl.d.soren...@gmail.com wrote:
> I think that wrapping a variable declaration in a code declaration is
> undesirable. It complicates the format of the documentation, for very
> little benefit (if any).
>
> If we want to change the format of @var{} in HT
LGTM.
(for clarity: none of the comments made so far will force a second
draft, so if nobody has a complaint in the next 5 hours, you're good to
push it)
http://codereview.appspot.com/2791041/diff/1/ly/predefined-guitar-fretboards.ly
File ly/predefined-guitar-fretboards.ly (right):
http://coder
On Thu, Oct 28, 2010 at 02:54:05PM +0100, James wrote:
> >warning: couldn't fit music on page: overflow is 3.626405
>
> I don't know if this is significant but as we have made changes to
> both this file and the spacing code it might matter or affect some
> of our docs.
There's a bunch of warning
http://codereview.appspot.com/2642043/diff/1/Documentation/notation/spacing.itely
File Documentation/notation/spacing.itely (right):
http://codereview.appspot.com/2642043/diff/1/Documentation/notation/spacing.itely#newcode1501
Documentation/notation/spacing.itely:1501: @item @emph{staff-like
con
40 matches
Mail list logo
