Re: musicxml merge

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: musicxml merge

Reinhold Kainhofer
Am Donnerstag, 13. September 2007 schrieb Han-Wen Nienhuys:
> +    # Allow the user to leave out the .xml on the filename
> +    filename = get_existing_filename_with_extension (args[0], "xml")
> +    if not os.path.exists (filename):
> +        print "Unable to find input file %s" % args[0]
>
> print is being deprecated in python 2.6; better use
>
>   sys.stderr.write()

Okay. I better use the progress(...) function, which does exactly that..

> +        if filename[-1] == '.':
> +            filename += "xml"
> +        elif not re.match ("\.xml$", filename):
> +            filename += ".xml"
>
> this looks a bit strange.
> Do you mean a boolean or here?

No, I'm checking the filename and appending .xml if it's not there (or only
xml if the filename already ends in a "."). The logic is:

If file with given filename exists => Use that filename

If not exists:
append "xml" if it ends in a dot (because of shell auto-completion) or
append ".xml" if it does not end in .xml, either.


> -        d.duration_log = mxl_note.get_duration_log ()
> +        duration_log = mxl_note.get_duration_log ()
> +        if duration_log:
> +            d.duration_log = mxl_note.get_duration_log ()
> +        else:
>
> would it be good to print a warning for this? Perhaps you could also
> mark the note in the .ly file.

I think I found the problem (I had it with a 40.000 lines musicxml scan, so it
was not so easy to find the culprit): Grace notes don't have any duration
set. As long as musicxml2ly does not convert grace notes, it's probably best
to write out a warning (and even after that, whenever such a case occurs,
it's apparently a bug in musicxml2ly).


> +# empty
> +
> +# UGH UGH
> +include $(make-dir)/lilypond-vars.make
> +
>
> why is this needed?

mainly because the binaries are defined there...

> also, if you feel adventurous, you could look into getting the
> musicxml files into the regtest; I'll have a look at it when possible,
> but it will probably be end of september earliest.

The main problem I ran into was how to create pdfs from the .ly files. I had
hoped that simply giving the .pdf files as targets would build the .ly files
from the .xml and then the .pdf from .ly, but apparently I'm missing
something in the makefiles for this to work.

Cheers,
Reinhold
--
------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: [hidden email], 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
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: musicxml merge

Han-Wen Nienhuys-3
2007/9/13, Reinhold Kainhofer <[hidden email]>:

> > +        if filename[-1] == '.':
> > +            filename += "xml"
> > +        elif not re.match ("\.xml$", filename):
> > +            filename += ".xml"
> >
> > this looks a bit strange.
> > Do you mean a boolean or here?
>
> No, I'm checking the filename and appending .xml if it's not there (or only
> xml if the filename already ends in a "."). The logic is:
>
> If file with given filename exists => Use that filename

both if-bodies are the same. That can't be right.

> > +# empty
> > +
> > +# UGH UGH
> > +include $(make-dir)/lilypond-vars.make
> > +
> >
> > why is this needed?
>
> mainly because the binaries are defined there...

but you're already including lilypond stuff from the GNUmakefile.

> > also, if you feel adventurous, you could look into getting the
> > musicxml files into the regtest; I'll have a look at it when possible,
> > but it will probably be end of september earliest.
>
> The main problem I ran into was how to create pdfs from the .ly files. I had
> hoped that simply giving the .pdf files as targets would build the .ly files
> from the .xml and then the .pdf from .ly, but apparently I'm missing
> something in the makefiles for this to work.

the real solution is to create a texidoc document, similar to how
input/regression/ does it; try running

  make test

to see what happens there.

--
Han-Wen Nienhuys - [hidden email] - http://www.xs4all.nl/~hanwen


_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: musicxml merge

Juergen Reuter
On Thu, 13 Sep 2007, Han-Wen Nienhuys wrote:

> 2007/9/13, Reinhold Kainhofer <[hidden email]>:
>>> +        if filename[-1] == '.':
>>> +            filename += "xml"
>>> +        elif not re.match ("\.xml$", filename):
>>> +            filename += ".xml"
>>>
>>> this looks a bit strange.
>>> Do you mean a boolean or here?
>>
>> No, I'm checking the filename and appending .xml if it's not there (or only
>> xml if the filename already ends in a "."). The logic is:
>>
>> If file with given filename exists => Use that filename
>
> both if-bodies are the same. That can't be right.
>

Isn't the right thing to completely drop the first "if"?  If a user really
choses a filename that ends with ".", I think the correct behavior
is to append ".xml" (rather than just "xml").  For example, imagine a
windows user chosing the filename "This is a complete sentence."  If you
only append "xml", the dot will disappear from the filename that is
displayed to the user in the windows GUI.  I think, the correct full
filename should in this case be "This is a complete sentence..xml".  Or do
I miss something?

Greetings,
Juergen


_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: musicxml merge

Reinhold Kainhofer
Am Donnerstag, 13. September 2007 schrieben Sie:

> On Thu, 13 Sep 2007, Han-Wen Nienhuys wrote:
> > 2007/9/13, Reinhold Kainhofer <[hidden email]>:
> >>> +        if filename[-1] == '.':
> >>> +            filename += "xml"
> >>> +        elif not re.match ("\.xml$", filename):
> >>> +            filename += ".xml"
> >>>
> >>> this looks a bit strange.
> >>> Do you mean a boolean or here?
> >>
> >> No, I'm checking the filename and appending .xml if it's not there (or
> >> only xml if the filename already ends in a "."). The logic is:
> >>
> >> If file with given filename exists => Use that filename
> >
> > both if-bodies are the same. That can't be right.

No, they aren't. The first one appends xml without the ".", the second one
appends .xml with a "."

> Isn't the right thing to completely drop the first "if"?  If a user really
> choses a filename that ends with ".", I think the correct behavior
> is to append ".xml" (rather than just "xml").  For example, imagine a
> windows user chosing the filename "This is a complete sentence."  If you
> only append "xml", the dot will disappear from the filename that is
> displayed to the user in the windows GUI.  I think, the correct full
> filename should in this case be "This is a complete sentence..xml".  Or do
> I miss something?

First, please note that this is for the INPUT file name (i.e. a filename of an
EXISTING file). There is a subsequent check whether that file really exists,
anyway. The file name for the OUTPUT file will be completely determined from
the existing xml file. My changes only affect the case when you leave out the
file extension on the command line and give an incomplete filename. For the
output filename it doesn't matter if you give test, test. or test.xml as
input file name (provided the xml file is test.xml).

E.g. assume you have files test.mus (Finale file) and test.xml in a directory.
You can then run either of the following commands to generate test.ly from
test.xml (which needs to exist anyway):
  - musicxml2ly test
  - musicxml2ly test.xml
  - musicxml2ly test.

This is the same behaviour as lilypond itself.

In a shell in Linux or Unix, when you do tab completion and you have files
test.xml and test.mus, you would typically type
musi<tab> te<tab>
(musi will be completed to the existing command musicxml2ly, te will
be "completed" using the existing file names to "test.", since that's the
largest common part in the existing file names). So, tab completion will
result in "musicxml2ly test." and it's quite convenient to have that command
working already.

However, I agree with the observation that this behaviour breaks with
filenames like test..xml (i.e. in this case you must give the full filename,
test. won't suffice). I'll fix this to first check for a file with .xml
appended and only afterwards with xml appended.

Cheers,
Reinhold

--
------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: [hidden email], 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
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel