Re: musicxml2ly: import chordnames attached to empty measures or whole rests?

[leonardlthomp...@gmail.com]

Much appreciated!

On Wed, Oct 13, 2021 at 12:41 PM Jean Abou Samra  wrote:

> Le 11/10/2021 à 22:37, leonardlthomp...@gmail.com a écrit :
> > Hello!
> > It seems that musicxml2ly won't create a chordname if the corresponding
> > harmony element in the musicxml file is attached to an empty whole rest
> > measure. Works just fine with a chord symbol attached to a single quarter
> > rest, for example, even in a measure of only quarter rests. Would a
> simple
> > modification to the musicxml2ly python file fix this? I've modified other
> > things successfully in that file so I don't mind trying on my own if
> anyone
> > has a hint.  Attached are the two different cases I've mentioned.
> > Thanks very much.
> > Leonard
>
> Thanks for your report. This is now
>
> https://gitlab.com/lilypond/lilypond/-/issues/6195
>
> Note that xml2ly (living at https://github.com/jacques-menu/musicformats)
> converts your example just fine.
>
> Best regards,
> Jean
>

Re: musicxml2ly: import chordnames attached to empty measures or whole rests?

[Jean Abou Samra]

Le 11/10/2021 à 22:37, leonardlthomp...@gmail.com a écrit :

Hello!
It seems that musicxml2ly won't create a chordname if the corresponding
harmony element in the musicxml file is attached to an empty whole rest
measure. Works just fine with a chord symbol attached to a single quarter
rest, for example, even in a measure of only quarter rests. Would a simple
modification to the musicxml2ly python file fix this? I've modified other
things successfully in that file so I don't mind trying on my own if anyone
has a hint.  Attached are the two different cases I've mentioned.
Thanks very much.
Leonard


Thanks for your report. This is now

https://gitlab.com/lilypond/lilypond/-/issues/6195

Note that xml2ly (living at https://github.com/jacques-menu/musicformats)
converts your example just fine.

Best regards,
Jean

Re: musicxml2ly: Emit bar checks for all voices (issue 553620043 by jonas.hahnf...@gmail.com)

[jonas . hahnfeld]

Reviewers: Dan Eble,


https://codereview.appspot.com/553620043/diff/581760043/scripts/musicxml2ly.py
File scripts/musicxml2ly.py (right):

https://codereview.appspot.com/553620043/diff/581760043/scripts/musicxml2ly.py#newcode2287
scripts/musicxml2ly.py:2287: if n._measure_position == Rational(0) and n
!= voice._elements[0]:
On 2020/03/10 00:20:12, Dan Eble wrote:
> Is the purpose of n != voice._elements[0] to avoid printing a bar
check at the
> beginning of the first measure?  If so, I would have been less puzzled
if the
> comment were "print a bar check at the beginning of every measure
after the
> first" or simply "print bar checks between measures".

I really have no idea. This condition was the way to fix the problem at
hand, but I'm not really into what the script is doing in detail. I tend
to agree with your analysis though. I'm going with "print bar checks
between measures", thanks for the suggestion.

Description:
musicxml2ly: Emit bar checks for all voices

The script only added them for the first voice, without explanation.
As this change doesn't seem to cause any problems, it's probably fine
to lift this restriction and make the generated code easier to read.

Suggested privately by Kai Ruemmler.

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

Affected files (+1, -1 lines):
  M scripts/musicxml2ly.py


Index: scripts/musicxml2ly.py
diff --git a/scripts/musicxml2ly.py b/scripts/musicxml2ly.py
index 
a14b1511877b506ce2106b9e681dfdd9b91286d4..03d3f9d8aaa195b38d3ef560eff92fd965af6e06
 100755
--- a/scripts/musicxml2ly.py
+++ b/scripts/musicxml2ly.py
@@ -2284,7 +2284,7 @@ def musicxml_voice_to_lily_voice(voice):
 continue
 
 # print a bar check at the beginning of each measure!
-if n.is_first() and n._measure_position == Rational(0) and n != 
voice._elements[0]:
+if n._measure_position == Rational(0) and n != voice._elements[0]:
 try:
 num = int(n.get_parent().number)
 except ValueError:

Re: musicxml2ly: portugues notenames and quarternotes in español (issue 571630043 by d...@gnu.org)

[torsten . haemmerle]

Pls see my comment about a patch introducing full quarter tone support
for all the languages - including a complete and consistent MusicXML
import language support.

I've asked on dev list about introducing català and português as
"official" consistent proper language names.
It's already included in the patch, but if people think it should stay
as it is, I'll remove the new names.

Thanks,
Torsten


https://codereview.appspot.com/571630043/

Re: musicxml2ly: portugues notenames and quarternotes in español (issue 571630043 by d...@gnu.org)

[torsten . haemmerle]

On 2020/02/15 16:58:45, hanwenn wrote:
>
https://codereview.appspot.com/571630043/diff/561450045/python/musicexp.py
> File python/musicexp.py (right):
> 
>
https://codereview.appspot.com/571630043/diff/561450045/python/musicexp.py#newcode364
> python/musicexp.py:364: function_dict = {
> I meant something like
> 
>   # this map should be synchronized with scm/define-note-names.scm

Hello,

I'd propose to leave it as it is for this patch.
But apart from that, I also dislike LilyPond's inconsistent language
naming conventions.

I've prepared a patch finally introducing full quarter tone support for
all languages and this also includes a complete set of fully tested
MusicMXL pitch import rules. And it's about proper language spelling
introducing català and português.

I've dropped a mail in the dev list asking for opinions about consistent
language naming conventions.
In any case, I'll wait with my patch until this one has been pushed.


All the best,
Torsten

https://codereview.appspot.com/571630043/

Re: musicxml2ly: portugues notenames and quarternotes in español (issue 571630043 by d...@gnu.org)

[hanwenn]

https://codereview.appspot.com/571630043/diff/561450045/python/musicexp.py
File python/musicexp.py (right):

https://codereview.appspot.com/571630043/diff/561450045/python/musicexp.py#newcode364
python/musicexp.py:364: function_dict = {
I meant something like

  # this map should be synchronized with scm/define-note-names.scm

https://codereview.appspot.com/571630043/

Re: musicxml2ly: portugues notenames and quarternotes in español (issue 571630043 by d...@gnu.org)

[hanwenn]

https://codereview.appspot.com/571630043/diff/567240043/python/musicexp.py
File python/musicexp.py (right):

https://codereview.appspot.com/571630043/diff/567240043/python/musicexp.py#newcode375
python/musicexp.py:375: "portugues": pitch_portugues,
On 2020/02/15 12:29:01, dak wrote:
> On 2020/02/15 12:19:54, hanwenn wrote:
> > português
> 
> I don't think it makes sense to use anything here that doesn't match
the
> notename language defined in scm/define-note-names.scm .  There is not
even an
> alias português there.

add this as a coment to the map.

https://codereview.appspot.com/571630043/

Re: musicxml2ly: portugues notenames and quarternotes in español (issue 571630043 by d...@gnu.org)

[dak]

Reviewers: hanwenn,


https://codereview.appspot.com/571630043/diff/567240043/python/musicexp.py
File python/musicexp.py (right):

https://codereview.appspot.com/571630043/diff/567240043/python/musicexp.py#newcode375
python/musicexp.py:375: "portugues": pitch_portugues,
On 2020/02/15 12:19:54, hanwenn wrote:
> português

I don't think it makes sense to use anything here that doesn't match the
notename language defined in scm/define-note-names.scm .  There is not
even an alias português there.

Description:
musicxml2ly: portugues notenames and quarternotes in español

Given by Torsten Hämmerle after issue 5746 ended.

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

Affected files (+7, -2 lines):
  M python/musicexp.py


Index: python/musicexp.py
diff --git a/python/musicexp.py b/python/musicexp.py
index 
8e3bde379312f570d79ba12b7ec7692eec6764f9..d6d5b6fa56e32cbda1fadc09c51e50ed9035c606
 100644
--- a/python/musicexp.py
+++ b/python/musicexp.py
@@ -348,8 +348,12 @@ def pitch_francais (pitch):
 return str
 
 def pitch_espanol (pitch):
-str = pitch_generic (pitch, ['do', 're', 'mi', 'fa', 'sol', 'la', 'si'], 
['b', None, None, 's'])
-return str
+str = pitch_generic (pitch, ['do', 're', 'mi', 'fa', 'sol', 'la', 'si'], 
['b', 'cb', 'cs', 's'])
+return str.replace ('bc', 'tc').replace ('sc', 'tc')
+
+def pitch_portugues (pitch):
+str = pitch_generic (pitch, ['do', 're', 'mi', 'fa', 'sol', 'la', 'si'], 
['b', 'bqt', 'sqt', 's'])
+return str.replace ('bbqt', 'btqt').replace ('ssqt', 'stqt')
 
 def pitch_vlaams (pitch):
 str = pitch_generic (pitch, ['do', 're', 'mi', 'fa', 'sol', 'la', 'si'], 
['b', None, None, 'k'])
@@ -368,6 +372,7 @@ def set_pitch_language (language):
 "catalan": pitch_catalan,
 "espanol": pitch_espanol,
 "español": pitch_espanol,
+"portugues": pitch_portugues,
 "vlaams": pitch_vlaams}
 pitch_generating_function = function_dict.get (language, pitch_general)
 

Re: musicxml2ly: handle hidden time signatures; support text+bpm \tempo marks. (issue 344000043 by a.mylt...@gmail.com)

[pkxgnugitcl]

On 2018/06/13 14:38:23, lilypond-pkx wrote:

On 2018/06/04 10:51:25, a.myltsev wrote:
> Removed the 'test' commits, leaving only changes to Python files.



Patch counted down - please push. Alex if you do not have commit

access can you

attach a git-formatted patch (re-based against current master) and I

can push it

for you - attach it to the tracker, I will see it -
https://sourceforge.net/p/testlilyissues/issues/5333/


author  Alexander Myltsev 
Wed, 27 Apr 2016 16:04:43 +0100 (18:04 +0300)
committer   James Lowe 
Sat, 16 Jun 2018 10:58:59 +0100 (10:58 +0100)
commit  d751f5fd70d1c4de9878dceb81bda42e9a500fb7

author  Alexander Myltsev 
Thu, 2 Jun 2016 09:19:07 +0100 (11:19 +0300)
committer   James Lowe 
Sat, 16 Jun 2018 10:59:08 +0100 (10:59 +0100)
commit  7b07440da921d979ab492fd284b6198152a8020c

Many thanks Alexander.

https://codereview.appspot.com/34443/

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

Re: musicxml2ly: handle hidden time signatures; support text+bpm \tempo marks. (issue 344000043 by a.mylt...@gmail.com)

[pkxgnugitcl]

On 2018/06/04 10:51:25, a.myltsev wrote:

Removed the 'test' commits, leaving only changes to Python files.


Patch counted down - please push. Alex if you do not have commit access
can you attach a git-formatted patch (re-based against current master)
and I can push it for you - attach it to the tracker, I will see it -
https://sourceforge.net/p/testlilyissues/issues/5333/

https://codereview.appspot.com/34443/

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

Re: musicxml2ly: handle hidden time signatures; support text+bpm \tempo marks. (issue 344000043 by a.mylt...@gmail.com)

[pkxgnugitcl]

On 2018/06/01 20:12:25, a.myltsev wrote:

> What are the scripts these 'test' dirs?



Those are actual tests for the added functionality, runnable with

`pytest`.


> Was this a mistake?



No, I believe that these tests are individually useful, even though

not yet

integrated into the Lilypond testing system. If you prefer, though, I

can leave

them out.


Yes if you wouldn't mind, that would be better I think.

We should only be testing 'a patch' that has components that are 'push
ready' (so  to speak).

If you want to add some more 'tests' then I suggest the best way would
be to create a new tracker for them that you can start a discussion
separate from the other work you have done.

However, if these tests are integral to this work and you intend to
eventually integrate them with the other work in this patch then that is
fine too, but it wasn't clear to me.

I'll wait to see what you want to do.

Thanks for your understanding.



https://codereview.appspot.com/34443/

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

Re: musicxml2ly: handle hidden time signatures; support text+bpm \tempo marks. (issue 344000043 by a.mylt...@gmail.com)

[a . myltsev]

What are the scripts these 'test' dirs?


Those are actual tests for the added functionality, runnable with
`pytest`.


Was this a mistake?


No, I believe that these tests are individually useful, even though not
yet integrated into the Lilypond testing system. If you prefer, though,
I can leave them out.

https://codereview.appspot.com/34443/

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

Re: musicxml2ly: handle hidden time signatures; support text+bpm \tempo marks. (issue 344000043 by a.mylt...@gmail.com)

[pkxgnugitcl]

On 2018/06/01 11:50:31, a.myltsev wrote:

musicxml2ly: hidden timesigs and tempo marks with text.


What are the scripts these 'test' dirs?

Was this a mistake?

If so can you re-submit the patch please?

thanks

James

https://codereview.appspot.com/34443/

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

Re: Musicxml2ly: Fix incorrect conversion of Minor Chords (issue 305700043 by pkx1...@gmail.com)

[David Kastrup]

David Nalesnik  writes:

> On Wed, Oct 12, 2016 at 5:52 AM, David Kastrup  wrote:
>
>> Bonus points for recognizing the fragment...
>
> Toccata and Fugue in D minor, BWV 565?

Ah, I should have removed the treble staff altogether so that you'd have
been forced to decipher the accordion chord notation in the left hand.

The chord progression in the right hand is probably characteristic
enough on its own, at least when adding the non-chord bass notes.

I've not actually played this adaption by Anzaghi for standard bass
since I have acquired an instrument with free bass manual since then.
So there is no real point in not playing the organ version mostly.

But the score has nevertheless been useful occasionally as a reference
for particular notational elements.

-- 
David Kastrup

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

Re: Musicxml2ly: Fix incorrect conversion of Minor Chords (issue 305700043 by pkx1...@gmail.com)

[David Nalesnik]

On Wed, Oct 12, 2016 at 5:52 AM, David Kastrup  wrote:

> Bonus points for recognizing the fragment...

Toccata and Fugue in D minor, BWV 565?

DN

P.S. Sorry, nothing apropos the main topic!

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

Re: Musicxml2ly: Fix incorrect conversion of Minor Chords (issue 305700043 by pkx1...@gmail.com)

[David Kastrup]

Johan Vromans  writes:

>> > The bottom line is: What is required in chord c:blah so that .NN can  
>> > be added as a pure addition. It is unfortunate that c:.13 is invalid  
>> > syntax.
>
> Since MusicXML additions are pure additions, would it be safe to turn these
> into (addNN)?
>
> E.g. C + 13 => c:(add13)

Uh, we don't have syntax like that as _input_ syntax?  You mean, allow
c:add13 here?

> Even though that will turn a friendly C13 (user input) via C + 7 + 9 + 11 +
> 13 (MusicXML) into an ugly c:(add7)(add9)(add11)(add13) (LilyPond)...
>
> Otherwise, I'd go for the origional idea of parsing for a preceding digit,
> optionally followed by '+' or '-' (if that would cover all).

Frankly, the .xxx syntax essentially already means "add".  I happen to
be partial to creating a "major" modifier.

Here is how the Italian accordionists do it:


Bonus points for recognizing the fragment...

Here is a somewhat expansive description:


>From the various notations, I find that "M" does fit LilyPond's existing
schemes best as a "major" modifier.

I am not convinced at how the following are rendered.  Particularly c:m5
seems nonsensical, but I'm not too enthusiastic about the others either.

\chordmode { c:dim5 c:m5 c:5 c:maj5 }

Maybe just kill the special effect of "5" whenever it is not first?
There is also the possibility of "whenever it is not alone", but I am
less convinced about what that would do to c:5.6 and similar.

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

Re: Musicxml2ly: Fix incorrect conversion of Minor Chords (issue 305700043 by pkx1...@gmail.com)

[Johan Vromans]

> > The bottom line is: What is required in chord c:blah so that .NN can  
> > be added as a pure addition. It is unfortunate that c:.13 is invalid  
> > syntax.

Since MusicXML additions are pure additions, would it be safe to turn these
into (addNN)?

E.g. C + 13 => c:(add13)

Even though that will turn a friendly C13 (user input) via C + 7 + 9 + 11 +
13 (MusicXML) into an ugly c:(add7)(add9)(add11)(add13) (LilyPond)...

Otherwise, I'd go for the origional idea of parsing for a preceding digit,
optionally followed by '+' or '-' (if that would cover all).

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

Re: Musicxml2ly: Fix incorrect conversion of Minor Chords (issue 305700043 by pkx1...@gmail.com)

[dak]

On 2016/10/07 17:31:40, jvromans_squirrel.nl wrote:


While we're at it: A couple of lines later (line 1617):



 if self.bass:
 value += "/+%s" % self.bass.ly_expression ()



AFAIK, a bass note is written as /c, not /+c.


An inversion is written as /c but an additional bass note is /+c .  See
the manual for more information.

https://codereview.appspot.com/305700043/

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

Re: Musicxml2ly: Fix incorrect conversion of Minor Chords (issue 305700043 by pkx1...@gmail.com)

[pkx166h]

On 2016/10/07 17:31:40, jvromans_squirrel.nl wrote:

On Fri, 07 Oct 2016 07:45:53 -0700
mailto:d...@gnu.org wrote:



> https://codereview.appspot.com/305700043/diff/1/python/musicexp.py
> File python/musicexp.py (right):
>
>


https://codereview.appspot.com/305700043/diff/1/python/musicexp.py#newcode1608

> python/musicexp.py:1608: # digit. If none, omit the ".".
> I think this behavior is wrong since the first digit is _not_ a mere
> addition but determines the "stacking height" of the preceding

chord.

> See, for example, the output of
>
> \chordmode { c:dim3.5.13 c:dim13 }
>
> for the difference.



Yes, that's right.



Cdim13 (in MuseScore) becomes MusicXML C + dim7 + 9 + 11 + 13.



Cdim(add13) becomes C + dim + 13. This would then be translated to

Cdim13.


> The pattern \d$ also is not sufficient since it
> does not cover 5- (for example).  Maybe something like r':.*?\d'

would

> do the trick?



The bottom line is: What is required in chord c:blah so that .NN can

be

added as a pure addition. It is unfortunate that c:.13 is invalid

syntax.


While we're at it: A couple of lines later (line 1617):



 if self.bass:
 value += "/+%s" % self.bass.ly_expression ()



AFAIK, a bass note is written as /c, not /+c.



Thanks for chiming in!



-- Johan

Johan,

Does this mean you are going to provide a new patch or something else?

James


https://codereview.appspot.com/305700043/

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

Re: Musicxml2ly: Fix incorrect conversion of Minor Chords (issue 305700043 by pkx1...@gmail.com)

[Johan Vromans]

On Fri, 07 Oct 2016 07:45:53 -0700
d...@gnu.org wrote:

> https://codereview.appspot.com/305700043/diff/1/python/musicexp.py
> File python/musicexp.py (right):
> 
> https://codereview.appspot.com/305700043/diff/1/python/musicexp.py#newcode1608
> python/musicexp.py:1608: # digit. If none, omit the ".".
> I think this behavior is wrong since the first digit is _not_ a mere
> addition but determines the "stacking height" of the preceding chord.
> See, for example, the output of
> 
> \chordmode { c:dim3.5.13 c:dim13 }
> 
> for the difference.

Yes, that's right.

Cdim13 (in MuseScore) becomes MusicXML C + dim7 + 9 + 11 + 13.

Cdim(add13) becomes C + dim + 13. This would then be translated to Cdim13.

> The pattern \d$ also is not sufficient since it
> does not cover 5- (for example).  Maybe something like r':.*?\d' would
> do the trick?

The bottom line is: What is required in chord c:blah so that .NN can be
added as a pure addition. It is unfortunate that c:.13 is invalid syntax.

While we're at it: A couple of lines later (line 1617):

if self.bass:
value += "/+%s" % self.bass.ly_expression ()

AFAIK, a bass note is written as /c, not /+c.

Thanks for chiming in!

-- Johan

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

Re: Musicxml2ly: Fix incorrect conversion of Minor Chords (issue 305700043 by pkx1...@gmail.com)

[dak]

https://codereview.appspot.com/305700043/diff/1/python/musicexp.py
File python/musicexp.py (right):

https://codereview.appspot.com/305700043/diff/1/python/musicexp.py#newcode1608
python/musicexp.py:1608: # digit. If none, omit the ".".
I think this behavior is wrong since the first digit is _not_ a mere
addition but determines the "stacking height" of the preceding chord.
See, for example, the output of

\chordmode { c:dim3.5.13 c:dim13 }

for the difference.  So for better or worse, if we don't have a digit in
the chord so far, we need to add 3.5. before other additions rather than
omitting . altogether.  The pattern \d$ also is not sufficient since it
does not cover 5- (for example).  Maybe something like r':.*?\d' would
do the trick?  That's a digit anywhere after : .

https://codereview.appspot.com/305700043/

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

Re: musicxml2ly tremolo tag on notes shorter than quarter

[Martin Tarenskeen]

On Tue, 12 May 2015, pls wrote:


For example what happened with the Philomenos musixcml2ly-dev fork?



Yes, Philomelos is still alive and I’m about to update the musicxml2ly-dev 
Github repo.  Over at least three years I have written almost 100 bug
reports  and many test cases for Philomelos and I will try to publish them as 
well.  We have fixed quite a few of these bugs.  I just implemented
a solution to the tremolo bug reported here.


Sound promising!

Allow to me to do a drastic suggestion. Wouldn't it be much simpler to 
replace the current musicxml2ly from the official LilyPond development 
tree with the one from Philomenos entirely and allow the Philomenos guy(s) 
to continue the work there, if he/they wants to?


I never quite understood why this fork was needed. And if the Philomenos 
version is the only one that has been actively developed since a few years 
now I don't see why not everyone who installs the official LilyPond should 
not have the latest and greatest musicxml2ly tool without extra effort?


--

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

Re: musicxml2ly output indentation style

[Martin Tarenskeen]

On Sat, 16 Nov 2013, Peter Bjuhr wrote:


On 11/14/2013 09:16 AM, Martin Tarenskeen wrote:


Hi,

The lilypond output that is produced from musicxml2ly uses another 
indentation style than I see in my own scores when using for example Vim or 
Frescobaldi, or in all examples in the Lilypond documentation.



Hi Martin!

Thanks for pointing this out! In the latest development version of 
Frescobaldi scores imported through internal musicXML import are now 
reformatted (the same way as if Tools-Format were used).


I did a short try with the dev version from Github (downloaded zip there) 
but I see no difference. Still had to use Tools-Format manually.


But even if it works, it would still be a workaround instead of a real 
fix.


--

MT



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

Re: musicxml2ly output indentation style

[Peter Bjuhr]

On 11/17/2013 07:02 PM, Martin Tarenskeen wrote:


I did a short try with the dev version from Github (downloaded zip 
there) but I see no difference. Still had to use Tools-Format manually.


Sorry for a stupid question, but did you install after download?



But even if it works, it would still be a workaround instead of a real 
fix.




Agreed, as also Urs pointed out.

Best
Peter

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

Re: musicxml2ly output indentation style

[Urs Liska]

Peter Bjuhr peterbj...@gmail.com schrieb:

On 11/14/2013 09:16 AM, Martin Tarenskeen wrote:

 Hi,

 The lilypond output that is produced from musicxml2ly uses another 
 indentation style than I see in my own scores when using for example 
 Vim or Frescobaldi, or in all examples in the Lilypond documentation.

 for example:

 %commonly used style
 music = \relative c' {
   a b c d
 }

 %musicxml2ly style
 music = \relative c' {
   a b c d
   }


Hi Martin!

Thanks for pointing this out! In the latest development version of 
Frescobaldi scores imported through internal musicXML import are now 
reformatted (the same way as if Tools-Format were used).

... which of course doesn't mean that this issue couldn't/shouldn't be fixed 
right in musicxml2ly.

Urs

Best
Peter


___
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: musicxml2ly output indentation style

[Peter Bjuhr]

On 11/14/2013 09:16 AM, Martin Tarenskeen wrote:


Hi,

The lilypond output that is produced from musicxml2ly uses another 
indentation style than I see in my own scores when using for example 
Vim or Frescobaldi, or in all examples in the Lilypond documentation.


for example:

%commonly used style
music = \relative c' {
  a b c d
}

