Re: Unable to remove dynamic line inside Dynamics

[Marek Klein]

2011/2/18 Jay Anderson 

> On Mon, Sep 13, 2010 at 8:03 AM, Jay Anderson 
> wrote:
>
> This is a somewhat old request. Are there any known issues with adding
> the Tweak_engraver to the Dynamics context? Thanks.
>
>
I have added tracker issue for this:


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

Re: exact inversion (issue4173065)

[tdanielsmusic]

The patch works fine, but the documentation could be improved.
Expanding the example in a different section to show \inversion is not
optimal.  We need an @lilypond{} immediately after the @example showing
the syntax in the Inversion section.

Also, with this addition, it would be sensible to take \retrograde out
of the Modal transformations section and place it in a section of its
own, like Inversion.

All this could be done in a separate patch I guess, so LGTM.


http://codereview.appspot.com/4173065/

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

Re: exact inversion (issue4173065)

[Benkő Pál]

> The patch works fine, but the documentation could be improved.

agreed.

> Expanding the example in a different section to show \inversion is not
> optimal.

sorry, I don't get that.

> We need an @lilypond{} immediately after the @example showing
> the syntax in the Inversion section.
>
> Also, with this addition, it would be sensible to take \retrograde out
> of the Modal transformations section and place it in a section of its
> own, like Inversion.

agreed.

> All this could be done in a separate patch I guess, so LGTM.

should I move retrograde into its own section now or is there a
volunteer who can improve the documentation on transpose and
inversion as well after pushing as is?

p

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

Re: contributors / mentors

[Benkő Pál]

> A year ago, I added a section to the CG about having mentors for contributors:
>  http://lilypond.org/doc/v2.13/Documentation/contributor/mentors
>
> Sadly, it didn't take off -- I took on two doc contributors (just like
> the Grand Documentation Project, albeit on a small scale), but there
> were no volunteers on the "programming" side of things (other than
> Carl, who did all new Frogs).
>
> Could we give this another go?  I'm particularly looking at the newest
> "generation" of developers -- James, Mike, Keith, Pal, Janek, etc.
> Other than James, you guys didn't have a dedicated mentor... but
> wouldn't it have been nice?  Somebody who could guide you through our
> sometimes labyrinthine development process, somebody to commiserate
> with about the lack of reviews and who would go raise a fuss on your
> behalf, somebody to glance over a patch privately and hopefully catch
> any embarrassing mistakes before you sent it to lilypond-devel?
>
> If you think that a mentor would have helped *you*, then please
> consider volunteering to be a mentor to others.  I sure could have
> used a mentor when I began doc work 8 years ago, and certainly could
> have used one when I began doing build system stuff two years ago!
> I'm not asking for a lifelong bond here; most new contributors will
> only need a mentor for the first two or three months.

as a start I'd take Graham Breed's microtonal thingy:
http://lists.gnu.org/archive/html/lilypond-devel/2011-02/msg00567.html

p

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

Re: contributors / mentors

[Graham Percival]

On Tue, Feb 22, 2011 at 12:00:17PM +0100, Benkő Pál wrote:
> as a start I'd take Graham Breed's microtonal thingy:
> http://lists.gnu.org/archive/html/lilypond-devel/2011-02/msg00567.html

I don't recommend that; Felipe has been working on microtonal
notation support.  See:
http://code.google.com/p/lilypond/issues/detail?id=1278
and the discussion and patch links from that issue.

Cheers,
- Graham

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

Re: exact inversion (issue4173065)

[Trevor Daniels]

Benkő Pál wrote Tuesday, February 22, 2011 10:56 AM


should I move retrograde into its own section now or is there a
volunteer who can improve the documentation on transpose and
inversion as well after pushing as is?


I'm happy to fix up the documentation, so I will
apply this as-is if I hear nothing contrary in the
near future.

Trevor


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

Re: DOC: NR 1.5.2 Multiple voices - part combining (issue4188056)

[pkx166h]

one correction.


http://codereview.appspot.com/4188056/diff/2004/Documentation/notation/simultaneous.itely
File Documentation/notation/simultaneous.itely (right):

http://codereview.appspot.com/4188056/diff/2004/Documentation/notation/simultaneous.itely#newcode820
Documentation/notation/simultaneous.itely:820: unison (@notation{a due})
parts are marked by default with the text
I think this is meant to be 'a deux' also there is an aigue accent on
the 'a'.

http://codereview.appspot.com/4188056/

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

Re: contributors / mentors

[Benkő Pál]

