headers
Marc Hohl | 1 Oct 2009 08:59
Picon
Favicon

Re: different sizes for instrument names (Staff vs. PianoStaff)

Mats Bengtsson schrieb:
> The simple explanation is that the fontSize property is handled by the 
> Font_size_engraver, which by default lives in the Staff context. Since 
> the PianoStaff instrument names are typeset at the PianoStaff level, 
> it means that the value of fontSize isn't used, then.
> One solution is to add the engraver also at the PianoStaff level:
> \layout{
>  \context{
>    \PianoStaff
>    \consists "Font_size_engraver"
>  }
> }
Ah, I understand. Thanks for this clarification!
>
> As far as I can see, this does not influence how the fontSize property 
> is handled at the Staff level, so there should be no negative 
> side-effects.
Wouldn't it make sense to include the Font_size_engraver by default into 
the PianoStaff context?
>
> An alternative, is to explicitly set the font size for the instrument 
> names:
> \new PianoStaff \with { \override InstrumentName #'font-size = 
> #(magnification->font-size 2/3) ... }
>
I found yet another solution via \markup:
\new PianoStaff \with { instrumentName = \markup { \font-size 
#(magnification->font-size 2/3) ... } }

Thanks,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jean-Charles Malahieude | 1 Oct 2009 15:59
Picon
Favicon

Re: output-distance.py

Le 30/09/2009 23:17, Patrick McCarty disait :
>
> Hi,
>
> On 2009-09-30, Jean-Charles Malahieude wrote:
>> On Tue, 29 Sep 2009 13:36:32, Patrick McCarty wrote:
>>>
>>> Aside from a build failure in the German docs (notation.de.pdf), I can
>>> cleanly compile the docs with `make -j2' on the second run.
>>
>> No problem to build everything on a fresh tree according to commit
>> e785c84e6dfaca8ad657337418bd407da781adba
>> with 'make -j3&&  make -j3 doc'.
>>
>> But make check fails. If you wish to have a look at the log file...
>
> Did you do 'make test-baseline' before commit 4c5a581ca ?
>
> If you did, I think that is the reason why 'make check' is failing for
> you, since the directory names and snippet names are different now.
>
> I have a different problem related to 'make check' that is unrelated,
> so I can't easily test this right now.  Does it work if you do a
> test-baseline for commit 4c5a581ca, and then a 'make check' with
> current master?
>
>
> Thanks,
> Patrick
(Continue reading)

Permalink | Reply | 3 comments |
headers
Patrick McCarty | 1 Oct 2009 20:45
Picon
Gravatar

Re: output-distance.py

On 2009-10-01, Jean-Charles Malahieude wrote:
> 
> In fact, it was on a fresh local clone of the master branch as of
> Reinhold's "Fix killCues ..." patch dated 2009-09-30 15:44:45. I
> never did a 'test-baseline' before.
> Would you like me to clean everything, rewind to 4c5a581ca, make a
> test-baseline (and save the logs), and then rebuild as of a clean
> current master?  I'm available for the next 5 hours, going forward
> on my translation process (in a separate directory/clone)...

Sure, I think that would be helpful.

Thanks,
Patrick
Permalink | Reply | 2 comments |
headers
Patrick McCarty | 1 Oct 2009 23:37
Picon
Gravatar

Re: GUB - Failed target: darwin-x86::cross/gcc

Hi Jan,

On 2009-09-18, Jan Nieuwenhuizen wrote:
> Op donderdag 17-09-2009 om 18:19 uur [tijdzone -0700], schreef Patrick
> McCarty:
> 
> > Doing a "make -f lilypond.make bootstrap", GUB halts at
> > darwin-x86::cross/gcc.
> 
> Could you look into that?

I am still unable to tell what is causing this error.

As a test, I bumped darwin-ppc::cross/gcc to version 4.3.2, and it too
fails with the same error, i.e.

  make[2]: *** [stmp-fixinc] Error 1

The various differences I'm noticing in the logs are most likely due
to the many changes between 4.1.1 and 4.3.2.

I also tried to add this patch to GUB:

  http://gcc.gnu.org/ml/gcc-patches/2009-09/msg01259.html

to see if that would fix it, but for some reason I couldn't get that
working; my normal method of adding "patches = [...]" didn't work.
GUB just seemed to skip over the "patches = [...]" line and only
applied the substitutions in the "patch" function.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Graham Percival | 1 Oct 2009 23:40
Picon
Favicon

Re: GUB - Failed target: darwin-x86::cross/gcc

On Thu, Oct 01, 2009 at 02:37:13PM -0700, Patrick McCarty wrote:
> On 2009-09-18, Jan Nieuwenhuizen wrote:
> > Op donderdag 17-09-2009 om 18:19 uur [tijdzone -0700], schreef Patrick
> > McCarty:
> > 
> > > Doing a "make -f lilypond.make bootstrap", GUB halts at
> > > darwin-x86::cross/gcc.
> > 
> > Could you look into that?
> 
> I am still unable to tell what is causing this error.

Recent GUB (from 3 days ago, IIRC) has much better logging --
could you try a git update and try again?  It almost certainly
still fail, but at least it will be easier to find the relevant
log file(s).

Cheers,
- Graham
Permalink | Reply | 1 comment |
headers
Patrick McCarty | 1 Oct 2009 23:50
Picon
Gravatar

Re: GUB - Failed target: darwin-x86::cross/gcc

On 2009-10-01, Graham Percival wrote:
> On Thu, Oct 01, 2009 at 02:37:13PM -0700, Patrick McCarty wrote:
> > On 2009-09-18, Jan Nieuwenhuizen wrote:
> > > Op donderdag 17-09-2009 om 18:19 uur [tijdzone -0700], schreef Patrick
> > > McCarty:
> > > 
> > > > Doing a "make -f lilypond.make bootstrap", GUB halts at
> > > > darwin-x86::cross/gcc.
> > > 
> > > Could you look into that?
> > 
> > I am still unable to tell what is causing this error.
> 
> Recent GUB (from 3 days ago, IIRC) has much better logging --
> could you try a git update and try again?  It almost certainly
> still fail, but at least it will be easier to find the relevant
> log file(s).

Yes, I started a build from scratch a couple of days ago, and I much
appreciate the improved logging.  Thanks, Jan!

The two logs I was just comparing were

  darwin-ppc/log/cross/gcc.log
  darwin-ppc/log/cross/gcc.log.20090930-153622

One difference that might be of significance are this line (leaving
irrelevant information out with [...]):

  GCC 4.1.1:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Neil Puttock | 2 Oct 2009 00:32
Picon

[PATCH] Fix #69: RehearsalMark end-of-score visibility

Hi there,

Here's a patch which ensures that a RehearsalMark at the end of a
score will be visible without having to set 'break-visibility
manually:

http://codereview.appspot.com/126073/show

Please review.

Cheers,
Neil
Permalink | Reply | 2 comments |
headers
Neil Puttock | 2 Oct 2009 00:52
Picon

Re: [PATCH] New margin handling - final version (updated)

2009/9/30 Michael Käppler <xmichael-k <at> web.de>:
> Are there still any objections against applying?

I guess not. :)

There are a few minor nitpicks remaining with whitespace and
formatting, but I'll sort those out once I've applied the patch.

Would you mind preparing a patch to document the changes (in
particular, right-margin)?

Regards,
Neil
Permalink | Reply | 7 comments |
headers
Michael Käppler | 2 Oct 2009 09:28
Picon

Re: [PATCH] New margin handling - final version (updated)


> There are a few minor nitpicks remaining with whitespace and
> formatting, but I'll sort those out once I've applied the patch.
>   
Hmm, that's bad. Can you tell me more exactly what's happened? I thought 
the whitespace issues have gone since I've configured vim to 
automatically remove trailing whitespace on saving. What do you mean 
with "formatting"? Are there still overlong lines or do you speak of 
indentation?

> Would you mind preparing a patch to document the changes (in
> particular, right-margin)?
>   
Yes, sure.

Regards,
Michael
Permalink | Reply | 0 comments |
headers
Mats Bengtsson | 2 Oct 2009 11:53
Picon
Picon
Favicon

Re: [PATCH] Fix #69: RehearsalMark end-of-score visibility

Nice! However, this will only solve a few of the special situations 
where you need to override the break-visibility of RehearsalMarks. How 
about separating the syntax and grobs used for typesetting rehearsal 
marks from used to attach other information to a bar line. Using \mark 
to add fermatas or "Fine" or whatever to a bar line, feels more and more 
like an ugly cludge, since it's very often you have to override both 
break-visibility and other properties (and struggle to revert them or 
use \once to avoid that these settings affect the true rehearsal marks).
Then, it would perhaps even be possible to add support for situations like
- Fermatas both above and below the system
- Different marks at the end of a line and at the beginning of the next line

I shouldn't really say these things since I don't have the time to 
contribute to the implementation myself, but perhaps someone is tempted 
to give it a try.

     /Mats

Neil Puttock wrote:
> Hi there,
>
> Here's a patch which ensures that a RehearsalMark at the end of a
> score will be visible without having to set 'break-visibility
> manually:
>
> http://codereview.appspot.com/126073/show
>
> Please review.
>
> Cheers,
(Continue reading)

Permalink | Reply | 0 comments |

Gmane