%musicxml2ly style
music = \relative c' {
  a b c d
  }



Hi Martin!

Thanks for pointing this out! In the latest development version of 
Frescobaldi scores imported through internal musicXML import are now 
reformatted (the same way as if Tools-Format were used).


Best
Peter


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

Re: musicxml2ly

[Martin Tarenskeen]

On Sun, 8 Apr 2012, Martin Tarenskeen wrote:

The good news is that in many cases only a little editing of the .ly file 
is required to turn a bad conversion into a good one. For example, all 
lead sheets from Wikifonia that I have tried have the Chords printed below 
instead of above the staff.


I remember this had been fixed in one of the previous lilypond 2.15.x 
versions, but with musicxml2ly from Lilypond 2.15.37 I am still (again?) 
having this problem.


Same with 2.15.38


Hi,

I did not see a reaction to this question, so I try again. What happened 
with this musicxml2ly bug ? First chords were printed below the staff, 
then I think it was fixed, and now the chords are below the staff again. 
Regression?


--

MT

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

Re: musicxml2ly

[Graham Percival]

On Wed, May 16, 2012 at 09:33:09AM +0200, Martin Tarenskeen wrote:
 
 I did not see a reaction to this question, so I try again. What
 happened with this musicxml2ly bug ? First chords were printed below
 the staff, then I think it was fixed, and now the chords are below
 the staff again. Regression?

Report bugs to the bugs mailing list, not the user or devel lists.

- Graham

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

Re: musicxml2ly

[Colin Hall]

On Wed, May 16, 2012 at 09:33:09AM +0200, Martin Tarenskeen wrote:
 The good news is that in many cases only a little editing of
 the .ly file is required to turn a bad conversion into a good
 one. For example, all lead sheets from Wikifonia that I have
 tried have the Chords printed below instead of above the
 staff.
 
 I remember this had been fixed in one of the previous lilypond
 2.15.x versions, but with musicxml2ly from Lilypond 2.15.37 I am
 still (again?) having this problem.
 
 Same with 2.15.38
 
 I did not see a reaction to this question, so I try again. What
 happened with this musicxml2ly bug ? First chords were printed below
 the staff, then I think it was fixed, and now the chords are below
 the staff again. Regression?

That must be very frustrating for you. Sorry that I can't help you, as
I'm not familiar with musicxml2ly. It appears to be central to
Patrick's project so I would imagine he or his colleagues are working
hard on this.

http://www.philomelos.net/en/about

There are a number of issue trackers relating to musicxml2ly but I see
no issue tracker for this bug, Martin.

I'd like to at least record the bug. We can create a tracker if you
supply these details:

1. A version of lilypond/musicxml2ly and a specific lead sheet from Wikifonia
   in MusicXML format that together exhibit the bug.

2. A version of lilypond/musicxml2ly from the 2.15.x series which does not 
exhibit the bug.

Cheers,
Colin.

-- 

Colin Hall

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

Re: musicxml2ly

[pls]

It's not a regression. It has never been officially fixed. A while ago I posted 
a bug report and a minimal example: 
http://old.nabble.com/musicxml2ly%3A-chordnames-placement-bug-td33309393.html.

Here is a solution for the chord symbol bug: 
http://codereview.appspot.com/5697059/. I still haven't found the time to tidy 
up the patch. But it works!
Am 16.05.2012 um 10:18 schrieb Colin Hall:

 On Wed, May 16, 2012 at 09:33:09AM +0200, Martin Tarenskeen wrote:
 The good news is that in many cases only a little editing of
 the .ly file is required to turn a bad conversion into a good
 one. For example, all lead sheets from Wikifonia that I have
 tried have the Chords printed below instead of above the
 staff.
 
 I remember this had been fixed in one of the previous lilypond
 2.15.x versions, but with musicxml2ly from Lilypond 2.15.37 I am
 still (again?) having this problem.
 
 Same with 2.15.38
 
 I did not see a reaction to this question, so I try again. What
 happened with this musicxml2ly bug ? First chords were printed below
 the staff, then I think it was fixed, and now the chords are below
 the staff again. Regression?
 
 That must be very frustrating for you. Sorry that I can't help you, as
 I'm not familiar with musicxml2ly. It appears to be central to
 Patrick's project so I would imagine he or his colleagues are working
 hard on this.
 
 http://www.philomelos.net/en/about
 
 There are a number of issue trackers relating to musicxml2ly but I see
 no issue tracker for this bug, Martin.
 
 I'd like to at least record the bug. We can create a tracker if you
 supply these details:
 
 1. A version of lilypond/musicxml2ly and a specific lead sheet from Wikifonia
   in MusicXML format that together exhibit the bug.
 
 2. A version of lilypond/musicxml2ly from the 2.15.x series which does not 
 exhibit the bug.
 
 Cheers,
 Colin.
 
 -- 
 
 Colin Hall
 
 ___
 bug-lilypond mailing list
 bug-lilyp...@gnu.org
 https://lists.gnu.org/mailman/listinfo/bug-lilypond


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

Re: musicxml2ly

[Colin Hall]

On Wed, May 16, 2012 at 10:42:09AM +0200, pls wrote:
 It's not a regression. It has never been officially fixed. A while
 ago I posted a bug report and a minimal example:
 http://old.nabble.com/musicxml2ly%3A-chordnames-placement-bug-td33309393.html.

 Here is a solution for the chord symbol bug:
 http://codereview.appspot.com/5697059/. I still haven't found the
 time to tidy up the patch. But it works!

Thanks, Patrick. I'm going to move this conversation to bug-lilypond cc Martin
and respond in full there.

Cheers,
Colin.

-- 

Colin Hall

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

Re: musicxml2ly

[Martin Tarenskeen]

On Sun, 8 Apr 2012, Martin Tarenskeen wrote:

The good news is that in many cases only a little editing of the .ly file is 
required to turn a bad conversion into a good one. For example, all lead 
sheets from Wikifonia that I have tried have the Chords printed below instead 
of above the staff.


I remember this had been fixed in one of the previous lilypond 2.15.x 
versions, but with musicxml2ly from Lilypond 2.15.37 I am still (again?) 
having this problem.


--

MT

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

Re: musicxml2ly

[James]

Hello,

On 8 April 2012 17:47, Martin Tarenskeen m.tarensk...@zonnet.nl wrote:
...
 Or are many
 problems already known?

http://code.google.com/p/lilypond/issues/list?can=2q=musicxmlsort=prioritycolspec=IDx=typey=prioritymode=gridcells=tiles

There is also this recent - seemingly unfinished patch

http://codereview.appspot.com/5697059/

And see

http://lists.gnu.org/archive/html/lilypond-devel/2011-12/msg00025.html

http://lists.gnu.org/archive/html/lilypond-user/2011-11/msg00280.html

This will give you an idea of the current issues and the effort still required.

James

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

Re: musicxml2ly

[pls]

Hi Martin,

yes, we are currently working on the musicxml2ly scripts and we have solved 
e.g. the issue concerning the chord symbols you mentioned. I haven't had time 
to work on the patch James pointed to but it works as it is. We use it on 
www.philomelos.net. Philomelos is a new community site for free and editable 
sheet music. The private beta version includes the ability to read and share 
MusicXML files that are displayed online using LilyPond technology. If someone 
wants to be invited: drop me a line offlist.

We will share all improvements on musicxml2ly but we could also need some help! 
We are planning to add a blog/wiki to our website so that philomelos can be 
used to test MusicXML files and to share music sheets and knowledge concerning 
MusicXML, conversions between musical notation codes...

Cheers,
patrick
Am 08.04.2012 um 19:13 schrieb James:

 Hello,
 
 On 8 April 2012 17:47, Martin Tarenskeen m.tarensk...@zonnet.nl wrote:
 ...
 Or are many
 problems already known?
 
 http://code.google.com/p/lilypond/issues/list?can=2q=musicxmlsort=prioritycolspec=IDx=typey=prioritymode=gridcells=tiles
 
 There is also this recent - seemingly unfinished patch
 
 http://codereview.appspot.com/5697059/
 
 And see
 
 http://lists.gnu.org/archive/html/lilypond-devel/2011-12/msg00025.html
 
 http://lists.gnu.org/archive/html/lilypond-user/2011-11/msg00280.html
 
 This will give you an idea of the current issues and the effort still 
 required.
 
 James
 
 ___
 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: musicxml2ly

[Reinhold Kainhofer]

On 2012-04-08 20:15, pls wrote:
yes, we are currently working on the musicxml2ly scripts and we have 
solved e.g. the issue concerning the chord symbols you mentioned. I 
haven't had time to work on the patch James pointed to but it works as 
it is. We use it on www.philomelos.net http://www.philomelos.net. 
Philomelos is a new community site for free and editable sheet music. 
The private beta version includes the ability to read and share 
MusicXML files that are displayed online using LilyPond technology. If 
someone wants to be invited: drop me a line offlist.


We will share all improvements on musicxml2ly but we could also need 
some help! We are planning to add a blog/wiki to our website so that 
philomelos can be used to test MusicXML files and to share music 
sheets and knowledge concerning MusicXML, conversions between musical 
notation codes...


I was the last one to extensively work on musicxml2ly, so if you have 
any questions, drop me a mail. I must add, though, that I have beeen 
really busy the last few weeks and I'm not sure if this will change in 
the near future, so expect some days of response time.


Cheers,
Reinhold

--
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
 * Financial  Actuarial Math., Vienna Univ. of Technology, Austria
 * http://www.fam.tuwien.ac.at/, DVR: 0005886
 * LilyPond, Music typesetting, http://www.lilypond.org

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

Re: musicxml2ly: title and subtitle (issue 1913), miscellaneous (issue 5096050)

[Janek Warchoł]

2012/1/16 pls p.l.schm...@gmx.de:
 BTW: http://codereview.appspot.com/5303063/ is still open and hasn't been 
 pushed.

Oops!  Looks like this patch slipped through the cracks because it
wasn't mentioned in tracker issue 1985.  I'm adding it now, it should
be checked soon.

thanks,
Janek

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

Re: musicxml2ly: title and subtitle (issue 1913), miscellaneous (issue 5096050)

[pls]

Hi Janek,

done!

Thanks
patrick

BTW: http://codereview.appspot.com/5303063/ is still open and hasn't been 
pushed.
Am 16.01.2012 um 00:07 schrieb Janek Warchoł:

 Hi Patrick,
 
 your patch was pushed when i was absent; now i see that Rietveld issue
 is still opened.  Could you close it please?
 
 http://codereview.appspot.com/5096050/
 
 Janek
 
 ___
 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

Re: musicxml2ly: title and subtitle (issue 1913), miscellaneous (issue 5096050)

