>> To sum up: Keywords like `orientation' are far too frequent in
>> normal text to be handled without protection if convert-ly is
>> applied to lilypond-book (or texinfo) input.
>
> I'm fine with this being a command-line option to convert-ly.
> Actually, this could even be the default -- as long
Apparently GUB (from about a year ago) no longer works on 10.3.9.
It's quite possible that this was broken in the change that made it
work on 10.5.
http://code.google.com/p/lilypond/issues/detail?id=1295
I have no clue how to fix the errors. I'm quite willing to apply test
patches and upload tes
On Thu, Oct 21, 2010 at 6:06 AM, Werner LEMBERG wrote:
>
> What I consider problematic is that syntax changes aren't restricted to
> lilypond
> environments.
This is useful for updating the docs -- we *want* it to change text
like "to change the direction of the slur, use \oldSlurUpCommand".
>
In the documentation, there is an example how to convert a texinfo
file to a newer version:
convert-ly --from=... --to=... --no-version *.itely
A similar command can be used for lilypond-book input files:
convert-ly --from=... --to=... --no-version *.tex
What I consider problematic is that
On Wed, Oct 20, 2010 at 10:30:17AM -0600, Carl Sorensen wrote:
> On 10/20/10 9:59 AM, "Francisco Vila" wrote:
>
> > doctitle = "Customizing fretboard fret diagrams"
> > } % begin verbatim
> >
> > \include "predefined-guitar-fretboards.ly"
> > \storePredefinedDiagram #default-fret-table \chordmod
I like this idea as a way to get the functionality you want in the short
term. But I don't like it for the long term. I think the long-term
syntax needs to be
\language "foobar"
so that we don't have a separate keyword for each language. As you
point out, that will require a parser change.
I
Hi Ian,
I just tested your patch.
In addition to the small tweak that is needed (see my comment below), it
seems that the `(use-modules (ice-9 curried-definitions))' statement
does not carry over to display-lily.scm. I am a bit puzzled by this.
This is the error message, in context:
;;; compi
Hi Ian,
I will test your patch shortly.
Thanks,
Patrick
http://codereview.appspot.com/2219044/diff/15001/scm/lily.scm
File scm/lily.scm (right):
http://codereview.appspot.com/2219044/diff/15001/scm/lily.scm#newcode231
scm/lily.scm:231: (_ "Guile 1.8\n")
Okay, I can live with this. :)
ht
OK to remove offending line even when using Guile V1.8.7?
Ian
http://codereview.appspot.com/2219044/diff/15001/scm/lily.scm
File scm/lily.scm (right):
http://codereview.appspot.com/2219044/diff/15001/scm/lily.scm#newcode271
scm/lily.scm:271: (debug-enable 'debug)
This causes a deprecation warn
New patchset uploaded
Ian
http://codereview.appspot.com/2219044/diff/10001/scm/lily.scm
File scm/lily.scm (right):
http://codereview.appspot.com/2219044/diff/10001/scm/lily.scm#newcode231
scm/lily.scm:231: (_ "module (ice-9 curried-definitions) not in Guile
1.8\n")
Change --verbose ly:mess
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.
Hi Trevor,
I've taken the liberty to apply James' suggestions myself:
http://git.savannah.gnu.org/gitweb/?p=lilypond.g
Reviewers: ,
Message:
Greetings everybody,
this user-friendly modification has been discussed for a while but
nothing concrete had been done so far. Therefore I took the liberty of
proposing a very simple patch, since this modification is something I
really really need (well, not me, but rather
James
Many thanks for your comments. At first glance they all seem
pertinent. I'll have a look at fixing them up tomorrow.
I'm actually dealing with TODOs dotted around the file in no
particular order, so there is no high-water mark for the changes
I've made. You could read and comment do
These are just some things that I noticed.
2.1.1 Entering Lyrics.
Lyrics are entered in a special input mode, which can be introduced by
the keyword \lyricmode, or by using \addlyrics or \lyricsto. In this mode…
Which mode? This has bugged me for a while, and since changes are being ma
Hi all,
I'm currently working on automatic cue clefs (i.e. \cueDuring in different
clefs than the containing voice, e.g. using a violin or flute cue inside the
cello part).
My current state is up at rietveld at:
http://codereview.appspot.com/2588042
As the cue clefs should not override the staff
Yes, please do. It's probably my mistake.
Thanks,
Carl
On 10/20/10 9:59 AM, "Francisco Vila" wrote:
> Hello.
>
> see
> Customizing fretboard fret diagrams
> Documentation/snippets/customizing-fretboard-fret-diagrams.ly
> lines 74 -- 81:
>
> doctitle = "Customizing fretboard fret diagrams"
Hello.
see
Customizing fretboard fret diagrams
Documentation/snippets/customizing-fretboard-fret-diagrams.ly
lines 74 -- 81:
doctitle = "Customizing fretboard fret diagrams"
} % begin verbatim
\include "predefined-guitar-fretboards.ly"
\storePredefinedDiagram #default-fret-table \chordmode { c'
LGTM.
Carl
http://codereview.appspot.com/2401042/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
> why does LyricText #'font-series default to #'bold-narrow?
This looks like an oversight. The change is from 2004 where TeX has
been still used as the output device.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu
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 narrow font as the most
> important thing to read in a piece; it's just to
> The README also says that we shouldn't apply transformations to
> fills, but instead transform the path then fill the path. The
> current varsegno transforms the penstroke, which I think is contrary
> to this instruction.
Yep. For this glyph it works accidentally. Thanks for noticing, I've
m
On 10/20/10 1:59 AM, "Werner LEMBERG" wrote:
>
>
>> + ... {dir (180 - loopangle)}z7e{dir (180 - loopangle)}
>
> This is too much :-) The following
>
> + ... z7e{dir (180 - loopangle)}
>
> is sufficient. A new patch attached (to preserve tabs for dull mail
>
Hi, folks,
why does LyricText #'font-series default to #'bold-narrow?
First, it's counterintuitive to me to have a bold narrow font as the
most important thing to read in a piece; it's just too black-ish.
Condensed seems fine for lyrics, but bold?
Second, it's defined for nearly no font, in p
Am 18.09.2010 22:21, schrieb n.putt...@gmail.com:
[...]
I think the only sane method would be to use a scheme engraver, since
you could acknowledge interesting grobs and make typesetting decisions
for the TabNoteHead based on the grobs present at a particular timestep.
Done.
> This doesn't be
> + ... {dir (180 - loopangle)}z7e{dir (180 - loopangle)}
This is too much :-) The following
+ ... z7e{dir (180 - loopangle)}
is sufficient. A new patch attached (to preserve tabs for dull mail
programs).
Werner
--- feta-scripts.mf.old 2010-10-17 13:40:03.0
Am 20.10.2010 09:50, schrieb Werner LEMBERG:
This is probably overkill. FontForge is quite good in doing this for
you, provided the intersections are well defined. `fill' is necessary
because you can't exactly control the direction of the outline by
using `penstroke'.
But if I change f
>> This is probably overkill. FontForge is quite good in doing this for
>> you, provided the intersections are well defined. `fill' is necessary
>> because you can't exactly control the direction of the outline by
>> using `penstroke'.
>
> But if I change from penstroke to fill, using zkr to go a
> Here's a patch for the accordion push symbol.
This looks fine.
> It would have been simpler if I had just drawn two straight lines:
>
> draw z1
> -- z2;
>
> draw z3
> -- z2;
>
>
> This would seem to be allowed by the instructions in README, but I
> get the sense that mf2tp1 reall
28 matches
Mail list logo
