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

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

[leonardlthomp...@gmail.com]

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


chordname attached to quarter rest is fine.musicxml
Description: Binary data


fails to import chordname attached to empty measure.musicxml
Description: Binary data

Re: ModuleNotFoundError while doing musicxml2ly

[Thomas Morley]

Am Do., 30. Juli 2020 um 22:28 Uhr schrieb Thomas Morley
:
>
> Am Do., 30. Juli 2020 um 22:26 Uhr schrieb Thomas Morley
> :
> >
> > Am Do., 30. Juli 2020 um 08:29 Uhr schrieb Jonas Hahnfeld 
> > :
> > >
> > > Am Mittwoch, den 29.07.2020, 23:04 +0200 schrieb Thomas Morley:
> > > > Hi,
> > > >
> > > > testing a new patch locally a .xml-file popped up.
> > > >
> > > > While having a closer look I tried to convert it to a ly-file with
> > > > ~$ lilypond-git/build/out/bin/musicxml2ly
> > > > lilypond-git/input/regression/musicxml/71d-ChordsFrets-Multistaff.xml
> > > >
> > > > -->
> > > >
> > > > Traceback (most recent call last):
> > > >   File "lilypond-git/build/out/bin/musicxml2ly", line 38, in 
> > > > import musicexp
> > > > ModuleNotFoundError: No module named 'musicexp'
> > > >
> > > > Any insights whats going on?
> > >
> > > Should be fixed by
> > > https://gitlab.com/lilypond/lilypond/-/merge_requests/282.
> > >
> > > Cheers
> > > Jonas
> >
> > Hi Jonas,
> >
> > I tried to download and switch to your branch.
> >
> > Doing
> > $ git log --oneline
> > returns
> > 598d3a9b93 (HEAD -> hahnjo/lilypond-scripts-relocate) Unify dynamic
> > relocation for Python scripts
> > 6ea7b23ba3 Drop all variants of libdir and lib-prefix
> > 4cb4e2747d Fix relocation for Python scripts
> > 4ac82e5e7f Add .setsafe for Ghostscript command
> > ...
> >
> > Looks ok, imho.
> >
> > Then:
> > hermann@kasten ~/lilypond-git/build
> > (hahnjo/lilypond-scripts-relocate)$ out/bin/musicxml2ly --version
> >
> > -->
> >
> > Traceback (most recent call last):
> >   File "out/bin/musicxml2ly", line 38, in 
> > import musicexp
> > ModuleNotFoundError: No module named 'musicexp'
> >
> > :(
> >
> > Cheers,
> >   Harm
>
> Uh, I forgot those are not simple scm-files. Need to recompile...
>
> Sorry for the noise,
>   Harm

Works now and helped me to detect a flaw in my recent patch.

Thanks,
  Harm

Re: ModuleNotFoundError while doing musicxml2ly

[Thomas Morley]

Am Do., 30. Juli 2020 um 22:26 Uhr schrieb Thomas Morley
:
>
> Am Do., 30. Juli 2020 um 08:29 Uhr schrieb Jonas Hahnfeld :
> >
> > Am Mittwoch, den 29.07.2020, 23:04 +0200 schrieb Thomas Morley:
> > > Hi,
> > >
> > > testing a new patch locally a .xml-file popped up.
> > >
> > > While having a closer look I tried to convert it to a ly-file with
> > > ~$ lilypond-git/build/out/bin/musicxml2ly
> > > lilypond-git/input/regression/musicxml/71d-ChordsFrets-Multistaff.xml
> > >
> > > -->
> > >
> > > Traceback (most recent call last):
> > >   File "lilypond-git/build/out/bin/musicxml2ly", line 38, in 
> > > import musicexp
> > > ModuleNotFoundError: No module named 'musicexp'
> > >
> > > Any insights whats going on?
> >
> > Should be fixed by
> > https://gitlab.com/lilypond/lilypond/-/merge_requests/282.
> >
> > Cheers
> > Jonas
>
> Hi Jonas,
>
> I tried to download and switch to your branch.
>
> Doing
> $ git log --oneline
> returns
> 598d3a9b93 (HEAD -> hahnjo/lilypond-scripts-relocate) Unify dynamic
> relocation for Python scripts
> 6ea7b23ba3 Drop all variants of libdir and lib-prefix
> 4cb4e2747d Fix relocation for Python scripts
> 4ac82e5e7f Add .setsafe for Ghostscript command
> ...
>
> Looks ok, imho.
>
> Then:
> hermann@kasten ~/lilypond-git/build
> (hahnjo/lilypond-scripts-relocate)$ out/bin/musicxml2ly --version
>
> -->
>
> Traceback (most recent call last):
>   File "out/bin/musicxml2ly", line 38, in 
> import musicexp
> ModuleNotFoundError: No module named 'musicexp'
>
> :(
>
> Cheers,
>   Harm

Uh, I forgot those are not simple scm-files. Need to recompile...

Sorry for the noise,
  Harm

Re: ModuleNotFoundError while doing musicxml2ly

[Thomas Morley]

Am Do., 30. Juli 2020 um 08:29 Uhr schrieb Jonas Hahnfeld :
>
> Am Mittwoch, den 29.07.2020, 23:04 +0200 schrieb Thomas Morley:
> > Hi,
> >
> > testing a new patch locally a .xml-file popped up.
> >
> > While having a closer look I tried to convert it to a ly-file with
> > ~$ lilypond-git/build/out/bin/musicxml2ly
> > lilypond-git/input/regression/musicxml/71d-ChordsFrets-Multistaff.xml
> >
> > -->
> >
> > Traceback (most recent call last):
> >   File "lilypond-git/build/out/bin/musicxml2ly", line 38, in 
> > import musicexp
> > ModuleNotFoundError: No module named 'musicexp'
> >
> > Any insights whats going on?
>
> Should be fixed by
> https://gitlab.com/lilypond/lilypond/-/merge_requests/282.
>
> Cheers
> Jonas

Hi Jonas,

I tried to download and switch to your branch.

Doing
$ git log --oneline
returns
598d3a9b93 (HEAD -> hahnjo/lilypond-scripts-relocate) Unify dynamic
relocation for Python scripts
6ea7b23ba3 Drop all variants of libdir and lib-prefix
4cb4e2747d Fix relocation for Python scripts
4ac82e5e7f Add .setsafe for Ghostscript command
...

Looks ok, imho.

Then:
hermann@kasten ~/lilypond-git/build
(hahnjo/lilypond-scripts-relocate)$ out/bin/musicxml2ly --version

-->

Traceback (most recent call last):
  File "out/bin/musicxml2ly", line 38, in 
import musicexp
ModuleNotFoundError: No module named 'musicexp'

:(

Cheers,
  Harm

Re: ModuleNotFoundError while doing musicxml2ly

[Jonas Hahnfeld via Discussions on LilyPond development]

Am Mittwoch, den 29.07.2020, 23:04 +0200 schrieb Thomas Morley:
> Hi,
> 
> testing a new patch locally a .xml-file popped up.
> 
> While having a closer look I tried to convert it to a ly-file with
> ~$ lilypond-git/build/out/bin/musicxml2ly
> lilypond-git/input/regression/musicxml/71d-ChordsFrets-Multistaff.xml
> 
> -->
> 
> Traceback (most recent call last):
>   File "lilypond-git/build/out/bin/musicxml2ly", line 38, in 
> import musicexp
> ModuleNotFoundError: No module named 'musicexp'
> 
> Any insights whats going on?

Should be fixed by 
https://gitlab.com/lilypond/lilypond/-/merge_requests/282.

Cheers
Jonas


signature.asc
Description: This is a digitally signed message part

ModuleNotFoundError while doing musicxml2ly

[Thomas Morley]

Hi,

testing a new patch locally a .xml-file popped up.

While having a closer look I tried to convert it to a ly-file with
~$ lilypond-git/build/out/bin/musicxml2ly
lilypond-git/input/regression/musicxml/71d-ChordsFrets-Multistaff.xml

-->

Traceback (most recent call last):
  File "lilypond-git/build/out/bin/musicxml2ly", line 38, in 
import musicexp
ModuleNotFoundError: No module named 'musicexp'

Any insights whats going on?

Cheers,
  Harm

Re: Doc: Minor typo (missing dash) in MusicXML2ly usage (issue 551800043 by michael.kaepp...@googlemail.com)

[Michael Käppler]

Am 22.04.2020 um 22:16 schrieb fedel...@gmail.com:

On 2020/04/21 16:24:47, michael.kaeppler wrote:

Hope this is the right way to submit translation fixes. Any advice is
appreciated.

I think goin' through Rietveld is overkill in this case.
You'd better send a git formatted patch to lilypond-devel or translation
mailing lists.
Patch should be applied to the translation branch.

Ok, sure, so IIUC this patch should be removed from
Rietveld/Sourceforge, since it should not be pushed to staging after
countdown, but
to translation, right?
Does James take care of applying the patch to the translation branch or
someone else?


Have you ever considered updating some manual?
http://lilypond.org/doc/v2.21/Documentation/contributor/translating-the-documentation

I considered it a few times in the past, but at the moment I have no
time left for it,
unfortunately.
Homeschooling, preparing digtal courses for university asf.
I'm also sorry I could not continue to investigate the
graphic / mkosi issues within LilyDev VM

All the best,
Michael



https://codereview.appspot.com/551800043/

Re: Doc: Minor typo (missing dash) in MusicXML2ly usage (issue 551800043 by michael.kaepp...@googlemail.com)

[fedelogy]

On 2020/04/21 16:24:47, michael.kaeppler wrote:
> Hope this is the right way to submit translation fixes. Any advice is
> appreciated.

I think goin' through Rietveld is overkill in this case.
You'd better send a git formatted patch to lilypond-devel or translation
mailing lists.
Patch should be applied to the translation branch.

Have you ever considered updating some manual?
http://lilypond.org/doc/v2.21/Documentation/contributor/translating-the-documentation


https://codereview.appspot.com/551800043/

Doc: Minor typo (missing dash) in MusicXML2ly usage (issue 551800043 by michael.kaepp...@googlemail.com)

[michael . kaeppler--- via Discussions on LilyPond development]

Reviewers: ,

Message:
Hope this is the right way to submit translation fixes. Any advice is
appreciated.

Description:
Doc: Minor typo (missing dash) in MusicXML2ly usage

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

Affected files (+1, -1 lines):
  M Documentation/de/usage/external.itely


Index: Documentation/de/usage/external.itely
diff --git a/Documentation/de/usage/external.itely 
b/Documentation/de/usage/external.itely
index 
6f57989516fd4d001a36e3a98c7c2ab42992a981..51d55ac00ab303b8e08d5d6e389ca2286b65f0de
 100644
--- a/Documentation/de/usage/external.itely
+++ b/Documentation/de/usage/external.itely
@@ -464,7 +464,7 @@ Benutzt das lxml.etree Python-Paket für die Verarbeitung 
von XML (benötigt wen
 @item -m --midi
 Aktiviert die MIDI-Umgebung
 
-@item -nd --no-articulation-directions
+@item --nd --no-articulation-directions
 Konvertiert keine Richtungsangaben (@code{^}, @code{_} oder @code{-})
 von Artikulations- und Lautstärkebezeichnungen.
 

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:

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

[nine . fierce . ballads]

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]:
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".

LGTM.

https://codereview.appspot.com/553620043/

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)
 

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,
português

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

Re: wrong note name conversion in musicxml2ly

[David Kastrup]

mari+lilyp...@mailbox.org writes:

> According to
> http://www.ekmelic-music.org/de/extra/name24.htm
> the "beh" in Netherlands or "bqf" in English does correspond indeed to
> "heh" in German. But I never worked with quarter notes.

Frankly, I suspect that their names are essentially misappropriated from
LilyPond and fixed for obvious problems.  But yes, that would imply the
choice of having b exclusively as a replacement for hes but base all
other note names regularly on h .

I don't know whether there are actual standards, but I'll count that as
an independent vote that this might be the sanest extension into
quarternote territory.

> On 2/9/20 5:52 PM, David Kastrup wrote:
>> mari+lilyp...@mailbox.org writes:
>> 
>>>> On 2/9/20 1:49 PM, David Kastrup wrote:
>>>>> mari+lilyp...@mailbox.org writes:
>>>>>
>>>>>> when converting a mxl file with "musicxml2ly --language=deutsch" the
>>>>>> note "beses" is converted to "bes". Lilypond gives an error at this
>>>>>> notename with \language "deutsch", because the correct german notename
>>>>>> for "double flat b" is "heses". This happens with all musicxml2ly
>>>>>> versions at least from 2.18.2 to 2.21.0.
>>>>>
>>>>> Just trying to fix it, but I find the following in
>>>>> scm/define-note-names.ly in the German section:
>>>>>
>>>>> (heses . ,(ly:make-pitch -1 6 DOUBLE-FLAT))
>>>>> (heseh . ,(ly:make-pitch -1 6 THREE-Q-FLAT))
>>>>> (b . ,(ly:make-pitch -1 6 FLAT))
>>>>> (beh . ,(ly:make-pitch -1 6 SEMI-FLAT))
>>>>> (h . ,(ly:make-pitch -1 6 NATURAL))
>>>>> (hih . ,(ly:make-pitch -1 6 SEMI-SHARP))
>>>>> (his . ,(ly:make-pitch -1 6 SHARP))
>>>>>     (hisih . ,(ly:make-pitch -1 6 THREE-Q-SHARP))
>>>>> (hisis . ,(ly:make-pitch -1 6 DOUBLE-SHARP))
>>>>>
>>>>> That looks almost like something I could work with, except for beh .
>>>>> For all other note names, the suffix -eh indicates _lowering_ by a
>>>>> quarter note, whereas beh _raises_ b by a quarternote.  Shouldn't it
>>>>> rather be heh , making b the _only_ exception?
>>>
>>> At least the output of musicxml2ly should be consistent with lilypond
>>> and should not not give an error message when compiling.
>>>
>>> Here the german Wikipedia for "double flat b":
>>> https://de.wikipedia.org/wiki/Doppel-b
>> 
>> That is all very well, but making musicxml2ly agree with LilyPond here
>> makes mostly sense when we are reasonably sure that LilyPond will not
>> need to get changed again soon.  So even while I understand that you are
>> not interested in getting quarternotes working or consistent as well, I
>> don't think it makes sense to not cater for consistency here too while
>> I am touching the code.
>> 
>> Since the interest on the bug list is limited for the quarternote naming
>> problem in German, I am including the developer list here.  I don't
>> think the discussion will be so long that adding two separate fixes will
>> prove necessary.
>> 

-- 
David Kastrup
My replies have a tendency to cause friction.  To help mitigating
damage, feel free to forward problematic posts to me adding a subject
like "timeout 1d" (for a suggested timeout of 1 day) or "offensive".

Re: wrong note name conversion in musicxml2ly

[David Kastrup]

mari+lilyp...@mailbox.org writes:

>> On 2/9/20 1:49 PM, David Kastrup wrote:
>>> mari+lilyp...@mailbox.org writes:
>>> 
>>>> when converting a mxl file with "musicxml2ly --language=deutsch" the
>>>> note "beses" is converted to "bes". Lilypond gives an error at this
>>>> notename with \language "deutsch", because the correct german notename
>>>> for "double flat b" is "heses". This happens with all musicxml2ly
>>>> versions at least from 2.18.2 to 2.21.0.
>>> 
>>> Just trying to fix it, but I find the following in
>>> scm/define-note-names.ly in the German section:
>>> 
>>> (heses . ,(ly:make-pitch -1 6 DOUBLE-FLAT))
>>> (heseh . ,(ly:make-pitch -1 6 THREE-Q-FLAT))
>>> (b . ,(ly:make-pitch -1 6 FLAT))
>>> (beh . ,(ly:make-pitch -1 6 SEMI-FLAT))
>>> (h . ,(ly:make-pitch -1 6 NATURAL))
>>> (hih . ,(ly:make-pitch -1 6 SEMI-SHARP))
>>> (his . ,(ly:make-pitch -1 6 SHARP))
>>> (hisih . ,(ly:make-pitch -1 6 THREE-Q-SHARP))
>>> (hisis . ,(ly:make-pitch -1 6 DOUBLE-SHARP))
>>> 
>>> That looks almost like something I could work with, except for beh .
>>> For all other note names, the suffix -eh indicates _lowering_ by a
>>> quarter note, whereas beh _raises_ b by a quarternote.  Shouldn't it
>>> rather be heh , making b the _only_ exception?
>
> At least the output of musicxml2ly should be consistent with lilypond
> and should not not give an error message when compiling.
>
> Here the german Wikipedia for "double flat b":
> https://de.wikipedia.org/wiki/Doppel-b

That is all very well, but making musicxml2ly agree with LilyPond here
makes mostly sense when we are reasonably sure that LilyPond will not
need to get changed again soon.  So even while I understand that you are
not interested in getting quarternotes working or consistent as well, I
don't think it makes sense to not cater for consistency here too while
I am touching the code.

Since the interest on the bug list is limited for the quarternote naming
problem in German, I am including the developer list here.  I don't
think the discussion will be so long that adding two separate fixes will
prove necessary.

-- 
David Kastrup
My replies have a tendency to cause friction.  To help mitigating
damage, feel free to forward problematic posts to me adding a subject
like "timeout 1d" (for a suggested timeout of 1 day) or "offensive".

Fw: Errors with midi2ly and musicxml2ly

[m.tarensk...@zonnet.nl]

   Verzonden vanaf mijn Huawei mobiele telefoon

    Oorspronkelijk bericht 
   Onderwerp: Re: Errors with midi2ly and musicxml2ly
   Van: m.tarensk...@zonnet.nl
   Aan: Aaron Hill
   Cc:

 There are more python2 vs python3 issues in those scripts than just
 that one. You can try to check ( and fix) using the 2to3 script.
 Or use Python2 to run the scripts.
 Verzonden vanaf mijn Huawei mobiele telefoon

    Oorspronkelijk bericht 
   Onderwerp: Re: Errors with midi2ly and musicxml2ly
   Van: Aaron Hill
   Aan: bug-lilyp...@gnu.org
   Cc:

 On 2019-11-20 12:00 am, Артем Тартаковский wrote:
 > ср, 20 нояб. 2019 г., 2:00 Aaron Hill :
 >> It's a compatibility issue between Python 2 and 3. The backtick
 >> operator was removed [1] in Python 3, in favor of the repr()
 >> procedure.
 >>
 >> [1]:
 >>
 https://portingguide.readthedocs.io/en/latest/syntax.html#backticks
 >>
 >> It is my understanding the scripts shipping with LilyPond are not
 >> expected to be interpretable by Python 3 yet.
 >
 > So what do I have to replace this construction with?
 Near as I can tell, it's a simple replacement of `foo` with
 repr(foo).
 So, you could potentially run the scripts through the following sed
 command:
 sed -i~ 's/`\([^`]*\)`/repr(\1)/g' *.py
 -- Aaron Hill
 ___
 bug-lilypond mailing list
 bug-lilyp...@gnu.org
 https://lists.gnu.org/mailman/listinfo/bug-lilypond

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: crash during musicxml2ly

[Frédéric Gohier]

Hello,

Thanks


Regards,
GOHIER Frédéric

De : James Lowe <james.l...@runbox.com>
Envoyé : lundi 7 mai 2018 10:13
À : James Lowe
Cc : Frédéric Gohier; lilypond-devel
Objet : Re: crash during musicxml2ly

Frederic

On Wed, 02 May 2018 12:09:37 +0100 (BST), "James Lowe" <pkx1...@runbox.com> 
wrote:

> Hello Frederic,
>
> On Tue, 1 May 2018 16:47:24 +, Frédéric Gohier <fgohie...@hotmail.com> 
> wrote:
>
> > hello,
> >
> > I just push the patch on rietveld : 
> > https://codereview.appspot.com/339560043/

This has now gone through the patch review process.

Can you provided a git formatted patch based on current master and I can push 
it for you?

Thank you.

James


diff --git a/python/musicexp.py b/python/musicexp.py
index 1c061da..99649b2 100644
--- a/python/musicexp.py
+++ b/python/musicexp.py
@@ -2130,7 +2130,8 @@ class StaffGroup:
 self.part_information = staves_info
 else:
 for c in self.children:
-c.set_part_information (part_name, staves_info)
+if hasattr(c, 'set_part_information'):
+c.set_part_information (part_name, staves_info)
 
 def add_context_modification (self, modification):
 self.context_modifications.append (modification)
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: crash during musicxml2ly

[James Lowe]

Frederic

On Wed, 02 May 2018 12:09:37 +0100 (BST), "James Lowe"  
wrote:

> Hello Frederic,
> 
> On Tue, 1 May 2018 16:47:24 +, Frédéric Gohier  
> wrote:
> 
> > hello,
> > 
> > I just push the patch on rietveld : 
> > https://codereview.appspot.com/339560043/

This has now gone through the patch review process.

Can you provided a git formatted patch based on current master and I can push 
it for you?

Thank you.

James



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

Re: crash during musicxml2ly

[James Lowe]

Hello Frederic,

On Tue, 1 May 2018 16:47:24 +, Frédéric Gohier  
wrote:

> hello,
> 
> I just push the patch on rietveld : https://codereview.appspot.com/339560043/
> 
>

Thank you, I have created https://sourceforge.net/p/testlilyissues/issues/5317/ 
for this issue.

I will help start the review of this patch to our development team. Assuming 
that the patch passes all the tests, they may have some comments and will let 
you know.

Thank you for your contribution.

Regards

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

Re: [PATCH] musicxml2ly fix for lyrics when chord is present (fixes 61e)

[James Lowe]

Vincent,

On 29/11/16 09:50, Vincent Le Ligeour wrote:
> As commented in the patch I did not find any documentation if a chord
> element can contain multiple lyrics, so I just assumed that the first note
> of the chord contained the lyrics (consistant with Finale and Muscore
> exports).

Thanks, added as


https://sourceforge.net/p/testlilyissues/issues/5005/

-- 
--

James


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

[PATCH] musicxml2ly fix for lyrics when chord is present (fixes 61e)

[Vincent Le Ligeour]

Hello,

This patch should fix the musicxml regression tests that have both lyrics
and chords (for example 61e).
As commented in the patch I did not find any documentation if a chord
element can contain multiple lyrics, so I just assumed that the first note
of the chord contained the lyrics (consistant with Finale and Muscore
exports).

Regards

Vincent
From 2a50b100f11733d8dd99f5ed80cfa0ad4f1d97d5 Mon Sep 17 00:00:00 2001
From: Vincent Le Ligeour 
Date: Tue, 22 Nov 2016 23:52:41 +0100
Subject: [PATCH] fix: musicxml regression 61e - lyrics and chords

---
 scripts/musicxml2ly.py | 8 
 1 file changed, 8 insertions(+)
 mode change 100644 => 100755 scripts/musicxml2ly.py

diff --git a/scripts/musicxml2ly.py b/scripts/musicxml2ly.py
old mode 100644
new mode 100755
index 766214bd76..4d6b149ef1
--- a/scripts/musicxml2ly.py
+++ b/scripts/musicxml2ly.py
@@ -2127,6 +2127,9 @@ def extract_lyrics(voice, lyric_key, lyrics_dict):
 def is_rest(elem):
 return elem.get_typed_children(musicxml.Rest)
 
+def is_chord(elem):
+return elem.get_typed_children(musicxml.Chord)
+
 def is_note_and_not_rest(elem):
 return is_note(elem) and not is_rest(elem)
 
@@ -2153,6 +2156,11 @@ def extract_lyrics(voice, lyric_key, lyrics_dict):
  not note_has_lyric_belonging_to_lyric_part:
 result.append('\skip1 ')
 # Note does not have any lyric attached to it.
+elif is_chord(elem):
+# note without lyrics part of a chord. MusicXML format is
+# unclear if a chord element could contain a lyric, lets
+# asume that we do not want to put a skip here.
+continue
 elif is_note_and_not_rest(elem):
 result.append('\skip1 ')
 
-- 
2.11.0.rc2

___
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

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

[pkx166h]

Reviewers: ,

Message:
Patch on countdown for October 11th

Description:
Musicxml2ly: Fix incorrect conversion of Minor Chords

Issue 4980

The solutions for the invalid combinations
are provided in python/musicexp.py. A colon
is added if a colon-less chord (i.e., major)
has modifications. Adding additions checks
for a trailing digit, if none, the leading
period is omitted.

Note that the changes in python/musicexp.py
are harmless to an un-patched scripts/musicxml2ly.

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

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


Index: python/musicexp.py
diff --git a/python/musicexp.py b/python/musicexp.py
index  
e8cbcb016769301209d51af8a4f8283537959b37..cee77054162db03d4214807d4300a4aabaa8dd02  
100644

--- a/python/musicexp.py
+++ b/python/musicexp.py
@@ -1597,10 +1597,19 @@ class ChordNameEvent (Event):
 value += self.duration.ly_expression ()
 if self.kind:
 value = self.kind.format(value)
+# If there are modifications, we need a ":". This will not be
+# the case for plain major chords.
+if self.modifications and not ":" in value:
+value += ":"
 # First print all additions/changes, and only afterwards all  
subtractions

 for m in self.modifications:
 if m.type == 1:
-  value += m.ly_expression ()
+  # Additions start with ".", but that requires a trailing
+  # digit. If none, omit the ".".
+  if re.search(r'\d$', value):
+value += m.ly_expression ()
+  else:
+value += m.ly_expression () [1:]
 for m in self.modifications:
 if m.type == -1:
   value += m.ly_expression ()
Index: scripts/musicxml2ly.py
diff --git a/scripts/musicxml2ly.py b/scripts/musicxml2ly.py
index  
766214bd762b5dc8e991849d70a91473f4bbb782..f2874fea5b6201778624b990cb0ad612021163f4  
100644

--- a/scripts/musicxml2ly.py
+++ b/scripts/musicxml2ly.py
@@ -1601,10 +1601,10 @@ def musicxml_chordpitch_to_lily(mxl_cpitch):
 return r

 chordkind_dict = {
-'major': r'{}:5',
-'minor': r'{}:m5',
-'augmented': r'{}:aug5',
-'diminished': r'{}:dim5',
+'major': r'{}',
+'minor': r'{}:m',
+'augmented': r'{}:aug',
+'diminished': r'{}:dim',
 # Sevenths:
 'dominant': r'{}:7',
 'dominant-seventh': r'{}:7',
@@ -1612,8 +1612,8 @@ chordkind_dict = {
 'minor-seventh': r'{}:m7',
 'diminished-seventh': r'{}:dim7',
 'augmented-seventh': r'{}:aug7',
-'half-diminished': r'{}:dim5m7',
-'major-minor': r'{}:maj7m5',
+'half-diminished': r'{}:m7.5-',
+'major-minor': r'{}:maj7m',
 # Sixths:
 'major-sixth': r'{}:6',
 'minor-sixth': r'{}:m6',



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

Reimplement issue 4781 for musicxml2ly more literally. (issue 302050043 by j...@weathervanefarm.net)

[john]

Reviewers: ,

Message:
Issue 4781 is reimplemented as requested by David Kastrup.

Description:
Reimplement issue 4781 for musicxml2ly more literally.
Reimplementation was necessary as part of the implementation of issue
4751, but some of the code changes for 4781 were omitted. This
reproduces all the 4781 changes.

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

Affected files (+8, -13 lines):
  M python/musicxml.py


Index: python/musicxml.py
diff --git a/python/musicxml.py b/python/musicxml.py
index  
f0b82f1333c7613bcd80f5c418c8f99afb96f35e..ae5ca80a59647dca423d6b374bf6b595b53ee315  
100644

--- a/python/musicxml.py
+++ b/python/musicxml.py
@@ -145,11 +145,11 @@ class Music_xml_spanner(Music_xml_node):
 class Measure_element(Music_xml_node):

 def get_voice_id(self):
-voice_id = self.get_maybe_exist_named_child('voice')
-if voice_id:
-return voice_id.get_text()
+voice = self.get_maybe_exist_named_child('voice')
+if voice:
+return voice.get_text()
 else:
-return None
+return self.voice_id

 def is_first(self):
 # Look at all measure elements(previously we had self.__class__,  
which

@@ -1558,15 +1558,10 @@ class Part(Music_xml_node):
 continue

 if isinstance(n, Direction):
-staff_id = n.get_maybe_exist_named_child(u'staff')
-if staff_id:
-staff_id = staff_id.get_text()
-if staff_id:
-dir_voices = staff_to_voice_dict.get(staff_id,  
voices.keys())

+if (n.voice_id):
+voices[n.voice_id].add_element (n)
 else:
-dir_voices = voices.keys()
-for v in dir_voices:
-voices[v].add_element(n)
+assign_to_next_note.append (n)
 continue

 if isinstance(n, Harmony) or isinstance(n, FiguredBass):
@@ -1635,7 +1630,7 @@ class Dashes(Music_xml_spanner):
 class DirType(Music_xml_node):
 pass

-class Direction(Music_xml_node):
+class Direction(Measure_element):
 pass

 class Dot(Music_xml_node):



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

Possible errors reimplementing musicxml2ly fix for issue 4581

[John Gourlay]

I sent the message below to Tobias Kretschmar using the email address 
tobias.kretsch...@gmx.de and after a few days it was returned as undeliverable. 
Does anyone know an alternate way to reach him? Tobias, are you following this 
email list?

John Gourlay

——-

Tobias,

In my recent work on LilyPond issue 4751 I had to reimplement the changes you 
made for issue 4581 in February. It seems that I might have done an inadequate 
job, and I’m hoping that you will be able to help clarify the issue. It would 
be especially useful if you could explain in more detail how you originally 
verified that the bug was fixed. Was the bug originally evident in the LilyPond 
output from the regression test 42a-MultiVoice-TwoVoicesOnStaff-Lyrics.xml? I 
am attaching the PDF output from this test as it is produced now. Is it correct?

The background of this, in brief, is that I brought a large body of changes 
into musicxml2ly that were made over several years separately from LilyPond in 
the Philomelos project. Not fully understanding the Philomelos changes, I opted 
to preserve the Philomelos code when it seemed to work rather than recreating 
the latest LilyPond code. The effect of this strategy was apparently to remove 
some of your changes. If you are interested you can see the whole discussion 
between me and David Kastrup at the end of the long series of comments to issue 
4751.

John Gourlay



42a-MultiVoice-TwoVoicesOnStaff-Lyrics.pdf
Description: Adobe PDF document
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Make additional changes to the new version of musicxml2ly (issue 297370043 by j...@weathervanefarm.net)

[john]

Reviewers: ,

Message:
A few days a go I uploaded a new patch for issue 4751, "Import
Philolelos enhancements to musicxml2ly", the first patch for which had
been flagged as needing work. I hope this version works better.

Description:
Make additional changes to the new version of musicxml2ly imported
from the Philomelos project. The changes are also uploaded to the
branch dev/johngourlay/issue-4751. After these changes I can run the
following build commands without error:

make
make test-clean
make test
make check

The problems with the earlier patch were due to my misunderstanding of
the make test dependencies. I did not run make test-clean, and so I did
not see that some musicxml regression tests did not run.

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

Affected files (+3760, -2169 lines):
  M python/musicexp.py
  M python/musicxml.py
  A python/musicxml2ly_conversion.py
  A python/utilities.py
  M scripts/musicxml2ly.py



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

Re: [PATCH] musicxml2ly: Make sure movement_title exists before using it

[James]

Hello,

On 13/12/15 21:32, Thomas Weber wrote:
> fixed problem and was generated by Sibelius' internal MusicXML export 
> functionality (not Dolet).
Ticket created at:
https://sourceforge.net/rest/p/testlilyissues/issues/4699/

Thanks

James

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

Re: [PATCH] musicxml2ly: Avoid duplicate "tr" if both and, are present

[Urs Liska]

Am 15.12.2015 um 09:06 schrieb James:
> Ticket created at:
> https://sourceforge.net/rest/p/testlilyissues/issues/4698/
http://sourceforge.net/p/testlilyissues/issues/4698/

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

Re: [PATCH] musicxml2ly: Avoid duplicate "tr" if both and, are present

[James]

Hello,

On 13/12/15 21:48, Thomas Weber wrote:
> In situations like this:
>
> 
> 
>
> this will be created:
>
> \trill \startTrillSpan
>
> It should only be \startTrillSpan
Ticket created at:
https://sourceforge.net/rest/p/testlilyissues/issues/4698/

Thanks

James

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

Re: [PATCH] musicxml2ly: Avoid duplicate "tr" if both and, are present

[James]

Thomas,

On 13/12/15 21:48, Thomas Weber wrote:
> Another patch for musicxml2ly: In situations like this:
>
> 
> 
>
> this will be created:
>
> \trill \startTrillSpan
>
> It should only be \startTrillSpan.
>
> (My changes can also be found on Github: https://github.com/th-we/lilypond.)
>
> Greets,
> Thomas Weber
This patch breaks 'make doc'

--snip--

lilypond-book.py: error: `musicxml2ly  --out=- - ' failed (0)
lilypond-book.py: error: The error log is as follows:
musicxml2ly: Reading MusicXML from Standard input ...
musicxml2ly: Converting to LilyPond expressions...
Traceback (most recent call last):
  File "/home/jlowe/lilypond-git/build/scripts/out/musicxml2ly", line
2990, in 
main()
  File "/home/jlowe/lilypond-git/build/scripts/out/musicxml2ly", line
2985, in main
voices = convert (filename, options)
  File "/home/jlowe/lilypond-git/build/scripts/out/musicxml2ly", line
2891, in convert
(voices, staff_info) = get_all_voices (parts)
  File "/home/jlowe/lilypond-git/build/scripts/out/musicxml2ly", line
2578, in get_all_voices
part_ly_voices[n] = musicxml_voice_to_lily_voice (v)
  File "/home/jlowe/lilypond-git/build/scripts/out/musicxml2ly", line
2402, in musicxml_voice_to_lily_voice
ev = musicxml_articulation_to_lily_event (ch, a)
  File "/home/jlowe/lilypond-git/build/scripts/out/musicxml2ly", line
1229, in musicxml_articulation_to_lily_event
ev = tmp_tp (mxl_event)
AttributeError: TremoloEvent instance has no __call__ method
/home/jlowe/lilypond-git/build/scripts/build/out/texi2omf --format pdf
--location
/usr/local/share/doc/lilypond/html/input/regression/musicxml/collated-files.pdf 
--version 2.19.34 out-www/collated-files.texi >
out-www/collated-files.pdf.omf
Traceback (most recent call last):
  File "/home/jlowe/lilypond-git/build/scripts/build/out/texi2omf", line
73, in 
texi = open (infile).read ()
IOError: [Errno 2] No such file or directory: 'out-www/collated-files.texi'
make[4]: *** [out-www/collated-files.pdf.omf] Error 1
make[4]: Leaving directory
`/home/jlowe/lilypond-git/build/input/regression/musicxml'
make[3]: *** [WWW-1] Error 2
make[3]: Leaving directory `/home/jlowe/lilypond-git/build/input/regression'
make[2]: *** [WWW-1] Error 2
make[2]: Leaving directory `/home/jlowe/lilypond-git/build/input'
make[1]: *** [WWW-1] Error 2
make[1]: Leaving directory `/home/jlowe/lilypond-git/build'
make: *** [doc-stage-1] Error 2


--snip--

James

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

[PATCH] musicxml2ly: Make sure movement_title exists before using it

[Thomas Weber]

Here's a little trivial patch to musicxml2ly.  The attached MusicXML file 
triggers the fixed problem and was generated by Sibelius' internal MusicXML 
export functionality (not Dolet).

Best,
Thomas Weber
>From 12576c27e26693832659602bf883a3d08b04fa78 Mon Sep 17 00:00:00 2001
From: Thomas Weber <t...@notabit.eu>
Date: Sun, 13 Dec 2015 17:12:57 +0100
Subject: [PATCH] musicxml2ly: Make sure movement_title exists before using it

---
 scripts/musicxml2ly.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/musicxml2ly.py b/scripts/musicxml2ly.py
index dda374d..5cf5333 100644
--- a/scripts/musicxml2ly.py
+++ b/scripts/musicxml2ly.py
@@ -178,7 +178,7 @@ def extract_score_information (tree):
 if work:
 work_title = work.get_work_title ()
 set_if_exists ('title', work_title)
-if work_title == '':
+if work_title == '' and movement_title :
 set_if_exists ('title', movement_title.get_text ())
 elif movement_title:
 set_if_exists ('subtitle', movement_title.get_text ())
-- 
1.9.1


http://www.musicxml.org/dtds/partwise.dtd;>

 
  
 
 
  Copyright © 
  
   2015-12-13
   tom
   Sibelius 8.0.0
   Direct export, not from Dolet
   Sibelius / MusicXML 3.0
   
   
   
   
   
  
 
 
  
   210
   1200
  
  
   1697
   1200
   
72
72
72
72
   
  
  
   
22
0
   
   92
  
  
   0.9375
   5
   0.9375
   1.5625
   5
   1.5625
   1.5625
   1.25
   0.9375
   1.25
   5
   1.5625
   0.9375
   1.5625
   1.5625
   1.5625
   0.625
   1.5625
   0.625
   75
   60
  
  
  
  
 
 
  
   P1
   
 

 General MIDI
 Bright Piano

   
  
 
 
  
  
   

 
  22
  0
 
 218

   
   
256

 0
 major


 4
 4

1

 G
 2


   
   

1024

1
whole
1
   
   
light-heavy
   
  
 

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

[PATCH] musicxml2ly: Avoid duplicate "tr" if both and, are present

[Thomas Weber]

Another patch for musicxml2ly: In situations like this:




this will be created:

\trill \startTrillSpan

It should only be \startTrillSpan.

(My changes can also be found on Github: https://github.com/th-we/lilypond.)

Greets,
Thomas Weber
>From 282b5b501d89a70a4aa799214744bb69af61630c Mon Sep 17 00:00:00 2001
From: Thomas Weber <t...@notabit.eu>
Date: Sun, 13 Dec 2015 21:07:15 +0100
Subject: [PATCH] musicxml2ly: Avoid duplicate "tr" if both  and
  are present

---
 scripts/musicxml2ly.py | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/scripts/musicxml2ly.py b/scripts/musicxml2ly.py
index 5cf5333..397dd78 100644
--- a/scripts/musicxml2ly.py
+++ b/scripts/musicxml2ly.py
@@ -1179,7 +1179,7 @@ articulations_dict = {
 #"toe": "?",
 "turn": "turn",
 "tremolo": musicxml_tremolo_to_lily_event,
-"trill-mark": "trill",
+"trill-mark": lambda notations: None if notations.get_named_children ('wavy-line') else "trill",
 #"triple-tongue": "?",
 #"unstress": "?"
 "up-bow": "upbow",
@@ -1187,12 +1187,16 @@ articulations_dict = {
 }
 articulation_spanners = [ "wavy-line" ]
 
-def musicxml_articulation_to_lily_event (mxl_event):
+def musicxml_articulation_to_lily_event (mxl_event, parent_node):
 # wavy-line elements are treated as trill spanners, not as articulation ornaments
 if mxl_event.get_name () in articulation_spanners:
 return musicxml_spanner_to_lily_event (mxl_event)
 
 tmp_tp = articulations_dict.get (mxl_event.get_name ())
+
+if hasattr (tmp_tp, '__call__'):
+tmp_tp = tmp_tp(parent_node)
+
 if not tmp_tp:
 return
 
@@ -2351,7 +2355,7 @@ def musicxml_voice_to_lily_voice (voice):
 
 # accidental-marks are direct children of !
 for a in notations.get_named_children ('accidental-mark'):
-ev = musicxml_articulation_to_lily_event (a)
+ev = musicxml_articulation_to_lily_event (a, notations)
 if ev:
 ev_chord.append (ev)
 
@@ -2376,7 +2380,7 @@ def musicxml_voice_to_lily_voice (voice):
 
 for a in ornaments:
 for ch in a.get_all_children ():
-ev = musicxml_articulation_to_lily_event (ch)
+ev = musicxml_articulation_to_lily_event (ch, a)
 if ev:
 ev_chord.append (ev)
 
-- 
1.9.1

ÿþ<?xml version='1.0' encoding='UTF-16' standalone='no'?>

<!DOCTYPE score-partwise PUBLIC '-//Recordare//DTD MusicXML 3.0 Partwise//EN' 'http://www.musicxml.org/dtds/partwise.dtd'>

<score-partwise version='3.0'>

	<identification>

		<rights>Copyright © </rights>

		<encoding>

			<software>Sibelius 8.0</software>

			<software>Dolet 6.5 for Sibelius</software>

			<encoding-date>2015-12-13</encoding-date>

			<supports element='accidental' type='yes'/>

			<supports element='transpose' type='no'/>

			<supports attribute='new-page' element='print' type='yes' value='yes'/>

			<supports attribute='new-system' element='print' type='yes' value='yes'/>

		</encoding>

	</identification>

	<defaults>

		<scaling>

			<millimeters>7</millimeters>

			<tenths>40</tenths>

		</scaling>

		<page-layout>

			<page-height>1697</page-height>

			<page-width>1200</page-width>

			<page-margins type='odd'>

				<left-margin>72.5714</left-margin>

				<right-margin>72.5714</right-margin>

				<top-margin>72.5714</top-margin>

				<bottom-margin>72.5714</bottom-margin>

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: merging philomelos musicxml2ly-dev

[James]

On 13/07/14 14:57, Martin Tarenskeen wrote:



On Sun, 13 Jul 2014, James wrote:


I have no preferences either way - we have done this for articulate.ly
for instance - but unless we know that philomelos and LilyPond's
versions are reasonably close to start with we could end up with each
version becoming so far apart in terms of codebase that nothing gets
fixed or that LilyPond's musicxml2ly becomes so far behind philomelos to
be worse than useless and we might as well remove musicxml2ly from the
code and just point to Philomelos.



Would it be an idea to freeze development of musicxml2ly until the 
Philomenos improvments have been merged with Lilypond's official 
version?


This is already the defacto situation? There haven't been much changes 
for months on both sides I think?



This is a question for the dev list.

cc-ing them.

James

___
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

musicxml2ly output indentation style

[Martin Tarenskeen]

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
  }

This is not a real-life example, but it shows what I mean. 
(I don't know if the indentation will survive in e-mail readers, so I have 
attached the example also)


It looks like everyone prefers the closing bracket to un-indent, except 
the people who developed musicxml2ly?


Is this a known issue, something that needs fixing?

--

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

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


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

Fwd: New Feature: musicxml2ly should consider colors of noteheads and stems

[Marek Klein]

Forwarding to devel list - this is more patch proposal than bug report.
Please comment if we need tracker issue for this...

-- Forwarded message --
From: DaLa d.la...@gmx.de
Date: 2013/7/20
Subject: New Feature: musicxml2ly should consider colors of noteheads and
stems
To: bug-lilyp...@gnu.org


Hello,
many thanks for all the software of the lilypond project.
Yesterday I colored some noteheads in a piece of music using the format
musicxml.
I learned: the format musicxml supports color attributes for noteheads and
stems.
Unfortunately the script musicxml2ly.py in lilypond version 2.16.2-1 seems
to ignore color attributes of noteheads and stems.

I therefore would like to recommend the following changes in the scripts
 * musicxml2ly.py
 * musicexp.py

I have made some simple tests - the changes seem to work. Maybe some
additional regression tests are necessary. (and: I'm not familiar with the
methods pre_note_ly of the Event classes - must they consider the color
attribute? I don't know.)

Thank You
DaLa

 - - -

[musicxml2ly.py, line 1610]

def musicxml_notehead_to_lily (nh): #function changed: additionally process
color attribute
styles = []

# Notehead style
style = notehead_styles_dict.get (nh.get_text ().strip (), None)
style_elm = musicexp.NotestyleEvent ()
if style:
style_elm.style = style
if hasattr (nh, 'filled'):
style_elm.filled = (getattr (nh, 'filled') == yes)
if hasattr (nh, 'color'):
style_elm.color = hex_to_color (getattr (nh, 'color'))
if style_elm.style or (style_elm.filled != None) or (style_elm.color !=
None):
styles.append (style_elm)

# parentheses
if hasattr (nh, 'parentheses') and (nh.parentheses == yes):
styles.append (musicexp.ParenthesizeEvent ())

return styles

def musicxml_stem_to_lily (st): #function added: process stem color
attribute
styles = []

# Stem style
style_elm = musicexp.StemstyleEvent ()
if hasattr (st, 'color'):
style_elm.color = hex_to_color (getattr (st, 'color'))
if (style_elm.color != None):
styles.append (style_elm)

return styles


[musicexp.py, line 1247]

class NotestyleEvent (Event): #class changed: additional attribute color
def __init__ (self):
Event.__init__ (self)
self.style = None
self.filled = None
self.color = None
def pre_chord_ly (self):
return_string = ''
if self.style:
return_string +=  \\once \\override NoteHead #'style = #%s %
self.style
if self.color:
return_string +=  \\once \\override NoteHead #'color =
#(rgb-color %s %s %s) % (self.color[0], self.color[1], self.color[2])
return return_string
def pre_note_ly (self, is_chord_element):
if self.style and is_chord_element:
return \\tweak #'style #%s % self.style
else:
return ''
def ly_expression (self):
return self.pre_chord_ly ()

class StemstyleEvent (Event): #class added
def __init__ (self):
Event.__init__ (self)
self.color = None
def pre_chord_ly (self):
if self.color:
return \\once \\override Stem #'color = #(rgb-color %s %s %s)
% (self.color[0], self.color[1], self.color[2])
else:
return ''
def pre_note_ly (self, is_chord_element):
return ''
def ly_expression (self):
return self.pre_chord_ly ()




___
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

musicxml2ly

[pls]

Hey all,we have been working on solutions for old musicxml2ly-bugs and some new functions. We have published our efforts onhttps://github.com/Philomelos/lilypond-musicxml2ly-dev. We will continue working on musicxml2ly but there are far more bugs than we could ever handle on our own. So if no one minds we will send a lot of musicxml2ly related reports to the bug list in the near future.hthpatrickHere is a list of new commits and some test files:1) https://github.com/Philomelos/lilypond-musicxml2ly-dev/commit/f22cb84f93dc968322abd6bc0a89371ddf54Test files:https://github.com/Philomelos/lilypond-musicxml2ly-dev/blob/master/MusicXML-TestSuite/midi-block-single-part.xml (MIDI-Bugfixed:monophonicpieceswereconvertedwithoutamidi-block.Nowallscoresareexportedina\score{}containinga\midi-Block)https://github.com/Philomelos/lilypond-musicxml2ly-dev/blob/master/MusicXML-TestSuite/placement-musical-directions.xml (placement attributes for musical directions now work for dynamics, hairpins, textspans and ligature brackets)https://github.com/Philomelos/lilypond-musicxml2ly-dev/blob/master/MusicXML-TestSuite/wavy-line.xml (wavy-line bug fixed (Issue: 2316))https://github.com/Philomelos/lilypond-musicxml2ly-dev/blob/master/MusicXML-TestSuite/barre.xml ((curved) barre-indications are now included in fret diagrams)

powerchordsymbol.xml
Description: XML document
(The symbol for powerchords is now "C5" instead of "C")https://github.com/Philomelos/lilypond-musicxml2ly-dev/blob/master/MusicXML-TestSuite/new%20functions/transpose/scale.xml (new transpose function to be able to transpose .xml-files via command line)2)https://github.com/Philomelos/lilypond-musicxml2ly-dev/commit/f6e50496a56a38d7ec0ec333df8b03257aa1bb7chttps://github.com/Philomelos/lilypond-musicxml2ly-dev/commit/32f8dda4c3e2302a0e755a3e1fb3aebb2cd30fcehttps://github.com/Philomelos/lilypond-musicxml2ly-dev/commit/ed9e55034f154fb219cfaabdf8f5cfe2df356cb7Test file:https://github.com/Philomelos/lilypond-musicxml2ly-dev/blob/master/MusicXML-TestSuite/sound.xml (added sound tempo recognition for midi output)3)https://github.com/Philomelos/lilypond-musicxml2ly-dev/commit/5501d9562ba245697ec7273fe0eaa6952eebbffdhttps://github.com/Philomelos/lilypond-musicxml2ly-dev/commit/91eee40736e923690f39d735a5d301704f3a7a35https://github.com/Philomelos/lilypond-musicxml2ly-dev/commit/9576bfa0996829c24ee0f1759d16dac8ac57ec40https://github.com/Philomelos/lilypond-musicxml2ly-dev/commit/dc077b4611400e1b9e77b0aa625a3debe68af29fWith e.g. --shift-meter 2/2 you canchange the length|duration of notes as a function of agiven time signature to make the score look faster orslower, (eg. '4/4' or '2/2')4)https://github.com/Philomelos/lilypond-musicxml2ly-dev/commit/0747e5ce34f8d3a6128302ec0363a8f5f91ce3fdTest file:https://github.com/Philomelos/lilypond-musicxml2ly-dev/blob/master/MusicXML-TestSuite/stem.xmlimplemented recognition of stem values "up" and "down"(and neutral)5)https://github.com/Philomelos/lilypond-musicxml2ly-dev/commit/6b45d133394dbea0a28eaf36a1c474dd9835cb1chttps://github.com/Philomelos/lilypond-musicxml2ly-dev/commit/21580656ca819099e7dcc6e9f9b44f19cd32ca77Test file:

fretboardvoice.xml
Description: XML document
command line option:--fb --fretboardsconverts 'frame' events to a separate FretBoardsvoice instead of markupsThis helps to align the fretboards vertically. fretboards in markups tend to go up and down.6)https://github.com/Philomelos/lilypond-musicxml2ly-dev/commit/a5b7a919cf26700c51b8aa5a43099a291d65b3adhttps://github.com/Philomelos/lilypond-musicxml2ly-dev/commit/13e97f8d56492afc4adfc1eee3f112879c92ae55Test file:

tabclef.xml
Description: XML document
command line option:--tc --tab-clef=TABCLEFNAMEswitch between two versions of tab clefs ("tab" and"moderntab")7)https://github.com/Philomelos/lilypond-musicxml2ly-dev/commit/a534b4c446fc807019d87c8cffd4184095a3159dTest file:

string-numbers.xml
Description: XML document
command line option:--sn --string-numbers=t[rue]/f[alse]deactivate string number stencil with --string-numbersf[alse]. Default is t[rue]8)https://github.com/Philomelos/lilypond-musicxml2ly-dev/commit/68f3f2c8bf2084496777ba96603fbfc79351946dhttps://github.com/Philomelos/lilypond-musicxml2ly-dev/commit/33957a48cbde9d5b30e24aefa324d14154e19a19Test file:https://github.com/Philomelos/lilypond-musicxml2ly-dev/blob/master/MusicXML-TestSuite/frame.xmlIf a frame-note is not defined (or commented out) in an .xml-file musicxml2ly converts it as an unplayed (muted) string.___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Fix for several musicxml2ly bugs. (issue 5697059)

[ptrcklschmdt]

Hey Julien,

thanks a million!

Cheers,
patrick

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

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

Re: Fix for several musicxml2ly bugs. (issue 5697059)

[julien . rioux]

Hi Patrick,

A cleaned up version of this patch has been committed (and credited to
you), so you may close this Rietveld issue. You will see the fix in
version 2.15.41, the next development release.

Cheers,
Julien

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

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

musicxml2ly: Fix title, chord symbol and midi bugs. (issue 6330046)

[graham]

LGTM

http://codereview.appspot.com/6330046/

___
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

musicxml2ly

[Martin Tarenskeen]

Hi,

There have been many requests from several people for Lilypond-to-MusicXML 
conversion. I am not going to repeat that question.


We do have a musicxml2ly script. I have tried it with many example xml and 
mxl files from here:


http://www.makemusic.com/musicxml/music/example-set

and here:

http://www.wikifonia.org/

And the lilypond results are sometimes not quite perfect - which is 
acceptable - but sometimes really bad or even useless.


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.


The MakeMusic/Recordare example set reveals some more serious problems 
like wrong stem directions, duplicated text and dynamic markings, 
collisions.


Is anyone currently actively working on musicxml2ly ?
Does it help if I write a more detailed description of errors I encounter 
when I try to convert real life examples of MusicXML files? Or are many 
problems already known?


--

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: Fix for several musicxml2ly bugs. (issue 5697059)

[ptrcklschmdt]

On 2012/02/29 22:33:45, Julien Rioux wrote:

This patch is not associated with any issue in the bug tracker. It

will not get

a proper review until it is added there, and the automatic testing

shows that it

does not cause any unexpected problems. Should it be added to issue

1983, or is

it sufficiently different that we should open a new issue for it?


Well it would certainly be easier for me if we opened a new issue for
this patch as it contains fixes for several bugs I reported lately.  For
some of them no issues were opened. Here are the bugs / reports at
stake:
-) http://code.google.com/p/lilypond/issues/detail?id=1983
-)
http://old.nabble.com/musicxml2ly%3A-chordnames-placement-bug-td33309393.html
-) http://lists.gnu.org/archive/html/bug-lilypond/2012-02/msg00519.html

I also added 2 lines to Usage as the new command line options -m and
--midi hadn't been added yet.

Beyond that I have a partial fix for
(http://code.google.com/p/lilypond/issues/detail?id=1969). Should I make
a new patch or can I add the code here?


There are a lot of formatting changes to musicxml.py that are

unnecessary and

make it difficult to see the meaningful changes in your patch. You

also

introduce whitespace errors. So please revert the changes to

musicxml.py except

for...



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



http://codereview.appspot.com/5697059/diff/1/scripts/musicxml2ly.py#newcode25

scripts/musicxml2ly.py:25: # Store command-line options in a global

variable, so

we can access them everywhere
...this typo...

OK.  Will do.  But I'll leave out the former lines 477 and 478 as this
_is_ a meaningful change.

Thanks for your help!
patrick

BTW: I should mention that the bugs in this patch were fixed by René
Fauck.

http://codereview.appspot.com/5697059/diff/1/scripts/musicxml2ly.py#newcode534

scripts/musicxml2ly.py:534: return None
...and this thinko.



http://codereview.appspot.com/5697059/diff/1/scripts/musicxml2ly.py#newcode2570

scripts/musicxml2ly.py:2570: p.version = ('''%prog (LilyPond)

2.15.24\n\n'''

Especially, don't change this.




http://codereview.appspot.com/5697059/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Fix for several musicxml2ly bugs. (issue 5697059)

[Colin Campbell]

On 12-03-01 10:23 AM, ptrcklsch...@googlemail.com wrote:


Well it would certainly be easier for me if we opened a new issue for
this patch as it contains fixes for several bugs I reported lately.  For
some of them no issues were opened. Here are the bugs / reports at
stake:
-) http://code.google.com/p/lilypond/issues/detail?id=1983


This sounds very straightforward; can you cook up a small patch 
restricted to this item alone

-)
http://old.nabble.com/musicxml2ly%3A-chordnames-placement-bug-td33309393.html 



This one sounds like issue 1969, and could probably be added as a comment.


-) http://lists.gnu.org/archive/html/bug-lilypond/2012-02/msg00519.html

I also added 2 lines to Usage as the new command line options -m and
--midi hadn't been added yet.



Because this one brings in the MIDI set of . . . complications . . . it 
should probably have a separate tracker item.



Beyond that I have a partial fix for
(http://code.google.com/p/lilypond/issues/detail?id=1969). Should I make
a new patch or can I add the code here?


This would involve creating a Rietveld item referencing tracker 1969, 
which would be the better way of handling the work in process patch.



I gather you would like to create a single tracker item and merge all 
the above into it, but that might make the result rather too broad for 
easy review and analysis.



Cheers,
Colin

--
I've learned that you shouldn't go through life with a catcher's mitt on both 
hands.
You need to be able to throw something back.
-Maya Angelou, poet (1928- )


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

Re: Fix for several musicxml2ly bugs. (issue 5697059)

[julien . rioux]

This patch is not associated with any issue in the bug tracker. It will
not get a proper review until it is added there, and the automatic
testing shows that it does not cause any unexpected problems. Should it
be added to issue 1983, or is it sufficiently different that we should
open a new issue for it?

There are a lot of formatting changes to musicxml.py that are
unnecessary and make it difficult to see the meaningful changes in your
patch. You also introduce whitespace errors. So please revert the
changes to musicxml.py except for...


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

http://codereview.appspot.com/5697059/diff/1/scripts/musicxml2ly.py#newcode25
scripts/musicxml2ly.py:25: # Store command-line options in a global
variable, so we can access them everywhere
...this typo...

http://codereview.appspot.com/5697059/diff/1/scripts/musicxml2ly.py#newcode534
scripts/musicxml2ly.py:534: return None
...and this thinko.

http://codereview.appspot.com/5697059/diff/1/scripts/musicxml2ly.py#newcode2570
scripts/musicxml2ly.py:2570: p.version = ('''%prog (LilyPond)
2.15.24\n\n'''
Especially, don't change this.

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

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

Re: Fix for several musicxml2ly bugs. (issue 5697059)

[julien . rioux]

On 2012/02/29 22:33:45, Julien Rioux wrote:

So please revert the changes to musicxml.py


I mean musicxml2ly.py

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

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

Fix for several musicxml2ly bugs. (issue 5697059)

[ptrcklschmdt]

Reviewers: ,

Description:
Fix for several musicxml2ly bugs.



musicxml2ly: title, chord symbol and midi bug

Titles and headers can now contain single words followed by a
 punctuation mark (.,!:).  See issue 1983.

Chord symbols are now placed above staffs instead of below.

musicxml2ly now includes an out-commented midi-block in every .ly-file.

Docs: Added command line options -m and --midi to Usage

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

Affected files:
  M Documentation/usage/external.itely
  M python/musicexp.py
  M python/musicxml.py
  M scripts/musicxml2ly.py



___
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

scripts

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

musicxml2ly: use either work-title or movement-title as title

[Patrick Schmidt]

Hey Reinhold,

here is a small patch for the title issue.

hth
patrick


0001-musicxml2ly-use-either-work-title-or-movement-title-.patch
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

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

[Patrick Schmidt]

Hey all,

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

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

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

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

So what's your opinion?

Cheers
patrick
___
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

[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: Isue 1868: Loglevels in our python scripts (lilypond-book, musicxml2ly, convert-ly) (issue 4908041)

[pkx166h]

I was able to do a full make doc with no errors.

James

http://codereview.appspot.com/4908041/

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

Re: Isue 1868: Loglevels in our python scripts (lilypond-book, musicxml2ly, convert-ly) (issue 4908041)

[pkx166h]

passes make and reg tests

http://codereview.appspot.com/4908041/

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

Loglevels in our python scripts (lilypond-book, musicxml2ly, convert-ly) (issue 4908041)

[pkx166h]

Patch no longer applies to current tree

http://codereview.appspot.com/4908041/

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