[Janek Warchoł]

Hi Patrick,

your patch was pushed when i was absent; now i see that Rietveld issue
is still opened.  Could you close it please?

http://codereview.appspot.com/5096050/

Janek

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

Re: musicxml2ly: title and subtitle (issue 1913), miscellaneous (issue 5096050)

[ptrcklschmdt]

On 2011/09/25 18:30:51, janek wrote:

2011/9/25  ptrcklsch...@googlemail.com:
 Hi Janek,

 I was talking about uploading some changes of this patch to

rietveld. I

 forgot to add some bits and pieces I had announced in the

description of

 this patch to the reworked version. I would have had to adjust only

2 of

 the 3 files in the patch. That's why I asked whether it's possible

to

 upload only these 2 changed files in a new patch, but probably

not...


It is possible.



 As I'm not really experienced with git I would have to redo the

whole

 patch.



That surely won't be necessary.
In fact, it'd be undesired also from our point of view.



 I use Lilydev and git. IIRC I had some problems with lily-git the

last

 time I used it, but I will give it another try...



If you are able to use git via command line, there's no point in
switching to lily-git :)  Lily-git is only an easy tool for people
that may have trouble with command line.



So, here is what you need to know about git in your current situation.
  For clarity i'll describe how everything is done from the very
beginning:
1) work begins by cloning git repository from official server to your

Lilydev

2) make changes in files inside working directory (i.e. files that
appear inside lilypond-git)
3) make a commit: 'git commit -a'
4) update your repository: 'git pull -r'
5) upload your patch to Rietveld: 'git cl upload origin/master'
After this step the newly created Rietveld issue will show the
differencies between your local git repository (which contains your
patch, since you have committed it in step 3) and official master
repository.  There are differencies in 3 files.
This is the step you are in.
6) make the changes you forgot about to the files in working
directory, save those files
7) commit the changes: 'git commit -a -m write your commit message
inside quotation marks ' (you can also omit -m option and write
commit message in the editor that appears)
8) update your repository: 'git pull -r'
9) upload new version of the patch to Rietveld: 'git cl upload

origin/master'

What exactly does this do?  First of all, it doesn't create a new
Rietveld issue, but updates the issue that already exists (that's
good).  It sends the difference between your local git repository and
official repository.  It doesn't matter that it was done as two
commits; the Rietveld tool will look at the diff send and think there
is a difference in two files between what was previously uploaded and
the current state of things and update these two files.  We will be
able to see everything - both newest versions of these two files and
your version of the third file (which is already uploaded) - when we
go to http://codereview.appspot.com/5096050/



I hope this makes things clear.  If you have any questions, ask!
Good luck,
Janek


Thanks!

http://codereview.appspot.com/5096050/

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

Re: musicxml2ly: title and subtitle (issue 1913), miscellaneous (issue 5096050)

[janek . lilypond]

LGTM.
Thanks!


http://codereview.appspot.com/5096050/diff/20001/python/musicexp.py
File python/musicexp.py (right):

http://codereview.appspot.com/5096050/diff/20001/python/musicexp.py#newcode1510
python/musicexp.py:1510: # Print out the style if we have ome, but the
'() should only be
The typo that was fixed in the previous version of the patch is back :P

http://codereview.appspot.com/5096050/

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

Re: musicxml2ly: title and subtitle (issue 1913), miscellaneous (issue 5096050)

[pkx166h]

This also passes a completely fresh make ; make doc.

http://codereview.appspot.com/5096050/

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

Re: musicxml2ly: title and subtitle (issue 1913), miscellaneous (issue 5096050)

[Janek Warchoł]

Hi Patrick,

2011/9/24  ptrcklsch...@googlemail.com:
 I just discovered that I forgot to add the changes related to
 conversion-info and \center-column. Do I have to make a completely new
 patch containing all 3 files (musicxml2ly.py, musicxml.py and
 musicexp.py) or is it ok to upload only the files with these changes
 (i.e. musicexp.py and musicxml2ly.py)?

I'm not sure what you mean.  Are you talking about uploading changes
to Rietveld, or fixing a different issue separately from current one?

cheers,
Janek

PS are you using Lilydev and lily-git?

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

Re: musicxml2ly: title and subtitle (issue 1913), miscellaneous (issue 5096050)

[ptrcklschmdt]

On 2011/09/25 10:31:14, janek wrote:

Hi Patrick,



2011/9/24  ptrcklsch...@googlemail.com:
 I just discovered that I forgot to add the changes related to
 conversion-info and \center-column. Do I have to make a completely

new

 patch containing all 3 files (musicxml2ly.py, musicxml.py and
 musicexp.py) or is it ok to upload only the files with these changes
 (i.e. musicexp.py and musicxml2ly.py)?



I'm not sure what you mean.  Are you talking about uploading changes
to Rietveld, or fixing a different issue separately from current one?



cheers,
Janek



PS are you using Lilydev and lily-git?


Hi Janek,

I was talking about uploading some changes of this patch to rietveld. I
forgot to add some bits and pieces I had announced in the description of
this patch to the reworked version. I would have had to adjust only 2 of
the 3 files in the patch. That's why I asked whether it's possible to
upload only these 2 changed files in a new patch, but probably not... As
I'm not really experienced with git I would have to redo the whole
patch. But I think it's better to include these changes in the next
patch.

I use Lilydev and git. IIRC I had some problems with lily-git the last
time I used it, but I will give it another try...

Thanks for your help!
patrick

http://codereview.appspot.com/5096050/

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

Re: musicxml2ly: title and subtitle (issue 1913), miscellaneous (issue 5096050)

[Janek Warchoł]

2011/9/25  ptrcklsch...@googlemail.com:
 Hi Janek,

 I was talking about uploading some changes of this patch to rietveld. I
 forgot to add some bits and pieces I had announced in the description of
 this patch to the reworked version. I would have had to adjust only 2 of
 the 3 files in the patch. That's why I asked whether it's possible to
 upload only these 2 changed files in a new patch, but probably not...

It is possible.

 As I'm not really experienced with git I would have to redo the whole
 patch.

That surely won't be necessary.
In fact, it'd be undesired also from our point of view.

 I use Lilydev and git. IIRC I had some problems with lily-git the last
 time I used it, but I will give it another try...

If you are able to use git via command line, there's no point in
switching to lily-git :)  Lily-git is only an easy tool for people
that may have trouble with command line.

So, here is what you need to know about git in your current situation.
 For clarity i'll describe how everything is done from the very
beginning:
1) work begins by cloning git repository from official server to your Lilydev
2) make changes in files inside working directory (i.e. files that
appear inside lilypond-git)
3) make a commit: 'git commit -a'
4) update your repository: 'git pull -r'
5) upload your patch to Rietveld: 'git cl upload origin/master'
   After this step the newly created Rietveld issue will show the
differencies between your local git repository (which contains your
patch, since you have committed it in step 3) and official master
repository.  There are differencies in 3 files.
This is the step you are in.
6) make the changes you forgot about to the files in working
directory, save those files
7) commit the changes: 'git commit -a -m write your commit message
inside quotation marks ' (you can also omit -m option and write
commit message in the editor that appears)
8) update your repository: 'git pull -r'
9) upload new version of the patch to Rietveld: 'git cl upload origin/master'
   What exactly does this do?  First of all, it doesn't create a new
Rietveld issue, but updates the issue that already exists (that's
good).  It sends the difference between your local git repository and
official repository.  It doesn't matter that it was done as two
commits; the Rietveld tool will look at the diff send and think there
is a difference in two files between what was previously uploaded and
the current state of things and update these two files.  We will be
able to see everything - both newest versions of these two files and
your version of the third file (which is already uploaded) - when we
go to http://codereview.appspot.com/5096050/

I hope this makes things clear.  If you have any questions, ask!
Good luck,
Janek

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

Re: musicxml2ly: title and subtitle (issue 1913), miscellaneous (issue 5096050)

[ptrcklschmdt]

On 2011/09/23 15:36:15, p-l-s wrote:

Hi Reinhold and Janek,



I hope I got it right this time. I didn't include the bit about

miscellaneous.

This will be part of a seperate patch.



BTW: I noticed that the midi-block is not always inserted in every .ly

file

(this is not related to my patch). I will do some testing...



Thanks for your help!
patrick


I just discovered that I forgot to add the changes related to
conversion-info and \center-column. Do I have to make a completely new
patch containing all 3 files (musicxml2ly.py, musicxml.py and
musicexp.py) or is it ok to upload only the files with these changes
(i.e. musicexp.py and musicxml2ly.py)?

http://codereview.appspot.com/5096050/

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

Re: musicxml2ly: title and subtitle (issue 1913), miscellaneous (issue 5096050)

[pkx166h]

passes make and reg tests

http://codereview.appspot.com/5096050/

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

Re: musicxml2ly: title and subtitle (issue 1913), miscellaneous (issue 5096050)

[ptrcklschmdt]

On 2011/09/22 13:26:54, Reinhold wrote:

Welcome to the wonderful world of LilyPond development!

:)

Most changes look fine, but there are some things that can't be

submitted yet.

See my comments.



Most important: Please edit the source file in scripts/musicxml2ly.py

and don't

modify the installed musicxml2ly file and copy it over to the source

tree! In

particular, the source code contains identifiers like

@TOPLEVEL_VERSION@, which

will be replaced by the build system with proper values, so that we

don't have

to hardcode things like version or python path!



So,
-) Modify only the scripts/musicxml2ly.py and python/musicexp.py and
python/musicxml.py
-) Run make (you can kill it after a few seconds, as soon as all

python files

are processed, which happends right at the beginning)
-) You can't run scripts/musicxml2ly.py directly, but rather the built
out/bin/musicxml2ly



For the last item, on my computer,  I have created a simply wrapper

script

~/.bin/musicxml2ly (if ~/.bin is in your PATH environment variable),

which

contains only:



reinhold@curie:~$ cat .bin/musicxml2ly
#!/bin/sh
exec ~/lilypond/lilypond/out/bin/musicxml2ly $@



You can then simply call musicxml2ly, and the built musicxml2ly will

be called.

OK, I basically use the same method, but the make-trick was new to me.
I obviously modified the program files directly in the build directory
and copied them to the source tree because 'git status' couldn't find
any modified files.

http://codereview.appspot.com/5096050/diff/1/python/musicexp.py
File python/musicexp.py (right):



http://codereview.appspot.com/5096050/diff/1/python/musicexp.py#newcode63

python/musicexp.py:63: self.print_verbatim ('\\version 2.15.13')
On 2011/09/22 12:50:43, janek wrote:
 Isn't this a mistake?



I suppose it is a mistake. The source should contain

@TOPLEVEL_VERSION@, which

will be replaced by the current version by make.



http://codereview.appspot.com/5096050/diff/1/python/musicexp.py#newcode283

python/musicexp.py:283: return False
These functions should not be placed here. The pitch language

functions are

here, because the Pitch class is next. The midi functions don't belong

here.

OK

http://codereview.appspot.com/5096050/diff/1/python/musicxml.py
File python/musicxml.py (right):



http://codereview.appspot.com/5096050/diff/1/python/musicxml.py#newcode252

python/musicxml.py:252: return None
Please don't exactly duplicate get_file_description!



A much cleaner solution would be to rename get_file_description to
get_miscellaneous and return a hash of all miscellaneous fields (note

that the

'name' attribute is REQUIRED in the MusicXML specification)...



Something like:
def get_miscellaneous (self):
 misc = self.get_named_children ('miscellaneous')
 ret = []
 for m in misc:
 misc_fields = m.get_named_children ('miscellaneous-field')
 for mf in misc_fields:
 if hasattr (mf, 'name'):
 ret[mf.name] = mf.get_text ()
 else:
 // Print a warning here...
 return ret



