Re: changes.tely: deal with \transposition and instrumentTransposition changes (issue 7404046)

2013-03-03 Thread Keith OHara 

On Sun, 03 Mar 2013 00:18:09 -0800, David Kastrup  wrote:


"Keith OHara"  writes:


The \oldTransposition you suggested in
 has the required trickery,
and I just re-checked that it works fine.



I'd prefer not giving it a name of its own, instead load a Scheme file
on-demand that redefines \transposition ...


The backward-compatible \oldTransposition is *much* more useful if it can be 
used alongside \transposition.  If you were unfortunate enough to depend on the 
misfeature, you will probably want to change only the few instances of 
\transpose to \oldTransposition necessary to make cue notes and/or MIDI come 
out correctly under 2.17.11, and them move or adjust the \oldTranpositions to 
the correct \transposition, checking the output as you go.


Just issue a diagnostic when seeing \transposition?


Yes, just one message per file that contains "\transposition ".  No automatic 
conversion because most uses will need no change, and we cannot tell which uses might be 
passed through a \transpose operation.


Patterns for that will not exactly be easy to make since
instrumentTransposition is usually an alist.


No convert-ly rule at all is the most appropriate here, because every known 
setting of instrumentTransposition /tried/ to use the /new/ behavior (and thus 
would not have worked previously).

For example in  for 
version 2.9, you find
\tag #'horn-A {
\key c \major
\set Staff . instrumentTransposition = #(ly:make-pitch -1 5 0)
\clef treble }
There are no cues, so no problems in the printed output, but the MIDI is rather 
unharmonious.


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

Re: Alternative pixel-based regtest checker

2013-03-03 Thread Phil Holmes 
- Original Message - 
From: "Phil Holmes" 

To: "Devel" 
Sent: Friday, March 01, 2013 7:15 PM
Subject: Alternative pixel-based regtest checker



4 files attached.  To try this out: create a new directory and place
NoTagline.ly in it.  Create a subdirectory called input and put some 
regtest

files in there.  Run MakeOldPix.sh.  Make a change to lilypond.  Run
MakeNewPix.sh.  Run ComparePix.sh.  Om my tests there were some false
alarms, but it seems a fairly simple way to make an alternative regtest
checker.

There's lots of improvements that could be made: parallelism, using
something other than diff, but it basically works.

Thoughts?

--
Phil Holmes



Thanks to Felix (and some modification of his suggestion) I now have version 
0.b of my pixel-regtest checker.  And it works.  Instructions are as above.


I now convert the grayscale PNGs to black and white, which makes them less 
susceptible to false alarms.  On my build machine, the entire create old; 
make; create new; check takes about 4 minutes, of which 1 minute is the 
make.  If this were to be part of the code base, I'd suggest skipping the 
"copy the regtests" step and use the in-place ones; have a more sensible set 
of directory names for the old and new images; but apart from that I think 
it's ready to go.  Would people be comfortable with this as a set of 3 shell 
scripts, or should it be integrated into make in some way?


--
Phil Holmes 


ComparePix.sh
Description: Binary data


MakeOldPix.sh
Description: Binary data


MakeNewPix.sh
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Lilypond command line syntax

2013-03-03 Thread Felix Janda 
On 03/03/13 at 04:18pm, Phil Holmes wrote:
> We're in dir Test.
> Get a list of all lilypond files that are currently in Test/input
> Use that list of files to run lilypond, with all output PNGs going to 
> Test/Pix and including file Test/include.ly.  The .png files should use the 
> root filename of each .ly file processed.

How about the following?

cd Test/Pix
ls ../input > list
lilypond --png --relocate -djob-count 4 -dread-file-list list

(Assuming that no input file name contains newlines)

Felix

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

Lilypond command line syntax