>> as a start I'd take Graham Breed's microtonal thingy:
>> http://lists.gnu.org/archive/html/lilypond-devel/2011-02/msg00567.html
>
> I don't recommend that; Felipe has been working on microtonal
> notation support.  See:
> http://code.google.com/p/lilypond/issues/detail?id=1278
> and the discussion and patch links from that issue.

I know; I want to check whether it addresses Graham's
problem (I fear not, but I'll see; I have to catch up with
both issues).

both of these scratch nicely my itch to get a decent
meantone or Pythagorean MIDI, so I'd like to help;
at least to make sure Graham's problem doesn't get lost.

p

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

Re: exact inversion (issue4173065)

[Benkő Pál]

>> should I move retrograde into its own section now or is there a
>> volunteer who can improve the documentation on transpose and
>> inversion as well after pushing as is?
>
> I'm happy to fix up the documentation, so I will
> apply this as-is if I hear nothing contrary in the
> near future.

thanks!

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

RE: Hidden accidentals hiding visible ones

[James Lowe]

Hello,

)-Original Message-
)From: lilypond-user-bounces+james.lowe=datacore@gnu.org
)[mailto:lilypond-user-bounces+james.lowe=datacore@gnu.org] On
)Behalf Of David Kastrup
)Sent: 22 February 2011 08:54
)To: lilypond-u...@gnu.org
)Cc: lilypond-devel@gnu.org
)Subject: Re: Hidden accidentals hiding visible ones
)
)Nick Payne  writes:
)
)> This is probably user error rather than anything else, but I just
)> wasted 20 minutes wondering why an accidental on a note in a score
)was
)> missing in the PDF output before realising that the same note appeared
)> earlier in the same bar but in a hidden voice.
)>
)> In most guitar scores I use a hidden voice for such things as
)> simultaneous text spanners, arpeggio brackets to indicate barring,
)> etc.
)>
)> The following example shows that the order of the voices in the source
)> file affects whether the accidental appears or not:
)
)Is it an option to write the hidden voice without accidental?  Maybe one
)should mention this caveat in the manual?  

if someone lets me know where we think this could go I could write an 
@knownissue or @warning.

James


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

Re: contributors / mentors

[Graham Breed]

On 22 February 2011 15:27, Benkő Pál  wrote:
>>> as a start I'd take Graham Breed's microtonal thingy:
>>> http://lists.gnu.org/archive/html/lilypond-devel/2011-02/msg00567.html
>>
>> I don't recommend that; Felipe has been working on microtonal
>> notation support.  See:
>> http://code.google.com/p/lilypond/issues/detail?id=1278
>> and the discussion and patch links from that issue.
>
> I know; I want to check whether it addresses Graham's
> problem (I fear not, but I'll see; I have to catch up with
> both issues).

That patch addresses it in that it gives a new mechanism that could be
used to define meantone temperaments.  But it's currently being
re-written to bring back rational alterations, so who knows where
it'll end up?

> both of these scratch nicely my itch to get a decent
> meantone or Pythagorean MIDI, so I'd like to help;
> at least to make sure Graham's problem doesn't get lost.

Meantone and Pythagorean MIDI work.  You have my files for that.  The
only problem is that a conventional key signature breaks the MIDI
production, and causes the whole process to fail.  There are work
arounds, and there's now a one line patch.  This would mean a
completely mainstream input file in mainstream notation can be
retuned, and maybe sound better.

(There are still problems with pitch bends.  Neither patch addresses
that.  Switching to MIDI Tuning Standard real time messages looks
easy.  But allowing users to choose the retuning method would require
a minimal amount of work, that would then sit alongside all the other
open issues for years waiting to be attended to.)

I'm generally happy to stay out of the development loop and work
around limitations.  I don't think most people are aware how good the
current microtonal support is.  I have a simple patch for something
that looks like a bug.  It would be nice to get a version number for
it being suppressed that I can submit a snippet against.


Graham

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

Re: DOC: NR 1.5.2 Multiple voices - part combining (issue4188056)

[reinhold . kainhofer]

http://codereview.appspot.com/4188056/diff/2004/Documentation/notation/simultaneous.itely
File Documentation/notation/simultaneous.itely (right):

http://codereview.appspot.com/4188056/diff/2004/Documentation/notation/simultaneous.itely#newcode820
Documentation/notation/simultaneous.itely:820: unison (@notation{a due})
parts are marked by default with the text
On 2011/02/22 11:23:44, pkx166h wrote:

