I think some of the confusion could be avoided by running all mf
files through expand(1).
This is a good idea, and I will do so after Phil has done his work.
I'm really bewildered that it is apparently so hard for many
contributors to format and indent new code in the same manner as
the
On Fri, 07 Sep 2012 09:23:08 -0700, m...@mikesolomon.org m...@mikesolomon.org
wrote:
On 7 sept. 2012, at 09:34, k-ohara5...@oco.net wrote:
Having the invisible Grobs taking up space will confuse the innocent.
I tried to add comments about this in the source - perhaps the CG needs an
Can you announce here the release of 2.16.1 at least a week before the
actual release?
So translators will have time to complete their works.
I have a patch which will be ready next week and I hope it won't miss
next stable release.
Thanks
--
Federico
Federico Bruni fedel...@gmail.com writes:
Can you announce here the release of 2.16.1 at least a week before the
actual release?
So translators will have time to complete their works.
I have a patch which will be ready next week and I hope it won't miss
next stable release.
No danger. By
On 2012/09/06 23:24:04, Ian Hulin (gmail) wrote:
On 2012/09/06 18:07:53, dak wrote:
When we go Guilev2, we don't want to search for all the backward
compatibility.
So I'd say you use something like
#if GUILEV1
for splicing in the compatibility stuff, and define it as either 0
or 1 in
Folks,
due to the discussion about funny accidental placements in music
written for strings with scordatura, I had a closer look at the Rosary
Sonatas from Biber. As a result, I'm playing the 14th sonata with my
daughter in a concert[1], among other pieces :-)
In case you like baroque music
On 08/09/12 10:17, Werner LEMBERG wrote:
due to the discussion about funny accidental placements in music
written for strings with scordatura, I had a closer look at the Rosary
Sonatas from Biber. As a result, I'm playing the 14th sonata with my
daughter in a concert[1], among other pieces :-)
A quick note to Werner. 1) apologies for being rather brusque, but I'd
pretty much killed my self getting this sorted - the original code had
some very odd calculation methods in it, and it's the first time I'd
ever touched metafont. Your follow up is helpful - please ignore my
recent comment
It was my plan to try to do a development release about every 2 weeks -
running on a Sunday. This Sunday would have been the first. However, my
large screen monitor has just died and I've nicked the one from my wife's
computer, and as a result I'm on a very much smaller desktop that I'm used
This is a follow-up on a discussion from the issue tracker comments at
http://code.google.com/p/lilypond/issues/detail?id=185,
where I suggested a kludgy fix for a favorite LilyPond pet peeve of
mine. I am interested in making it less kludgy. As I am new to the
LilyPond codebase, please bear
On Fri, Sep 7, 2012 at 4:42 AM, David Kastrup d...@gnu.org wrote:
There's one thing worth clarifying: when i say syntax changes, i
mean changes in how user input looks like. So a renaming of a
command is a syntax change to me (despite the fact that no grammar
rules change).
That's probably
Actually, it's been in the back of my head for a while that those
pieces could be a great demo for Lilypond, particularly in respect
of being able to generate both written and sounding-pitched parts
for violin from the same material without any stupid tricks.
Indeed, typesetting the first few
Han-Wen Nienhuys hanw...@gmail.com writes:
On Fri, Sep 7, 2012 at 4:42 AM, David Kastrup d...@gnu.org wrote:
There's one thing worth clarifying: when i say syntax changes, i
mean changes in how user input looks like. So a renaming of a
command is a syntax change to me (despite the fact that
Werner LEMBERG w...@gnu.org writes:
Actually, it's been in the back of my head for a while that those
pieces could be a great demo for Lilypond, particularly in respect
of being able to generate both written and sounding-pitched parts
for violin from the same material without any stupid
On Thu, Sep 6, 2012 at 7:28 AM, Joseph Rushton Wakeling
joseph.wakel...@webdrake.net wrote:
Has anyone ever actually engaged with any major publishers to identify the
factors that are of interest to them in engraving software, and the features
that Lilypond would have to implement in order to
On Sat, Sep 8, 2012 at 12:00 PM, David Kastrup d...@gnu.org wrote:
Han-Wen Nienhuys hanw...@gmail.com writes:
On Fri, Sep 7, 2012 at 4:42 AM, David Kastrup d...@gnu.org wrote:
There's one thing worth clarifying: when i say syntax changes, i
mean changes in how user input looks like. So a
Han-Wen Nienhuys hanw...@gmail.com writes:
On Sat, Sep 8, 2012 at 12:00 PM, David Kastrup d...@gnu.org wrote:
Han-Wen Nienhuys hanw...@gmail.com writes:
On Fri, Sep 7, 2012 at 4:42 AM, David Kastrup d...@gnu.org wrote:
There's one thing worth clarifying: when i say syntax changes, i
mean
On 8 sept. 2012, at 08:46, k-ohara5...@oco.net wrote:
On 2012/09/08 05:28:02, Keith wrote:
now I measure it 2% /faster/ than master.
Of course that makes no sense. I got confused of which executable I had
when switching between patches. This patch is still about 6% slower
than master,
On 8 sept. 2012, at 09:06, Keith OHara k-ohara5...@oco.net wrote:
On Fri, 07 Sep 2012 09:23:08 -0700, m...@mikesolomon.org
m...@mikesolomon.org wrote:
On 7 sept. 2012, at 09:34, k-ohara5...@oco.net wrote:
Having the invisible Grobs taking up space will confuse the innocent.
I tried
On 07/09/12 01:14, Graham Percival wrote:
On Mon, Sep 03, 2012 at 08:15:27PM +0100, Graham Percival wrote:
For the past 6 days, we've performed an experiment: can we have a
On Thursday, I will create a new mailing list, with the tentative
name lilypond-syntax-explorations. Alternate name
On 2012-09-08 08:11, Werner LEMBERG wrote:
1. reject any offers of help from contributors who do not follow the
existing formatting.
2. educate each contributor individually, go through multiple rounds
of each patch to adjust the formatting, etc.
3. use an automatic formatting tool.
This is just a toe-in-the-water enquiry.
Given the work David put in to allow optional music function parameters
in the 2.16 release, how much work would it be able to do something like
\afterGrace :#note d1 :#grace { c16[ d]} :#fraction 15/16
or
\afterGrace :#fraction 15/16 :#note d1 :#grace {
Indeed, typesetting the first few bars of one of the Biber sonatas,
together with correct MIDI output, would yield a very nice example.
Three staffs: true pitch, scordatura, tablature.
Entry would be presumably in true pitch plus string number (where
not in lowest terms).
Why tablature? A
On 2012/09/08 09:13:17, dak wrote:
On 2012/09/06 23:24:04, Ian Hulin (gmail) wrote:
On 2012/09/06 18:07:53, dak wrote:
When we go Guilev2, we don't want to search for all the backward
compatibility.
So I'd say you use something like
#if GUILEV1
for splicing in the compatibility
Ian Hulin i...@hulin.org.uk writes:
This is just a toe-in-the-water enquiry.
Given the work David put in to allow optional music function parameters
in the 2.16 release, how much work would it be able to do something like
\afterGrace :#note d1 :#grace { c16[ d]} :#fraction 15/16
or
On Sat, Sep 8, 2012 at 12:27 PM, David Kastrup d...@gnu.org wrote:
No idea. What we have under the umbrella of syntax discussion
contains three things: lexical units, grammar and vocabulary, mostly
implemented in lexer.ll, parser.yy, and *.ly respectively. In order to
keep syntax
Werner LEMBERG w...@gnu.org writes:
Indeed, typesetting the first few bars of one of the Biber sonatas,
together with correct MIDI output, would yield a very nice example.
Three staffs: true pitch, scordatura, tablature.
Entry would be presumably in true pitch plus string number (where
not
Han-Wen Nienhuys hanw...@gmail.com writes:
On Sat, Sep 8, 2012 at 12:27 PM, David Kastrup d...@gnu.org wrote:
No idea. What we have under the umbrella of syntax discussion
contains three things: lexical units, grammar and vocabulary, mostly
implemented in lexer.ll, parser.yy, and *.ly
David Kastrup dak at gnu.org writes:
Werner LEMBERG wl at gnu.org writes:
Actually, it's been in the back of my head for a while that those
pieces could be a great demo for Lilypond, particularly in respect
of being able to generate both written and sounding-pitched parts
for violin
http://codereview.appspot.com/6488097/diff/3001/scm/bar-line.scm
File scm/bar-line.scm (right):
http://codereview.appspot.com/6488097/diff/3001/scm/bar-line.scm#newcode178
scm/bar-line.scm:178: ;; the default distance between centre of dots is
composed of
Have you considered working entirely in
On 2012/09/08 18:54:07, Keith wrote:
http://codereview.appspot.com/6488097/diff/3001/scm/bar-line.scm
File scm/bar-line.scm (right):
http://codereview.appspot.com/6488097/diff/3001/scm/bar-line.scm#newcode178
scm/bar-line.scm:178: ;; the default distance between centre of dots
is composed
ok, thinking about a new patch.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
I fully agree. Since we have no support for (3) yet, I will do a bit
of (2), and I really hope that Phil can bear with me :-)
Is it really such a big deal if the code formatting is not perfectly
consistent in every little detail? In particular, I would favor
option
5. (relax 2 a bit)
It's a violin part using a G-clef, together with a basso continuo
staff.
Oops, please ignore the attached image.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
http://codereview.appspot.com/6497103/diff/1/Documentation/learning/fundamental.itely
File Documentation/learning/fundamental.itely (right):
http://codereview.appspot.com/6497103/diff/1/Documentation/learning/fundamental.itely#newcode2921
Documentation/learning/fundamental.itely:2921: f16 ees f
I guess you are thinking we bring the dots inside the staff if there is at
least one staff-postion of space for each dot (as in 2-line percussion staves)
and continue to move them closer to the center if we find locations with at
least two-staff-positions of space for each dot, or more space
I was aware of a slight difference, although actually I'm
not certain it's that important - these are machine drawn
glyphs intending to replicate hand-drawn clefs from the
15th century. How important is 0.1 staff space?
This is not the point. Your are changing the shape without documenting
- Original Message -
From: lemzw...@googlemail.com
To: philehol...@googlemail.com; w...@gnu.org; gra...@percival-music.ca;
m...@philholmes.net
Cc: lilypond-devel@gnu.org; re...@codereview-hr.appspotmail.com
Sent: Saturday, September 08, 2012 9:52 PM
Subject: Re: Fixes position of
sorry, I'm confused.
do we want to support
- NR 2.5.1 style 2-line percussion staves (setting both line-count and
staff-space to 2 instead of setting just line-positions to (-2 2))?
- default TabStaff's (even line-count, 1.5 staff-space)?
if we want to support both of those without changing dot
On Sat, 08 Sep 2012 15:26:21 -0700, benko@gmail.com wrote:
do we want to support
- NR 2.5.1 style 2-line percussion staves (setting both line-count and
staff-space to 2 instead of setting just line-positions to (-2 2))?
- default TabStaff's (even line-count, 1.5 staff-space)?
if we want to
40 matches
Mail list logo
