Re: github mirror of lilypond?

[Erlend Aasland]

(Sorry for the messed up indent/quote level. Apple Mail is a pain in the butt 
sometimes.)

> On 19 Jan 2020, at 21:31, Erlend Aasland  wrote:
> 
> On 19 Jan 2020, at 18:19, David Kastrup mailto:d...@gnu.org>> 
> wrote:
> What is of concern is the whole metadata about issues and their handling
> and resolution, the stuff you propose moving to GitHub in the first
> place.
> 
> Just for the record; I’m not suggesting GitHub as the one and only 
> alternative. I think I mentioned some of the GH alternatives in my original 
> email, IIRC.
> 
> I understand the concern about metadata and such, but a lot of that 
> information is already present in the commits (both as metadata in the 
> commits and as commit messages), so I guess you’ve already put uncomfortably 
> much information in there already…
> 
> The current use of Savannah hosting for that reason is not a whole lot
> more than a vote of confidence to GNU/FSF/Stallman (which at the current
> point of time are more separate entities than they historically were)
> but not of practical importance.
> 
> True.
> 
> Our current ties to Google (via Rietveld) and SourceForge (for
> Allura/issue tracking) are practically speaking more tenuous to replace.
> Of course they deserve replacing, but doing so by picking GitHub would
> definitely be a much more invasive step for the project than just
> entertaining a Git mirror.
> 
> True.
> 
> Make no mistake: our current dependencies in that regard are of lukewarm
> quality concerning the "Free Software" regard and are a crutch
> technically.  So a change is definitely called for.
> 
> True.
> 
> But I don’t consider GitHub a nobrainer or I'd likely have an account there: 
> I chose
> not to the last time I read their terms of use, and while I haven't
> rechecked since then, its change of ownership does not inspire
> confidence.  Now of course the terms and guarantees then might have been
> chosen in order not to interfere with potential high-powered
> acquisitions, a goal many startups work towards to, and may be something
> that Microsoft does not need to bother with.  So in theory they might
> even have improved.  I'd need to check again.
> 
> I haven’t delved into this either, but I know that they “support GPL” 
> (whatever that means).
> 
> But LilyPond is a size where taking out a commercial offer would be pretty 
> expensive, and
> taking out a free offer means you have nothing to rely or insist on
> since there hasn't been an exchange of considerations involved.
> 
> True. But, there are GitHub alternatives that are free, for example Gitea.
> 
> 
> Erlend
> 
> 
> --
> David Kastrup
> 

Re: github mirror of lilypond?

[Erlend Aasland]

On 19 Jan 2020, at 18:19, David Kastrup mailto:d...@gnu.org>> 
wrote:
What is of concern is the whole metadata about issues and their handling
and resolution, the stuff you propose moving to GitHub in the first
place.

Just for the record; I’m not suggesting GitHub as the one and only alternative. 
I think I mentioned some of the GH alternatives in my original email, IIRC.

I understand the concern about metadata and such, but a lot of that information 
is already present in the commits (both as metadata in the commits and as 
commit messages), so I guess you’ve already put uncomfortably much information 
in there already…

The current use of Savannah hosting for that reason is not a whole lot
more than a vote of confidence to GNU/FSF/Stallman (which at the current
point of time are more separate entities than they historically were)
but not of practical importance.

True.

Our current ties to Google (via Rietveld) and SourceForge (for
Allura/issue tracking) are practically speaking more tenuous to replace.
Of course they deserve replacing, but doing so by picking GitHub would
definitely be a much more invasive step for the project than just
entertaining a Git mirror.

True.

Make no mistake: our current dependencies in that regard are of lukewarm
quality concerning the "Free Software" regard and are a crutch
technically.  So a change is definitely called for.

True.

But I don’t consider GitHub a nobrainer or I'd likely have an account there: I 
chose
not to the last time I read their terms of use, and while I haven't
rechecked since then, its change of ownership does not inspire
confidence.  Now of course the terms and guarantees then might have been
chosen in order not to interfere with potential high-powered
acquisitions, a goal many startups work towards to, and may be something
that Microsoft does not need to bother with.  So in theory they might
even have improved.  I'd need to check again.

I haven’t delved into this either, but I know that they “support GPL” (whatever 
that means).

But LilyPond is a size where taking out a commercial offer would be pretty 
expensive, and
taking out a free offer means you have nothing to rely or insist on
since there hasn't been an exchange of considerations involved.

True. But, there are GitHub alternatives that are free, for example Gitea.


Erlend


--
David Kastrup

Re: github mirror of lilypond?

[Erlend Aasland]

> On 19 Jan 2020, at 00:00, David Kastrup  wrote:
> 
> Erlend Aasland  writes:
> 
> GitHub is putting our eggs in Microsoft's basket.  Not too enthused
> about that idea.

Technically, you already did, since there is a GitHub LilyPond mirror…


E

> If I remember correctly, GitLab had some size
> restrictions that clearly are not going to fly with LilyPond.
> 
> -- 
> David Kastrup

Re: github mirror of lilypond?

[Erlend Aasland]

> On 19 Jan 2020, at 08:41, Han-Wen Nienhuys  wrote:
> 
> On Sun, Jan 19, 2020 at 7:21 AM Werner LEMBERG  wrote:
>>> As it stands, GitLab would probably be a more viable candidate to
>>> look at than GitHub.
>> 
>> I agree.  IMHO, the main repository should stay at Savannah, though.
> 
> I strongly disagree with this.

I do too.

> If we are serious about code review (and it seems that we are), the
> code review has to be integrated with the git hosting system. With the
> current setup, there needs to be infrastructure that takes a patch for
> review, applies it to source tree, runs tests, and then reports back.
> On submission, something has to apply the patch, and push the result
> to the git master branch.

Yes!

E

> I don't how this done today with LilyPond (manually?). Doing this
> manually is tedious and error-prone busywork. If it is automated, it
> requires infrastructure that needs maintenance, and we have too few
> developers anyway.
> 
> Also, in practice, if you visit the lilypond website, or its savannah
> page, one cannot find the in-progress patches that others are working
> on and you cannot find its bug reports.  By contrast, with Gerrit or
> Github, you could go to
> 
>  https://review.gerrithub.io/q/project:lilypond%252Flilypond+status:open
> 
> or
> 
> https://github.com/lilypond/lilypond/pulls
> 
> and see what is happening with the project.
> 
> --
> Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
> 

Re: github mirror of lilypond?

[Erlend Aasland]

Yes, I’m open for both GitHub, GitLab, Gitea, and similar «complete development 
environments» (or whatever it’s called.) I’ve been working in GitHub the last 
years, and it’s so nice to have a decent bugtracker, a great review tool, a 
great git web interface, and more, all in one place. It really saves 
development time and gets rid of a lot of developer frustrations.
Erlend


From: Jonas Hahnfeld 
Sent: Saturday, January 18, 2020 11:59:37 AM
To: Han-Wen Nienhuys ; Erlend Aasland 
Cc: lilypond-devel 
Subject: Re: github mirror of lilypond?

Am Samstag, den 18.01.2020, 10:38 +0100 schrieb Han-Wen Nienhuys:
> On Sat, Jan 18, 2020 at 8:35 AM Erlend Aasland <
> erlen...@innova.no
> > wrote:
> > Is there a reason _not_ to use GitHub for 
> > development/bugtracking/wiki/planning? The current dev model is, to put it 
> > mildly, and in lack of better words, cumbersome and archaic. GNU licences 
> > are AFAICS supported by GitHub, so that can’t be a showstopper. If we had a 
> > more modern development model, it would perhaps be easier to engage new 
> > (and old) developers. No offence meant for those of you who like the 
> > current dev model!
>
> I think this would be a good thing to discuss at the Salzburg event.
>
> I am partial to Gerrit, see eg.
>
>
> https://review.gerrithub.io/q/lilypond/lilypond
>
>
> regardless of the particular choice, though, a more standard
> environment would save developer time, and make it easier to onboard
> contributors.

I strongly dislike Gerrit, it's really hard to learn and even after
some time I still can't figure out how to use it correctly.
Both GitHub and GitLab (on gitlab.com) would be a great improvement.
Not sure though if this is "allowed" for GNU projects (it's probably
not about the license, but being "GNU LilyPond").

Jonas

Re: github mirror of lilypond?

[Erlend Aasland]

Is there a reason _not_ to use GitHub for 
development/bugtracking/wiki/planning? The current dev model is, to put it 
mildly, and in lack of better words, cumbersome and archaic. GNU licences are 
AFAICS supported by GitHub, so that can’t be a showstopper. If we had a more 
modern development model, it would perhaps be easier to engage new (and old) 
developers. No offence meant for those of you who like the current dev model!


Erlend



From: lilypond-devel  
on behalf of Han-Wen Nienhuys 
Sent: Saturday, January 18, 2020 12:04:15 AM
To: lilypond-devel 
Subject: github mirror of lilypond?

It looks like https://github.com/lilypond was last updated in Jun
2019. If there was an automated mirror, it has stopped working. Could
someone give it a kick again?

--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen

Re: [Notensatz im 21. Jahrhundert] documentation for those who cannot attend?

[Erlend Aasland]

Oh yes, a video or audio stream of the whole conference (or parts or it) would 
be very cool. I would also like to attend, but due to family obligations, I 
can’t travel that weekend. Hope to be able join next year.


Erlend E. Aasland

> On 12 Jan 2020, at 20:00, Malte Meyn  wrote:
> 
> Hi list,
> 
> after reading the recent threads about the upcoming conference I had another 
> look at the updated programme and saw that so many of you will be there and 
> the LilyPond dev meeting on Sunday will have a very interesting agenda. I 
> would love to come and meet you in person after all the years on this list 
> but sadly I can’t make it :'(
> 
> I assume that many of the talks and discussions would be interesting for lots 
> of developers who cannot come. Is there a possibility to document the 
> unconference day, f.e. by recording video and distributing it (if not public 
> then protected by password that only users asking for it get by private mail)?
> 
> Cheers,
> Malte
> 

