Of course. But I meant it's impossible to interpret a mask that would be a
MetaFont glyph.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
You're right... So I vote for define-void-function.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
What about { b' { c'' } \\ { a' } d'' } ?
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
2011/10/1 m...@apollinemike.com m...@apollinemike.com
Bertrand's bringing two people from his fan club
Unfortunately, one of them can't come. Only Cécile will come.
Actually, IRC is probably a better option (I just said Skype cuz it's the
first thing that came to my mind). I'll keep all
2011/9/28 Werner LEMBERG w...@gnu.org
If at all, please use a more decent, *single* character instead of
`--'. What about `='? Not that I'm very happy with it, but... Then
we could also add `|' to inhibit ligatures (which is quite important
in German):
Auf|lagen=steigerung
Very good
@Dak: Yes, that would be perfect if everything could be defined so easily.
I guess this still requires a lot of work on the parser (yours are awesome,
besides!).
@Mike: Using pango and libhyphen would definitely be better. I'm therefore
waiting for our « coding par-tay!!1 »!
Bertrand
This would require some work on the parser/lexer, but I think it is possible
to do.
The example you wrote seems a bit messy to me. It is better to keep the
lyricmode:
someText = lyricmode { some4 de8 -- mon16 -- stra -- tion4 text, hoo -- ray!
}
\markup \someText
\new Lyrics \someText
I don't
2011/9/25 Werner LEMBERG w...@gnu.org
Actually, we don't *need* `\-' at all since Unicode already provides
characters to control hyphenation:
00ADSOFT HYPHEN
2010HYPHEN
2011NON-BREAKING HYPHEN
Bertrand, does your code work support them?
Here is how it works for the
2011/9/23 Janek Warchoł janek.lilyp...@gmail.com
Hi Bertrand,
2011/9/23 Bertrand Bordage bordage.bertr...@gmail.com:
* making a system that allows to specify where a word is breakable (like
\-
in LaTeX);
I vote for this because it seems most multi-language friendly. I.e.,
implementing
2011/9/24 Peekay Ex pkx1...@gmail.com
Hmm... breaking a 4 letter word into two over two lines?
The typesetter in me cringes slightly.
Indeed, global rules would be great for absent-minded people like me...
@Trevor : Yes, this was only a manual demonstration.
Bertrand
The commit you want to push must follow origin/master.
If it does, just do:
git push --dry-run origin [hash_of_the_commit]:master
This will push this single commit.
If not, you have to rebase so that the commit follows origin/master:
git rebase -i origin
An editor opens, where you can change the
Hi Nicolas
This is very interesting.
I always wanted to fix these issues.
Tell me if I can do something to help this work.
(I'm also ready to give at least 100€ to the one that would fix this.)
Bertrand
___
lilypond-devel mailing list
Hi,
I made a mistake when pushing 0fa2313ae40ae4419b635193bce21dd2c17c02f4
As you can see, I pushed some other patches by error.
Sorry for that, they are reverted. I didn't tried to make a git push -f
origin [previous HEAD]:master. This could have done worse...
Bertrand
It looks good.
Is this also working with complex cases such as { \times 4/5 { a8 a32 a8
a16. a8 a8 } } ?
I think (not sure) the beamlets should be: 32 to the right, 16. to the left.
Bertrand
___
lilypond-devel mailing list
lilypond-devel@gnu.org
I think so.
I'm already writing a section called C/Scheme interface where I explain
that scm_integer_p (x) == SCM_BOOL_T isn't correct.
I also start a list of functions like to_boolean explaining why and how to
use them.
As an expert of these issues, you will probably want to add some details
I'm already writing a section called C/Scheme interface where I
explain that scm_integer_p (x) == SCM_BOOL_T isn't correct.
Well, it works as long as scm_is_eq works the same as ==. But that's an
implementation detail of Guile and not part of the Guile API. Bypassing
the Guile API here
2011/8/17 David Kastrup d...@gnu.org
Bertrand Bordage bordage.bertr...@gmail.com writes:
This would be great if Han-Wen decides to keep it like that.
Otherwise there is really a lot of work, with many shortcuts to
define.
to_boolean (scm_is_pair (x))
That one would be wrong since
Compile Lilypond with
-DSCM_DEBUG_TYPING_STRICTNESS=2
I don't understand how you're applying this setting.
I tried
./configure -DSCM.
and
make -DSCM.
without success.
*cough* Bertrand? ;)
You're right!
Cécile Hauchemaille has started working on this!
Bertrand
This would be great if Han-Wen decides to keep it like that.
Otherwise there is really a lot of work, with many shortcuts to define.
to_boolean (scm_is_pair (x))
to_boolean (scm_list_p (x)) !to_boolean (scm_null_p (x))
etc
Bertrand
___
lilypond-devel
This was introduced in one of Han-Wen's commits
: 7d7d33f3f1c6c45aaf3fd1e5c68b0b75a1be248d
At that time there was no property to center figures, that's probably why
Han-Wen added this condition (I know, this doesn't explain well its
presence).
___
I've done a very dirty test which showed that a properly set glyph
bounding box solves this perfectly (see in the attachment how the
bounding box should change).
However, there is a problem. Currently bounding box is set by
procedure draw_outside_ellipse (defined in mf/feta-params.mf) - it
Yes, this probably needs to be discussed during the GLISS.
But maybe we can do something before, because adding the tilde notation
doesn't mean that the current syntax must be removed.
Bertrand
___
lilypond-devel mailing list
lilypond-devel@gnu.org
Okay, I will fix these before the end of the day.
Thanks for taking time to do the review !
Bertrand
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Hi all,
I am currently working on some huge figured bass projects and there's
something truely annoying and quite unnatural:
when using \bassFigureExtendersOn, we need to tell LilyPond when we don't
want an extender (by adding \! to the number) instead of telling when we
want one.
I'm making a
What are we doing then? We only update git-cl's repository in the CG?
Bertrand
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
I was referring to issues 1606, 590, 582, 570, 480, 409, 397.
These could be fixed with a Tie_collision_engraver.
I would like to try to implement this engraver if you are disposed to help
me.
Regards,
Bertrand
___
lilypond-devel mailing list
Hi all,
As mentioned in the title, git-cl's repository on neugierig.org is down.
It looks like this project isn't supported anymore.
I suggest we rewrite the last part of CG 3.3.4 Uploading a patch for
review.
In fact, why were we using git-cl ? What is git-cl providing that can't be
done with
Would it be possible to make upload.py sent multiple commits? For
casual contributors, a single commit is fine, but serious
developers like Mike require the ability to upload multiple
commits for a single issue.
Yes, this will be possible.
Do you mean something like this ?
git-cl stored the issue number inside each git branch, so that you can
easily update an issue with a new pathcset without having to look up the
issue number.
Hum, this is true.
Plus, you don't have to create a patch file on disk that you can then
upload. So, git-cl is basically only half
I would like to rewrite the CG, but first I would like somebody
(not me) to change upload.py
- ideally the changes should be sent upstream
- I'm willing to have a temporary fork of upload.py while we're
waiting for a new official version of upload.py
I finally made a good patch
This would be an honor !
Bertrand
From c33434d6acbe3b5ad313c7f05c89db10a2a98242 Mon Sep 17 00:00:00 2001
From: Bertrand Bordage bordage.bertr...@gmail.com
Date: Mon, 6 Jun 2011 14:27:15 +0200
Subject: [PATCH] Authors: new contributor.
---
Documentation/included/authors.itexi |3 ++-
1 files
Voilà !
From fe6fb4094d462d02c3c844cda9bf263675005089 Mon Sep 17 00:00:00 2001
From: Bertrand Bordage bordage.bertr...@gmail.com
Date: Mon, 6 Jun 2011 14:27:15 +0200
Subject: [PATCH] Authors: new contributor.
---
Documentation/included/authors.itexi |1 +
1 files changed, 1 insertions(+), 0
Hi,
I recently noticed that small braces are too thin to be read.
This patch gently increases the thickness of the 256 first braces :
http://codereview.appspot.com/4518052/
It prepares a future patch that will implement in-staves braces especially
used in organ music.
Several examples in these
Comparison between original and fattened braces attached.
Bertrand
attachment: original braces.pngattachment: fattened braces.png___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Hello,
Reinhold's last commit (3d571d9c80b7855422c96ecc6966bcbfa4dfb9ff) just broke
the table of contents when we use a TOC command before a bookpart :
\version 2.13.60
\book {
\markuplines \table-of-contents
\tocItem a
\bookpart {
\tocItem the first
\score {{ a
A shorter
Yes, I noticed the same changes. That's exactly what I expected.
Thanks,
Bertrand
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Which version of 2.13 are you using?
2.13.59
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Nice ! (and quick)
Thanks :o)
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Hi,
Thanks for your watchfulness ! (Can we say this? I'm pretty bad at
English...)
I added Graham and Neil's changes.
Regards,
Bertrand
(Git patch attached with the commit's informations)
From fe20aad02a7c4a6ace4a9c31670b5f4c7dbe87ba Mon Sep 17 00:00:00 2001
From: Bertrand Bordage bordage.bertr
Hi,
You're cheating a bit, Mike !
This wasn't c'4~ c'8. instead of a4~ a8. in the lower voice.
It's even more tight !
Here is the example in context (Breitkopf und Härtel 1878) :
http://imslp.org/wiki/Special:ImagefromIndex/05677
The last two systems of the second page.
You can also notice a
Hello,
I made a patch that adds a postscript dotted line in tocItemMarkup.
What do you think about it ? Can this be officially added to LilyPond ?
Regards,
Bertrand
From a678dfdd7c329482a42f405df4a3238fa7195e32 Mon Sep 17 00:00:00 2001
From: Bertrand Bordage bordage.bertr...@gmail.com
Date: Mon
Ooops, forgot to remove the # before the define. Update attached. I also
changed the names from length to width.
Regard,
Bertrand
From ed72ba9abbed89d0e6209ea48ba0fd05ac00912f Mon Sep 17 00:00:00 2001
From: Bertrand Bordage bordage.bertr...@gmail.com
Date: Mon, 14 Feb 2011 12:21:01 +0100
Subject
Wow, nice !
Thanks a lot, this really helps :-p
LaTeX-like text footnotes are nearly done.
After doing these footnotes and endnotes, I will probably try to implement
drop caps support.
(My secret wish is to get rid of lilypond-book...)
Regards,
Bertrand
Thanks Jan-Peter !
I agree with your idea of using asterisks instead of numbers when annotating
scores (but for text, numbers seems more elegant).
For the moment, I will try to do LaTeX-like footnotes for markuplines.
Indeed, this would be a good solution for now :
- A column of footnotes on
/notenbeispiele/108056.jpg
http://www.bodensee-musikversand.de/notenbeispiele/108452.jpg
http://www.bodensee-musikversand.de/notenbeispiele/108452_midi.gif
I made a patch that removes the 2 useless definitions in
mf/feta-scripts.mfand update
scm/script.scm.
Regards,
Bertrand Bordage.
diff --git a/mf
I suppose that there is some argument for changing the names of the
scripts,
e.g. from \rtoe to \stdtoe, and from \ltoe to \invtoe, with corresponding
changes to heel. But this discussion should by part of the GLISS
discussion, to be held after 2.14 is out.
OK, I'll be back after 2.14
Something quite better :
http://books.google.com/books?id=c9x1XBrdwuIClpg=PP1pg=PA4#v=onepageqf=false
and this ... http://www.ldsorganistblog.com/2009/10/pedal-points.html
___
lilypond-devel mailing list
lilypond-devel@gnu.org
47 matches
Mail list logo