I think this is meant to be 'a deux' also there is an aigue accent on

the 'a'.

Nope, "a due" is the conventional Italian phrase for "by both", just
like "unisono" is the term for "unison".

http://codereview.appspot.com/4188056/

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

Re: contributors / mentors

[David Kastrup]

Graham Breed  writes:

> On 22 February 2011 15:27, Benkő Pál  wrote:
 as a start I'd take Graham Breed's microtonal thingy:
 http://lists.gnu.org/archive/html/lilypond-devel/2011-02/msg00567.html
>>>
>>> I don't recommend that; Felipe has been working on microtonal
>>> notation support.  See:
>>> http://code.google.com/p/lilypond/issues/detail?id=1278
>>> and the discussion and patch links from that issue.
>>
>> I know; I want to check whether it addresses Graham's
>> problem (I fear not, but I'll see; I have to catch up with
>> both issues).
>
> That patch addresses it in that it gives a new mechanism that could be
> used to define meantone temperaments.  But it's currently being
> re-written to bring back rational alterations, so who knows where
> it'll end up?

I don't think we should confuse tuning in the score and tuning in the
MIDI.

-- 
David Kastrup


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

Re: contributors / mentors

[Benkő Pál]

> as a start I'd take Graham Breed's microtonal thingy:
> http://lists.gnu.org/archive/html/lilypond-devel/2011-02/msg00567.html

 I don't recommend that; Felipe has been working on microtonal
 notation support.  See:
 http://code.google.com/p/lilypond/issues/detail?id=1278
 and the discussion and patch links from that issue.
>>>
>>> I know; I want to check whether it addresses Graham's
>>> problem (I fear not, but I'll see; I have to catch up with
>>> both issues).
>>
>> That patch addresses it in that it gives a new mechanism that could be
>> used to define meantone temperaments.  But it's currently being
>> re-written to bring back rational alterations, so who knows where
>> it'll end up?
>
> I don't think we should confuse tuning in the score and tuning in the
> MIDI.

what's more, we should clean up their connection.

p

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

Re: DOC: NR 1.5.2 Multiple voices - part combining (issue4188056)

[reinhold . kainhofer]

http://codereview.appspot.com/4188056/diff/1003/Documentation/notation/simultaneous.itely
File Documentation/notation/simultaneous.itely (right):

http://codereview.appspot.com/4188056/diff/1003/Documentation/notation/simultaneous.itely#newcode852
Documentation/notation/simultaneous.itely:852: chord or unisono.
On 2011/02/21 20:29:42, Colin Campbell wrote:

I believe "unisono" is a Dutch usage, so I've changed it to "unison",

although

it is hardwired into the names of functions like \partCombineUnisono.


Unisono is the usual Italian term, as opposed to "divisi".

http://codereview.appspot.com/4188056/diff/1003/Documentation/notation/simultaneous.itely#newcode872
Documentation/notation/simultaneous.itely:872: Use the combination
strategy automatically determined.
On 2011/02/21 17:56:05, pkx166h wrote:

Can we be more descriptive on what the 'automatic' strategy is? Or we

could

simply say



"Let the software decide which is the best option". I want to not use

the word

'strategy'.


Actually, it's not easy to describe the default (combine, if it is
possible, but not for voice crossings or for different spanners or
dynamics, or if the notes are further apart than an octave or so).

Also, lilypond does not usually decide what's the best option, but
rather the simplest.

http://codereview.appspot.com/4188056/

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

Coredump and orphan avoidance code.

[Han-Wen Nienhuys]

Hi Boris,

I was looking at why

  \markuplines{}

is dumping core, and came across code committed in

commit 4878fcdb04b335041f1440c8d31b0b4b80ecaea9
Author: Boris Shingarov 

  Prob *ps;
  SCM list;
  for (list = texts ; scm_is_pair (list) ; list = scm_cdr (list))