Re: macOS 64-bit

[Erlend Aasland]

Hi Marnen. Seems to work fine here (after necessary adjustments in System 
Preferences => Security & Privacy).
MacBook Pro running macOS Catalina version 10.15.2.


Erlend E. Aasland

On 11 Jan 2020, at 20:31, Marnen Laibow-Koser 
mailto:mar...@marnen.org>> wrote:

On Sat, Jan 11, 2020 at 8:58 AM Marnen Laibow-Koser 
mailto:mar...@marnen.org>>
wrote:



On Sat, Jan 11, 2020 at 8:45 AM Dan Eble 
mailto:d...@faithful.be>> wrote:

On Jan 11, 2020, at 08:40, Marnen Laibow-Koser 
mailto:mar...@marnen.org>> wrote:
Dammit, I did already fix this error!  I wonder if I left the modified
gs.reloc file out of the bundle by mistake, or if something else is going
on.

Would you post the contents of
LilyPond.app/Contents/Resources/etc/relocate/gs.reloc ?

$ cat /Applications/LilyPond.app/Contents/Resources/etc/relocate/gs.reloc

prependdir GS_FONTPATH=$INSTALLER_PREFIX/share/ghostscript/9.50/fonts
prependdir GS_FONTPATH=$INSTALLER_PREFIX/share/gs/fonts
prependdir GS_LIB=$INSTALLER_PREFIX/share/ghostscript/9.50/Resource
prependdir GS_LIB=$INSTALLER_PREFIX/share/ghostscript/9.50/Resource/Init


OK, this was a packaging error: I forgot to update this file in the
bundle.  I’ll have a fix later today if all goes welll.  Sorry to waste
your time!


New version is now available at
https://bintray.com/marnen/lilypond-darwin-64/download_file?file_path=lilypond-2.19.83.build20200111.1-darwin-64.tar.gz
(sha-256 6f1300a64281273da22c53926b6f5cbfa41fe612df173b0aaa4da905ee6b2af7;
I switched to Bintray because Google Drive isn't that great for hosting
large downloads).  I fixed the packaging error, and hopefully everything
should be OK now.

Best,
--
Marnen Laibow-Koser
mar...@marnen.org
http://www.marnen.org

Re: MacOS 64-bit build

[Erlend Aasland]

Argh, yes, you are of course right. Thanks.


Erlend

> On 9 Jan 2020, at 13:34, Werner LEMBERG  wrote:
> 
> 
>> `configure` should warn or bail on incompatible flex versions.  I
>> suggest we add a version check in configure.ac to ensure that flex
>> version is between 2.5.37 and 2.5.39 (given that 2.5.38 and 2.5.39
>> actually works).
> 
> What you suggest wouldn't work as expected.  There is no guarantee
> that `FlexLexer.h` found during compilation is the one that is used by
> a recent flex version.  Unfortunately, `FlexLexer.h` doesn't contain
> any version information, so it is really impossible to protect against
> this situation automatically.
> 
> I was bitten by that on my Mac OS Lion box, and as a consequence I
> implemented the `--with-flexlexer-dir` configuration option.
> 
> 
>Werner

Re: MacOS 64-bit build

[Erlend Aasland]

(Sorry, 'bout incorrect quote level in previous email!)

E 

> On 9 Jan 2020, at 13:00, Erlend Aasland  wrote:
> 
>> On 13 Feb 2019, at 20:16, Daniel Johnson  wrote:
>> 
>> I am using guile 1.8.8, gcc 7.4.0, and flex 2.6.4.  Here's my configure line:
>> 
>> On build, I get a long string of errors originating in 
>> out/lexer.cc<http://lexer.cc>:
>> 
>> out/lexer.cc:6272<http://lexer.cc:6272>:46: error: cannot convert 
>> 'std::istream {aka
>> std::basic_istream}' to 'std::istream* {aka std::basic_istream*}'
>> in assignment
>>YY_CURRENT_BUFFER_LVALUE->yy_input_file = yyin;
> 
> Use flex 2.5.37, as the flex 2.6.* C++ lexer is broken (discussed on the Bison
> lists): a stream pointer has been changed in the declaration to a reference
> without doing it in the code. Reported some years ago on the flex list.
> 
> `configure` should warn or bail on incompatible flex versions. I suggest we 
> add a version check in configure.ac to ensure that flex version is between 
> 2.5.37 and 2.5.39 (given that 2.5.38 and 2.5.39 actually works).
> 
> 
> 
> Erlend E. Aasland

Re: MacOS 64-bit build

[Erlend Aasland]

> On 13 Feb 2019, at 20:16, Daniel Johnson  wrote:
>
> I am using guile 1.8.8, gcc 7.4.0, and flex 2.6.4.  Here's my configure line:
>
> On build, I get a long string of errors originating in 
> out/lexer.cc:
>
> out/lexer.cc:6272:46: error: cannot convert 
> 'std::istream {aka
> std::basic_istream}' to 'std::istream* {aka std::basic_istream*}'
> in assignment
> YY_CURRENT_BUFFER_LVALUE->yy_input_file = yyin;

Use flex 2.5.37, as the flex 2.6.* C++ lexer is broken (discussed on the Bison
lists): a stream pointer has been changed in the declaration to a reference
without doing it in the code. Reported some years ago on the flex list.

`configure` should warn or bail on incompatible flex versions. I suggest we add 
a version check in configure.ac to ensure that flex version is between 2.5.37 
and 2.5.39 (given that 2.5.38 and 2.5.39 actually works).



Erlend E. Aasland

