> 1) Fix issue #628, whereby grob 'style settings (e.g., TextSpanner
> #'style = #'trill) interfere with the default notehead style for
> \note(-by-number);
>
> 2) Use the code from note-head::calc-glyph-name to ensure all notehead
> style can be set via 'style in \note(-by-number).
Nice!
Although the patch is right for 16th notes, it seems to be broken in certain
cases for 32nd notes. I'll follow up on that.
Thanks,
Carl
At last, thanks to help above and beyond the call of duty by Neil, I have
finally got the autobeam engraver fixed so it beams 4 4 right when there are
16th no
2009/12/16 Valentin Villenave :
> On Wed, Dec 16, 2009 at 1:19 AM, Francisco Vila wrote:
>> What do I have to do to get this public announcement in our website?
>
> Checkout the 'web' branch of the git repo, and edit the file
> site/news.html/in (or you can send me your announcement and I'll push
> "Matthias" == Matthias Kilian writes:
Matthias> On Tue, Dec 15, 2009 at 04:33:14PM +0100, Jan Nieuwenhuizen
Matthias> wrote:
>> > (I really > don't remember the reason, too much time has passed
>> since I made > this patch)
>>
>> It would be nice to know why we need this, esp. as this fix
On Wed, Dec 16, 2009 at 1:19 AM, Francisco Vila wrote:
> What do I have to do to get this public announcement in our website?
Checkout the 'web' branch of the git repo, and edit the file
site/news.html/in (or you can send me your announcement and I'll push
it for you).
That's excellent news! I a
Hi everybody,
This patch does two things:
1) Fix issue #628, whereby grob 'style settings (e.g., TextSpanner
#'style = #'trill) interfere with the default notehead style for
\note(-by-number);
2) Use the code from note-head::calc-glyph-name to ensure all notehead
style can be set via 'style in \
Hello! After a loong wait trying to host our Spanish list at GNU I
have just received this from the admins:
"For be labeled as Official GNU software we need you to point us to an
offical public announcement in the official Lily Pond site that
certifies this as the offical Liky Pond spanish list. U
2009/12/11 Werner LEMBERG :
>
> Thanks to Neil, TextSpanner items are now displayed in `Dynamics'
> contexts. However, this exhibits another serious annoyance, as shown
> in bug issue #928.
This should be fixed now, Werner. If you can confirm, I'll close #928.
Thanks,
Neil
___
On Wed, Dec 16, 2009 at 12:18 AM, Neil Puttock wrote:
> There's no harm in adding it, I suppose. I'm certainly not going to
> stick my neck out and declare it impossible, even if I don't have the
> faintest idea how it could be implemented. :)
Neither have I. The music-function's type signature
Neil Puttock wrote Tuesday, December 15, 2009 11:28 PM
2009/12/15 Trevor Daniels :
but if I do this:
SCM duration_symbol;
Item *duration_grob;
...
duration_grob = make_item ("TabDuration", events_[0]->self_scm
());
...
duration_symbol = ly_string2scm ("A");
duration_grob->set_property ("t
2009/12/15 Trevor Daniels :
> but if I do this:
>
> SCM duration_symbol;
> Item *duration_grob;
> ...
> duration_grob = make_item ("TabDuration", events_[0]->self_scm ());
> ...
> duration_symbol = ly_string2scm ("A");
> duration_grob->set_property ("text", duration_symbol);
>
> the program
2009/12/15 Valentin Villenave :
> Hm, I forgot about that. We already encountered the same problem when
> Reinhold rewrote the \tempo command, for instance.
> *sigh* This is one of those limitations that make me want to bang my
> head against a wall. Do you think this could deserve a feature reque
On Tue, Dec 15, 2009 at 9:36 PM, Neil Puttock wrote:
> But that's why it's in the parser; you can't have music functions with
> optional arguments (and I doubt that's going to change any time soon).
Hm, I forgot about that. We already encountered the same problem when
Reinhold rewrote the \tempo
2009/12/15 Carl Sorensen :
> Everything compiles OK. And it runs fine until I get into recheck_beam.
> Recheck_beam actually executes successfully, but an exception is thrown
> later, and the exception doesn't make sense to me when I use gdb. Values
> are changed between the calling procedure an
I'm drafting out a new engraver to produce durations above a tab
staff for use in lute tablature, and I've been stumped by a problem
for several hours. Perhaps someone can see something I'm missing.
The problem is this (recast in a simplified form):
If I set the text property in a new grob li
2009/12/15 Frédéric Bron :
> I think your problem may come from the fact that:
> * in Beam::set_beaming, "i" is a vsize (=size_t) which is an unsigned integer
> * in Beaming_pattern::beamlet_count, "i" is an int which is signed
No, that's only likely to cause a compilation warning, since `i' in
s
2009/12/15 Graham Percival :
> Check it here. It compiled, just about, with much cajoling, and
> that's good enough for me.
> http://lilypond.org/~graham/
Will check later. Can't at the moment since I'm testing Carl's
autobeaming patch.
> I see dead people. And also a lot of backports. Any
After 6 almost straight hours of GUB and
regenerating-2.12.2-regtests-because-of-the-changed-hash-function fun,
I'm pissed^H^H^H^H^H^Hhappy to almost-announce 2.12.3.
Check it here. It compiled, just about, with much cajoling, and
that's good enough for me.
http://lilypond.org/~graham/
Also,
> Everything compiles OK. And it runs fine until I get into recheck_beam.
> Recheck_beam actually executes successfully, but an exception is thrown
> later, and the exception doesn't make sense to me when I use gdb. Values
> are changed between the calling procedure and the called procedure in a
[sorry for mumbling to myself too much]
On Sun, Dec 13, 2009 at 06:53:57PM +0100, Matthias Kilian wrote:
[...]
> -out = file (path + '.ly', 'w')
> +out = tempfile.NamedTemporaryFile(mode = 'w', suffix = '.lytmp',
> + dir = directory, delete
On 2009-12-15, Graham Percival wrote:
> On Tue, Dec 15, 2009 at 12:06:08AM +0100, Francisco Vila wrote:
> > I've looked at some random issues and many of them have the image
> > visible online, no need to re-upload these. Do you know why some and
> > not all?
>
> Given that I don't even know the
On 2009-12-15, Jan Nieuwenhuizen wrote:
> Op dinsdag 15-12-2009 om 20:01 uur [tijdzone +0100], schreef Matthias
> Kilian:
> > On Tue, Dec 15, 2009 at 04:33:14PM +0100, Jan Nieuwenhuizen wrote:
>
> > > It would be nice to know why we need this, esp. as this fix
> > > does not make the logic more re
2009/12/15 Valentin Villenave :
> Please, please don't. To me, having the ability to use \relative
> without specifying a pitch is (and should remain) a feature, not a
> bug. Yeah, I know, that requires parsing, yadda yadda. We can live
> with it.
If it's really that important, then we shouldn't
On Tue, Dec 15, 2009 at 09:24:01PM +0100, Valentin Villenave wrote:
> On Tue, Dec 15, 2009 at 9:01 PM, Neil Puttock wrote:
> > A good reason would be that it would allow \relative to be removed
> > from the parser: currently we need two parser rules to cater for both
> > cases, whereas deprecating
On Tue, Dec 15, 2009 at 9:01 PM, Neil Puttock wrote:
> A good reason would be that it would allow \relative to be removed
> from the parser: currently we need two parser rules to cater for both
> cases, whereas deprecating \relative { } would allow the command to be
> implemented as a music functi
Op dinsdag 15-12-2009 om 20:01 uur [tijdzone +0100], schreef Matthias
Kilian:
> On Tue, Dec 15, 2009 at 04:33:14PM +0100, Jan Nieuwenhuizen wrote:
> > It would be nice to know why we need this, esp. as this fix
> > does not make the logic more readible.
>
> Not necessary, I aready had a closer lo
2009/12/15 Graham Percival :
> 1) "why is `\relative {' being deprecated" -- see the mailist
> archives. I don't know the details, but Han-Wen suggested it, and
> he's the person who'd know. :)
A good reason would be that it would allow \relative to be removed
from the parser: currently we ne
On Tue, Dec 15, 2009 at 04:33:14PM +0100, Jan Nieuwenhuizen wrote:
> > (I really
> > don't remember the reason, too much time has passed since I made
> > this patch)
>
> It would be nice to know why we need this, esp. as this fix
> does not make the logic more readible.
Not necessary, I aready ha
Le mercredi 16 décembre 2009 à 00:54 +0800, 陳韋安 a écrit :
> hi everyone:
> I'm from Taiwan and interested in translate the site to Traditional
> Chinese, is there any suggestion? BTW, this is the first time for me
> to participate in a open source project, I have some knowledge on C++
> and client
On 12/15/09 9:54 AM, "陳韋安" wrote:
> hi everyone:
> I'm from Taiwan and interested in translate the site to Traditional Chinese,
> is there any suggestion?
Your first place to start is in the Contributor's Guide, where it talks
about how we manage translations.
You can find this section of th
hi everyone:
I'm from Taiwan and interested in translate the site to Traditional Chinese,
is there any suggestion? BTW, this is the first time for me to participate
in a open source project, I have some knowledge on C++ and client side web
page, please feel free to say anything.
chwan1
___
On 15.12.2009, at 10:00, Mark Polesky wrote:
In NR 1.1.1 "Writing pitches" -- Relative octave entry,
"it is recommended that [startpitch] be an octave of c."
Why? Most of the time it won't even be the "startpitch".
Perhaps "referencepitch" is more accurate, but what's wrong
with "\relative fi
On Tue, Dec 15, 2009 at 3:34 PM, Jan Nieuwenhuizen
wrote:
> Op dinsdag 15-12-2009 om 14:05 uur [tijdzone +], schreef Graham
> Percival:
>> On Mon, Dec 14, 2009 at 11:00:34PM -0800, Patrick McCarty wrote:
>> > On 2009-12-13, Matthias Kilian wrote:
>
>> I'm also hesitant, but don't have time to
Op dinsdag 15-12-2009 om 14:05 uur [tijdzone +], schreef Graham
Percival:
> On Mon, Dec 14, 2009 at 11:00:34PM -0800, Patrick McCarty wrote:
> > On 2009-12-13, Matthias Kilian wrote:
> I'm also hesitant, but don't have time to test it at the moment.
> If nobody more knowledgeable says "it's ok
Op zondag 13-12-2009 om 20:14 uur [tijdzone +0100], schreef Matthias
Kilian:
> (I really
> don't remember the reason, too much time has passed since I made
> this patch)
It would be nice to know why we need this, esp. as this fix
does not make the logic more readible.
By cutting the command in b
Graham Percival writes:
> 2) "why a C?" -- a few ideas:
>
> - for better or worse, almost all lilypond scores use c'. Of
> course, this is a chicken and egg "problem", but I don't think
> it's a particular problem. Having a single recommended note
> per octave increases the readability
Le mardi 15 décembre 2009 à 15:11 +0100, Mats Bengtsson a écrit :
> On the other hand, Mark's question is highly relevant. Why not use the
> starting note of the voice? I, myself, have mistyped the octave for the
> C at several times and would probably have done it correctly more times
> if I ha
Graham Percival wrote:
2) "why a C?" -- a few ideas:
- for better or worse, that's the "basic" note in western music.
(I think they should have renamed the letters such that A major
had no sharps/flats, but oh well)
- for better or worse, c is the octave boundary in lilypond, i.e.
c vs
On Mon, Dec 14, 2009 at 11:00:34PM -0800, Patrick McCarty wrote:
> On 2009-12-13, Matthias Kilian wrote:
> >
> > I have this as a patch in the lilypond port of OpenBSD for years
> > (since 2006, IIRC), and it looks like I still need it for the
> > development branch. Without this, configure isn't
On Tue, Dec 15, 2009 at 01:00:52AM -0800, Mark Polesky wrote:
> In NR 1.1.1 "Writing pitches" -- Relative octave entry,
> "it is recommended that [startpitch] be an octave of c."
>
> Why? Most of the time it won't even be the "startpitch".
> Perhaps "referencepitch" is more accurate, but what's w
2009/12/15 Graham Percival
> On Tue, Dec 15, 2009 at 09:55:10AM +0100, Werner LEMBERG wrote:
> >
> > [all lilypond documentation snippets running through lilypond-book get
> > a horizontal offset of 3mm to the right]
> >
> > > We have code that detects if the example is a single line; if so, it
>
On Tue, Dec 15, 2009 at 12:06:08AM +0100, Francisco Vila wrote:
> I've looked at some random issues and many of them have the image
> visible online, no need to re-upload these. Do you know why some and
> not all?
Given that I don't even know the numbers of which issues have an
image vs. the ones
On Tue, Dec 15, 2009 at 09:55:10AM +0100, Werner LEMBERG wrote:
>
> [all lilypond documentation snippets running through lilypond-book get
> a horizontal offset of 3mm to the right]
>
> > We have code that detects if the example is a single line; if so, it
> > adds ragged-right=##t.
>
> I think
In NR 1.1.1 "Writing pitches" -- Relative octave entry,
"it is recommended that [startpitch] be an octave of c."
Why? Most of the time it won't even be the "startpitch".
Perhaps "referencepitch" is more accurate, but what's wrong
with "\relative fis"? Doing "\relative c" when the first
note is F
[all lilypond documentation snippets running through lilypond-book get
a horizontal offset of 3mm to the right]
I redirect this discussion to lilypond-devel.
>> [...] The lilypond-book option --left-padding controls this; if
>> not given, a default value of 3mm is used. Main reason to use have
45 matches
Mail list logo