...
   if (list == texts)
   {


complaints:

1. this code leaves ps and list uninitialized. Always initialize *all*
local variables.

2. the if never fires, unless tests==SCM_EOL in the first place

3. Given that the if never fires, do we have a regression test that
covers this code,  and are you sure this actually does something
useful?

Can you please fix this, both the esthetics and the functionality; it
is a release blocking problem.

-- 
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen

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

Re: PATCHES: 48-hour notice for markuplines crash and toc lines

[Han-Wen Nienhuys]

On Tue, Feb 22, 2011 at 4:29 AM, Graham Percival
 wrote:
> Thurs 9am.
>
>
> Assuming we want \markuplines { } to behave like \markup { } (i.e.,
> produce a \null toplevel markup), then this patch works, since it
> ensures a valid Paper_score in paper-book.cc:
> http://codereview.appspot.com/4160059/

This patch is a stopgap.  Please do not apply.

Let me have a look.

-- 
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen

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

Re: Draws a line above footnotes (issue4167063)

[mtsolo]

Reviewers: Bertrand Bordage, mikesol_ufl.edu, joeneeman,

Message:
Thanks Joe!


http://codereview.appspot.com/4167063/diff/3018/lily/note-head.cc
File lily/note-head.cc (right):

http://codereview.appspot.com/4167063/diff/3018/lily/note-head.cc#newcode189
lily/note-head.cc:189: "footnote "
On 2011/02/22 01:05:49, joeneeman wrote:

Any particular reason this belongs to note-head-interface (rather

than, say,

item-interface)?


No, changed to item-interface.

http://codereview.appspot.com/4167063/diff/3018/lily/page-breaking.cc
File lily/page-breaking.cc (right):

http://codereview.appspot.com/4167063/diff/3018/lily/page-breaking.cc#newcode516
lily/page-breaking.cc:516: Page_breaking::draw_page (SCM systems, SCM
footnotes, SCM configuration, int page_num, bool last)
On 2011/02/22 01:05:49, joeneeman wrote:

Surely draw_page can extract the footnotes from the systems rather

than taking

them as an argument? Then you don't have to keep passing them around,

and you

get support for the other page breaking algorithms for free.


Fixed.

http://codereview.appspot.com/4167063/diff/3018/lily/page-layout-problem.cc
File lily/page-layout-problem.cc (right):

http://codereview.appspot.com/4167063/diff/3018/lily/page-layout-problem.cc#newcode65
lily/page-layout-problem.cc:65: Stencil mol;
On 2011/02/22 01:05:49, joeneeman wrote:

Why not make the separator a (stencil-valued) property of the

paper-book?

I could, but currently, this patch employs its current stencil kludge
for the following (perhaps-unfounded) reason.  Please let me know if I
am correct in worrying about this.

The page spacer, when it is calculating rod_height_, takes into account
the height of footnotes in the current patch.  However, it also needs to
take into account the height of the footnote separator.  If the height
and padding of this separator is encoded in the paper-book, there will
be no way for the page spacer to have access to this information (I
think...).  Is there a good way to get the spacer this info w/o more
kludgery?

http://codereview.appspot.com/4167063/diff/3018/lily/page-spacing.cc
File lily/page-spacing.cc (right):

http://codereview.appspot.com/4167063/diff/3018/lily/page-spacing.cc#newcode81
lily/page-spacing.cc:81: for (vsize i = 0; i < line.footnotes_.size ();
i++)
On 2011/02/22 01:05:49, joeneeman wrote:

You'll need to do this in append_system also.


Done.

http://codereview.appspot.com/4167063/diff/3018/lily/system.cc
File lily/system.cc (right):

http://codereview.appspot.com/4167063/diff/3018/lily/system.cc#newcode623
lily/system.cc:623: footnote_search (Grob *g, vsize start, vsize end,
vector* s)
On 2011/02/22 01:05:49, joeneeman wrote:

Have you checked the performance of this? This part is linear and so

it makes

break_into_pieces quadratic. Also, you can make it simpler by

iterating through

"all-elements" instead of recursing through "elements".


I've made the change to iterate through all-elements, but I still need
to measure the performance of the algorithm.  How would I do this?

Description:
Draws a line above footnotes


Footnote sketch

Please review this at http://codereview.appspot.com/4167063/

Affected files:
  M lily/constrained-breaking.cc
  M lily/include/constrained-breaking.hh
  M lily/include/page-breaking.hh
  M lily/include/page-layout-problem.hh
  M lily/include/page-spacing.hh
  M lily/include/system.hh
  M lily/item.cc
  M lily/page-breaking.cc
  M lily/page-layout-problem.cc
  M lily/page-spacing.cc
  M lily/system.cc
  M ly/paper-defaults-init.ly
  M scm/define-grob-properties.scm



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

Re: exact inversion (issue4173065)

[tdanielsmusic]

Pushed to git/origin/master 22 Feb 11
d245674e0266cde01a425317fa28aeb792ce589d
7230509dd005d9bbc7b2a7f0a064abc2de3b0ce6

plus doc changes
28c797d550d5557e75842c59a459aa48349e7ad5
94cce45d444cd6700d3f4df84cda68fb7de96cd7

Trevor

http://codereview.appspot.com/4173065/

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

Re: exact inversion (issue4173065)

[Benkő Pál]

> Pushed to git/origin/master 22 Feb 11
> d245674e0266cde01a425317fa28aeb792ce589d
> 7230509dd005d9bbc7b2a7f0a064abc2de3b0ce6
>
> plus doc changes
> 28c797d550d5557e75842c59a459aa48349e7ad5
> 94cce45d444cd6700d3f4df84cda68fb7de96cd7

thanks again!
p

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

Re: pdfTex failure

[Trevor Daniels]

Graham, you wrote Sunday, February 20, 2011 10:07 PM


On Thu, Feb 17, 2011 at 11:47:17PM -, Trevor Daniels wrote:


make doc was failing for me with

 TeX capacity exceeded, sorry [save size=5000].

I hacked etc/texmf/texmf.cnf to increase save size,
which allowed make doc to proceed, but what is the
correct way to fix this?


Sorry, I can't reproduce in native ubuntu or in lilydev.  Can you
remember any other info about when you saw this?  Was this a doc
build from scratch, and if so, were you using lilydev 1.1 or
something else?  Or was this while building the docs on windows
with your shell scripts?


Sorry, I should have been clearer.  This was in 
Ubuntu 9.10 running under VirtualBox in Vista.  
I don't use lilydev.


The build was a doc build using make doc.  I think
if was after doing make doc-clean, but it seemed
pretty well independent of other things.

After increasing save size to 1 the doc build
completed perfectly, so all is OK at the moment,
but as I hacked a file which says "don't hack this"
I guess it might revert back again after an update
sometime in the future.

What value do you have for save size in 
etc/texmf/texmf.cnf?


Trevor



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

RE: pdfTex failure

[James Lowe]

Hello

)-Original Message-
)From: lilypond-devel-bounces+james.lowe=datacore@gnu.org
)[mailto:lilypond-devel-bounces+james.lowe=datacore@gnu.org] On
)Behalf Of Trevor Daniels
)Sent: 22 February 2011 16:27
)To: Graham Percival
)Cc: Lily-Devel List
)Subject: Re: pdfTex failure
)
)
)Graham, you wrote Sunday, February 20, 2011 10:07 PM
)
)> On Thu, Feb 17, 2011 at 11:47:17PM -, Trevor Daniels wrote:
)>
)>> make doc was failing for me with
)>>
)>>  TeX capacity exceeded, sorry [save size=5000].
)>>
)>> I hacked etc/texmf/texmf.cnf to increase save size, which allowed
)>> make doc to proceed, but what is the correct way to fix this?
)>
)> Sorry, I can't reproduce in native ubuntu or in lilydev.  Can you
)> remember any other info about when you saw this?  Was this a doc
)build
)> from scratch, and if so, were you using lilydev 1.1 or something else?
)> Or was this while building the docs on windows with your shell
)> scripts?
)
)Sorry, I should have been clearer.  This was in Ubuntu 9.10 running under
)VirtualBox in Vista.
)I don't use lilydev.
)
)The build was a doc build using make doc.  I think if was after doing make
)doc-clean, but it seemed pretty well independent of other things.
)
)After increasing save size to 1 the doc build completed perfectly, so
)all is OK at the moment, but as I hacked a file which says "don't hack this"
)I guess it might revert back again after an update sometime in the future.
)
)What value do you have for save size in etc/texmf/texmf.cnf?
)

If it helps, I do use Lily-dev and my cnf file says

param_size = 1   % simultaneous macro parameters
save_size = 5% for saving values outside current group
stack_size = 5000% simultaneous input sources

James



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

Re: Draws a line above footnotes (issue4167063)

[bordage . bertrand]

I meant : we can't use this to do a footnote when in a markup or
markuplines.
Something like :
\markuplines { bla bla bla \footnote { Oh yes ? } bla bla bla }

I know lilypond-book is the best solution for this issue. But it would
be easier if LilyPond had a native support of these features.

http://codereview.appspot.com/4167063/

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

Re: Issue 1278: Arrow notation for quarter-tones. (issue3789044)

[Benkő Pál]

Felipe,

I'm still far from digesting the whole, but this is really great work!

> 2. int vs Rational
>
>> Why not use a sequence of Rationals (rather than ints) to represent
>> the alteration?
>
>> If we use rational numbers, we can maintain backward compatibility.
>
>> The re-scaling of the alterations is interesting but
>> unnecessary.  They could still be rationals.
>
> That is a very reasonable idea. Its main advantage would be, as pointed, in
> more robust backwards compatibility, as well as ease of implementation.
>
> If you decide for that, I can work on a new patch.
>
> Further considerations of mine might be found below question 1.1 in
> http://lists.gnu.org/archive/html/lilypond-devel/2010-12/msg00729.html
> and after the last quote in
> http://lists.gnu.org/archive/html/lilypond-devel/2010-12/msg00737.html

