>> What's the new method for providing proper distances between the
>> header, the body, and the footer of a page? If I do it the old way
>> (this is, I just run a new lilypond binary on my score) the footer
>> line gets always attached to the body without any vertical space
>> inbetween,
>
> You
Neil Puttock writes:
> I agree, but I think this will have to wait until the chord naming
> code has been reworked since it appears to rely on \hspace having some
> vertical extent for correct positioning.
I'm not aware of this (though I don't doubt that you're right).
Could you give me an examp
> Are there any guidelines LilyPond adheres to for creating bounding
> boxes?
No.
> For example, when I adjusted the bbox for the \eyeglasses markup
> command, I _underestimated_ the bbox. Should I have slightly
> _overestimated_ instead? Attached is a PNG displaying the bbox.
I think overesti
>> For example, I see that there are no makefile rules which handle
>> changes to configure.in or aclocal.m4...[1]
>
> Should we ever have one?
IMHO yes.
> I'm not sure this is a good idea, because AFAIK make can't rerun
> configure with all the options the user could wish, so configure
> (and
> As for the example I posted, I did say it was a quick test; to
> implement this change properly will involve amending
> engraver-init.ly as well as gregorian.ly (following a careful check
> that it doesn't cause any problems elsewhere).
Yes. Please do so :-)
Werner
On Sun, 2009-08-09 at 09:05 +0200, Werner LEMBERG wrote:
> [git b6e82e5a from today]
>
>
> Joe,
>
>
> since documentation of your changes is not yet available, I have to
> ask directly: What's the new method for providing proper distances
> between the header, the body, and the footer of a page
On Sun, Aug 9, 2009 at 6:09 PM, Patrick McCarty wrote:
> On Sun, Aug 09, 2009 at 05:52:41PM -0600, Andrew Hawryluk wrote:
>> In the snippet printing-the-bar-number-for-the-first-measure.ly (NR
>> 1.2.5), there appears to be an error.
>> It recommends
>>
>> \set Score.barNumberVisibility = #all-bar-
On 9 Aug 2009, at 18:53, David Kastrup wrote:
Dan Eble writes:
On 9 Aug 2009, at 18:21, Mark Polesky wrote:
Dan Eble wrote:
I appreciate your reply. Applying this statement to certain
other figures (e.g. key signature or clef) would indicate a bug.
Does a non-functional bar line differ f
Hi,
Are there any guidelines LilyPond adheres to for creating bounding
boxes?
For example, when I adjusted the bbox for the \eyeglasses markup
command, I _underestimated_ the bbox. Should I have slightly
_overestimated_ instead? Attached is a PNG displaying the bbox.
Also, in the case of Metaf
On Mon, 2009-08-10 at 00:52 +0200, Reinhold Kainhofer wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Another issue with the new vertical layout engine:
>
> I have a score with lyrics and multiple pieces. With the new vertical laytout
> engine, the lyrics of the last staff before a
On Sun, Aug 09, 2009 at 05:52:41PM -0600, Andrew Hawryluk wrote:
> In the snippet printing-the-bar-number-for-the-first-measure.ly (NR
> 1.2.5), there appears to be an error.
> It recommends
>
> \set Score.barNumberVisibility = #all-bar-numbers-visible
> \bar ""
>
> but the first line gives a war
In the snippet printing-the-bar-number-for-the-first-measure.ly (NR
1.2.5), there appears to be an error.
It recommends
\set Score.barNumberVisibility = #all-bar-numbers-visible
\bar ""
but the first line gives a warning: type check for
`barNumberVisibility' failed; value `#' must be of type
`pro
On Sun, Aug 09, 2009 at 11:45:05PM +0200, John Mandereau wrote:
> Le samedi 08 août 2009 à 13:55 -0600, Carl Sorensen a écrit :
> > As a practical matter, -r first applies the changes that were made on origin
> > (since your branch was checked out), then applies your changes on top of the
> > curr
On Sun, 2009-08-09 at 20:25 +0100, Neil Puttock wrote:
> 2009/8/9 Reinhold Kainhofer :
>
> > Yes, this seems to work. But if I set alignAboveContext, then staff-
> > affinity=#DOWN should be automatically applied. After all, I'm already
> > telling
> > lilypond that this context should be above t
On Sun, 2009-08-09 at 21:16 +0200, Werner LEMBERG wrote:
> > I'm not sure what's going on here, Werner, but something which might
> > improve matters would be to use barlines for divisiones instead of
> > breathing signs: since Joe's fixed the spacing problems associated
> > with empty barlines, it
2009/8/1 Mark Polesky :
> The patch looks good to me
I agree, but I think this will have to wait until the chord naming
code has been reworked since it appears to rely on \hspace having some
vertical extent for correct positioning.
> but I'd also remove the comment above it:
> ;; todo: fix negat
On 09/08/2009 23:23, John Mandereau wrote:
Sorry for my initial reply to this, it was not enough to the point, I'm
trying again :-)
Le jeudi 06 août 2009 à 09:55 -0700, Mark Polesky a écrit :
Well, now I think we're pretty much back at Han-Wen's original
suggestion, which was to have two comman
On Sun, Aug 09, 2009 at 03:53:51PM +0200, Werner LEMBERG wrote:
> Does ancient music work correctly -- I mean `correctly' to the extent
> of the limited support we have?
To the best of my knowledge, ancient music has been officially not
supported since 2006 or 2007 or so. Ju"rgen Reuter was the o
2009/8/10 Patrick McCarty :
> I wonder why we are seeing different beaming patterns? I think all of
> your manually-beamed patterns are correct though.
Trevor's using the MinGW build I posted a few days ago, so it's
missing Carl's last changes to beam-settings.scm.
Regards,
Neil
_
On Sun, Aug 09, 2009 at 11:38:22PM +0100, Trevor Daniels wrote:
>
> Carl Sorensen wrote Sunday, August 09, 2009 10:59 PM
>
> >Could the two of you please take some of these examples and beam
> >them
> >manually so that I can see what they *should* do? I'll then try
> >to figure
> >out why the au
Le dimanche 09 août 2009 à 08:27 +0200, Werner LEMBERG a écrit :
> Is it OK nowadays to say
>
> git pull
> make all
>
> to *really* have a good build?
Not really. There is an issue in the tracker about fonts that are not
rebuilt after changes in the fonts sources and the build tree is not
Dan Eble writes:
> On 9 Aug 2009, at 18:21, Mark Polesky wrote:
>
>> Dan Eble wrote:
>>> I appreciate your reply. Applying this statement to certain
>>> other figures (e.g. key signature or clef) would indicate a bug.
>>> Does a non-functional bar line differ from those?
>>
>> I wouldn't apply t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Another issue with the new vertical layout engine:
I have a score with lyrics and multiple pieces. With the new vertical laytout
engine, the lyrics of the last staff before a new piece title are printed AFTER
the piece title. An example is attached.
Carl Sorensen wrote:
> Hmmm... The planned syntax improvements are to get rid of prefix commands,
> but music functions are always prefix operators. So I guess we'll be
> distinguishing between "commands" (or some other name -- operators?) and
> music functions.
>
> We will need to be careful
On 8/9/09 4:23 PM, "John Mandereau" wrote:
> Sorry for my initial reply to this, it was not enough to the point, I'm
> trying again :-)
>
> Le jeudi 06 août 2009 à 09:55 -0700, Mark Polesky a écrit :
>> Well, now I think we're pretty much back at Han-Wen's original
>> suggestion, which was to
Carl Sorensen wrote Sunday, August 09, 2009 10:59 PM
Could the two of you please take some of these examples and beam
them
manually so that I can see what they *should* do? I'll then try
to figure
out why the autobeam engraver doesn't do it.
Some explanation as to *why* it should work the w
Dan Eble wrote:
> OK, but what I was trying to ask is, is it a *correct* behavior
> of the \bar command? Saying that something is so differs from
> saying that it should be so.
The way I see it, the \bar command itself is a workaround...
- Mark
_
Dan Eble wrote:
> In case it is relevant, here is the applied function. (I know
> it's not perfect. For one thing, the double bar lines still
> consume space when they are invisible.)
This should be fixed in 2.13.4. If you're on Windows, you can try
Neil's snapshot from a couple days ago:
http://
On 8/9/09 4:27 PM, "John Mandereau" wrote:
> Le dimanche 09 août 2009 à 16:21 -0600, Carl Sorensen a écrit :
>> Perfect! I hope I didn't mess up the translated docs too badly with my
>> recent merge.
>
> The only risk to mess up translated docs checking is in case you change
> committishes t
On 9 Aug 2009, at 18:21, Mark Polesky wrote:
Dan Eble wrote:
I appreciate your reply. Applying this statement to certain
other figures (e.g. key signature or clef) would indicate a bug.
Does a non-functional bar line differ from those?
I wouldn't apply that statement to other figures. This i
Le dimanche 09 août 2009 à 16:21 -0600, Carl Sorensen a écrit :
> Perfect! I hope I didn't mess up the translated docs too badly with my
> recent merge.
The only risk to mess up translated docs checking is in case you change
committishes that appear as comments at the head of each file. If this
Sorry for my initial reply to this, it was not enough to the point, I'm
trying again :-)
Le jeudi 06 août 2009 à 09:55 -0700, Mark Polesky a écrit :
> Well, now I think we're pretty much back at Han-Wen's original
> suggestion, which was to have two commands, one for temporary
> afterGraceFractio
Dan Eble wrote:
> I appreciate your reply. Applying this statement to certain
> other figures (e.g. key signature or clef) would indicate a bug.
> Does a non-functional bar line differ from those?
I wouldn't apply that statement to other figures. This is a
specific behavior of the \bar command.
On 8/9/09 3:45 PM, "John Mandereau" wrote:
> Le samedi 08 août 2009 à 13:55 -0600, Carl Sorensen a écrit :
>> As a practical matter, -r first applies the changes that were made on origin
>> (since your branch was checked out), then applies your changes on top of the
>> current origin. The pre
Patrick McCarty wrote Saturday, August 08, 2009 5:33 PM
On Sat, Aug 08, 2009 at 01:59:50AM -0700, Graham Percival wrote:
A few people talked about browsing the history, which surprised
me. Whenever I want to look at history, I use the web git
interface. But evidently other people don't sha
On 8/9/09 1:56 PM, "Trevor Daniels" wrote:
>
>
> Patrick McCarty wrote Sunday, August 09, 2009 3:36 AM
>
>
>> On Sat, Aug 08, 2009 at 07:21:42PM -0700, Patrick McCarty wrote:
>>>
>>
>> Hmm, I just realized that the inconsistency still exists, even
>> with my
>> patch. Here's an example:
Le samedi 08 août 2009 à 13:55 -0600, Carl Sorensen a écrit :
> As a practical matter, -r first applies the changes that were made on origin
> (since your branch was checked out), then applies your changes on top of the
> current origin. The prevents an extra commit to merge your branch with
> or
On 9 Aug 2009, at 15:46, Trevor Daniels wrote:
Mark Polesky wrote Sunday, August 09, 2009 7:31 PM
Well, that's not a functional barline, it's just printed.
Mark,
I appreciate your reply. Applying this statement to certain other
figures (e.g. key signature or clef) would indicate a bug.
2009/8/9 Werner LEMBERG :
> Yes, I made the same suggestion.
Curse my slow fingers and dithering over the appearance of a PNG. :)
> Indeed. I can only glimpse a single serious problem: the last
> \divisioMinima is positioned incorrectly.
Because it follows a melisma, there's no text underneat
Hi,
If you did, I've removed the tag for the time being, since `Hiding the
extender line for text dynamics' is already included as a docs
snippet. If you think the other snippet's a better option, please let
me know.
Cheers,
Neil
___
lilypond-devel m
2009/8/7 Valentin Villenave :
> So, I'm thinking that we'd better junk these pseudo-options, and ask
> Seba to make HTML formatting allowed in all snippet descriptions.
I think this is the best option; anything which simplifies the process
of adding snippets for users is preferable.
Do you know
Patrick McCarty wrote Sunday, August 09, 2009 3:36 AM
On Sat, Aug 08, 2009 at 07:21:42PM -0700, Patrick McCarty wrote:
Hmm, I just realized that the inconsistency still exists, even
with my
patch. Here's an example:
\relative c'' {
a8 a a a
a8 a a a
a16 a a8 a a
a8 a16 a a
Mark Polesky wrote Sunday, August 09, 2009 7:31 PM
Well, that's not a functional barline, it's just printed. It's
similar to putting ":|" which prints a repeat sign, but doesn't
cause LilyPond to recognize the previous section as repeated. I
guess NR 1.2.5 could make this clearer.
original par
2009/8/9 Reinhold Kainhofer :
> Yes, this seems to work. But if I set alignAboveContext, then staff-
> affinity=#DOWN should be automatically applied. After all, I'm already telling
> lilypond that this context should be above the staff, so the vertical layout
> engine should be smart enough to ke
> I'm not sure what's going on here, Werner, but something which might
> improve matters would be to use barlines for divisiones instead of
> breathing signs: since Joe's fixed the spacing problems associated
> with empty barlines, it should be possible to reinstate barAlways =
> ##t together with
Dan Eble wrote:
> That reminds me of a problem I once encountered. Aren't
> accidentals normally supposed to be cancelled by the next bar
> line? This one carries over, so that the second B flat has no
> flat printed.
>
> \version "2.12.1"
> \include "english.ly"
>
> \relative c'
> {
> c4 c bf
2009/8/9 Werner LEMBERG :
> Does ancient music work correctly -- I mean `correctly' to the extent
> of the limited support we have? Looking at the headword of section
> 2.8 (Ancient notation), I see that the very last note clashes with the
> final double barline. Additionally, if I change the \p
> \break doesn't always work where you'd expect; this is because the
> divisiones are breath marks not barlines. So doing "\finalis \break"
> doesn't always work. In fact, the VaticanaVoice context defaults to
> 4/4 time-signature, even though this is meaningless in Gregorian
> Chant. So "\finalis
Hi,
On Sat, 8 Aug 2009, Patrick McCarty wrote:
> On Sat, Aug 08, 2009 at 01:59:50AM -0700, Graham Percival wrote:
> >
> > A few people talked about browsing the history, which surprised me.
> > Whenever I want to look at history, I use the web git interface. But
> > evidently other people do
Werner LEMBERG wrote:
> ... (Ancient notation), I see that the very last note clashes
> with the final double barline. Additionally, if I change the
> \paper section from ... ragged-right=##t ... to ...
> line-width=15\cm ... I see that the \finalis double line is two
> times positioned *before*
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am Sonntag, 9. August 2009 18:03:28 schrieb Neil Puttock:
> 2009/8/9 Reinhold Kainhofer :
> > Attached is another problem with the new vertical layout engine: Lyrics
> > are always spaced as if they belong to the staff above. If you have a
> > lyrics c
2009/8/8 Frédéric Bron :
> For example, today, it is not possible to have neo-modern at voice level.
> Separating the level from the method would reduce the number of
> automatic types and would enlarge the possibilities.
The problem is that the Accidental_engraver has to be placed in the
Staff c
2009/8/9 Reinhold Kainhofer :
> Attached is another problem with the new vertical layout engine: Lyrics are
> always spaced as if they belong to the staff above. If you have a lyrics
> context with alignAboveContext = #"...", then this is not true and the result
> looks bad (because the lyrics are
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Attached is another problem with the new vertical layout engine: Lyrics are
always spaced as if they belong to the staff above. If you have a lyrics
context with alignAboveContext = #"...", then this is not true and the result
looks bad (because the
[git 2eee8fa8 from today]
Does ancient music work correctly -- I mean `correctly' to the extent
of the limited support we have? Looking at the headword of section
2.8 (Ancient notation), I see that the very last note clashes with the
final double barline. Additionally, if I change the \paper se
> That reminds me of a problem I once encountered. Aren't accidentals
> normally supposed to be cancelled by the next bar line? This one carries
> over, so that the second B flat has no flat printed.
>
> \version "2.12.1"
> \include "english.ly"
>
> \relative c'
> {
> c4 c bf \bar "||" bf | c1
>
That reminds me of a problem I once encountered. Aren't accidentals
normally supposed to be cancelled by the next bar line? This one
carries
over, so that the second B flat has no flat printed.
\version "2.12.1"
\include "english.ly"
\relative c'
{
c4 c bf \bar "||" bf | c1
}
--
Dan
On 8
On Sun, Aug 09, 2009 at 08:27:28AM +0200, Werner LEMBERG wrote:
>
> Second, is it now safe to follow with
>
> make doc
>
> to get an up-to-date documentation?
I can't speak to the normal compilation, but "make doc" is
explicitly *NOT* guaranteed without a "make doc-clean" for the
next few wee
[git b6e82e5a from today]
Joe,
since documentation of your changes is not yet available, I have to
ask directly: What's the new method for providing proper distances
between the header, the body, and the footer of a page? If I do it
the old way (this is, I just run a new lilypond binary on my
Folks,
assume that I've compiled lilypond from scratch, say, two weeks ago,
together with the full documentation. Is it OK nowadays to say
git pull
make all
to *really* have a good build? For example, I see that there are no
makefile rules which handle changes to configure.in or aclocal.
On Sat, Aug 08, 2009 at 07:59:25AM -0700, Mark Polesky wrote:
>
> Graham Percival wrote:
>
> > But evidently other people don't share my pathological
> > hatred of git...
>
> Umm, hello?
Oh, you're getting there. But to be like me, you still need to
spend another 3 years contributing to lilypo
Kieren MacMillan Sunday, August 09, 2009 4:47 AM
From my point of view the main use for smallStaff (or whatever it
gets called) is for ossia staves.
Except IIRC ossia staves and solo/cue staves are usually of
different sizes, yes?
In scores for a capella vocal music a piano
accompaniment
62 matches
Mail list logo