2013-03-03 Thread Phil Holmes 
I've got my shell-based Ubuntu regtest comparator working well, using 
comparison functions from imagemagick.  What I want to do now is make it use 
more CPUs by using job-count.  AFAIK, this works by processing multiple 
files in parallel, rather than using lots of CPUs for a single file.  The 
simplest way to pass lots of filenames to lily is a ls > dir.txt and 
then -dread-file-list="dir.txt".  However, if I do this, fails to find an 
include file, which is important to get rid of the tagline.  If I try 
running it from a lower level directory and use the -o flag to put the 
output files in the correct output directory, it puts the first one in the 
right place and then either names the others DirName.png or simply doesn't 
output them.  Here's a synopsis of what I want.


We're in dir Test.
Get a list of all lilypond files that are currently in Test/input
Use that list of files to run lilypond, with all output PNGs going to 
Test/Pix and including file Test/include.ly.  The .png files should use the 
root filename of each .ly file processed.


Sounds easy, but I couldn't get it to work.  If a determined command-line 
hacker could try to provide the right syntax, I would be very grateful.


--
Phil Holmes



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

Re: bug in articulate.ly

2013-03-03 Thread David Kastrup 
Zefram  writes:

> David Kastrup wrote:
>>>   articulate.ly:446:13: In procedure map in expression (map (lambda
>>> # #)):
>>>   articulate.ly:446:13: Wrong number of arguments to
>>> #
>
> Oh, hmm.  Oops.  The expression
>
>   (map (lambda (alt) (list (ly:music-deep-copy body) alt)))
>
> should be
>
>   (map (lambda (alt) (list (ly:music-deep-copy body) alt)) ealtl)
>
> Need more tests!

Do you intend creating a fix for issue 3204?  If not, I'd rather revert
the original patch rather than poking around in the dark.

-- 
David Kastrup

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

Re: build: missing explicit dependency?

2013-03-03 Thread James 
Hello (sorry to reply to myself)

On 3 March 2013 13:51, James  wrote:

> Hello,
>
>
> On 2 March 2013 16:54, Francisco Vila  wrote:
>
>> Hello. When trying to build lilypond, I had to install the
>> texlive-metapost package which the autogen.sh did not ask for. Is this
>> a flaw of the config process?
>> --
>> Francisco Vila. Badajoz (Spain)
>> www.paconet.org , www.csmbadajoz.com
>>
>> ___
>> lilypond-devel mailing list
>> lilypond-devel@gnu.org
>> https://lists.gnu.org/mailman/listinfo/lilypond-devel
>>
>
> Well when I follow the NR to install the software to compile LP the
> builddep-lilypond seems to contain this
>
> https://launchpad.net/ubuntu/precise/+source/lilypond
>
> I am not sure what Linux Dist you are using but did you follow the NR or
> are you getting the parts in a different way.
>
> Correct me if I have misunderstood though.
>


I know this doesn't address whether configure should report something else
than what it currently does, but also does configure list components of
this package therefore implying that it is/is not installed?

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

Re: build: missing explicit dependency?

2013-03-03 Thread James 
Hello,

On 2 March 2013 16:54, Francisco Vila  wrote:

> Hello. When trying to build lilypond, I had to install the
> texlive-metapost package which the autogen.sh did not ask for. Is this
> a flaw of the config process?
> --
> Francisco Vila. Badajoz (Spain)
> www.paconet.org , www.csmbadajoz.com
>
> ___
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-devel
>

Well when I follow the NR to install the software to compile LP the
builddep-lilypond seems to contain this

https://launchpad.net/ubuntu/precise/+source/lilypond

I am not sure what Linux Dist you are using but did you follow the NR or
are you getting the parts in a different way.

Correct me if I have misunderstood though.

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

Allows minimum-length to work for end-of-line spanners. (issue 7453046)

2013-03-03 Thread lemzwerg 

LGTM.  Thanks for the good comment :-)

https://codereview.appspot.com/7453046/

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

Re: Alternative pixel-based regtest checker

2013-03-03 Thread Phil Holmes 
- Original Message - 
From: "Werner LEMBERG" 

To: 
Cc: ; ; 
Sent: Sunday, March 03, 2013 7:06 AM
Subject: Re: Alternative pixel-based regtest checker





I know from my Windows pixel-based checker that, generally, the PNG
files contain the same image, version after version (there are a few
oddities with some text, which I'm used to).  I would have believed
that identical images would only be produced by identical PNG files?


Usually, picture container formats like PNG also contain metadata like
the date of image creation or a comment.  This makes PNGs different
even in case the contained images are identical.

Additionally, it's possible that identical images are stored in
different formats, for example, a B/W image can be stored either as a
1-bit bitmap or an 8-bit pixmap.

However, you could convert PNG images temporarily to the PGM format
to compute a hashsum: PGM doesn't have metadata.

 http://en.wikipedia.org/wiki/Netpbm_format

The program to do this is `pngtopnm', probably followed by a call to
`pgmtopgm' to assure that B/W images are handled as grayscale images
too:

 pngtopnm image.png \
 | pgmtopgm \
 | md5sum -b > image.md5


   Werner



I did some more looking at this last night, but didn't have time to post the 
results.  There were lots of differences in a couple of PNG files which 
appeared identical visually.  I actually converted them to bitmaps and found 
there were six pixels different, to the tune of 1/255 in brightness - so 
they were effectively the same.  I assume the PNGs were so different because 
of the way the compression algorithm works.  It's certainly not meta data in 
these files - most comparisons show 2 files created by different lilypond 
versions to be byte-identical.


I've done some more work on the comparison and will post an update once it's 
worth demonstrating.  Not sure when that will be - rehearsing and college 
work is pressing.


--
Phil Holmes 



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

Re: Alternative pixel-based regtest checker

2013-03-03 Thread David Kastrup 
Werner LEMBERG  writes:

>> I know from my Windows pixel-based checker that, generally, the PNG
>> files contain the same image, version after version (there are a few
>> oddities with some text, which I'm used to).  I would have believed
>> that identical images would only be produced by identical PNG files?
>
> Usually, picture container formats like PNG also contain metadata like
> the date of image creation or a comment.  This makes PNGs different
> even in case the contained images are identical.

Also they are compressed, and even with lossless compression, there is
more than one valid representation for most data.

However, if there is no time stamp in the image data and the image is
created by the same software, chances are that a byte-by-byte comparison
will largely reduce the amount of data one has to compare more
carefully.

-- 
David Kastrup

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

Re: changes.tely: deal with \transposition and instrumentTransposition changes (issue 7404046)

2013-03-03 Thread David Kastrup 
"Keith OHara"  writes:

> On Wed, 27 Feb 2013 00:47:21 -0800,  wrote:
>
>> On 2013/02/27 07:40:59, Keith wrote:
>>
>>> Oops.  It was \oldTransposition  but it was not put into LilyPond.
>>
>> Since the sign of instrumentTransposition has been inverted, it would
>> require serious trickery or a separate music event type to implement
>> \oldTransposition with the previous semantics.
>
> The \oldTransposition you suggested in
>  has the required trickery,
> and I just re-checked that it works fine.

Would you believe that I had already forgotten about this contraption?
It did not exactly get a favorable review from you, either.

Ok, but we'd still need to figure out how to deal with this abomination.
I'd prefer not giving it a name of its own, instead load a Scheme file
on-demand that redefines \transposition (of course, that does not work
using the given definition with #{ \transposition ... #} inside but that
is easily fixed).  That way, our proper code base steers clear of this
kind of cruft.

The question is what convert-ly should try doing about it.  Just issue a
diagnostic when seeing \transposition?  Load the compatibility file
unconditionally?  Load/warn only given certain patterns?

> Probably no-one has used \addInstrumentDefinition for transposition,
> but if someone has, the instrumentTransposition assignments already
> use ly:make-pitch, so inserting ly:pitch-negate is not too much work.

Patterns for that will not exactly be easy to make since
instrumentTransposition is usually an alist.

-- 
David Kastrup

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