I'm wholeheartedly for Int's, both as mathematician and as musician.

math: if rationals are used, I'd expect to be able to use not only 1/2
but 3/5 etc.

mus: I don't care too much for quarter tones,
but I do care for e.g. meantone tuning, where graphical output is the
same, but MIDI manipulations are very different: the enharmonic interval
gis-as is a bit more than half of g-gis.  Using hard-coded 1/2 is plain ugly,
OTOH I know that 1 is just the coefficient of the augmented prime (aka
chromatic half-note).

as a programmer: since we switch from numbers to pairs, users using
exotic constructs ouside FLAT or SEMI-SHARP should anyway think
carefully about converting to the new representation.

p

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

Re: Draws a line above footnotes (issue4167063)

[Mike Solomon]

I cooked up something that more or less does the job.  It's up on Rietveld.

Cheers,
MS



foo.ly
Description: Binary data


foo.pdf
Description: Adobe PDF document


On Feb 22, 2011, at 12:24 PM, bordage.bertr...@gmail.com wrote:

> I meant : we can't use this to do a footnote when in a markup or
> markuplines.
> Something like :
> \markuplines { bla bla bla \footnote { Oh yes ? } bla bla bla }
> 
> I know lilypond-book is the best solution for this issue. But it would
> be easier if LilyPond had a native support of these features.
> 
> http://codereview.appspot.com/4167063/

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

Re: Draws a line above footnotes (issue4167063)

[bordage . bertrand]

:p
Great job !
There's no word to thank you enough !

Thanks thanks thanks,
Bertrand

http://codereview.appspot.com/4167063/

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

Re: Draws a line above footnotes (issue4167063)

[joeneeman]

On 2011/02/22 15:23:00, MikeSol wrote:

On 2011/02/22 01:05:49, joeneeman wrote:
> Why not make the separator a (stencil-valued) property of the

paper-book?


I could, but currently, this patch employs its current stencil kludge

for the

following (perhaps-unfounded) reason.  Please let me know if I am

correct in

worrying about this.



The page spacer, when it is calculating rod_height_, takes into

account the

height of footnotes in the current patch.  However, it also needs to

take into

account the height of the footnote separator.  If the height and

padding of this

separator is encoded in the paper-book, there will be no way for the

page spacer

to have access to this information (I think...).  Is there a good way

to get the

spacer this info w/o more kludgery?


If you give Page_breaking a public accessor for its paper-book, then you
can access it in Page_spacing. For performance (because
Page_spacing::calc_force gets called a lot), it's probably best to
access the stencil and cache its height in Page_spacing's constructor.


On 2011/02/22 01:05:49, joeneeman wrote:
> Have you checked the performance of this? This part is linear and so

it makes

> break_into_pieces quadratic. Also, you can make it simpler by

iterating

through
> "all-elements" instead of recursing through "elements".



I've made the change to iterate through all-elements, but I still need

to

measure the performance of the algorithm.  How would I do this?


The change to all-elements was just for simplicity; I still think it
will be quadratic. You can do a profiling build with
./configure --enable-conf=prof --enable-profiling --disable-optimising
make conf=prof
(and the binary will be out-prof/bin/lilypond). You can also just time
lilypond on a largish score (ie. multiple minutes of processing time).
You can find such scores on the mailing list if you don't have one; Hu
Haipeng often sends them. Or you can try Valentin's opera, but that's
more like multiple hours of processing time...



http://codereview.appspot.com/4167063/

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

Re: pdfTex failure

[Graham Percival]

On Tue, Feb 22, 2011 at 04:33:34PM +, James Lowe wrote:
> Hello
> 
> )After increasing save size to 1 the doc build completed perfectly, so
> )all is OK at the moment, but as I hacked a file which says "don't hack this"
> )I guess it might revert back again after an update sometime in the future.

BTW, you're "supposed" to edit the file
  /etc/texmf/texmf.d/95NonPath.cnf
and then run
  update-texmf
(as root)