Instead of the if hasattr you can also use mf.get('name', '').



Of course, you'll have to adjust musicxml2ly.py, too. But at least

this solution

is more general, and the logic to abuse a description  misc field

for the

texidoc is implemented in the main file, not in a library file.


Hm, I didn't understand all of this. What do I have to change in
musicxml2ly? My idea was to use the description misc field for a
custom header variable named 'miscellaneous' by default. I was thinking
about implementing a cmd line option ('-t' and '--texinfo') to be able
to use the 'texinfo' variable when needed. But if at all this should be
implemented in a different patch...

http://codereview.appspot.com/5096050/diff/1/scripts/musicxml2ly.py
File scripts/musicxml2ly.py (right):



http://codereview.appspot.com/5096050/diff/1/scripts/musicxml2ly.py#newcode1

scripts/musicxml2ly.py:1: #!/usr/bin/python
Please don't modify  the compiled musicxml2ly and copy it to the

source tree.

Rather modify the scripts/musicxml2ly.py in the source tree and call

make. To

run it, simply call out/bin/musicxml2ly.



The source code MUST have the @TARGET_PYTHON@, @relocate-preamble@,

etc.


http://codereview.appspot.com/5096050/diff/1/scripts/musicxml2ly.py#newcode33

scripts/musicxml2ly.py:33: 
Same as above: Needs to be @relocate-preamble@ in the code!



http://codereview.appspot.com/5096050/diff/1/scripts/musicxml2ly.py#newcode210

scripts/musicxml2ly.py:210: set_if_exists ('subtitle',

movement_title.get_text

())
else  is missing (if there is no work, then no title will be set at

all, even

if movement_title exists). I would structure the if as follows

(pseudocode):


if work:
 'title' = work_title
 if movement_title:
 'subtitle' = movement_title
elif movement_title:
 'title' = movement_title


OK

http://codereview.appspot.com/5096050/diff/1/scripts/musicxml2ly.py#newcode221

Re: musicxml2ly: title and subtitle (issue 1913), miscellaneous (issue 5096050)

[reinhold . kainhofer]

Hm, I didn't understand all of this. What do I have to change in

musicxml2ly? My

idea was to use the description misc field for a custom header

variable named

'miscellaneous' by default. I was thinking about implementing a cmd

line option

('-t' and '--texinfo') to be able to use the 'texinfo' variable when

needed. But

if at all this should be implemented in a different patch...


My suggestion is more general: It copies every miscellaneous-field to
the lilypond file as a header variable with the same name. This way,
nothing gets lost from the MusicXML file. And the 'description' fields
is duplicated as 'texidoc', too.
I don't think we need a --texinfo cmd line option, see my comment below.


http://codereview.appspot.com/5096050/diff/1/python/musicxml.py
File python/musicxml.py (right):

http://codereview.appspot.com/5096050/diff/1/python/musicxml.py#newcode252
python/musicxml.py:252: return None
On 2011/09/22 13:26:54, Reinhold wrote:

Of course, you'll have to adjust musicxml2ly.py, too.


I already gave you the spot where you would have to modify it. I'll add
some pseudocode there to make it clearer what I envisioned...

http://codereview.appspot.com/5096050/diff/1/scripts/musicxml2ly.py
File scripts/musicxml2ly.py (right):

http://codereview.appspot.com/5096050/diff/1/scripts/musicxml2ly.py#newcode231
scripts/musicxml2ly.py:231: #set_if_exists ('miscellaneous',
ids.get_miscellaneous ());
On 2011/09/22 13:26:54, Reinhold wrote:

If you change get_miscellaneous to a hash, you can extract the

'description'

here for the texidoc, and loop through all fields to insert custom

header fields

for them.


What I'm thinking of is something like:

misc = ids.get_miscellaneous (); # This is a hash with fieldname -
value
for i in misc.keys ():
# Create a header variable for each miscellaneous-field:
set_if_exists (i, misc[i]);
if (i == 'description'):
set_if_exists ('texidoc', misc[i]);

This will create a header variable for each miscellaneous-field, plus
one texidoc header variable for the description. I don't think we need a
cmd line argument to switch on/off texidoc creation. If someone really
uses a miscellaneous-field with 'description' type for a MusicXML file
that is not part of our regtest suite, it still doesn't hurt to have one
more header variable. The user won't need it, but it also doesn't cause
any problems.

http://codereview.appspot.com/5096050/

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

Re: musicxml2ly: title and subtitle (issue 1913), miscellaneous (issue 5096050)

[ptrcklschmdt]

Hi Reinhold and Janek,

I hope I got it right this time. I didn't include the bit about
miscellaneous. This will be part of a seperate patch.

BTW: I noticed that the midi-block is not always inserted in every .ly
file (this is not related to my patch). I will do some testing...

Thanks for your help!
patrick

http://codereview.appspot.com/5096050/

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

Re: musicxml2ly: title and subtitle (issue 1913), miscellaneous (issue 5096050)

[janek . lilypond]

Some concerns and a handful of questions (as usual in my case).


http://codereview.appspot.com/5096050/diff/1/python/musicexp.py
File python/musicexp.py (right):

http://codereview.appspot.com/5096050/diff/1/python/musicexp.py#newcode63
python/musicexp.py:63: self.print_verbatim ('\\version 2.15.13')
Isn't this a mistake?
If not, can it not be hardcoded?

http://codereview.appspot.com/5096050/diff/1/python/musicexp.py#newcode283
python/musicexp.py:283: return False
Can you add a comment saying what does this do?
I'd appreciate it, because i don't know :)

http://codereview.appspot.com/5096050/diff/1/python/musicxml.py
File python/musicxml.py (right):

http://codereview.appspot.com/5096050/diff/1/python/musicxml.py#newcode176
python/musicxml.py:176: for r in source:
What does this do?
Can you add a comment explaining this?

http://codereview.appspot.com/5096050/

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

Re: musicxml2ly: title and subtitle (issue 1913), miscellaneous (issue 5096050)

[reinhold . kainhofer]

Welcome to the wonderful world of LilyPond development!
Most changes look fine, but there are some things that can't be
submitted yet. See my comments.

Most important: Please edit the source file in scripts/musicxml2ly.py
and don't modify the installed musicxml2ly file and copy it over to the
source tree! In particular, the source code contains identifiers like
@TOPLEVEL_VERSION@, which will be replaced by the build system with
proper values, so that we don't have to hardcode things like version or
python path!

So,
-) Modify only the scripts/musicxml2ly.py and python/musicexp.py and
python/musicxml.py
-) Run make (you can kill it after a few seconds, as soon as all python
files are processed, which happends right at the beginning)
-) You can't run scripts/musicxml2ly.py directly, but rather the built
out/bin/musicxml2ly

For the last item, on my computer,  I have created a simply wrapper
script ~/.bin/musicxml2ly (if ~/.bin is in your PATH environment
variable), which contains only:

reinhold@curie:~$ cat .bin/musicxml2ly
#!/bin/sh
exec ~/lilypond/lilypond/out/bin/musicxml2ly $@

You can then simply call musicxml2ly, and the built musicxml2ly will be
called.



http://codereview.appspot.com/5096050/diff/1/python/musicexp.py
File python/musicexp.py (right):

http://codereview.appspot.com/5096050/diff/1/python/musicexp.py#newcode63
python/musicexp.py:63: self.print_verbatim ('\\version 2.15.13')
On 2011/09/22 12:50:43, janek wrote:

Isn't this a mistake?


I suppose it is a mistake. The source should contain @TOPLEVEL_VERSION@,
which will be replaced by the current version by make.

http://codereview.appspot.com/5096050/diff/1/python/musicexp.py#newcode283
python/musicexp.py:283: return False
These functions should not be placed here. The pitch language functions
are here, because the Pitch class is next. The midi functions don't
belong here.

http://codereview.appspot.com/5096050/diff/1/python/musicxml.py
File python/musicxml.py (right):

http://codereview.appspot.com/5096050/diff/1/python/musicxml.py#newcode252
python/musicxml.py:252: return None
Please don't exactly duplicate get_file_description!

A much cleaner solution would be to rename get_file_description to
get_miscellaneous and return a hash of all miscellaneous fields (note
that the 'name' attribute is REQUIRED in the MusicXML specification)...

Something like:
def get_miscellaneous (self):
misc = self.get_named_children ('miscellaneous')
ret = []
for m in misc:
misc_fields = m.get_named_children ('miscellaneous-field')
for mf in misc_fields:
if hasattr (mf, 'name'):
ret[mf.name] = mf.get_text ()
else:
// Print a warning here...
return ret

Instead of the if hasattr you can also use mf.get('name', '').

Of course, you'll have to adjust musicxml2ly.py, too. But at least this
solution is more general, and the logic to abuse a description  misc
field for the texidoc is implemented in the main file, not in a library
file.

http://codereview.appspot.com/5096050/diff/1/scripts/musicxml2ly.py
File scripts/musicxml2ly.py (right):

http://codereview.appspot.com/5096050/diff/1/scripts/musicxml2ly.py#newcode1
scripts/musicxml2ly.py:1: #!/usr/bin/python
Please don't modify  the compiled musicxml2ly and copy it to the source
tree. Rather modify the scripts/musicxml2ly.py in the source tree and
call make. To run it, simply call out/bin/musicxml2ly.

The source code MUST have the @TARGET_PYTHON@, @relocate-preamble@, etc.

http://codereview.appspot.com/5096050/diff/1/scripts/musicxml2ly.py#newcode33
scripts/musicxml2ly.py:33: 
Same as above: Needs to be @relocate-preamble@ in the code!

http://codereview.appspot.com/5096050/diff/1/scripts/musicxml2ly.py#newcode210
scripts/musicxml2ly.py:210: set_if_exists ('subtitle',
movement_title.get_text ())
else  is missing (if there is no work, then no title will be set at
all, even if movement_title exists). I would structure the if as follows
(pseudocode):

if work:
'title' = work_title
if movement_title:
'subtitle' = movement_title
elif movement_title:
'title' = movement_title

http://codereview.appspot.com/5096050/diff/1/scripts/musicxml2ly.py#newcode221
scripts/musicxml2ly.py:221: #set_if_exists ('tagline',
ids.get_encoding_software ())
Simply remove the code without comment.

http://codereview.appspot.com/5096050/diff/1/scripts/musicxml2ly.py#newcode231
scripts/musicxml2ly.py:231: #set_if_exists ('miscellaneous',
ids.get_miscellaneous ());
If you change get_miscellaneous to a hash, you can extract the
'description' here for the texidoc, and loop through all fields to
insert custom header fields for them.

http://codereview.appspot.com/5096050/diff/1/scripts/musicxml2ly.py#newcode2596
scripts/musicxml2ly.py:2596: p.version = ('''%prog (LilyPond)
2.15.13\n\n'''
@TOPLEVEL_VERSION@

http://codereview.appspot.com/5096050/diff/1/scripts/musicxml2ly.py#newcode2797
scripts/musicxml2ly.py:2797: 

Re: musicxml2ly: proposals concerning tagline, conversion info, source-element and midi-output

[Reinhold Kainhofer]

Am Saturday, 17. September 2011, 16:50:33 schrieben Sie:
 I'd like to change (and add) some minor things in musicxml2ly, but before I
 make a patch I wanted to make sure that no-one objects:
 
 1) tagline: musicxml2ly currently uses the contents of  the
 software-element for the LilyPond-tagline. So the tagline at the end of
 a piece engraved by LilyPond actually contains information as to the
 encoding software of the .xml-file. As this information is also saved in a
 custom LilyPond-variable named encodingsoftware and the converted file
 is actually engraved by LilyPond I'd suggest to comment out/delete the
 following line in musicxml2ly in order to print out the standard
 LilyPond-tagline (Music engraving by LilyPond...):
 
 set_if_exists ('tagline', ids.get_encoding_software ())