Re: Status of Guile 2.0 Support (Next Debian release won't ship guile-1.8)

[Erlend Aasland]

Right, so we’re sticking with 1.8 for now. Have we ever considered throwing out 
Guile and replacing it with something else? (Yes, I know that would be a huge 
operation.)


Erlend

> On 8 Jan 2020, at 13:29, David Kastrup  wrote:
> 
> Erlend Aasland  writes:
> 
>> Hey, guys! What’s the status of Guile support in LilyPond? Is there
>> still a transition from Guile 1.8 to 2.0 happening, or has 2.0 been
>> ditched in favour of 2.2? I did a quick search in the
>> bugtracker<https://sourceforge.net/p/testlilyissues/issues/search/?q=guile>,
>> and there seem to be people who use Guile 2.x with LP.
> 
> Guile 2.x (or the upcoming 3.x) continues to be a non-sensible option
> for using LilyPond.  The state is "barely working" and "at least 3 times
> slower".
> 
> -- 
> David Kastrup

Re: Status of Guile 2.0 Support (Next Debian release won't ship guile-1.8)

[Erlend Aasland]

I understand. Thanks for your answers.


Erlend

> On 8 Jan 2020, at 13:51, David Kastrup  wrote:
> 
> Erlend Aasland  writes:
> 
>> Right, so we’re sticking with 1.8 for now. Have we ever considered
>> throwing out Guile and replacing it with something else? (Yes, I know
>> that would be a huge operation.)
> 
> Replacing Scheme with something else would be a completely different
> application.  Using a different Scheme interpreter would not be easier
> than using Guile-2.x .
> 
> -- 
> David Kastrup

Re: Status of Guile 2.0 Support (Next Debian release won't ship guile-1.8)

[Erlend Aasland]

Hey, guys! What’s the status of Guile support in LilyPond? Is there still a 
transition from Guile 1.8 to 2.0 happening, or has 2.0 been ditched in favour 
of 2.2? I did a quick search in the 
bugtracker, 
and there seem to be people who use Guile 2.x with LP.


Erlend E. Aasland

Don Armstrong  writes:

> What is the current status of #1055[1] (support for Guile 2.0 in
> lilypond)?

I'm currently working on it.  There is a branch dev/guilev2 with the
current work.  Current objective is to make it through the test suite.
Several crashes so far look like the memory management is borked.

> Debian is going to be dropping guile-1.8 completely, so in order for
> lilypond to be in the next Debian release (and rosegarden, and a few
> other things), I need to have it support guile 2.0 at least a month
> before freeze, which will likely happen in February at the latest.

"Support guile 2.0" by 2015: not sure.  Support it in a manner that
would be preferable to an installation using 1.8: rather dubious.

Be released as stable version 2.20: unlikely.  At best, we'll have a
2.20 branch only open to bug fixes and Guile 2.0 necessitated changes.

But it seems feasible to get Guile 2.0 itself into the state needed to
support LilyPond by the time of the freeze.  Or get convincing
admissions that it isn't there yet, possibly bargaining for a last-time
inclusion of 1.8.

--
David Kastrup

Re: c:maj inconsistency

[Erlend Aasland]

Hi

On 19. mai. 2008, at 00:31, Carl D. Sorensen wrote:



Right now, :maj adds a major 7th step, even if no number is present.

c:maj is equivalent to c:maj7.  That is the confusion.



Agree


IMHO, by making c:maj equal to c, we would make c:maj7 (and
friends) less clear. By just disallowing c:maj (without a 7,
9, 11, ...) we get rid of the problem.



I'm OK with that, too.

In looking through the chord name scheme on Wikipedia (I know, it's  
not definitive for music, but it's widely available) (see http://en.wikipedia.org/wiki/Chord_(music) 
), Cmaj is listed as an alternate name for the major triad.  In any  
guitar music I've ever played, major chords are always indicated  
without any suffix.




Same here; As a jazz guitarist I've never seen a plain major chord  
notated with any kind of suffix.



E


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: c:maj inconsistency

[Erlend Aasland]

Hmmm, since c:maj is ambiguous, I think it's better to just disallow  
c:maj without the 7.


E

On 18. mai. 2008, at 00:43, Graham Percival wrote:

Exerpt from Chords:
---
maj
   The major 7th chord. This modifier adds a raised 7th step. The
7 following maj is optional. Do NOT use this modifier to create a
major triad.
---

In other words,
 \chordmode{ c:maj c:maj7 }
produce the same chord, although
 \chordmode{ c:m c:m7 }
don't.

Why?  IMO, it would be much clearer if
 \chordmode{ c c:maj }
produced the same output.


No, I'm not offering to make this change myself; I'm just seeking
arguments against adding this as a feature request.

Cheers,
- Graham


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel




___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Broken hairpinToBarline context property?

[Erlend Aasland]

Hi Neil

On 28. apr. 2008, at 01:22, Neil Puttock wrote:

Since there's a 'to-barline property now, I wonder whether
hairpinToBarline is deprecated; it's not documented in the internals
reference under Dynamic_engraver, and there's a bit of code in
dynamic-spanner.cc which is annotated 'backwards compatibility with
hairpinToBarline'. Perhaps 'to-barline should be set by default
instead in define-grobs.scm.



hairpinToBarline is as far as I know deprecated. 'to-barline should be  
set by default instead. Should we issue a warning when  
hairpinToBarline is used?



Regards,
  Erlend


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Broken hairpinToBarline context property?

[Erlend Aasland]

On 28. apr. 2008, at 08:57, Erlend Aasland wrote:

On 28. apr. 2008, at 01:22, Neil Puttock wrote:
[…] Perhaps 'to-barline should be set by default instead in define- 
grobs.scm.


hairpinToBarline is as far as I know deprecated. 'to-barline should  
be set by default instead.


Hmm... I've removed the invalid line in engraver-init.ly and instead  
added a default for 'to-barline in define-grobs.scm. But, since the  
code in lily/dynamic-engraver.cc only looks at hairpinToBarline when  
'to-barline is undefined, setting hairpinToBarline now won't work...


What about removing hairpinToBarline completely?


E

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Doc of 'style ?

[Erlend Aasland]

See commit 7e427da63980dfb6c9d1304ee189ac966c868f32

E

On 7. mar. 2008, at 19:07, Graham Percival wrote:


On Fri, 7 Mar 2008 13:55:49 +0100
Erlend Aasland [EMAIL PROTECTED] wrote:


Well, here's the possible style values for these interfaces. Since
english is not my main language, I leave it to somebody else to
write a nice documentation string.


Other doc strings were written by Han-Wen and Jan, so don't
feel that they need to be in nice English.  We're never going to
have so much doc help that we can be picky about this kind of
thing in the IR.

Please produce a full patch for this.

Cheers,
- Graham




___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Doc of 'style ?

[Erlend Aasland]

Hi,

On 7. mar. 2008, at 13:18, Mats Bengtsson wrote:

[…] the documentation of style is missing in the following interfaces:
custos-interface, system-start-delimiter-interface, dots-interface.

Anybody interested in doing some detective work in the C++ source  
code to
figure out what should be written in the documentation string for  
these interfaces?


Well, here's the possible style values for these interfaces. Since  
english is not my main language, I leave it to somebody else to write  
a nice documentation string.


lily/dots.cc, 2 valid styles:
vaticana and  (an empty string)
default is 

lily/system-start-delimiter.cc, 4 valid styles:
bracket, brace, bar-line  line-bracket
no default value (is bar-line an ok default value?)

lily/custos-interface, 4 valid styles:
mensural, vaticana, medicaea and hufnagel
default is mensural


Erlend



 /Mats



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

MusicXML patch

[Erlend Aasland]

Hi Reinhold

Since you've done most of the MusicXML stuff lately, could you please  
review the attached patch. I'll apply it if you approve it.



Regards,
  Erlend


xml.patch
Description: Binary data


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: MusicXML patch

[Erlend Aasland]

Ok, I've done a make web in input/regression/musicxml and I've checked  
that I did'nt break anything. I'll add a test for unpitched and graces  
withous type using Sibelius/Dolet later.



Best regards,
  Erlend

On 31. jan. 2008, at 17:10, Reinhold Kainhofer wrote:


Am Donnerstag, 31. Januar 2008 schrieb Erlend Aasland:

Since you've done most of the MusicXML stuff lately, could you please
review the attached patch. I'll apply it if you approve it.


Thanks for the patches.
I don't see any problems with the patch.
Can you maybe add a unit test for unpitched and for the graces with  
missing
type to input/regression/musicxml and check that your changes don't  
break

tests 13a and 13b (see
http://kainhofer.com/~lilypond/input/regression/musicxml/collated-files.html)?

Cheers,
Reinhold



--
--
Reinhold Kainhofer, Vienna University of Technology, Austria
email: [EMAIL PROTECTED], http://reinhold.kainhofer.com/
* Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/
* K Desktop Environment, http://www.kde.org, KOrganizer maintainer
* Chorvereinigung Jung-Wien, http://www.jung-wien.at/




___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Chord fonts

[Erlend Aasland]

Hmmm, strange. I've done a make distclean and a make web, but the  
m and s are still chosen from the wrong font. I'll try to  
investigate it later today.

Can anyone else reproduce this, or am I the only one with this problem?


Erlend

On 30. jan. 2008, at 07:19, Werner LEMBERG wrote:




The chord font seems to be messed up after the mf2pt1 change. The
letter m and s is chosen from the dynamic font (see attached
picture).  Can you reproduce this?


No, I can't repeat with the current git.  For me, the chord name chard
from the lilypond manual's appendix just displays fine (using ArialMT
installed on GNU/Linux box).


   Werner




___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: commit message

[Erlend Aasland]

Shure, no problem. I'll try to remember to document my commits better  
from now on.


E

On 30. jan. 2008, at 01:12, Han-Wen Nienhuys wrote:


Hi Erlend,


could you be a little more verbose in your messages?

**
   Fix issue 558
**


--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen




___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Chord fonts

[Erlend Aasland]

Hi Werner,

The chord font seems to be messed up after the mf2pt1 change. The  
letter m and s is chosen from the dynamic font (see attached  
picture). Can you reproduce this? I guess you can fix this pretty  
quick :-)



Best regards,
  Erlend
inline: pastedGraphic.png


inline: pastedGraphic.png

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: fonts mangling

[Erlend Aasland]

Some input to this problem:

With global staff size 20, everything is ok. When using other staff  
sizes, LP fails to find the correct feta-alphabet font, and therefore  
it's not included in the .ps and .pdf output. It seems that mf2pt1  
gives the fonts wrong names, thats why LP fails to find them:


From build output:
[...]
Font metrics written on parmesan23.tfm.
189 output files written: parmesan23.33 .. parmesan23.221
Transcript written on parmesan23.log.

mf2pt1 is using the following font parameters:
font_version:  001.000
font_comment:  Font converted to Type 1 by mf2pt1,  
written by Scott Pakin.

font_family:   parmesan22.45
font_weight:   Medium
font_identifier:   parmesan22.45
font_fixed_pitch:  false
font_slant:0
font_underline_position:   -45
font_underline_thickness:  22
font_name: parmesan22.45-Medium
font_unique_id:4956955
font_size: 22.3661270236613 (bp)
font_coding_scheme:asis
[...]

Font family, name and identifier should be 23, right?


Regards,
  Erlend

On 20. jan. 2008, at 20:48, Werner LEMBERG wrote:




Yes, he has, and he made some other changes too;


Ah, ok.


I played a bit with git bisect, running make clean  make each
time, and found that at least one of these commits caused this font
selection problem: [...]


I'm abroad with a slow internet connection (and limited time) so I
won't be able to investigate this further the next days.  Han-Wen?


Well, mf2pt1 only creates PFAs, nothing else.


Huh!? after compiling with current Git, I see a lot of .pfb files in
mf/out, but no .pfa; is it the source of the problem?


A typo of mine, sorry.


   Werner


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: fonts mangling

[Erlend Aasland]

... and here's the output of strings mf/out/feta-alphabet*.pfb | grep  
FontName:


[15:52:21][Macintosh-2]src/lilypond.git% strings mf/out/feta- 
alphabet*.pfb | grep FontName

/FontName /feta-alphabet11.22-Medium def
/FontName /feta-alphabet12.6-Medium def
/FontName /feta-alphabet14.14-Medium def
/FontName /feta-alphabet15.87-Medium def
/FontName /feta-alphabet17.82-Medium def
/FontName /feta-alphabet20-Medium def
/FontName /feta-alphabet22.45-Medium def
/FontName /feta-alphabet25.2-Medium def


Erlend

On 25. jan. 2008, at 15:48, Erlend Aasland wrote:


Some input to this problem:

With global staff size 20, everything is ok. When using other staff  
sizes, LP fails to find the correct feta-alphabet font, and  
therefore it's not included in the .ps and .pdf output. It seems  
that mf2pt1 gives the fonts wrong names, thats why LP fails to find  
them:


From build output:
[...]
Font metrics written on parmesan23.tfm.
189 output files written: parmesan23.33 .. parmesan23.221
Transcript written on parmesan23.log.

mf2pt1 is using the following font parameters:
font_version:  001.000
font_comment:  Font converted to Type 1 by mf2pt1,  
written by Scott Pakin.

font_family:   parmesan22.45
font_weight:   Medium
font_identifier:   parmesan22.45
font_fixed_pitch:  false
font_slant:0
font_underline_position:   -45
font_underline_thickness:  22
font_name: parmesan22.45-Medium
font_unique_id:4956955
font_size: 22.3661270236613 (bp)
font_coding_scheme:asis
[...]

Font family, name and identifier should be 23, right?


Regards,
  Erlend

On 20. jan. 2008, at 20:48, Werner LEMBERG wrote:




Yes, he has, and he made some other changes too;


Ah, ok.


I played a bit with git bisect, running make clean  make each
time, and found that at least one of these commits caused this font
selection problem: [...]


I'm abroad with a slow internet connection (and limited time) so I
won't be able to investigate this further the next days.  Han-Wen?


Well, mf2pt1 only creates PFAs, nothing else.


Huh!? after compiling with current Git, I see a lot of .pfb files in
mf/out, but no .pfa; is it the source of the problem?


A typo of mine, sorry.


   Werner


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Is bug reporting visible enough on lilypond.org?

[Erlend Aasland]

Hi Graham et al,

On 7. des. 2007, at 12:19, Graham Percival wrote:

Still, I should have dropped a link to:
http://lilypond.org/web/devel/participating/bugs


IMHO, this page could (or should) be more visible to users by  
providing a link on the front page of lilypond.org. A How to submit  
bugs-link in the top menu or under Quick links could helpful for  
bugreporters. Currently you have to dig through Development- 
Participating…-(scroll down)Reporting bugs before you find the  
correct link.



Kind regards,
  Erlend

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Is bug reporting visible enough on lilypond.org?

[Erlend Aasland]

Hi,

On 7. des. 2007, at 13:44, Mats Bengtsson wrote:
IMHO, this page could (or should) be more visible to users by  
providing a link on the front page of lilypond.org. A How to  
submit bugs-link in the top menu or under Quick links could  
helpful for bugreporters. Currently you have to dig through  
Development-Participating…-(scroll down)Reporting bugs before  
you find the correct link.

[…] Since you have to look at these places anyway
to find the email address to use, I would say that it already is well
advertized […]


Good point, I didn't think of that :-)


E

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Math stuff

[Erlend Aasland]

Hi Han-Wen,

There is an old comment in flower/include/real.hh about MacOSX 10.3  
and g++ 3.3. Can I apply the attached patch? I guess we could replace  
the is_inf() with std::isinf() in flower/offset.cc too.


Regards,
  Erlend


math.patch
Description: Binary data


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GDP: Colors in RGB?

[Erlend Aasland]

Hi Trevor,

Yes, the internal color format is hidden from the user on purpose. The  
reason for this is that if we need to change the internal format  
sometime in the future, the format change will not be noticed by the  
user. With the default color macros and the X11 color macros, the user  
won't have to care about the internal color representation.



Kind regards,
  Erlend Aasland

On 29. nov. 2007, at 20:49, Trevor Daniels wrote:



I'm helping to write the GDP manuals, and am puzzled by an
omission in the description of setting the color property of
grobs.  The Internals Reference (grob-interface) says the
color should be a list, and supplying a list of RGB values
like

   \once \override Voice.Slur #'color = #'(1.0 0.0 0.0)

certainly turns the slur red.  But this way of overriding
the color is not mentioned in any of the user manuals, at
least not that I can find.  Is there a reason for this
omission, or may I describe this method (as well as the
standard ones) in the new GDP manuals?

Trevor D




___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel




___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Logo for Lilypond

[Erlend Aasland]

Hi

On 14. sep. 2007, at 01.42, Han-Wen Nienhuys wrote:

2007/9/13, Jonas Nyström [EMAIL PROTECTED]:
To me, the nice little happy note does *not* give an association  
to the

professional level that Lilypond represents!


I totally agree.

I tried to make a stylish logo for my deceased company […] perhaps  
something along those lines?


Yes, I like this: a simple yet beautiful logo.

Just my humble opinion :-)


