On Wed, Mar 24, 2004 at 03:09:05PM +0100, Werner LEMBERG wrote:
>
> With gs 8.14 I repeatedly get the fatal error
>
> ./src/gxccman.c:576:
> gx_add_cached_char: Assertion `cc->pair == pair' failed.
>
> I consider this as a serious problem in gs. Has anybody already sent
> a bug report to
[EMAIL PROTECTED] writes:
>
> %
> % This file shows a problem with broken slurs in staves having different
> % sizes in lilypond CVS 2004-03-23 21:42 MET.
> %
> % . The starting point of the continuation of a broken slur is offset
> % too far to the left in the smaller staff.
Why? where do you
On Wednesday 24 March 2004 18.42, Marco Gusy wrote:
> Alle 14:52, mercoledì 24 marzo 2004, hai scritto:
> > As you yourself wrote in your previous email, beams are sometimes
> > used instead of slurs to indicate melismas. In that case, it's likely
> > that the automatic beams often don't give the d
> http://www.mindview.net/WebLog/log-0025
I liked especially the following rule:
"If it is not tested, it is broken." =)
>
> > Scheme is interpreted, the behavior of the program (say LilyPond) can be
> > changed dynamically.
>
> Just to bring a correction:
> inte
Alle 14:52, mercoledì 24 marzo 2004, hai scritto:
> As you yourself wrote in your previous email, beams are sometimes
> used instead of slurs to indicate melismas. In that case, it's likely
> that the automatic beams often don't give the desired melismas.
I think they should always do. Look at the
With gs 8.14 I repeatedly get the fatal error
./src/gxccman.c:576:
gx_add_cached_char: Assertion `cc->pair == pair' failed.
for anti-aliased graphics. Virtually no lilypond score which contains
more than a single staff and staff braces works.
I consider this as a serious problem in gs.
%
% This file shows a problem with broken slurs in staves having different
% sizes in lilypond CVS 2004-03-23 21:42 MET.
%
% . The starting point of the continuation of a broken slur is offset
% too far to the left in the smaller staff.
\version "2.1.34"
\score {
<<
\new Staff \with {
Wed, 24 Mar 2004 02:46:04 +0200 (EET), Heikki a dit :
> For me, it looks like the first fundamental difference between these two
> syntaxes is that in C++ you have to be extremely careful with type and
> inheritance, whereas in Scheme (seems like) you do not usually need to care.
This s
Matevz Jekovec wrote:
Does lilypond support utf8/16 coding for text elements (lyrics, title,
authors)?
No not at the moment. However, it might be fairly easy to fix that
using lilypond-book on a LaTeX document with embedded LilyPond code.
LilyPond will probably use completely wrong spacing for t
As you yourself wrote in your previous email, beams are sometimes
used instead of slurs to indicate melismas. In that case, it's likely
that the automatic beams often don't give the desired melismas.
That's probably why it was decided to only use manual beams for
melismas in LilyPond.
Regarding the
[EMAIL PROTECTED] writes:
> > > Recently, the (default) appearance of triplet brackets have
> > > changed [...]
> >
> > Try fiddling with TupletBracket #'gap (let me know what value you
> > like best.)
>
> The current default value of the gap on the left side is fine, but on
> the right it should
I noticed that lyricsto listens to manual beams in lyrics-melisma-beam.ly
regression test. Why only manual ones?
By the way, there isn't the melisma in that example...
___
Lilypond-devel mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listin
Hi, I think /addlyrics behavior should be revisited.
Currently (correct me if i'm worng) it follows only slurs to skip syllables.
The right behavior should be this:
if note duration <= eight (notes with possible beaming):
follow beaming: commonly two syllables are NEVER tied in a beam
13 matches
Mail list logo