Okay.

 2) conversion info: right now the conversion info at the top of the
 generated .ly-file says e.g.:
 
 % automatically converted from filename
 
 I'd like to change that to:
 
 % automatically converted with musicxml2ly from filename

Sounds fine.

 3) source-element: musicxml2ly currently doesn't know the
 source-element. I'd like to add it.

What would be the conversion result of a source element?

 4) MIDI: musicxml2ly currently automatically comments out the midi-output
 in the generated .ly-files. Why not leave it in by default?

If the user is interested, he can always add \midi{} himself. By default, 
lilypond doesn't create midi, so it makes sense to me to not add midi by 
default in musicxml2ly, either.

You might add a cmd line option to create a midi block (and a layout block to 
make sure a pdf is created, too).

Cheers,
Reinhold


-- 
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
 * Financial  Actuarial Math., Vienna Univ. of Technology, Austria
 * http://www.fam.tuwien.ac.at/, DVR: 0005886
 * LilyPond, Music typesetting, http://www.lilypond.org

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

Re: musicxml2ly: proposals concerning tagline, conversion info, source-element and midi-output

[Patrick Schmidt]

Am 17.09.2011 um 17:01 schrieb Reinhold Kainhofer:

 Am Saturday, 17. September 2011, 16:50:33 schrieben Sie:
 I'd like to change (and add) some minor things in musicxml2ly, but before I
 make a patch I wanted to make sure that no-one objects:
 
 1) tagline: musicxml2ly currently uses the contents of  the
 software-element for the LilyPond-tagline. So the tagline at the end of
 a piece engraved by LilyPond actually contains information as to the
 encoding software of the .xml-file. As this information is also saved in a
 custom LilyPond-variable named encodingsoftware and the converted file
 is actually engraved by LilyPond I'd suggest to comment out/delete the
 following line in musicxml2ly in order to print out the standard
 LilyPond-tagline (Music engraving by LilyPond...):
 
set_if_exists ('tagline', ids.get_encoding_software ())
 
 Okay.
 
 2) conversion info: right now the conversion info at the top of the
 generated .ly-file says e.g.:
 
% automatically converted from filename
 
 I'd like to change that to:
 
% automatically converted with musicxml2ly from filename
 
 Sounds fine.
 
 3) source-element: musicxml2ly currently doesn't know the
 source-element. I'd like to add it.
 
 What would be the conversion result of a source element?
Michael Good uses the source element for publishing information as to the 
original edition. (See MusicXML 3.0 Tutorial, pp 16 and identity.mod)
I'd suggest a custom LilyPond-variable named source or publisherinfo, e.g.:

\header {
  publisherinfo = (Based on) Bach-Gesellschaft Ausgabe, Band 19
Leipzig: Breitkopf  Härtel, 1871. Plate B.W. XIX.
}

 
 4) MIDI: musicxml2ly currently automatically comments out the midi-output
 in the generated .ly-files. Why not leave it in by default?
 
 If the user is interested, he can always add \midi{} himself. By default, 
 lilypond doesn't create midi, so it makes sense to me to not add midi by 
 default in musicxml2ly, either.
Okay.
 
 You might add a cmd line option to create a midi block (and a layout block to 
 make sure a pdf is created, too).
Sounds good! I'll see what I can do.

Thanks,
patrick
 
 Cheers,
 Reinhold
 
 
 -- 
 --
 Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
 * Financial  Actuarial Math., Vienna Univ. of Technology, Austria
 * http://www.fam.tuwien.ac.at/, DVR: 0005886
 * LilyPond, Music typesetting, http://www.lilypond.org


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

Re: musicxml2ly and language files

[Graham Percival]

On Sat, Nov 20, 2010 at 11:48:17AM +0100, Jean-Charles Malahieude wrote:
 Correcting some typos in the usage manual, I just read in the
 section about musicxml2ly:
 
 @item -l, --language=LANG
 use a different language file 'LANG.ly' and corresponding pitch names,
 e.g. 'deutsch' for deutsch.ly and German note names.
 
 I wonder if this assertion is still valid or will ever be deprecated.

It's easy to test if it is currently valid.  It's impossible to
say if it will ever be deprecated.

I suggest you find a musicxml file and try converting it to
lilypond a few times, giving different -l values.  If you do not
see the expected language, then file a bug report.

- Graham

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

Re: musicxml2ly and language files

[Carl Sorensen]

On 11/20/10 12:23 PM, Jean-Charles Malahieude lily...@orange.fr wrote:

 
 It's easy to test if it is currently valid.  It's impossible to
 say if it will ever be deprecated.
 
 I suggest you find a musicxml file and try converting it to
 lilypond a few times, giving different -l values.  If you do not
 see the expected language, then file a bug report.
 
 
 It works with every language (tested with 01a-Pitches-Pitches.xml and
 01d-Pitches-Microtones.xml from the regtests).
 
 The only thing that might be disturbing is the presence in the
 resulting file of the line
 
 \include lingua.ly
 
 instead of the newly formulation
 
 \language lingua
 
 unless there were some Arabic or makam  music.xml file around...

The \include lingua.ly syntax has not been deprecated yet.  So I think
it's fine to have it here.

If we do deprecate that syntax, we'll want to change things.

Thanks,

Carl


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

Re: musicxml2ly and language files

[Jean-Charles Malahieude]

Le 20/11/2010 21:17, Graham Percival disait :


On Sat, Nov 20, 2010 at 7:38 PM, Carl Sorensenc_soren...@byu.edu  wrote:

On 11/20/10 12:23 PM, Jean-Charles Malahieudelily...@orange.fr  wrote:


instead of the newly formulation

\language lingua

unless there were some Arabic or makam  music.xml file around...


The \include lingua.ly syntax has not been deprecated yet.  So I think
it's fine to have it here.


Sure, but a patch for this would definitely be an improvement.

Jean-Charles: please produce a patch to fix this.  Should take 10-60 minutes.





Hoping this is the way you would like me to proceed.

Cheers,
Jean-Charles
diff --git a/Documentation/usage/external.itely 
b/Documentation/usage/external.itely
index 2b00222..95f7e86 100644
--- a/Documentation/usage/external.itely
+++ b/Documentation/usage/external.itely
@@ -339,8 +339,7 @@ convert pitches in absolute mode.
 print usage and option summary.
 
 @item -l, --language=LANG
-use a different language file 'LANG.ly' and corresponding pitch names,
-e.g. 'deutsch' for deutsch.ly and German note names.
+use LANG for pitch names, e.g. 'deutsch' for note names in German.
 
 @item --lxml
 use the lxml.etree Python package for XML-parsing; uses less memory and cpu 