Regards,
  Erlend Aasland

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Guile and Lily

[Erlend Aasland]

Hello,

I've compiled and installed guile-1.8 + rational patch, and I'm now trying
to compile Lily against this. All is fine until the build-system reach the
lily/ subdir:

accidental-placement.cc: In function 'void
Accidental_placement_calc_positioning_done_init_functions()':
accidental-placement.cc:246: error: invalid conversion from
'scm_unused_struct* (*)()' to 'scm_unused_struct* (*)(...)'
accidental-placement.cc:246: error:   initializing argument 5 of
'scm_unused_struct* scm_c_define_gsubr(const char*, int, int, int,
scm_unused_struct* (*)(...))'
make[1]: *** [out/accidental-placement.o] Error 1
make: *** [all] Error 2


Any ideas?

In the meantime I'll try to build against guile-cvs and see if that helps...


Regards,
 Erlend
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Guile and Lily

[Erlend Aasland]

Ok, compiled successfully with this change:

diff --git a/lily/include/lily-guile.hh b/lily/include/lily-guile.hh
index 6eef555..d9387cb 100644
--- a/lily/include/lily-guile.hh
+++ b/lily/include/lily-guile.hh
@@ -20,7 +20,7 @@
  Hack for various MacOS incarnations.
 */
#ifndef GUILE_ELLIPSIS
-#define GUILE_ELLIPSIS
+#define GUILE_ELLIPSIS ...
#endif

#include guile-compatibility.hh


Erlend

On 1/18/07, Erlend Aasland [EMAIL PROTECTED] wrote:


Hmmm, can it be related to this:

lily/include/lily-guile.hh:

/*
  Hack for various MacOS incarnations.
 */
#ifndef GUILE_ELLIPSIS
#define GUILE_ELLIPSIS
#endif


Forgot to mention that I'm on MacOSX 10.4.8...


Erlend

On 1/18/07, Erlend Aasland [EMAIL PROTECTED] wrote:

 Hello,

 I've compiled and installed guile-1.8 + rational patch, and I'm now
 trying to compile Lily against this. All is fine until the build-system
 reach the lily/ subdir:

 accidental-placement.cc: In function 'void
 Accidental_placement_calc_positioning_done_init_functions()':
 accidental-placement.cc:246: error: invalid conversion from
 'scm_unused_struct* (*)()' to 'scm_unused_struct* (*)(...)'
 accidental-placement.cc:246: error:   initializing argument 5 of
 'scm_unused_struct* scm_c_define_gsubr(const char*, int, int, int,
 scm_unused_struct* (*)(...))'
 make[1]: *** [out/accidental-placement.o] Error 1
 make: *** [all] Error 2


 Any ideas?

 In the meantime I'll try to build against guile-cvs and see if that
 helps...


 Regards,
   Erlend



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Two simultaneous events

[Erlend Aasland]

Hi Han-Wen,With 2.9, translator.cc has begun to spit out a lot of warnings about simultaneous events (specially when you're creating a score and are using e.g. \new Staff  \partcombine \hnOne \hnTwo  and both parts contain the same rehearsal marks and dynamic markings). Most of these warnings are harmless and just annoying. Can I apply this patch?
--- lily/translator.cc 3 Nov 2006 01:05:21 - 1.112+++ lily/translator.cc 7 Nov 2006 11:05:50 -@@ -6,6 +6,8 @@ (c) 1997--2006 Han-Wen Nienhuys [EMAIL PROTECTED]
*/+#include main.hh+#include translator.hh#include context-def.hh@@ -329,8 +331,11 @@ ev_class.erase (0, strlen(prefix)); replace_all (ev_class, '_', '-');
- new_ev-origin ()-warning (_f (Two simultaneous %s events, junking this one, ev_class.c_str ()));- (*old_ev)-origin ()-warning (_f (Previous %s event here, ev_class.c_str ()));
+ if (be_verbose_global)+ {+ new_ev-origin ()-warning (_f (Two simultaneous %s events, junking this one, ev_class.c_str ()));+ (*old_ev)-origin ()-warning (_f (Previous %s event here, ev_class.c_str ()));
+ } return false; } elseErlend
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Two simultaneous events

[Erlend Aasland]

On 11/7/06, Han-Wen Nienhuys [EMAIL PROTECTED] wrote:
 Most of these warnings are harmless and just annoying.Can you analyse the problem completely, and then propose a solution? Iprefer a solution which keeps the message, but does away with thesuperfluous warnings.I suspect you'll have to take a look at
Stream_event::equal_pOk, thanks for the hint. I'll do that.Erlend
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Lost patch for bug report?

[Erlend Aasland]

Hi Graham,I've experimented a bit with this bug and created a patch, but as I've written in the comment, my patch will introduce a new bug. I've been very busy with some arrangements the last couple of days, so I haven't had time to look more into this.
ErlendOn 11/7/06, Graham Percival [EMAIL PROTECTED] wrote:
Somebody created a patch to solve #62, but there isn't any response.Has this patch been added, or was it just lost?http://code.google.com/p/lilypond/issues/detail?id=62
- Graham___lilypond-devel mailing listlilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Build issues...

[Erlend Aasland]