> )What value do you have for save size in etc/texmf/texmf.cnf?
> 
> If it helps, I do use Lily-dev and my cnf file says
> 
> param_size = 1 % simultaneous macro parameters
> save_size = 5  % for saving values outside current group
> stack_size = 5000  % simultaneous input sources

I have exactly the same setup (by default; not surprising since
they're both ubuntu 10.4).

Trevor - I think your solution is fine.

Cheers,
- Graham

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

Re: Draws a line above footnotes (issue4167063)

[Mike Solomon]

On Feb 22, 2011, at 7:17 PM, joenee...@gmail.com wrote:

> On 2011/02/22 15:23:00, MikeSol wrote:
>> On 2011/02/22 01:05:49, joeneeman wrote:
>> > Why not make the separator a (stencil-valued) property of the
> paper-book?
> 
>> I could, but currently, this patch employs its current stencil kludge
> for the
>> following (perhaps-unfounded) reason.  Please let me know if I am
> correct in
>> worrying about this.
> 
>> The page spacer, when it is calculating rod_height_, takes into
> account the
>> height of footnotes in the current patch.  However, it also needs to
> take into
>> account the height of the footnote separator.  If the height and
> padding of this
>> separator is encoded in the paper-book, there will be no way for the
> page spacer
>> to have access to this information (I think...).  Is there a good way
> to get the
>> spacer this info w/o more kludgery?
> 
> If you give Page_breaking a public accessor for its paper-book, then you
> can access it in Page_spacing. For performance (because
> Page_spacing::calc_force gets called a lot), it's probably best to
> access the stencil and cache its height in Page_spacing's constructor.
> 
>> On 2011/02/22 01:05:49, joeneeman wrote:
>> > Have you checked the performance of this? This part is linear and so
> it makes
>> > break_into_pieces quadratic. Also, you can make it simpler by
> iterating
>> through
>> > "all-elements" instead of recursing through "elements".
> 
>> I've made the change to iterate through all-elements, but I still need
> to
>> measure the performance of the algorithm.  How would I do this?
> 
> The change to all-elements was just for simplicity; I still think it
> will be quadratic. You can do a profiling build with
> ./configure --enable-conf=prof --enable-profiling --disable-optimising
> make conf=prof
> (and the binary will be out-prof/bin/lilypond). You can also just time
> lilypond on a largish score (ie. multiple minutes of processing time).
> You can find such scores on the mailing list if you don't have one; Hu
> Haipeng often sends them. Or you can try Valentin's opera, but that's
> more like multiple hours of processing time...
> 

You're right - it takes a long time :(

Perhaps it'd be wise to make a footnote switch that allows users to opt-out of 
this slowness.

The problem is that I'm having trouble drafting a footnote engraver because 
said engraver would (in theory) need to access grobs' systems, which are not 
available when translation happens.

Alternatively, is there a grob that I can acknowledge during the translation 
process that will always exist and will be easily accessible from the systems?  
If so, I can just use the pointer group interface to create a grob array of 
footnoted grobs.

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

Re: contributors / mentors

[Graham Breed]

I've improved my patch.  This line gives correct MIDI key signatures
for all plausibly authentic scenarios:

   (apply + (map (lambda (p) (round (* (cdr p) 2))) pitch-list)) )

It would give the wrong result for a key signature with double sharps
or flats in 19 note equal temperament.


  Graham

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

Re: Doc: NR accidental styles (issue4149045)

[percival . music . ca]

http://codereview.appspot.com/4149045/diff/6001/Documentation/notation/pitches.itely
File Documentation/notation/pitches.itely (right):

http://codereview.appspot.com/4149045/diff/6001/Documentation/notation/pitches.itely#newcode2313
Documentation/notation/pitches.itely:2313: signs.  For example, a
natural is printed before a C-sharp
On 2011/02/09 09:37:16, Keith wrote:

I thought about making the @lilyponds above show this effect, but they

are

already quite information-dense.
'Extra' naturals come up relatively rarely, and the choice to print

them /can/

be made independently from the accidental-style, so it seems best to

mention

them in a separate paragraph.


I disagree.  Please alter the above examples -- it's really easy to
misunderstand a textual description of accidentals, especially if
English is your second or third language.  "show, don't tell".

http://codereview.appspot.com/4149045/diff/6001/Documentation/snippets/dodecaphonic-style-accidentals-for-each-note-including-naturals.ly
File
Documentation/snippets/dodecaphonic-style-accidentals-for-each-note-including-naturals.ly
(left):

http://codereview.appspot.com/4149045/diff/6001/Documentation/snippets/dodecaphonic-style-accidentals-for-each-note-including-naturals.ly#oldcode2
Documentation/snippets/dodecaphonic-style-accidentals-for-each-note-including-naturals.ly:2:
% generated from Documentation/snippets/new
This file is auto-generated from D/s/n.  Have you removed it from there?

http://codereview.appspot.com/4149045/

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

RE: Issue 1278: Arrow notation for quarter-tones. (issue3789044)

[Carl Sorensen]

From: lilypond-devel-bounces+c_sorensen=byu@gnu.org 
[lilypond-devel-bounces+c_sorensen=byu@gnu.org] On Behalf Of Benkő Pál 
[benko@gmail.com]
Sent: Tuesday, February 22, 2011 2:11 PM
To: Felipe Gonçalves Assis
Cc: lilypond-devel@gnu.org
Subject: Re: Issue 1278: Arrow notation for quarter-tones. (issue3789044)

Felipe,

I'm still far from digesting the whole, but this is really great work!

> 2. int vs Rational
>
>> Why not use a sequence of Rationals (rather than ints) to represent
>> the alteration?
>
>> If we use rational numbers, we can maintain backward compatibility.
>
>> The re-scaling of the alterations is interesting but
>> unnecessary.  They could still be rationals.
>
> That is a very reasonable idea. Its main advantage would be, as pointed, in
> more robust backwards compatibility, as well as ease of implementation.
>
> If you decide for that, I can work on a new patch.
>
> Further considerations of mine might be found below question 1.1 in
> http://lists.gnu.org/archive/html/lilypond-devel/2010-12/msg00729.html
> and after the last quote in
> http://lists.gnu.org/archive/html/lilypond-devel/2010-12/msg00737.html

I'm wholeheartedly for Int's, both as mathematician and as musician.

math: if rationals are used, I'd expect to be able to use not only 1/2
but 3/5 etc.

mus: I don't care too much for quarter tones,
but I do care for e.g. meantone tuning, where graphical output is the
same, but MIDI manipulations are very different: the enharmonic interval
gis-as is a bit more than half of g-gis.  Using hard-coded 1/2 is plain ugly,
OTOH I know that 1 is just the coefficient of the augmented prime (aka
chromatic half-note).

as a programmer: since we switch from numbers to pairs, users using
exotic constructs ouside FLAT or SEMI-SHARP should anyway think
carefully about converting to the new representation.

p

___
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: Draws a line above footnotes (issue4167063)

[Joe Neeman]

On Wed, Feb 23, 2011 at 3:14 PM, Mike Solomon  wrote:

> On Feb 22, 2011, at 7:17 PM, joenee...@gmail.com wrote:
>
> > On 2011/02/22 15:23:00, MikeSol wrote:
>
> >> On 2011/02/22 01:05:49, joeneeman wrote:
> >> > Have you checked the performance of this? This part is linear and so
> > it makes
> >> > break_into_pieces quadratic. Also, you can make it simpler by
> > iterating
> >> through
> >> > "all-elements" instead of recursing through "elements".
> >
> >> I've made the change to iterate through all-elements, but I still need
> > to
> >> measure the performance of the algorithm.  How would I do this?
> >
> > The change to all-elements was just for simplicity; I still think it
> > will be quadratic. You can do a profiling build with
> > ./configure --enable-conf=prof --enable-profiling --disable-optimising
> > make conf=prof
> > (and the binary will be out-prof/bin/lilypond). You can also just time
> > lilypond on a largish score (ie. multiple minutes of processing time).
> > You can find such scores on the mailing list if you don't have one; Hu
> > Haipeng often sends them. Or you can try Valentin's opera, but that's
> > more like multiple hours of processing time...
> >
>
> You're right - it takes a long time :(
>
> Perhaps it'd be wise to make a footnote switch that allows users to opt-out
> of this slowness.
>

Better just to make it faster :). What if you add a vector to System
with all the footnoted grobs? The first time get_footnotes_in_range is
called, you do the search, populate the vector and sort it according to
column rank. From then on, you respond to get_footnotes_in_range by doing a
binary search for the upper and lower bounds.

Alternatively, is there a grob that I can acknowledge during the translation
> process that will always exist and will be easily accessible from the
> systems?  If so, I can just use the pointer group interface to create a grob
> array of footnoted grobs.
>

If you'd rather use an engraver to collect the footnotes, you could just
catch all the footnoted items in Score_engraver. You'll still need to sort
the array and use binary searches, though.

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