time.
diff --git a/scripts/musicxml2ly.py b/scripts/musicxml2ly.py
index 2f4b807..6f70baea 100644
--- a/scripts/musicxml2ly.py
+++ b/scripts/musicxml2ly.py
@@ -2707,7 +2707,7 @@ information.) % 'lilypond')
 p.add_option ('-l', '--language',
   metavar = _ (LANG),
   action = store,
-  help = _ (use a different language file 'LANG.ly' and 
corresponding pitch names, e.g. 'deutsch' for deutsch.ly))
+  help = _ (use LANG for pitch names, e.g. 'deutsch' for note 
names in German))
 
 p.add_option ('--nd', '--no-articulation-directions',
   action = store_false,
@@ -3000,7 +3000,7 @@ def main ():
 if options.language:
 musicexp.set_pitch_language (options.language)
 needed_additional_definitions.append (options.language)
-additional_definitions[options.language] = \\include \%s.ly\\n % 
options.language
+additional_definitions[options.language] = \\language \%s\\n % 
options.language
 conversion_settings.ignore_beaming = not options.convert_beaming
 conversion_settings.convert_page_layout = options.convert_page_layout
 
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: musicxml2ly and language files

[Carl Sorensen]

LGTM

Carl



On 11/20/10 2:39 PM, Jean-Charles Malahieude lily...@orange.fr wrote:

 Le 20/11/2010 21:17, Graham Percival disait :
 
 On Sat, Nov 20, 2010 at 7:38 PM, Carl Sorensenc_soren...@byu.edu  wrote:
 On 11/20/10 12:23 PM, Jean-Charles Malahieudelily...@orange.fr  wrote:
 
 instead of the newly formulation
 
 \language lingua
 
 unless there were some Arabic or makam  music.xml file around...
 
 The \include lingua.ly syntax has not been deprecated yet.  So I think
 it's fine to have it here.
 
 Sure, but a patch for this would definitely be an improvement.
 
 Jean-Charles: please produce a patch to fix this.  Should take 10-60 minutes.
 
 
 
 
 Hoping this is the way you would like me to proceed.
 
 Cheers,
 Jean-Charles


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

Re: musicxml2ly and language files

[Graham Percival]

On Sat, Nov 20, 2010 at 9:39 PM, Jean-Charles Malahieude
lily...@orange.fr wrote:

 Hoping this is the way you would like me to proceed.

Looks about right, but could we get a proper git commit (i.e. with
your name attached to it, and a commit message) ?  I don't want to
steal credit for this bugfix.

Cheers,
- Graham

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

Re: musicxml2ly and language files

[Jean-Charles Malahieude]

Le 20/11/2010 22:44, Graham Percival disait :

On Sat, Nov 20, 2010 at 9:39 PM, Jean-Charles Malahieude
lily...@orange.fr  wrote:


Hoping this is the way you would like me to proceed.


Looks about right, but could we get a proper git commit (i.e. with
your name attached to it, and a commit message) ?  I don't want to
steal credit for this bugfix.



Pushed as be33069c51a83bcb8579ec37e2527527a316a4a6

Now going to have a walk with Tosca, before switching off the lights.

Cheers,
Jean-Charles

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

Re: musicxml2ly bug?

[Reinhold Kainhofer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am Mittwoch, 15. Juli 2009 22:59:45 schrieb ArnoWaschk:
 Dear list,

 while trying to import some scores into lilypond i was given as xml export
 from a finale using collegue, i stumbled across some problems...

 by far the most common one i tried to reduce into the attached files.
 while the xml (correctly) contains a Vivace mark in the first bar, the
 .ly file resulting from musicxml2ly conversion shifts it incorrectly into
 the third bar, where it finds the first pitch...

Yes, that's a known problem. I have had that on my todo list for quite a 
while, but haven't found the time yet to fix it.

Cheers,
Reinhold
 
- -- 
- --
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
 * Financial  Actuarial Math., Vienna Univ. of Technology, Austria
 * http://www.fam.tuwien.ac.at/, DVR: 0005886
 * LilyPond, Music typesetting, http://www.lilypond.org

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iD8DBQFKYKDqTqjEwhXvPN0RAi9fAKCzKWVzD/OdFsLNBzPrUB4opfAasQCff3CW
bo4KaQP7RVCDnmPhVT5J6Nk=
=oAE1
-END PGP SIGNATURE-


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

Re: musicxml2ly bug?

[Valentin Villenave]

2009/7/15 ArnoWaschk hamama...@gmx.de:
 while trying to import some scores into lilypond i was given as xml export
 from a finale using collegue, i stumbled across some problems...

Hi Arno,

Added as http://code.google.com/p/lilypond/issues/detail?id=806

(please use the bug-lilypond mailing list for such reports, otherwise
there's a chance they'll go unnoticed.)

Regards,
Valentin


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

Re: MUSICXML2LY

[Reinhold Kainhofer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am Samstag, 27. September 2008 schrieb cab:
 Hi

 I would like to know whether we will be able to import some lyrics in
 the musicxml files to lilypond

If you use the latest development version (LilyPond 2.11), then yes, lyrics 
will be imported. For some complex scores, there might still appear some 
small issues, but I suppose you'll have to look and manually adjust the .ly 
file anyway.

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/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFI3o3/TqjEwhXvPN0RAoOIAJ4ju5WPNhf8wnBOsB98BQkIae/xogCg1jF0
m6uoWlkKY/Ei5omAdgzz19E=
=n/Zq
-END PGP SIGNATURE-


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

Re: Musicxml2ly and convert-ly localization

[John Mandereau]

Le dimanche 10 février 2008 à 19:14 +0100, Reinhold Kainhofer a écrit :
 No, these are fine. I also found some more strings in python/musicexp.ly and 
 python/musicxml.ly, which need to be translated...

Thanks, I fixed it a little (see detailed commit message) to work around
encoding details.


 How about the version string in the option_parser function? Is this 
 automatically translated, should it stay untranslated (due to the license), 
 or should we add the _?

It's already translated as far as I can test, and it's translated in
lilypond binary, so that's all right.

Cheers,
John



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

Re: Musicxml2ly and convert-ly localization

[John Mandereau]

Le vendredi 08 février 2008 à 17:30 +0100, Reinhold Kainhofer a écrit :
 Am Montag, 4. Februar 2008 schrieb John Mandereau:
  Reinhold, are Musixml2ly messages stable enough so they can be marked
  for translation?
 
 I don't think they'll rapidly change. 
 However, I have never really bothered about i18n-able messages, so some 
 error/warning messages might currently not really suited for translation...
 Also, some messages are not really userfriendly (i.e. hard to understand...). 

If I understand correctly, such messages seem to happen in weird cases,
and users who simply use MusicXML as a software-generated exchange
format and don't know about the format spec in detail probably won't
have a clue about the problem, whatever meaningful the error message is.


 So, in short, I don't think that most of the messages will change in the near 
 future, but feel free to improve the messages to make them more targeted at 
 end users (rather than simply describing a technical problem).

I tried to improve some messages, but I'm not sure at all I succeeded;
the problem is, I don't know MusicXML at all, so I'm not aware of
possible problems.  Feel free to revert messages strings I changed :-)


 Another thing: The musicxml2ly 
 (http://kainhofer.com/~lilypond/Documentation/user/lilypond-program/Invoking-musicxml2ly.html#Invoking-musicxml2ly)
  
 web page describes only a subset of options available with musicxml2ly.

If nobody else updates this, I'll do it when you have removed --relative
and added --absolute ;-) (I'm all for this change too).

Cheers,
John



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

Re: Musicxml2ly and convert-ly localization

[John Mandereau]

Le mercredi 06 février 2008 à 10:10 +0200, Till Rettig a écrit :
 John Mandereau schrieb:
  As for convert-ly, I've already marked messages that end not smart
  enough to convert..., and I wonder whether it's important to translate
  conversion rules (i.e., convert-ly -s output); what do you translators
  think?

 This is a very good idea!

Done.  There are 86 new strings compared to lilypond-2.11.34.pot, I
think this is a reasonable amount.

Best,
John



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

Re: Musicxml2ly and convert-ly localization

[Reinhold Kainhofer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am Sonntag, 10. Februar 2008 schrieb John Mandereau:
 Le vendredi 08 février 2008 à 17:30 +0100, Reinhold Kainhofer a écrit :
  Am Montag, 4. Februar 2008 schrieb John Mandereau:
   Reinhold, are Musixml2ly messages stable enough so they can be marked
   for translation?
 
  I don't think they'll rapidly change.
  However, I have never really bothered about i18n-able messages, so some
  error/warning messages might currently not really suited for
  translation... Also, some messages are not really userfriendly (i.e. hard
  to understand...).

 If I understand correctly, such messages seem to happen in weird cases,
 and users who simply use MusicXML as a software-generated exchange
 format and don't know about the format spec in detail probably won't
 have a clue about the problem, whatever meaningful the error message is.

Yes, that might be true...

  So, in short, I don't think that most of the messages will change in the
  near future, but feel free to improve the messages to make them more
  targeted at end users (rather than simply describing a technical
  problem).

 I tried to improve some messages, but I'm not sure at all I succeeded;
 the problem is, I don't know MusicXML at all, so I'm not aware of
 possible problems.  Feel free to revert messages strings I changed :-)

No, these are fine. I also found some more strings in python/musicexp.ly and 
python/musicxml.ly, which need to be translated...

How about the version string in the option_parser function? Is this 
automatically translated, should it stay untranslated (due to the license), 
or should we add the _?

  Another thing: The musicxml2ly
  (http://kainhofer.com/~lilypond/Documentation/user/lilypond-program/Invok
 ing-musicxml2ly.html#Invoking-musicxml2ly) web page describes only a
  subset of options available with musicxml2ly.

 If nobody else updates this, I'll do it when you have removed --relative
 and added --absolute ;-) (I'm all for this change too).

Okay, I added --absolute and made --relative the default (but did not remove 
it, so existing scripts don't break).

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/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHrz72TqjEwhXvPN0RAvGJAJ90I9J8nYhWYbZIT3aL+uRfYUm5wACfXjFE
1NNS5bCSOyilwxXVHOrRlXY=
=WmIr
-END PGP SIGNATURE-


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

Re: Musicxml2ly and convert-ly localization

[Reinhold Kainhofer]

Am Montag, 4. Februar 2008 schrieb John Mandereau:
 Hi,

 As I'm responsible for LilyPond translations, I'd like to mark more
 message strings to be translated, especially in musicxml2ly and
 convert-ly.

 Reinhold, are Musixml2ly messages stable enough so they can be marked
 for translation?

I don't think they'll rapidly change. 
However, I have never really bothered about i18n-able messages, so some 
error/warning messages might currently not really suited for translation...
Also, some messages are not really userfriendly (i.e. hard to understand...). 

So, in short, I don't think that most of the messages will change in the near 
future, but feel free to improve the messages to make them more targeted at 
end users (rather than simply describing a technical problem).

Another thing: The musicxml2ly 
(http://kainhofer.com/~lilypond/Documentation/user/lilypond-program/Invoking-musicxml2ly.html#Invoking-musicxml2ly)
 
web page describes only a subset of options available with musicxml2ly. The 
current set of options is:

Usage: musicxml2ly [options] FILE.xml

Convert MusicXML to LilyPond input.

Options:
   --versionshow program's version number and exit
   -h, --help   show this help message and exit
   -v, --verbosebe verbose
   --lxml   Use lxml.etree; uses less memory and cpu time.
   -z, --compressed Input file is a zip-compressed MusicXML file.
   -r, --relative   Convert pitches in relative mode.
   -l, --language=None  Use a different language file, e.g. 'deutsch' for
deutsch.ly.
   --no-articulation-directions --nd
Do not convert directions (^, _ or -) for
articulations.
   -o, --output=FILEset output filename to FILE

Bugs:
Report bugs via 
http://post.gmane.org/post.php?group=gmane.comp.gnu.lilypond.bugs


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: Musicxml2ly and convert-ly localization

[Till Rettig]

John Mandereau schrieb:

Hi,

As I'm responsible for LilyPond translations, I'd like to mark more
message strings to be translated, especially in musicxml2ly and
convert-ly.


As for convert-ly, I've already marked messages that end not smart
enough to convert..., and I wonder whether it's important to translate
conversion rules (i.e., convert-ly -s output); what do you translators
think?
  
This is a very good idea! How is the usage on windows, by the way? Can 
you drop the file accordingly to convert-ly as you drop it to the 
lilypond icon? Or do you have to go the way via the command line?


Greetings
Till


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

Re: Musicxml2ly and convert-ly localization

[Mats Bengtsson]

Till Rettig wrote:


John Mandereau schrieb:

Hi,

As I'm responsible for LilyPond translations, I'd like to mark more
message strings to be translated, especially in musicxml2ly and
convert-ly.


As for convert-ly, I've already marked messages that end not smart
enough to convert..., and I wonder whether it's important to translate
conversion rules (i.e., convert-ly -s output); what do you translators
think?
  
This is a very good idea! How is the usage on windows, by the way? Can 
you drop the file accordingly to convert-ly as you drop it to the 
lilypond icon? Or do you have to go the way via the command line?

So far, it's only available via the command line.

  /Mats


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

Re: musicxml2ly patch: Convert articulations (fermata, staccato, tremolo, etc.)

[Han-Wen Nienhuys]

2007/8/19, Reinhold Kainhofer [EMAIL PROTECTED]:
  use {}.get (..)

 I was just using the style of the rest of the code...

Certainly, however, the rest of the code is not perfect either.

 BTW, what is an easy way to work with git on multiple patches at the same
 time? Currently, I'm using git-format-patch origin to get the patches, but
 modifying something later on is not possible this way...

I don't understand this question completely. If you modify previous
patches a lot,
it makes more sense to just send the output of

 git diff origin HEAD

However, once you get the hang of style issues, there won't be as much
need for all the going back  forth with patches.


--
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

Re: musicxml2ly patch for articulations (fermata, staccato, accent, etc.)

[Han-Wen Nienhuys]

2007/8/19, Reinhold Kainhofer [EMAIL PROTECTED]:
   Grr, each small project has its own coding style (kdepim has spaces
   inside the parentheses, kdelibs has different style, lilypond another
   different style). That's so confusing, and I'm mainly used to the kdepim
   coding style, as that's my main project!
 
  Yes, that's unfortunate. We use the GNU coding style, FWIW.

 Ouch, To be honest, after looking at the style (it's at
 http://www.gnu.org/prep/standards/standards.html#Formatting, right?), I think
 it was designed to make it artificially hard to visually parse the code
 quickly.

That's what I always think when starting to work in whatever new
coding style there is, but it turns out that this is never true.

   Furthermore, do I really need to compile all of lilypond just to install
   a python script, that does not need compiling just installation?
 
  No, you don't have to compile anything.
  I'm just interested in the musicxml related patches. Look under scripts/
  and python/

 Yes, the scripts are there, but I still need to build lilypond, since during
 the build the preambles in musicxml2ly.py are inserted ([EMAIL PROTECTED]@
  and @relocate-preamble@)...

you can run configure and do

  cp GNUmakefile.in GNUmakefile
  make -C python
  make -C scripts

that should suffice.

 BTW, why is TARGET_PYTHON set to /usr/bin/python instead of the
 usual /usr/bin/env python?\

Good question. I don't know actually.

-- 
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

Re: musicxml2ly patch: Convert articulations (fermata, staccato, tremolo, etc.)

[Han-Wen Nienhuys]

Reinhold Kainhofer escreveu:
 Attached is a git diff to translate articulations from MusicXML to lilypond. 
 It's basically the patch from yesterday with a few style-fixes as requested 
 by Han-Wen.
 
 Cheers,
 Reinhold
 
 PS: If anyone needs an ubuntu package for guile 1.8.2, I have built one to be 
 able to build lilypond.
 
+def direction_mod (self):
+dirstr = ''
+try:
+dirstr += { 1: '^', -1: '_', 0: '-' }[self.force_direction]
+except KeyError:
+pass
+return dirstr

use {}.get (..)

+def musicxml_direction_to_indicator (direction):
+returnval = None
+try:
+  val = { above: 1, upright: 1, below: -1, downright: -1 
}[direction];

idem

+str += ':%s' % 2**( 2 + string.atoi (self.bars) )

no space inside (  )

+try:
+dir = musicxml_direction_to_indicator (mxl_event.placement)
+#dir = mxl_event.type
+if ( dir ):
+  ev.force_direction = dir
+except (KeyError, ValueError, AttributeError):
+pass
+return ev

don't use except() for control flow.  exceptions are for exceptional situations 
only
This programming style can easily hide programming errors.

also, no spaces inside ( ) , and no () around the if condition.

--

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

Re: musicxml2ly patches for dynamic marks and hairpin crescende/diminuendo

[Reinhold Kainhofer]

Hi again,

More patches...

Am Freitag, 17. August 2007 schrieb Reinhold Kainhofer:
  -) dynamic marks (given in a direction tag, assigned to the staff at a
  given position in xml, not to a note like in lilypond)

 Fixed with musicxml2ly_03_dynamics.patch. In the LilyPondVoiceBuilder, I
 added a method to store any pending dynamics and print them out only after
 the next note or rest (everything with duration0) is encountered.

Sorry, I sent the wrong patch. The correct one is attached now.

  -) (de-)crescendo (begin/end also given in a direction tag, not
  assigned to a particular note)

 Not yet done, will be done similar to the dynamics, just didn't find the
 time yet to write the code.

Patch attached as musicxml2ly_04_hairpins.patch
This patch also fixes some KeyError crashes and adds correct handling of 
attributes (I found that they are never read into the dict, so I'm accessing 
them as python attributes now)

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/
diff -u -r lilypond.03_dynamics/usr/bin/musicxml2ly lilypond.04_hairpins/usr/bin/musicxml2ly
--- lilypond.03_dynamics/usr/bin/musicxml2ly	2007-08-17 23:30:29.0 +0200
+++ lilypond.04_hairpins/usr/bin/musicxml2ly	2007-08-17 23:31:18.0 +0200
@@ -191,11 +191,11 @@
 ev = musicexp.ArticulationEvent()
 ev.type = fermata
 try:
-  dir = mxl_event._attribute_dict['type']
-except KeyError:
+  dir = mxl_event.type
+  if ( dir ):
+ev.force_direction = { above: ^, upright: ^, below: _, downright: _ }[dir];
+except (AttributeError, KeyError):
   pass
-if ( dir ):
-  ev.force_direction = { above: ^, upright: ^, below: _, downright: _ }[dir];
 return ev
 
 def musicxml_tremolo_to_lily_event(mxl_event):
@@ -263,14 +263,13 @@
 return
 
 try:
-dir = mxl_event._attribute_dict['placement']
-dir = mxl_event._attribute_dict['type']
+dir = mxl_event.placement
+#dir = mxl_event.type
 if ( dir ):
   dir = { above: ^, upright: ^, below: _, downright: _ }[dir]
-except KeyError:
+ev.force_direction = dir
+except (KeyError, ValueError, AttributeError):
 pass
-else:
-  ev.force_direction = dir
 return ev
 
 
@@ -292,7 +291,22 @@
   event = musicexp.DynamicsEvent()
   event.type = dynentry.get_name()
   res.append( event )
-
+  
+  if entry.get_name() == wedge:
+  try:
+try:
+wedgetype = entry.type;
+except ValueError:
+wedgetype = None
+wedgetypeval = None
+wedgetypeval = {crescendo : 1, decrescendo : -1, 
+diminuendo : -1, stop : 0 }[wedgetype]
+if wedgetypeval != None:
+event = musicexp.HairpinEvent( wedgetypeval )
+res.append( event )
+  except KeyError:
+continue
+
 return res
 
 instrument_drumtype_dict = {
diff -u -r lilypond.03_dynamics/usr/share/lilypond/current/python/musicexp.py lilypond.04_hairpins/usr/share/lilypond/current/python/musicexp.py
--- lilypond.03_dynamics/usr/share/lilypond/current/python/musicexp.py	2007-08-17 23:30:29.0 +0200
+++ lilypond.04_hairpins/usr/share/lilypond/current/python/musicexp.py	2007-08-17 23:31:18.0 +0200
@@ -497,6 +497,20 @@
 class TieEvent(Event):
 def ly_expression (self):
 return '~'
+
+class HairpinEvent(Event):
+def __init__(self, type):
+self.type = type
+def ly_expression(self):
+if self.type == 0: return '\!';
+elif self.type == 1: return '\';
+elif self.type == -1: return '\';
+return;
+def print_ly(self, printer):
+if self.type == 0: printer.dump( '\!' )
+elif self.type == 1: printer.dump( '\' )
+elif self.type == -1: printer.dump( '\' )
+
 
 class DynamicsEvent(Event):
 def __init__(self):
@@ -524,7 +538,7 @@
 class ArticulationEvent(Event):
 def __init__(self):
 self.type = None
-self.force_direction = False
+self.force_direction = None
 
 def direction_mod(self):
 dirstr=''
BinÀrdateien lilypond.03_dynamics/usr/share/lilypond/current/python/musicexp.pyc and lilypond.04_hairpins/usr/share/lilypond/current/python/musicexp.pyc sind verschieden.
diff -u -r lilypond.03_dynamics/usr/share/lilypond/current/python/musicxml.py lilypond.04_hairpins/usr/share/lilypond/current/python/musicxml.py
--- lilypond.03_dynamics/usr/share/lilypond/current/python/musicxml.py	2007-08-17 23:30:29.0 +0200
+++ 

Re: musicxml2ly patch for articulations (fermata, staccato, accent, etc.)

[Han-Wen Nienhuys]

Reinhold Kainhofer escreveu:
 Now that OMR applications like Audiveris (https://audiveris.dev.java.net/) or 
 SmartScore are in a state where they detect most of the music correctly, I 
 think it's more important than ever to have a good MusicXML to Lilypond 
 converter so that one can scan in a score and process it with lilypond 
 without loosing too much of the music.


Thanks for looking at this.

The musicxml2ly converter hasn't seen much attention.
As the primary author, I have forgot most of the subtleties, so would be 
nice if we would have some tests to make sure we don't break any functionality.
Could you provide small separate musicxml files that exercise the 
functionalities?
I could then integrate them in our regression test framework.

regarding your patch

+if ( dir ):

no ( ) in if and while.

+if ( mxl_event.get_name() != tremolo ): return

if body (return in this case) on separate line.

+self.force_direction = False
+
+def direction_mod(self):
+dirstr=''
+if (self.force_direction == 1 or self.force_direction == ^ or 
self.force_direction == up ):
+dirstr += '^'

Use a consistent type for force_direction. I recommend {-1,0,1}.

+#print Element named %s % n.get_name()
+
+#if  n.get_name() == 'direction':

delete  debugging hacks before submitting

+print 
+print Encountered a direction element!!!
+print 

print is actually being deprecated. Better use sys.stderr

+printer.dump( \\%s % self.type )
+else:
+printer.dump( \\markup{ \\dynamic %s } % self.type )

function calls look like 

  printer.dump (...)

note placement of spaces

Can you revise your patch(es), and submit them as git patch, preferably
one per fix/subject?  

thanks,

-- 
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

Re: musicxml2ly bug

[Graham Percival]

I'm not certain what to do with this report.  I'd normally ask for a 
small snippet, but I don't know if it's easy to produce one with 
musicxml.  OTOH, a 151Kb .xml file seems a bit large to add to the bug 
tracker.




Werner LEMBERG wrote:

[lilypond 2.11.7]

I've just received the attached MusicXML file for testing purposes.
Trying musicxml2ly on this file, the script aborts with

  Traceback (most recent call last):
File /usr/local/bin/musicxml2ly, line 656, in ?
  main()
File /usr/local/bin/musicxml2ly, line 653, in main
  voices = convert (args[0], options)
File /usr/local/bin/musicxml2ly, line 614, in convert
  voices = get_all_voices (parts)
File /usr/local/bin/musicxml2ly, line 465, in get_all_voices
  part_ly_voices[n] = (musicxml_voice_to_lily_voice (v), v)
File /usr/local/bin/musicxml2ly, line 333, in musicxml_voice_to_lily_voice
  num = int (n.get_parent ().number)
  ValueError: invalid literal for int(): 22A

And indeed, the corresponding XML snippet shows this:

  measure number=21
  ...
  measure number=22
  ...
  measure number=22A non-controlling=yes
  ...


 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: musicxml2ly bug

[Han-Wen Nienhuys]

Graham Percival escreveu:
 I'm not certain what to do with this report.  I'd normally ask for a
 small snippet, but I don't know if it's easy to produce one with
 musicxml.  OTOH, a 151Kb .xml file seems a bit large to add to the bug
 tracker.
 
 

Just note that measure numbers aren't numbers with the XML snippet.



-- 

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

LilyPond Software Design
 -- Code for Music Notation
http://www.lilypond-design.com



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

Re: musicxml2ly bug

[Graham Percival]

Han-Wen Nienhuys wrote:

Graham Percival escreveu:

I'm not certain what to do with this report.  I'd normally ask for a
small snippet, but I don't know if it's easy to produce one with
musicxml.  OTOH, a 151Kb .xml file seems a bit large to add to the bug
tracker.




Just note that measure numbers aren't numbers with the XML snippet.


OK, entered as
http://code.google.com/p/lilypond/issues/detail?id=222

- Graham


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

Re: musicxml2ly bug

[Werner LEMBERG]

 I'm not certain what to do with this report.  I'd normally ask for a
 small snippet, but I don't know if it's easy to produce one with
 musicxml.  OTOH, a 151Kb .xml file seems a bit large to add to the
 bug tracker.

I suggest to store it compressed.


Werner


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

Re: musicxml2ly bug and fix

[Han-Wen Nienhuys]

Graham Percival wrote:

Phillip Kirlin wrote:


FIX: in musicxml.py, change line 168 from

mode_node = self.get_maybe_exist_named_child ('mode')

to
mode_node = key.get_maybe_exist_named_child ('mode')

This is my first bug fix; I've never contributed to the project before 
(though I've been using Lilypond), so I hope I've provided enough 
information.  I thought this was too small as to warrant creating a 
whole patch, I figured a higher-up could just go change that line.


Patches are highly appreciated (read: required), no matter how small 
they are.  A patch (with -u) lets developers quickly see exactly what 
file you're talking about, and the context of this change.


Here's the patch:

Index: python/musicxml.py
===
RCS file: /sources/lilypond/lilypond/python/musicxml.py,v
retrieving revision 1.10
diff -u -r1.10 musicxml.py
--- python/musicxml.py  16 May 2006 11:58:58 -  1.10
+++ python/musicxml.py  24 Aug 2006 21:40:45 -
@@ -165,7 +165,7 @@
 return (fifths, mode) tuple

 key = self.get_named_attribute ('key')
-mode_node = self.get_maybe_exist_named_child ('mode')
+mode_node = key.get_maybe_exist_named_child ('mode')
 mode = 'major'
 if mode_node:
 mode = mode_node.get_text ()




please apply

--

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

LilyPond Software Design
 -- Code for Music Notation
http://www.lilypond-design.com



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

Re: musicxml2ly bug and fix

[Graham Percival]

Phillip Kirlin wrote:


FIX: in musicxml.py, change line 168 from

mode_node = self.get_maybe_exist_named_child ('mode')

to
mode_node = key.get_maybe_exist_named_child ('mode')

This is my first bug fix; I've never contributed to the project before 
(though I've been using Lilypond), so I hope I've provided enough 
information.  I thought this was too small as to warrant creating a 
whole patch, I figured a higher-up could just go change that line.


Patches are highly appreciated (read: required), no matter how small 
they are.  A patch (with -u) lets developers quickly see exactly what 
file you're talking about, and the context of this change.


Here's the patch:

Index: python/musicxml.py
===
RCS file: /sources/lilypond/lilypond/python/musicxml.py,v
retrieving revision 1.10
diff -u -r1.10 musicxml.py
--- python/musicxml.py  16 May 2006 11:58:58 -  1.10
+++ python/musicxml.py  24 Aug 2006 21:40:45 -
@@ -165,7 +165,7 @@
 return (fifths, mode) tuple

 key = self.get_named_attribute ('key')
-mode_node = self.get_maybe_exist_named_child ('mode')
+mode_node = key.get_maybe_exist_named_child ('mode')
 mode = 'major'
 if mode_node:
 mode = mode_node.get_text ()


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