Hi Han-Wen,In order to build latest CVS I had to apply this change (see below). Commit?Regards, Erlend
Index: scm/define-grob-interfaces.scm===
RCS file: /sources/lilypond/lilypond/scm/define-grob-interfaces.scm,v
retrieving revision 1.42diff -u -r1.42 define-grob-interfaces.scm
--- scm/define-grob-interfaces.scm18 Oct 2006 10:14:18 -1.42
+++ scm/define-grob-interfaces.scm26 Oct 2006 13:52:51 -@@ -49,7 +49,8 @@
'fret-diagram-interfaceA fret diagram
'(align-dir barre-type dot-color dot-radius finger-code fret-count
-label-dir number-type size string-count thickness))+label-dir number-type size string-count
+string-fret-finger-combinations thickness)) 
 (ly:add-interface'grace-spacing-interface
Index: scm/define-grob-properties.scm===
RCS file: /sources/lilypond/lilypond/scm/define-grob-properties.scm,v
retrieving revision 1.186diff -u -r1.186 define-grob-properties.scm
--- scm/define-grob-properties.scm25 Oct 2006 13:14:28 -1.186
+++ scm/define-grob-properties.scm26 Oct 2006 13:52:51 -@@ -390,7 +390,6 @@
(size ,number? Size of object, relative to standard size.)
(slope ,number? The slope of this object.)(slur-padding ,number? Extra distance between slur and script.)
- (string-fret-finger-combinations ,list? List consisting of (string-number fret-number finger-number) entries. )
(space-alist ,list? A table that specifies distances between
 prefatory items, like clef and time-signature. The format is an alist
 of spacing tuples: @code{(@var{break-align-symbol} @var{type}@@ -426,6 +425,7 @@
(strict-grace-spacing ,boolean? If set, grace notes  are not spaced separately, but put before musical columns.)
(string-count ,integer? The number of strings in a fret diagram.)
+ (string-fret-finger-combinations ,list? List consisting of (string-number fret-number finger-number) entries.)
(stroke-style ,string? set to \grace\ to turn stroke through flag on.)
(style ,symbol? This setting determines in what style a grob is

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Fixing issue #44

[Erlend Aasland]

On 10/14/06, Han-Wen Nienhuys [EMAIL PROTECTED] wrote:
Can you close the issue and add a fixed2924 tag ? I've added you as aproject member.Ok, done that.Erlend
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Fixing issue #44

[Erlend Aasland]

Hello,I had a look at issue #44 yesterday and came up with this patch (attached). It fixes the bug, but I guess using the side-position interface in some clever way can get rid of the magic numbers. Comments?
diff -u -r1.71 note-collision.cc--- lily/note-collision.cc 17 Sep 2006 11:02:29 - 1.71+++ lily/note-collision.cc 12 Oct 2006 08:05:59 -@@ -16,6 +16,7 @@#include output-def.hh
#include pointer-group-interface.hh#include rhythmic-head.hh+#include staff-symbol-referencer.hh#include side-position-interface.hh#include stem.hh
#include warn.hh@@ -242,6 +243,24 @@ else shift_amount *= 0.17;+ /*+ * Handle issue #44:+ *+ * Dots from left note head collide with right note head. Only occurs
+ * with a close half collide, if the left note head is between+ * lines and the right note head is on a line, and if right note head+ * hasn't got any dots.+ */+ if (close_half_collide+  Rhythmic_head::dot_count (nu)
+  !Rhythmic_head::dot_count (nd))+ {+ Grob *staff = Staff_symbol_referencer::get_staff_symbol (me);+ if (!Staff_symbol_referencer::on_line (staff, ups[0]))+ /* FIXME: magic numbers */
+ shift_amount *= 1 + (0.6 * Rhythmic_head::dot_count (nu));+ }+ /* For full or close half collisions, the right hand head may obscure dots. Move dots to the right. */ if (abs (shift_amount)  1e-6
Regards, Erlend Aasland


issue44.patch
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Fixing issue #44

[Erlend Aasland]

Hi Han-WenOn 10/12/06, Han-Wen Nienhuys [EMAIL PROTECTED] wrote:
 It fixes the bug, but I guess using the side-position interface in some clever way can get rid of the magic numbers. Comments?Unfortunately, my music typography books are packed, so I can't access
them, but all dots (of all voices) should aligned (to that purpose, wehave Dot_column_engraver). I think the correct patch is making sure thatthe undotted note head also is in the support of theside-position-interface for dot-column.
I see. I'll have another look at it later today.Erlend
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Fixing issue #44

[Erlend Aasland]

Hi,On 10/12/06, Erlend Aasland [EMAIL PROTECTED] wrote:
I think the correct patch is making sure thatthe undotted note head also is in the support of the
side-position-interface for dot-column.Ok, done that, patch attached. However, I'm not convinced that this is the best solution to the problem. (The only book about music typography I've got, is The Art of Music Copying (Roemer), but it doesn't mention this problem.)
Erlend


issue44-2.patch
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Easy Note Heads and colors

[Erlend Aasland]

Hi DanielOn 9/7/06, Graham Percival [EMAIL PROTECTED] wrote:
Daniel Tonda wrote: I know the colors are doable, although some articulations don't work when using colors, like dynamics,What's the problem with colors and articulations? If I write
\relative c' { \override NoteHead #'color = #red c4\ c c c\!\f }...I get just what I expect; red noteheads and a black crescendo that ends in a black forte.If I write \relative c' { \override DynamicText #'color = #red c4\ c c c\!\f }

...I get normal black noteheads and a black crescendo that ends in a red forte.Regards, Erlend
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Easy Note Heads and colors

[Erlend Aasland]

Hi MatsOn 9/8/06, Mats Bengtsson [EMAIL PROTECTED] wrote:
That's expected, since it's the Hairpin layout object that's used toprint the crescdendo.I know that. That's why I wrote as expected in my previous email :-)
Erlend
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Fix for accidental-modern-cautionary.ly bug

[Erlend Aasland]

I'm pretty shure that this patch is correct, so unless you complain I'll apply it to 2.9 and 2.8.On 5/31/06, Erlend Aasland 
[EMAIL PROTECTED] wrote:Hi Han-WenI believe this patch will fix the 
accidental-modern-cautionary.ly bug (
http://lilypond.org/bugs/v2.8/lily-130122389.ly
). Shall I commit?Regards, Erlend


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: New lyrics trick available in 2.9.6

[Erlend Aasland]

Hi,On 5/29/06, Erik Sandberg [EMAIL PROTECTED] wrote:
The new alternative trick, which IMHO is cleaner, is to align lyrics to adevnull context:This is a neat trick, but it fails when the target voice contains ties:voice = { \tag #'music { c''2 }
 \tag #'lyrics { c''4. ~ c''8 } d''2}lyr = \lyricmode { foo -- bar }\new Staff \keepWithTag #'music \voice\new Devnull=foo \keepWithTag #'lyrics \voice\new Lyrics \lyricsto foo \lyr
\new Staff { c'8 c' c' c' c' c' c' c'}... or am I missing something?Regards, Erlend Aasland
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: New lyrics trick available in 2.9.6

[Erlend Aasland]

Never mind, I solved it by using \new Devnull { \new Voice=foo \keepWithTag #'lyrics \voice }ErlendOn 6/1/06, 
Erlend Aasland [EMAIL PROTECTED] wrote:
Hi,On 5/29/06, Erik Sandberg 
[EMAIL PROTECTED] wrote:
The new alternative trick, which IMHO is cleaner, is to align lyrics to adevnull context:This is a neat trick, but it fails when the target voice contains ties:
voice = { \tag #'music { c''2 }
 \tag #'lyrics { c''4. ~ c''8 } d''2}lyr = \lyricmode { foo -- bar }\new Staff \keepWithTag #'music \voice\new Devnull=foo \keepWithTag #'lyrics \voice
\new Lyrics \lyricsto foo \lyr
\new Staff { c'8 c' c' c' c' c' c' c'}... or am I missing something?Regards, Erlend Aasland


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Fix for accidental-modern-cautionary.ly bug

[Erlend Aasland]

Hi Han-WenI believe this patch will fix the accidental-modern-cautionary.ly bug (http://lilypond.org/bugs/v2.8/lily-130122389.ly
). Shall I commit?Regards, Erlend


accidental-modern-cautionary.patch
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Fix for accidental-modern-cautionary.ly bug

[Erlend Aasland]

... forgot to mention that I've tested the patch, and everything seems ok (all cases for the modern-cautionary look good)...On 5/31/06, Erlend Aasland 
[EMAIL PROTECTED] wrote:Hi Han-Wen
I believe this patch will fix the accidental-modern-cautionary.ly bug (
http://lilypond.org/bugs/v2.8/lily-130122389.ly
). Shall I commit?Regards, Erlend


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Fix c-dynamic-accidental.ly bug

[Erlend Aasland]

Hello again Han-WenThis patch will fix the c-dynamic-accidental.ly bug (http://lilypond.org/bugs/v2.8/lily-376517676.ly
). I've just added an acknowledge accidental method to the dynamic engraver. Compiled and tested with latest CVS.Shall I commit?Regards, Erlend


c-dynamic-accidental.patch
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Cautionary accidentals in Ambitus

[Erlend Aasland]

Hi,When I write timpani parts I specify the tuning this way:tuning = \markup { \score { \new Staff \with { \remove Time_signature_engraver } { \set Staff.instrument = Tuning: 
 \clef bass { b,4 d e a } } \layout { ragged-right = ##t } }}\header { poet = \markup { \tuning }}I know it doesn't answer your question, but I thought you might find it interesting anyway.
Regards, Erlend AaslandOn 5/20/06, Cameron Horsburgh [EMAIL PROTECTED] wrote:
Hi folks,I've recently written a timpani part for a score I'm writing, and I thought I'd add an ambitus to the beginning of the part to show the necessary tuning (I know, it's not standard!)
The two notes I want the timps tuned to are aes and des, and the key is des major. However, because the key signature (which comes _after_ the ambitus) includes aes and des there are no flats on the ambitus. How do I add cautionary accidentals?
I notice in the programme reference that Ambitus_engraver has a setting for cautionary accidentals, but it doesn't tell me how to turn them on or off.Here's a simple version of my code:\version 
2.9.4\score{\relative c {\clef bass\key des \majordes aes des aes |}\layout{\context {\Voice\consists Ambitus_engraver}
}}--=Cameron Horsburgh/dev/random says:Dinner not ready: (A)bort (R)etry (P)izzahttp://web.netcall.com.au/horsburgh
 _ __ _ _/ ___| _ __ ___ (_) | ___| | | |\___ \| '_ ` _ \| | |/ _ \ | | | ___) | | | | | | | |__/_|_|_||/|_| |_| |_|_|_|\___(_|_|_)=
___lilypond-devel mailing listlilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: lilypond ./ChangeLog lily/dynamic-engraver.cc l...

[Erlend Aasland]

Hi Han-WenOn 5/16/06, Han-Wen Nienhuys [EMAIL PROTECTED] wrote:
diff -u lilypond/lily/hairpin.cc:1.65 lilypond/lily/hairpin.cc:1.66--- lilypond/lily/hairpin.cc:1.65 Tue Apr 11 12:36:44 2006+++ lilypond/lily/hairpin.ccTue May 16 19:00:39 2006@@ -162,7 +162,7 @@
x_points[d] = e.center () - d * padding / 3;}else- x_points[d] = e[d];+ x_points[d] = e[d] - d * padding;}}
 }This change looks a bit weird to me. Should not this padding only be applied if the right part of the hairpin is attached to a barline (and not a note)? That is, something like this:
--- lily/hairpin.cc 16 May 2006 19:00:39 - 1.66+++ lily/hairpin.cc 18 May 2006 06:56:39 -@@ -162,7 +162,11 @@ Hairpin::print (SCM smob) x_points[d] = e.center
 () - d * padding / 3; } else- x_points[d] = e[d] - d * padding;+ if (d == RIGHT + !me-get_bound (RIGHT)-get_column ()-is_musical (me-get_bound (RIGHT)-get_column ()))
+ x_points[d] = e[d] - d * padding;+ else+ x_points[d] = e[d]; } } }Regards, Erlend Aasland 
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Segnos, Codas, and Really Crap Formatting

[Erlend Aasland]

HiOn 5/16/06, [EMAIL PROTECTED] [EMAIL PROTECTED]
 wrote:I can't get my codas right. I want (as per normal practice) to have a
missing system between the main body of the music and the coda. Noproblem putting a line-break in, but how do I put extra space in thereto make it stand out? Even worse! How do I mark it up correctly?...
Maybe this can help you in the right direction:\relative c' { \override Score.RehearsalMark #'self-alignment-X = #right c4 c c c \mark D.S. al Coda | \bar |.
 \stopStaff s1 \startStaff | \override Score.RehearsalMark #'self-alignment-X = #left \mark Coda c c c c |} 
...Lily calculates how many lines it needs to setthe music. Is there any way to get between this and the actualtypesetting, and say never mind how many you think you need, use thisnumber? If I can tell lily that it needs to use ten lines...
This is already supported. You want this:\paper { system-count = #10}Regards, Erlend Aasland
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: lilypond ./ChangeLog lily/grob.cc lily/stencil-...

[Erlend Aasland]

On 5/15/06, Han-Wen Nienhuys [EMAIL PROTECTED] wrote:
a NEWS entry? perhaps an update of the manual?How's this for the news? I'll write something for the manual asap.Regards, Erlend


news.patch
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: lilypond ./ChangeLog lily/grob.cc lily/stencil-...

[Erlend Aasland]

On 5/15/06, Werner LEMBERG [EMAIL PROTECTED] wrote:
Well, rotating a note head is probably one of the more obscureapplications.I suggest that you replace it with a hairpin.Done.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Transformation experiments

[Erlend Aasland]

Hi Han-WenOn 5/8/06, Han-Wen Nienhuys [EMAIL PROTECTED] wrote:
Erlend Aasland wrote: There are no bugs with the current code, so why rewrite it?Because it's not _obviously_ correct.Ok. New version attached. I've thrown in something for the SVG-backend too, but that part is a bit buggy (I'll have to take a closer look at the SVG spec next week). The C++ stuff and PS-backend should look good now.
Regards, Erlend--Han-Wen Nienhuys - 
[EMAIL PROTECTED] - http://www.xs4all.nl/~hanwenLilyPond Software Design-- Code for Music Notationhttp://www.lilypond-design.com



rotate6.patch
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Transformation experiments

[Erlend Aasland]

On 5/12/06, Han-Wen Nienhuys [EMAIL PROTECTED] wrote:
 Ok. New version attached. I've thrown in something for the SVG-backend too, but that part is a bit buggy (I'll have to take a closer look at the SVG spec next week). The C++ stuff and PS-backend should look good now.
OK. If please commit when SVG is working too.Will do.Erlend
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Transformation experiments

[Erlend Aasland]

On 5/5/06, Han-Wen Nienhuys [EMAIL PROTECTED] wrote:
 ... the problem is more about what variables to modify. It appears to me like dim_ contains the bounding box, but when I modify it, the rotated stencils are misplaced.strange. are you sure you're not seeing artefacts of the fact that
placements algorithms look at the bbox to determine offsets?I found the bug: the misplacements came from TextScript #'staff-padding :-)Anyway, I've fixed a couple of bugs in the implementation and attached a bugfree (I hope) version of the patch. Enjoy.
Regards, Erlend


rotate5.patch
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Transformation experiments

[Erlend Aasland]

On 5/8/06, Han-Wen Nienhuys [EMAIL PROTECTED] wrote:
ok, nits that need to be addressed before integrating:- stencil::rotate should take Offset() as argument.Done 
- I think widen() can also shrink the bbox, can you double check thatyour scaling routine doesn't shrink the bbox?(x_new - x_len)lookssuspect to me.I've tested 0, 45, 90...360 degrees and everything looks nice. Of course it is possible that one of the extents will shrink: For example just rotate a box with x_length=2 and y_length=1 with 90 degrees and x_length will shrink to 1 and y_length will expand to 2.
Why don't you rotate the 4 corners and use add_point()on an empty box?
There are no bugs with the current code, so why rewrite it? - thescheme binding misses the offset arg
Fixed - SVG support !I've added it but not tested it (currently compiling...)
Erlend
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Transformation experiments

[Erlend Aasland]

Hi Han-WenI've had very little time to do coding the past two days, so I've only managed to do a little bit more on this rotation thing.Rotation is now specified as #'(degrees x y) where x and y are relative to the extent of the grob (
i.e. (0,0) is center and (1,1) is upper right corner...). This seems works perfect.But, I'm having some problems with adjusting the bounding box. Should it not be sufficient to modify dim_ in the stencil?I've got lots of spare time this weekend so I'll try to find it out myself, but if you've got some hints... :-)
ErlendOn 5/4/06, Erlend Aasland [EMAIL PROTECTED] wrote:
On 5/4/06, Han-Wen Nienhuys [EMAIL PROTECTED]
 wrote:

