feature : log file with positions of notes

2014-12-21 Thread Franck Revolle
Suggestion of (new ? ) feature :
When a lilypond score-image is created ( e.g. a png file ), a log file can be 
used by an external software. This log file contains information about 
graphical position of the notes, within the score-image ( e.g. beat, stave,  # 
of page, x-y-width-heigh ). The external software can use the score-image, and 
make graphical « interaction » with the picture ( highlight the items, ... ).

Usage :
I would like to develop a new version of my Expresseur freeware ( 
www.expresseur.com ). I would like to use lilypond to build the score-image, 
according to the user’s options ( staves to play/display ). 
For this, I can use Lilypond to build easily the score-image, building 
automatically the lilypond source-code. 
But I also need to interact with the score-image, to highlight position 
dynamically. So, I need to know where to find graphically the notes, within the 
image. The log file can be a solution …

My contribution :
I can update source-code ( C++, .. ). But some help can be useful to know where 
to « touch » this (large) project….

Alternative :
Filter tha available logs.
May be(?), this information is already available in a « verbose » log. In this 
case, I just need some indications to know how to generate this information, 
and where to find it in the log. With this information, it will be easy for me 
to parse the text logs…

For consideration
Franck Revolle






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


Re: feature : log file with positions of notes

2014-12-21 Thread Urs Liska
Without having a very close look at your project I'd first like to ask 
if you can imagine working with scores in SVG format. With these you'd 
have not only coordinates but real objects that you can quite easily 
interact with using JavaScript.


HTH
Urs

Am 21.12.2014 um 10:34 schrieb Franck Revolle:

Suggestion of (new ? ) feature :
When a lilypond score-image is created ( e.g. a png file ), a log file can be 
used by an external software. This log file contains information about 
graphical position of the notes, within the score-image ( e.g. beat, stave,  # 
of page, x-y-width-heigh ). The external software can use the score-image, and 
make graphical « interaction » with the picture ( highlight the items, ... ).

Usage :
I would like to develop a new version of my Expresseur freeware ( 
www.expresseur.com ). I would like to use lilypond to build the score-image, 
according to the user’s options ( staves to play/display ).
For this, I can use Lilypond to build easily the score-image, building 
automatically the lilypond source-code.
But I also need to interact with the score-image, to highlight position 
dynamically. So, I need to know where to find graphically the notes, within the 
image. The log file can be a solution …

My contribution :
I can update source-code ( C++, .. ). But some help can be useful to know where 
to « touch » this (large) project….

Alternative :
Filter tha available logs.
May be(?), this information is already available in a « verbose » log. In this 
case, I just need some indications to know how to generate this information, 
and where to find it in the log. With this information, it will be easy for me 
to parse the text logs…

For consideration
Franck Revolle






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


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


Fwd: Re: feature : log file with positions of notes

2014-12-21 Thread Urs Liska

Sorry, forwarded to the wrong list


 Weitergeleitete Nachricht 
Betreff:Re: feature : log file with positions of notes
Datum:  Sun, 21 Dec 2014 10:52:15 +0100
Von:Urs Liska 
An: 	Franck Revolle , lilypond-user 






Am 21.12.2014 um 10:49 schrieb Franck Revolle:

Good idea …!
Yes, I can display SVG : it seems available in the wxWidgets(*) library.
Do you have any links in the documentation, about lilypond SVG 
information ? It will help me to start the coding, to parse this SVG 
information :-)


No, but you may have a look at the SVG editing code in Frescobaldi:
https://github.com/wbsoft/frescobaldi/tree/master/frescobaldi_app/svgview

HTH
Urs



Musicalement vôtre
Franck Revolle



(*)Â wxWidgets is a C++ library that lets developers create 
applications for Windows, Mac OS X, Linux and other platforms with a 
single code base. www.widgets.org Â



Le 21 déc. 2014 à 10:37, Urs Liska > a écrit :


Without having a very close look at your project I'd first like to 
ask if you can imagine working with scores in SVG format. With these 
you'd have not only coordinates but real objects that you can quite 
easily interact with using JavaScript.


HTH
Urs

Am 21.12.2014 um 10:34 schrieb Franck Revolle:

