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
"define-procedure" sounds too generic to me. Why not
"define-void-procedure" ?
Bertrand
___
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
> 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 ya'll posted.
>
For
@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
__
2011/9/28 Werner LEMBERG
>
> 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 idea! A
2011/9/25 Werner LEMBERG
> 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 moment:
Th
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 kno
2011/9/24 Peekay Ex
>
> 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
_
2011/9/23 Janek Warchoł
> Hi Bertrand,
>
> 2011/9/23 Bertrand Bordage :
> > * 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.,
> implementin
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
You can specify what you want to push:
git push --dry-run origin [hash]:[branch]
This will push every commit between [hash] and origin, assuming we stay in
[branch].
Bertrand
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/
This collision has always been (2.12.3, 2.14.2...).
Bertrand
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
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
lilypond-devel@gnu
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
https://
>
> > 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
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
af
2011/8/17 David Kastrup
> Bertrand Bordage 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
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
>
> > 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 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).
___
lilypon
>
> 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)
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
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
htt
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 lot
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
lilypond-de
>
> 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 (b
>
> 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 onl
>
> 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 ?
http://coder
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
Voilà !
From fe6fb4094d462d02c3c844cda9bf263675005089 Mon Sep 17 00:00:00 2001
From: Bertrand Bordage
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 deletions(-)
diff --git a
This would be an honor !
Bertrand
From c33434d6acbe3b5ad313c7f05c89db10a2a98242 Mon Sep 17 00:00:00 2001
From: Bertrand Bordage
Date: Mon, 6 Jun 2011 14:27:15 +0200
Subject: [PATCH] Authors: new contributor.
---
Documentation/included/authors.itexi |3 ++-
1 files changed, 2 insertions
Comparison between original and fattened braces attached.
Bertrand
<><>___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
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 sc
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 short
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
Nice ! (and quick)
Thanks :o)
___
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
Mistake in my second line : one must read "was" instead of "wasn't".
Bertrand
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
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 s
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 Bor
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
Date: Mon, 14 Feb 2011 12:21:01 +0100
Subject: [PATCH] Add dots to
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
Date: Mon, 14 Feb 201
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 each
Something quite better :
http://books.google.com/books?id=c9x1XBrdwuIC&lpg=PP1&pg=PA4#v=onepage&q&f=false
and this ... http://www.ldsorganistblog.com/2009/10/pedal-points.html
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/ma
>
> 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.
nsee-musikversand.de/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 Bord
51 matches
Mail list logo