I think it's better to explicitly ask for everything, ie. #'rotation = #'(45 0 -1)(where the last 2 numbers are 1,-1 style.)I agree. I'll modify the patch.
Erlend




rotate4.patch
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Transformation experiments

[Erlend Aasland]

Hi JohannesOn 5/5/06, Johannes Schindelin [EMAIL PROTECTED] wrote:
I don't know about dim_, but the easiest way to find the new bounding boxis to rotate all four edges of the original bounding box, and take theminima and maxima of the results as new bounds.Of course, you could try to be clever and tell from the angle which is
going to be the minimum/maximum, but I don't think it is worth your time.I agree. But the problem is more about what variables to modify. It appears to me like dim_ contains the bounding box, but when I modify it, the rotated stencils are misplaced.
Regards, Erlend
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Transformation experiments

[Erlend Aasland]

On 5/5/06, Johannes Schindelin [EMAIL PROTECTED] wrote:
On Fri, 5 May 2006, Erlend Aasland wrote: I agree. But the problem is more about what variables to modify. It appears to me like dim_ contains the bounding box, but when I modify it, the rotated stencils are misplaced.
Ah. I understand. You probably have to adjust the offsets, too?Yeah, I guess so. I'll grep through lily/*.cc and try to find some examples.Erlend
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Transformation experiments

[Erlend Aasland]

On 5/3/06, Erlend Aasland [EMAIL PROTECTED] wrote:
Currently the implementation rotates a stencil around it's center, but this isn't alway desired (I think). It would perhaps make more sense to rotate hairpins around the origin... I'm thinking of a good way to make this tunable...
Hmm... What would be the best way to get the center of the rotation? Should I create another grob property (i.e. 'rotation-center = #'(0 . 0))? Or should we hide it in C++ and not make it tunable?
Erlend
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Transformation experiments

[Erlend Aasland]

On 5/4/06, Han-Wen Nienhuys [EMAIL PROTECTED] wrote:
I think it's better to explicitly ask for everything, ie. #'rotation = #'(45 0 -1)(where the last 2 numbers are 1,-1 style.)I agree. I'll modify the patch.Erlend

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Transformation experiments

[Erlend Aasland]

Hello everyone,I've been experimenting a bit with a rotate command (just for fun and for getting to know the internals of Lilypond better). The result of the experiment is in the attached patch. Seems to work well enough, but the implementation could probably be better :-)
Comments?Regards, Erlend Aasland


rotate.patch
Description: Binary data


rotate.ly
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Transformation experiments

[Erlend Aasland]