Suggestion of (new ? ) feature :
When a lilypond score-image is created ( e.g. a png file ), a log 
file can be used by an external software. This log file contains 
information about graphical position of the notes, within the 
score-image ( e.g. beat, stave, Â # of page, x-y-width-heigh ). The 
external software can use the score-image, and make graphical « 
interaction » with the picture ( highlight the items, ... ).


Usage :
I would like to develop a new version of my Expresseur freeware ( 
www.expresseur.com  ). I would like to 
use lilypond to build the score-image, according to the user’s 
options ( staves to play/display ).
For this, I can use Lilypond to build easily the score-image, 
building automatically the lilypond source-code.
But I also need to interact with the score-image, to highlight 
position dynamically. So, I need to know where to find graphically 
the notes, within the image. The log file can be a solution …


My contribution :
I can update source-code ( C++, .. ). But some help can be useful to 
know where to « touch » this (large) project….


Alternative :
Filter tha available logs.
May be(?), this information is already available in a « verbose » 
log. In this case, I just need some indications to know how to 
generate this information, and where to find it in the log. With 
this information, it will be easy for me to parse the text logs…


For consideration
Franck Revolle






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


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






___
lilypond-user mailing list
lilypond-u...@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

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


Re: Doc: NR section 3.5.x MIDI file creation tidy up (issue 120480043 by pkx1...@gmail.com)

2014-12-21 Thread pkx166h

Thanks to Trevor and Heikki.

Issues still to be resolved:

Do we still need to move the articulate section and if so, where?


https://codereview.appspot.com/120480043/diff/21/Documentation/notation/input.itely
File Documentation/notation/input.itely (right):

https://codereview.appspot.com/120480043/diff/21/Documentation/notation/input.itely#newcode2677
Documentation/notation/input.itely:2677: To create a MIDI output file
from a LilyPond input file, insert an empty
On 2014/12/07 23:43:00, Trevor Daniels wrote:

It doesn't have to be empty.  Maybe "insert a @code{\midi} block,

usually empty,

within ..."


Done.

https://codereview.appspot.com/120480043/diff/220001/Documentation/notation/input.itely
File Documentation/notation/input.itely (right):

https://codereview.appspot.com/120480043/diff/220001/Documentation/notation/input.itely#newcode2683
Documentation/notation/input.itely:2683: To create a MIDI output file
from a LilyPond input file, insert an empty
On 2014/12/07 23:43:00, Trevor Daniels wrote:

It doesn't have to be empty.  Maybe "insert a @code{\midi} block,

usually empty,

within ..."


Done.

https://codereview.appspot.com/120480043/diff/220001/Documentation/notation/input.itely#newcode2852
Documentation/notation/input.itely:2852: @code{channel 10 drum-kits}
entries listed in @file{scm/midi.scm} for
On 2014/12/07 23:43:00, Trevor Daniels wrote:

I'm not convinced this is an improvement.  It is unfair to expect
non-programming drummers to (a) locate a file buried deep in the file

hierarchy

and (b) understand enough of Scheme to read far enough to find this.

I think

the original wording was more helpful, although I don't mind adding

the

reference to the Scheme file with something like, "a full list can be

found ...

".  But then you'd need to add a @seealso to LM 4.7.4 Other sources of
information.


Done.

https://codereview.appspot.com/120480043/diff/220001/Documentation/notation/input.itely#newcode2880
Documentation/notation/input.itely:2880: turns) to be processed.A full
list of supported items can be found in
On 2014/12/07 23:43:00, Trevor Daniels wrote:

2 spaces please


Done.

https://codereview.appspot.com/120480043/diff/220001/Documentation/notation/input.itely#newcode2881
Documentation/notation/input.itely:2881: the script itself.  See
@file{ly/articulate.ly}.
On 2014/12/07 23:43:00, Trevor Daniels wrote:

Another @seealso to 4.7.4 Other sources of information.


Done.