...and another version, now with a generic grob property ('rotation) that let you rotate any grob (for example crescendo hairpins).On 5/3/06, Erlend Aasland
 [EMAIL PROTECTED] wrote:
...just a small improvement: the target stencil is now rotated around its center, not its origin.
On 5/3/06, Erlend Aasland 

[EMAIL PROTECTED] wrote:Hello everyone,
I've been experimenting a bit with a rotate command (just for fun and for getting to know the internals of Lilypond better). The result of the experiment is in the attached patch. Seems to work well enough, but the implementation could probably be better :-)
Comments?Regards, Erlend Aasland




rotate3.patch
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Transformation experiments

[Erlend Aasland]

Hi Han-WenOn 5/3/06, Han-Wen Nienhuys [EMAIL PROTECTED] wrote:
Interesting idea! We'll need a SVG implementation before I could acceptit; and the bboxes should be correct too.Shure.Currently the implementation rotates a stencil around it's center, but this isn't alway desired (I think). It would perhaps make more sense to rotate hairpins around the origin... I'm thinking of a good way to make this tunable... something like this perhaps:
stencil-rotate(angle, offset)where offset is either origin or center (or some other point)... Ideas?Regards, Erlend
Erlend Aasland schreef: ...and another version, now with a generic grob property ('rotation) that let you rotate any grob (for example crescendo hairpins). On 5/3/06, *Erlend Aasland * 
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: ...just a small improvement: the target stencil is now rotated
 around its center, not its origin. On 5/3/06, *Erlend Aasland*  [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
 wrote: Hello everyone, I've been experimenting a bit with a rotate command (just for fun and for getting to know the internals of Lilypond better).
 The result of the experiment is in the attached patch. Seems to work well enough, but the implementation could probably be better :-) Comments?
 Regards, Erlend Aasland--Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
LilyPond Software Design-- Code for Music Notationhttp://www.lilypond-design.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Transformation experiments

[Erlend Aasland]

On 5/4/06, David Feuer [EMAIL PROTECTED] wrote:
On 5/3/06, Han-Wen Nienhuys [EMAIL PROTECTED] wrote: Mats Bengtsson schreef:  Following the ideas of other alignments in LilyPond, you could let the
  offset be represented by a tuple (X offset and Y offset), where 0 means  center, -1 is left/lower edge, +1 is right/top edge.  Note that the values should/could be any real number, not necessarily
  limited to the range [-1,1]. good idea!What is the purpose of this transformation mechanism?Well, rotated hairpins and text on glissandos are the first things that come to mind. Other?
Regards, ErlendDavid___
lilypond-devel mailing listlilypond-devel@gnu.orghttp://lists.gnu.org/mailman/listinfo/lilypond-devel

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Fwd: reporting bugs in 2.9 (dotted line infects staff lines)

[Erlend Aasland]

[sorry...forgot to CC list]-- Forwarded message --From: Erlend Aasland [EMAIL PROTECTED]
Date: Apr 26, 2006 1:59 PMSubject: Re: reporting bugs in 2.9 (dotted line infects staff lines)To: Graham Percival [EMAIL PROTECTED]
On 4/26/06, Graham Percival [EMAIL PROTECTED] wrote:


I'm starting to look at doing Bug Meister stuff.How do we deal withbugs in 2.9?I think this bug has a simple fix; I don't think it'sworth entering it into cvs.Can I just send the report here?In this specific case, any dotted line (like a cresc. or
8va) causes all staff lines in the next stave to become dotted.This occurs in 2.9.2 but not in 2.8.I think this bug is already fixed in CVS.
Erlend


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: More tablature doc stuff

[Erlend Aasland]

Hi GrahamOn 4/21/06, Graham Percival [EMAIL PROTECTED] wrote:
... I wonder how much other info is in these?But what aboutthis line? -%%\override Stem #'up-to-staff = ##tSeems like up-to-staff was replaced by stem-end-position in september 2003. I've tried to set stem-end-position to different values, but there is nothing interesting happening (at least for tab use.)
The \stemDown introduced in the docs don't mimic this behavior; is thisimportant for tab users?
Well, many tabs use this feature.Regards, Erlend
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Impossible make web with missing glyph and an endless loop

[Erlend Aasland]

Hmm, I also get these error messages when running make web. However, if I remove the out/shared/lilypond/current/fonts directory and instead make a symlink to the fonts from the GUB application (/Applications/LilyPond.app/.../current/fonts) all is fine.
I've tried to revert mf/GNUmakefile all the way back to rev. 1.196, but it doesn't seem like the problem is there...On 4/19/06, Jan Nieuwenhuizen
 [EMAIL PROTECTED] wrote:Heikki Johannes Junes writes:
 In my debian-testing system (which should have all the required versions of programs, e.g. fontforge 20060413 compiled separately), invokingAre you sure that the seperately compiled fontforge is being used,
do you need a PATH override for debbuild, eg?Jan.--Jan Nieuwenhuizen [EMAIL PROTECTED] | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien | http://www.lilypond.org___lilypond-devel mailing list
lilypond-devel@gnu.orghttp://lists.gnu.org/mailman/listinfo/lilypond-devel
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

More tablature doc stuff

[Erlend Aasland]

Hi Graham,Please see the attached patch. It moves some commented stuff from ly/engravers-init.ly to the docs.Regards, Erlend


tabdoc.patch
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Move rotated_box ()

[Erlend Aasland]

On 4/18/06, Jan Nieuwenhuizen [EMAIL PROTECTED] wrote:
Erlend Aasland writes: Can I apply this patch?Yes please, but remember to add a change log entry.Yes, of course.Erlend
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Bug in the new PS code

[Erlend Aasland]

On 4/17/06, David Feuer [EMAIL PROTECTED] wrote:
On 4/16/06, Erlend Aasland [EMAIL PROTECTED] wrote:This should only be necessary for the draw_dashed_line procedure.Thedraw_dashed_slur one brackets its operations with gsave/grestore.
Yes, of course, I didn't notice :-) 
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Move rotated_box ()

[Erlend Aasland]

Hi Jan,Can I apply this patch?Regards, Erlend Aasland


rotated_box.patch
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Doc update for section 7.5

[Erlend Aasland]

Hi GrahamSince I happen to play guitar, I've cooked up some updates for the tablature section in the docs (section 7.5.2 and 7.5.3). Please see the attached patch. (Warning: I'm no expert in writing english documentation...)
Regards, Erlend


tab-doc.patch
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Bug in the new PS code

[Erlend Aasland]

Hi David,The two dash functions (draw_dashed_{line,slur}) set the dash pattern with setdash, but they forget to reset it (so the output looks a bit weird after the first dashed line has been drawn). The attached patch will fix this, but I'd like you to approve it before I apply it. It just throws in a [] 0 setdash after the stroke command.
Regards, Erlend Aasland


ps-dash.patch
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: al niente / de niente: circle size, hairpin alignment, al-niente-hairpin alignment

[Erlend Aasland]

On 4/11/06, Marcus Macauley [EMAIL PROTECTED] wrote:
 Thanks for the proofs. FWIW I think the very last one -- at 50% of a single staffspace -- is perfect. The distinction between 52.5% and 50% is particularly fine, but I vote for 50%.
I actually would vote for 55%.I agree with Marcus that the 50% can look a bit small when printed on paper, so I'll set it to 52.5% for now. When 2.9.2 comes out, more people get to test it (and there will be plenty of time to tune the circle size during the 
2.9 development period.)Regards, Erlend
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: al niente / de niente - was Re: (no subject)

[Erlend Aasland]

On 4/10/06, Trevor Bača [EMAIL PROTECTED] wrote:
Thanks for the proofs. FWIW I think the very last one -- at 50% of asingle staffspace -- is perfect. The distinction between 52.5% and 50%is particularly fine, but I vote for 50%.What do you think?
I also like the 50% circles. I don't think it should be smaller than that.
And Marcus?I Marcus agrees, I'll change it to 50%. Regards, Erlend
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: al niente / de niente - was Re: (no subject)

[Erlend Aasland]

On 4/9/06, Erlend Aasland [EMAIL PROTECTED] wrote:
These are 55% and 57.5% the size of one staff space (that would be about 12% and 15% of the original size). Smaller? I'll send examples that are 52.5% and 50% of one staff space in another mail (so it won't bounce on the mailing list).
...here is one... Erlend


hairpin-circled-525.pdf
Description: Adobe PDF document
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: al niente / de niente - was Re: (no subject)

[Erlend Aasland]

On 4/4/06, Marcus Macauley [EMAIL PROTECTED] wrote:
(If I felt like being nitpicky, I would point out two things. One, IMHO,the circle is still slightly too large. Not much, and arguably not at all,Well, the only real examples I've seen is the scans that Trevor sent me... It is no problem to make them a little bit smaller. What do you think Trevor?
...measure 19 of hairpin-circled.pdf uses the circle hairpin in an illogical manner
Oh, I was just testing the circle thing to see what alignment adjustments I needed to do...Regards, Erlend Aasland
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Postscript bug

[Erlend Aasland]

Hi David,Your recent changes to the PS code makes all circles look rather weird (they contain a straigt line from the center to the right of the circle, and the circle itself is misplaced). I fixed this with the attached patch, but since I'm not PS expert, perhaps you could verify that this look good? (I suspect that the newpath thing is a bit hacky...) Anyway, circles are printed right with this patch applied.
Regards, Erlend Aasland


ps-circle-bug.patch
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: make cvsclean?

[Erlend Aasland]

HiOn 4/4/06, Han-Wen Nienhuys [EMAIL PROTECTED] wrote:
I guess not, although I don't personally see the use (my sourcedirectory is a complete mess anyway because I dump all my debugging .lyfiles there)Well, I guess that there are other developers that might need this. I see no problem with the naming (since we've already got distclean and maintainerclean, cvsclean seems like a good name), but I'm not going to argue about that. New patch attached. Please apply.
ChangeLog:2006-04-04 Erlend Aasland [EMAIL PROTECTED] * stepmake/stepmake/generic-targets.make: add cvs-clean target * stepmake/stepmake/toplevel-
targets.make: print help info about cvs-clean--Han-Wen Nienhuys - 
[EMAIL PROTECTED] - http://www.xs4all.nl/~hanwenLilyPond Software Design-- Code for Music Notationhttp://www.lilypond-design.com



cvsclean.patch
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: al niente / de niente - was Re: (no subject)

[Erlend Aasland]

Hi Han-WenOn 4/3/06, Han-Wen Nienhuys [EMAIL PROTECTED] wrote:
can't you just use SCM_BOOL_F for the last argument of the circle call?OMG, why didn't I notice that in the first place...! Patch against latest CVS attached. Please apply.ChangeLog:2006-04-03 Erlend Aasland 
[EMAIL PROTECTED] * lily/hairpin.cc (print): add support for circled tip * scm/define-grob-properties.scm: add circled-tip parameter * scm/define-
grobs.scm: init circled-tip to falseThen you'll just get the outline. With that change, please send a
ChangeLog for the circle patch so I can integrate.--Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
LilyPond Software Design-- Code for Music Notationhttp://www.lilypond-design.com


hairpin-circle.patch
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: al niente / de niente - was Re: (no subject)

[Erlend Aasland]

Hi MarcusOn 3/16/06, Marcus Macauley [EMAIL PROTECTED] wrote:
On Thu, 16 Mar 2006 09:29:43 -0800, Trevor Bača [EMAIL PROTECTED] wrote:
 I'm interested in this kind of 'al niente' / 'de niente' thing, too, but haven't had a chance to figure out the right settings yet.This sounds interesting, do you have an image of a real world example? (I was unable to find one by googling). I wasn't aware of al niente until now, but I could certainly make use of it in some of my arrangements.