https://codereview.appspot.com/120480043/diff/220001/Documentation/notation/input.itely#newcode2890
Documentation/notation/input.itely:2890: @warning{The @file{articulate}
script may shorten chords, which mght not
On 2014/12/14 14:07:24, ht wrote:

mght -> might


Done.

https://codereview.appspot.com/120480043/diff/220001/Documentation/notation/input.itely#newcode2893
Documentation/notation/input.itely:2893: and breaths and so could sound
worse; in this case reconfigure the
On 2014/12/14 14:07:24, ht wrote:

Technically, possibly a more relevant reason why the output could

sound worse is

that the \articulate function will alter the default output even for

*notes

without any articulations* (as every note without any articulation

will get

"shortened" by ac:normalFactor), and slurs just (temporarily)

*disable* this

shortening behavior (so, in fact, the note at which a slur ends is the

only note

which \articulate will shorten, at least in the simple case where the

slurred

notes don't have any other articulations).



I don't wish all this technical detail to be added here: instead, I'd

change the

part added to the previous documentation (after the sentence about

shortening

chords) to something like:



 The \articulate function also shortens notes that do not have any
 articulations and so could make them sound worse; to compensate

for

 unwanted side effects, restrict the use of the function to shorter
 segments of music, or modify the values of the variables defined

in

 the @file{articulate} script to customize the shortening behavior.


Done.

https://codereview.appspot.com/120480043/diff/220001/Documentation/notation/input.itely#newcode2971
Documentation/notation/input.itely:2971: the @code{Staff} context.
On 2014/12/14 14:07:24, ht wrote:

I'm sorry to still return to this section, but I noticed that the

proposed new

organization of the material here could leave some confusion as to how

the

different ways of setting the minimum and maximum MIDI volume

interact.


I think that it might be clearer (as in the previous documentation) to

still

start with describing how to set midiMinimumVolume and

midiMaximumVolume on the

Score level, and only then move to tuning the volume ranges on the

Staff level

(since Staff-level properties will override any Score-level ones), or

using a

custom Score.instrumentEqualizer (which is really an alternative to

setting

midiMinimumVolume and midiMaximumVolume – in the Dynamic_performer
implementation, it looks like Scor

Re: GUB and mpfr/mpc

2014-12-21 Thread Keith OHara
Dan Eble  faithful.be> writes:

> > On Dec 8, 2014, at 08:21 , David Kastrup  gnu.org> wrote:
> > 
> > Masamichi HOSODA  sea.plala.or.jp> writes:
> > 
> >>> I agree that changing the algorithms is preferred; I didn’t mean to
> >> suggest otherwise.  But if that’s not going to happen overnight, and
> >> there is a way to mitigate the problem in the meantime without
> >> touching the code, the people affected would value it.
> >> 
> >> I tried "-mfpmath=sse -msse2".
> >> It worked fine. bad_alloc didn't occur.
> >> Correct PDF was generated.
> >> 
> >> It can be a workaround until changing the algorithms.
> > 
> > It's not architecture independent.  And may blow up for other reasons.
> 
> But it’s good to know that the problem was floating point and not memory 
corruption, so thanks for testing it.
> 

This sounds like the runaway-loop problem we noticed when allowing
zero-width items into skylines.   I opened issue 4229 and will post
a patch.




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


Re: mentorship

2014-12-21 Thread Keith OHara
Kevin Barry  gmail.com> writes:

> 
> > It depends on which part of LilyPond you want to help with as to the
> > availability of people to help you. Is there a particular skill-set, set
> > of issues or area of LilyPond you are particularly interested in?
> 
> Thank you for responding. I would like to be able to contribute code to 
the
> project but I'm not really a programmer (I'm a music academic). I worked
> through some chapters of SICP in the past, so I have a rudimentary
> understanding of ... the first few chapters of SICP. I would like to learn
> more, if that's something that would help. Otherwise I will help any way
> that might be needed. I don't have any specific goals other than
> contributing somehow and maybe learning more about programming along the
> way.
> 
> Kevin
> 


Given that you know a lot about how various kinds of printed music 
are supposed to look, and have an interest in how the program works,

I suggest you watch for interesting bug-reports, follow the resolutions,
and compile lilypond and test the patches if you can set up a computer
to do that.

Often we have enhancement requests
http://code.google.com/p/lilypond/issues/detail?id=1503
that turn out not to be completely wise
http://code.google.com/p/lilypond/issues/detail?id=4222

Sometimes the main question is one of how to design a feature to be useful
http://code.google.com/p/lilypond/issues/detail?id=1321
http://code.google.com/p/lilypond/issues/detail?id=3279


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


skyline.cc: merge algorithm terminates independent of floating-point (issue 186530043 by k-ohara5...@oco.net)

2014-12-21 Thread lemzwerg

LGTM


https://codereview.appspot.com/186530043/diff/1/lily/skyline.cc
File lily/skyline.cc (right):

https://codereview.appspot.com/186530043/diff/1/lily/skyline.cc#newcode249
lily/skyline.cc:249: printf ("We are here");
Debugging remnants?

https://codereview.appspot.com/186530043/

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


Re: skyline.cc: merge algorithm terminates independent of floating-point (issue 186530043 by k-ohara5...@oco.net)

2014-12-21 Thread k-ohara5a5a

Reviewers: lemzwerg,


https://codereview.appspot.com/186530043/diff/1/lily/skyline.cc
File lily/skyline.cc (right):

https://codereview.appspot.com/186530043/diff/1/lily/skyline.cc#newcode249
lily/skyline.cc:249: printf ("We are here");
On 2014/12/22 04:25:43, lemzwerg wrote:

Debugging remnants?


Proving that code is dead before I remove it.

Description:
skyline.cc: merge algorithm terminates independent of floating-point

skyline.cc: first_intersection algorithm more robust to optimized
floating-point

skyline.cc: remove deholify

Please review this at https://codereview.appspot.com/186530043/

Affected files (+86, -103 lines):
  M lily/include/skyline.hh
  M lily/include/skyline-pair.hh
  M lily/paper-column.cc
  M lily/separation-item.cc
  M lily/skyline.cc
  M lily/skyline-pair.cc
  M lily/stencil-integral.cc



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


Re: skyline.cc: merge algorithm terminates independent of floating-point (issue 186530043 by k-ohara5...@oco.net)

2014-12-21 Thread lemzwerg

LGTM.  Maybe it makes sense to commit the removal of the `deholify'
stuff separately.

https://codereview.appspot.com/186530043/

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