At least one music font/notation program, I forget which, includes for this
purpose a letter n in the same style as mrsfp for dynamics. So perhaps theideal way to implement this latter kind of niente notation (the hairpin circletip being the other kind) would be to create a new dynamic mark, called n, and
syntax analogous to the other dynamics, thus:c2~\ c~ c r\nI made a quick hack for this just for fun (I'm sure Han-Wen would implement it more properly, especially the font); see the attached patch and test case.
(I suspect that the circles are a bit misplaced, but as I said this is just a quick hack).Regards, Erlend Aasland


niente.patch
Description: Binary data


niente-test.pdf
Description: Adobe PDF document


niente-test.ly
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Minor corrections

[Erlend Aasland]

Hi,The 2.8 news page (http://lilypond.org/doc/v2.8/Documentation/topdocs/NEWS.html) says New features in 2.7..., but it should obviously say New features in 
2.8.Regards, Erlend Aasland
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: al niente / de niente - was Re: (no subject)

[Erlend Aasland]

HiOn 3/31/06, Trevor Bača [EMAIL PROTECTED] wrote:
Yeah, you've definitely got the idea; the best examples are in scoresof Sciarrino's recent music and I'll have time to dig through somethis weekend and make a few small scans.Great! 
IIRC I think the circles are a touch smaller, maybe about 80% of whatyou've rendered here; again, I get the scans to help out. Could the
size of the circle be a configurable parameter?Yes, I think so. Perhaps we should have a thickness parameter too? Regards, Erlend Aasland
--Trevor Bača[EMAIL PROTECTED]
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Trivial documentation stuff

[Erlend Aasland]

Hi,In section 8.5.3 Hidden notes of the manual, the old hack of creating LV ties is still present. Since LV ties are now supported, this should be removed (patch attached).Hmmm, perhaps it is better to replace this hidden-notes-hack with a different example? For example something like this:
\new Staff {  { c''4^fall\glissando \hideNotes c'4 \unHideNotes } { s4 r4 }  }Regards, Erlend Aasland


dochiddennotes.patch
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: documentation error

[Erlend Aasland]

HiOn 3/24/06, dave k [EMAIL PROTECTED] wrote:
On http://lilypond.org/doc/v2.8/Documentation/user/lilypond/Jazz-combo.htmlAlso, I was wonder why we have to do that nasty hack with
...to get the slashes. It's a pretty common aspect of jazz notation -why can this not be its own symbol?A cool feature would be to have an adlib keyword for the repeat command. For example you could write a bass part like this:
\new ChordNames \chordmode { c1 g:7 c: a2:m7 d:m7 g:7 }\new Staff { \clef bass \relative c { c4^ e f fis \repeat adlib 3 { g^Walking bass ad. lib f e d } }}This would write notes in the two first bars, and then write slashes without stems in the last two bars (kind of like \repeat percent).
Regards, Erlend Aasland___
bug-lilypond mailing listbug-lilypond@gnu.orghttp://lists.gnu.org/mailman/listinfo/bug-lilypond

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Scripts fail in Lilypond GUB 2.7.39

[Erlend Aasland]

Scripts like convert-ly and friends complain about not finding the subprocess module (MacOSX 10.4.5). Problem is fixed by downloading subprocess.py from the net and placing it in the share/lilypond/current/python directory.
Regards, Erlend Aasland
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Error building from latest CVS

[Erlend Aasland]

Hi,The build stops with this error:/usr/bin/perl /Users/erlend/src/lilypond-eaa/buildscripts/out/help2man out/convert-ly  out/convert-ly.1help2man: can't get `--help' info from out/convert-lymake[1]: *** [out/convert-
ly.1] Error 1make: *** [all] Error 2Trying to run convert-ly manually:bash$ ./scripts/out/convert-ly --helpTraceback (most recent call last): File ./scripts/out/convert-ly, line 39, in ?
 import lilylib as lyImportError: No module named lilylibSystem information: MacOSX 10.4.5, python 2.3.5, perl 5.8.7, gcc 4.0.1Regards, Erlend Aasland
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: current CVS fails on Debian sid

[Erlend Aasland]

This is already fixed in CVS. Just do a CVS update.On 2/17/06, Paul Scott [EMAIL PROTECTED] wrote:
This is the end of a broken make on Debian sid.Let me know if you needmore information.
rm -f ./out/relocate.dep; DEPENDENCIES_OUTPUT=./out/relocate.dep./out/relocate.o g++ -c -Woverloaded-virtual -DHAVE_CONFIG_H-DNDEBUG-I./include -I./out -I../flower/include -I../flower/./out
-I../flower/include-O2 -finline-functions -g -pipe-I/usr/include/freetype2 -I/usr/include/pango-1.0-I/usr/include/freetype2 -I/usr/include/glib-2.0-I/usr/lib/glib-2.0/include -Wno-pmf-conversions -W -Wall -Wconversion
-o out/relocate.o relocate.ccrelocate.cc: In function 'void setup_paths(const char*)':relocate.cc:292: error: invalid conversion from 'const char**' to 'char**'make[1]: *** [out/relocate.o] Error 1make[1]: Leaving directory `/home/paul/lilypond/lily'
make: *** [all] Error 2Paul Scott___lilypond-devel mailing listlilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: circling marks

[Erlend Aasland]

... and by the way, this is documented on page 190 and 191 in the fine manual.On 2/16/06, Erlend Aasland [EMAIL PROTECTED]
 wrote:HiOn 2/16/06, 
Paul Scott [EMAIL PROTECTED] wrote:

Can I use this to build something that works on \mark 37 just as isdoes on \mark \default ?You want this: \mark #37It's already there.

What about another \default that causes the current bar number to beused as the \mark?\set Score.markFormatter = #format-mark-barnumbersFor boxed or circled numbers:
\set Score.markFormatter
 = #format-mark-box-barnumbers

\set Score.markFormatter = #format-mark-circle-barnumbers

Thanks,PaulNo problemRegards,
 Erlend Aasland 
___lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: circling marks

[Erlend Aasland]

HiOn 2/16/06, Paul Scott [EMAIL PROTECTED] wrote:
Can I use this to build something that works on \mark 37 just as isdoes on \mark \default ?You want this: \mark #37It's already there.
What about another \default that causes the current bar number to beused as the \mark?\set Score.markFormatter = #format-mark-barnumbersFor boxed or circled numbers:\set Score.markFormatter
 = #format-mark-box-barnumbers

\set Score.markFormatter = #format-mark-circle-barnumbers

Thanks,PaulNo problemRegards, Erlend Aasland 
___lilypond-devel mailing list
lilypond-devel@gnu.orghttp://lists.gnu.org/mailman/listinfo/lilypond-devel
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: circling marks

[Erlend Aasland]

On 2/16/06, Paul Scott [EMAIL PROTECTED] wrote:
Erlend Aasland wrote:I have not seen page numbers in the manual.Can you tell me where tosee them?Yes, the right upper corner of each page (I assume you've downloaded the manual as pdf).
In section 8.2.3 Rehearsal Marks I don't see enough explanation to learnwhat you have just shown me.
\mark #number creates a rehearsal mark (formatted using the markFormatter function). Example: \mark #5...will create a rehearsal mark with the number 5 if the markFormatter is set to mark-format-numbers, mark-format-box-numbers or mark-format-circle-numbers. If markFormatter is set to 
i.e. mark-format-alphabet, is will produce a rehearsal mark with the letter E. If set to mark-format-barnumbers the current bar number is printed, (thus ignoring the #number argument.)(I thought the mark-format-barnumbers function was documented, but I was wrong.) You can use mark-format-barnumbers, mark-format-box-barnumbers and mark-format-circle-barnumbers to get bar numbers as rehearsal marks.
ErlendPaul___
lilypond-devel mailing listlilypond-devel@gnu.orghttp://lists.gnu.org/mailman/listinfo/lilypond-devel

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: circling marks

[Erlend Aasland]

On 2/16/06, Erlend Aasland [EMAIL PROTECTED] wrote:
Example: \mark #5...will create a rehearsal mark with the number 5 if the markFormatter is set to mark-format-numbers, mark-format-box-numbers or mark-format-circle-numbers. If markFormatter is set to 
i.e. mark-format-alphabet, is will produce a rehearsal mark with the letter E. If set to mark-format-barnumbers the current bar number is printed, (thus ignoring the #number argument.)
Hmmm, those should be format-mark-*, not mark-format-*Erlend
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

trivial patch for relocate.cc

[Erlend Aasland]

HiWhen building latest CVS, compilation stops in lily/relocate.cc. The attached one-liner patch should fix the problem.Regards, Erlend Aasland


relocate.patch
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Latest CVS and paths...

[Erlend Aasland]

... and by the way: This problem is still present in latest CVS (MacOSX 10.4.4):On 2/10/06, Erlend Aasland [EMAIL PROTECTED]
 wrote:Hi,I suspect that a recent change in GNUmakefile.in (revision 
1.186, see attached patch, extracted from CVS) has something to do with this:bash $ ls out/share/lilypond currentbash $ ls out/share/lilypond/current
2.7.33 elisp lilypond-force mf python scriptsdvips fonts ly ps scm texThe 2.7.33-directory is supposed to be located under out/share/lilypond, and the current directory is supposed to be a link, not a directory. Right? Reverting to 
GNUmakefile.in revision 1.185 seems to fix this, but I guess that there were a reason for the patch in the first place...Regards, Erlend Aasland


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Latest CVS and paths...

[Erlend Aasland]

Hi,I suspect that a recent change in GNUmakefile.in (revision 1.186, see attached patch, extracted from CVS) has something to do with this:bash $ ls out/share/lilypond currentbash $ ls out/share/lilypond/current
2.7.33 elisp lilypond-force mf python scriptsdvips fonts ly ps scm texThe 2.7.33-directory is supposed to be located under out/share/lilypond, and the current directory is supposed to be a link, not a directory. Right? Reverting to 
GNUmakefile.in revision 1.185 seems to fix this, but I guess that there were a reason for the patch in the first place...Regards, Erlend Aasland


GNUmakefile.in.patch
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Trivial patch for darwin.patch

[Erlend Aasland]

A whitespace change broke the darwin.patch. Since I guess this patch still is needed by MacOSX people, the attached patch should be applied.Regards, Erlend Aasland


darwinpatch.patch
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel