Re: musicxml2ly chord names

On Mon, Jan 29, 2024 at 12:55 AM Silvain Dupertuis < silvain-dupert...@bluewin.ch> wrote: > I could write an issue... but the webpage did recomment to write a message > first > This is now issue https://gitlab.com/lilypond/lilypond/-/issues/6694 -- Knute Snortum

Re: musicxml2ly chord names

://nextcloud.silvain-dupertuis.net/index.php/s/W5J8owidipexxTa It is easy for me to correct the ~/lilypond/usr/bin/musicxml2ly file (a text file) But I thought it might be useful to others... Moreover, it would be great to have a lily2musicxml conversion tool! The xml code for the first note

Re: musicxml2ly chord names

On Sun, Jan 28, 2024 at 8:50 AM Silvain Dupertuis < silvain-dupert...@bluewin.ch> wrote: > These first 2 lines of the dictionary for chords in musicxml2ly > contains a faulty 5 for simple major and minor chords > (I discovered it with a conversion from a MuseScore sheet conve

Re: Incorrect transposition via musicxml2ly

On Sun, Jan 28, 2024 at 10:30 AM Alexander Slávik < slavik.alexan...@seznam.cz> wrote: > > I can write this up as an issue unless you want to... > > Please do so; thanks! > It is now https://gitlab.com/lilypond/lilypond/-/issues/6693. I hope I explained it sufficiently. -- Knute Snortum

Re: Incorrect transposition via musicxml2ly

> I can write this up as an issue unless you want to... Please do so; thanks! AS

musicxml2ly chord names

These first 2 lines of the dictionary for chords in musicxml2ly contains a faulty 5 for simple major and minor chords (I discovered it with a conversion from a MuseScore sheet converted into xml) chordkind_dict = { 'major': ':5', 'minor': ':m5', should be chordkind_dict = { 'major

Re: Incorrect transposition via musicxml2ly

On Sun, Jan 28, 2024 at 12:01 AM Alexander Slávik < slavik.alexan...@seznam.cz> wrote: > Seems like this didn't get much attention… > It looks like a bug to me. I can write this up as an issue unless you want to... -- Knute Snortum

Re: Incorrect transposition via musicxml2ly

Seems like this didn't get much attention… AS

Incorrect transposition via musicxml2ly

Hello, the musicxml2ly script has the --transpose option, which automatically adds \transpose to the resulting source code. However, when the result has multiple voices in one staff (e.g. after converting the attached almost- minimal musicxml file), one gets lines like \context Voice

Re: musicxml2ly

not very skilled in Python. It is complicated to have this possibility? I don't think that musicxml2ly has an option for this. The easiest option is fixing the input afterwards in Frescobaldi: select the music, then Tools>Musical transformation>Rhythm>Make implicit. Maybe python-ly has

musicxml2ly

Dear all I just discover Lilypond engraver and I find it fantastic. I have some score I have done with musescore, and I would like to convert them to ly. So I use your program musixml2py. It works very well. I would like to have no repetition of note duration, for example if I have four c8, I

Re: musicxml2ly does not support non-numeric lyric numbers which are (accidentally) allowed by the MusicXML spec

numbers (partverse) in at least the part-wise scores. This case is documented online [1] [2] [3] as a known issue in MusicXML (which has not been resolved up to now, and probably never will given the time passed since it was raised). I think lilypond’s musicxml2ly should support conversion

musicxml2ly does not support non-numeric lyric numbers which are (accidentally) allowed by the MusicXML spec

is documented online [1] [2] [3] as a known issue in MusicXML (which has not been resolved up to now, and probably never will given the time passed since it was raised). I think lilypond’s musicxml2ly should support conversion of such none-numerical lyric numbers. Preferably by grouping lyrics based

Re: musicxml2ly does not honour --no-rest-positions option

Am Dienstag, den 28.07.2020, 17:15 +1000 schrieb jostle: > If musicxml2ly is invoked with the '--no-rest-positions' option it still > generates output in the form > > 'c4 \rest' instead of 'r4' > > The following change seems to fix the problem, > > ~/src/lilypond-git

musicxml2ly does not honour --no-rest-positions option

If musicxml2ly is invoked with the '--no-rest-positions' option it still generates output in the form 'c4 \rest' instead of 'r4' The following change seems to fix the problem, ~/src/lilypond-git$ git diff origin/master diff --git a/scripts/musicxml2ly.py b/scripts/musicxml2ly.py index

Re: musicxml2ly

Am Montag, den 25.05.2020, 16:17 +0200 schrieb Lukas-Fabian Moser: > On Sat, 23 May 2020, Martin Tarenskeen wrote: > > > > There must be something seriously broken if musicxml2ly can't convert > > > > this > > > > > > P.S. I just tried down

Re: musicxml2ly

Lukas-Fabian Moser writes: > On Sat, 23 May 2020, Martin Tarenskeen wrote: >>>> There must be something seriously broken if musicxml2ly can't convert >>>> this >>> P.S. I just tried downgrading to lilypond 2.19.84 (from Fedora repo) and >>>

Re: musicxml2ly

On Sat, 23 May 2020, Martin Tarenskeen wrote: There must be something seriously broken if musicxml2ly can't convert this P.S. I just tried downgrading to lilypond 2.19.84 (from Fedora repo) and the problem disappeared. So it does look like a regression to me. Thanks Martin; I’ve opened

Re: musicxml2ly

On Mon, 25 May 2020, Valentin Villenave wrote: Thanks Martin; I’ve opened this tracker page: https://gitlab.com/lilypond/lilypond/-/issues/5994 It seems weird that such a problem wasn’t caught by our pretty-extensive test suite, so I’m wondering what might be particular to your test file.

Re: musicxml2ly

On 5/23/20, Martin Tarenskeen wrote: > > On Sat, 23 May 2020, Martin Tarenskeen wrote: >> There must be something seriously broken if musicxml2ly can't convert >> this > > P.S. I just tried downgrading to lilypond 2.19.84 (from Fedora repo) and > the problem disapp

Re: musicxml2ly fails on with multiple

On Tue, 19 May 2020 at 12:18, Valentin Villenave wrote: > As far as I can see it doesn’t break anything from our regression > tests, so unless someone more knowledgeable than me objects, it should > be merged in the next version (2.21.2). Thanks! ___

Re: musicxml2ly fails on with multiple

On 5/18/20, Noam Postavsky wrote: >> > Ping? >> Ping?? > Ping??? Greetings Noam, thanks for being so persistent; I’m not very familiar with musicxml2ly but I submitted your patch here on your behalf: https://gitlab.com/lilypond/lilypond/-/merge_requests/65 As far as I can se

Re: musicxml2ly fails on with multiple

On Sun, 26 Apr 2020 at 13:12, Noam Postavsky wrote: > > > The attached example-musicxml-display-part-bug.xml shows a minimal > > > example to trigger the bug. It gives this output: > > > > > get_maybe_exist_typed_child > > > raise "More than 1 child", klass > > > Ping? > Ping?? Ping???

Re: musicxml2ly Pitch Changing Potential Bug

Alex Hansen wrote > I think I have found a bug. The following musicXML, when run through > musicxml2ly, produces lilypond which has entirely different pitches. I've > cut out as much of the XML as possible to ensure it is a minimal example. > Note that the musicXML specifies a single

musicxml2ly Pitch Changing Potential Bug

I think I have found a bug. The following musicXML, when run through musicxml2ly, produces lilypond which has entirely different pitches. I've cut out as much of the XML as possible to ensure it is a minimal example. Note that the musicXML specifies a single D whole note, but when it goes through

Re: musicxml2ly fails on with multiple

On Tue, 24 Mar 2020 at 18:38, Noam Postavsky wrote: > > On Thu, 5 Mar 2020 at 22:45, Noam Postavsky wrote: > > > > The attached example-musicxml-display-part-bug.xml shows a minimal > > example to trigger the bug. It gives this output: > > > get_maybe_exist_typed_child > > raise "More than 1

Re: musicxml2ly fails on with multiple

On Thu, 5 Mar 2020 at 22:45, Noam Postavsky wrote: > > The attached example-musicxml-display-part-bug.xml shows a minimal > example to trigger the bug. It gives this output: > get_maybe_exist_typed_child > raise "More than 1 child", klass > The original case where I ran into this is >

Re: musicxml2ly unsupported unicode range

encoding. > As my experience with Python is very limited, I will make no attempt to comment on whether the this thread's original issue is due to the musicxml2ly script, the Frescobaldi program, or the Python language/runtime itself. But rest assured, a properly-written program can mos

Re: musicxml2ly unsupported unicode range

and, I was surprised by Powershell's default encoding. As my experience with Python is very limited, I will make no attempt to comment on whether the this thread's original issue is due to the musicxml2ly script, the Frescobaldi program, or the Python language/runtime itself. But rest assured, a pr

Re: musicxml2ly unsupported unicode range

Hi again I could indeed solve the issue by changing the filename to another ;-)) Another issue was that musicxml2ly on windows 10 could not open compressed xml files (zlib module missing). But that it is not a big problem. Uncompressed worked OK. So now I can continue my work

Re: musicxml2ly unsupported unicode range

Jean ABOU SAMRA wrote >You likely have a special character in the name of your file. >Windows handles this poorly and LilyPond (actually Python, >behind the scenes) can't do much for this. Try removing >special characters from the file name, it should solve >your problem. I

musicxml2ly fails on with multiple

The attached example-musicxml-display-part-bug.xml shows a minimal example to trigger the bug. It gives this output: musicxml2ly: Reading MusicXML from example-musicxml-display-part-bug.xml ... musicxml2ly: Converting to LilyPond expressions... Traceback (most recent call last): File "/us

Re: musicxml2ly unsupported unicode range

> Hi > I have for some time as a musicshool teacher been a busy user > of lilypond on my Linux Desktop. Recently my employer have forced > me to work on windows 10. I have got a working setup but > musicxml2ly gives the following error: > > Starti

musicxml2ly unsupported unicode range

Hi I have for some time as a musicshool teacher been a busy user of lilypond on my Linux Desktop. Recently my employer have forced me to work on windows 10. I have got a working setup but musicxml2ly gives the following error: Starting python-windows.exe... Traceback (most recent call last

Re: wrong note name conversion in musicxml2ly

You are right. It was My fault. I did use the wrong path. Thank you for fixing. On 2/16/20 6:30 PM, David Kastrup wrote: > mari+lilyp...@mailbox.org writes: > >> As far as I understand the closed issue 5746 should fix the problem >> musicxml2ly generating the note name "

Re: wrong note name conversion in musicxml2ly

mari+lilyp...@mailbox.org writes: > As far as I understand the closed issue 5746 should fix the problem > musicxml2ly generating the note name "bes" instead of "heses" with > --language=deutsch. > > In fact the problem is not fixed in the actual git rep

Re: wrong note name conversion in musicxml2ly

As far as I understand the closed issue 5746 should fix the problem musicxml2ly generating the note name "bes" instead of "heses" with --language=deutsch. In fact the problem is not fixed in the actual git repository. See my attached mxl-file and the ly output of musicxml2l

Re: wrong note name conversion in musicxml2ly

Torsten Hämmerle writes: > Oh, great, thanks, > > I missed issue 5746. it exactly solves the problem and even will produce the > more common "asah" instead of "aseh" etc. > So apologies for my late (and hence superfluent) reply/hint. Well, I should have posted a notice regarding the tracker

Re: wrong note name conversion in musicxml2ly

Oh, great, thanks, I missed issue 5746. it exactly solves the problem and even will produce the more common "asah" instead of "aseh" etc. So apologies for my late (and hence superfluent) reply/hint. Torsten -- Sent from: http://lilypond.1069038.n5.nabble.com/Bugs-f58488.html

Re: wrong note name conversion in musicxml2ly

Torsten Hämmerle writes: > In any case, the current musicxml2ly problem is about heses. And the heses > note name definition in LilyPond (scm/define-note-names.scm) is correct and > should not be changed. > musicxml2ly must not produce a German "bes", because this clea

Re: wrong note name conversion in musicxml2ly

In any case, the current musicxml2ly problem is about heses. And the heses note name definition in LilyPond (scm/define-note-names.scm) is correct and should not be changed. musicxml2ly must not produce a German "bes", because this clearly should be "heses" Here's the cod

Re: wrong note name conversion in musicxml2ly

hat 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

Re: wrong note name conversion in musicxml2ly

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

Re: wrong note name conversion in musicxml2ly

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

Re: wrong note name conversion in musicxml2ly

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 On 2/9/20 1:49 PM, David Kastrup wrote: > mari+lilyp...@mailb

Re: wrong note name conversion in musicxml2ly

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 notena

wrong note name conversion in musicxml2ly

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

musicxml2ly does not honour the --nrp --no-rest-positions option

musicxml2ly --nrp  or --no-rest-positions still creates positioned "\rest" entries in the output file. The following patch seems to fix the problem : $ git diff diff --git a/scripts/musicxml2ly.py b/scripts/musicxml2ly.py index 28993850b5..9066dc84a9 100755 --- a/scripts/musicxml2l

Re: Errors with midi2ly and musicxml2ly

Hi, Am 20.11.19 um 01:00 schrieb Aaron Hill: > "SKIP: %s\n" % `e` 2to3 is the way to go as others said before. In this particular case, rather than calling repr, the standard solution would be: "SKIP: %r\n" % e as %r uses the repr-form while %s the str-form. Cheers, Joram

Re: Errors with midi2ly and musicxml2ly

Forwarding for visibility... On 2019-11-20 12:57 pm, Артем Тартаковский wrote: There is another problem with musicxml2ly. It gives me an error: Traceback (most recent call last): File "musicxml2ly.py", line 3297, in ? main() File "musicxml2ly.py", line 3279, in m

Re: Errors with midi2ly and musicxml2ly

tructions specific to your operating system for installing and using Python 2 and Python 3 side-by-side. And I cannot comment at all regarding the 2to3 script mentioned. On 2019-11-20 12:57 pm, Артем Тартаковский wrote: There is another problem with musicxml2ly. It gives me an error: Traceback (mo

Re: Errors with midi2ly and musicxml2ly

On 2019-11-20 9:40 am, m.tarensk...@zonnet.nl wrote: 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. Fair point. I was only intending to address Артем's question on that specific bit of syntax. Or use

Re: Errors with midi2ly and musicxml2ly

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

Re: Errors with midi2ly and musicxml2ly

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

Re: Errors with midi2ly and musicxml2ly

On 2019-11-19 3:29 pm, Артем Тартаковский wrote: I've tried to convert a MIDI file into LilyPond (version 2-19.83-1) using the command prompt, but it gives me an error: File "C:\Program Files (x86)\LilyPond\usr\bin\midi2ly.py", line 545 sys.stderr.write ("SKIP: %s\n" % `e`)

Errors with midi2ly and musicxml2ly

I've tried to convert a MIDI file into LilyPond (version 2-19.83-1) using the command prompt, but it gives me an error: File "C:\Program Files (x86)\LilyPond\usr\bin\midi2ly.py", line 545 sys.stderr.write ("SKIP: %s\n" % `e`) ^ SyntaxError: invalid

Re: issues with musicxml2ly

Double Oops!! The first quote mark is the correct one - omit the one at the end (though in fact Windows tolerates it, which is how it got in there unnoticed). Paul On 22/09/2019 15:50:55, "Paul Hodges" wrote: >Oops! Omit the quote mark in the middle of my statement after .py. > >Paul > >On

Re: issues with musicxml2ly

;On 14/07/2019 21:59:41, "Knut Petersen" >wrote: > >>Hi Gilberto! >>>>Try if replacing >>>> >>>> musicxml ... >>>> >>>>with >>>> >>>> python2 $(grep -o '"[^$^"]*$me"' `

Re: issues with musicxml2ly

erfectly for me, and is a significant improvement to Lilypond for my usage! Regards, Paul Hodges On 14/07/2019 21:59:41, "Knut Petersen" wrote: >Hi Gilberto! >>>Try if replacing >>> >>> musicxml ... >>> >>>with >>> >>> python

Re: issues with musicxml2ly

Hi  Michael! b) Is there work on migrationg to Python3? I don't think so. Python2 will be phased out by upstream really soon now. Yes. We know. No problem If we have our own python2 ;-) Sad to hear that. If I find time I'll have a look into it. Porting to Python3 is relatively doable in my

Re: issues with musicxml2ly

On 7/15/2019 8:59 AM, Michael Kesper wrote: If I find time I'll have a look into it. Porting to Python3 is relatively doable in my experience. A few other people have expressed interest in working on Python upgrades. Past discussions indicated that the biggest challenges would be getting GUB

Re: issues with musicxml2ly

Hi Knut, On 15.07.19 15:44, Knut Petersen wrote: > On 15.07.19 09:34, Michael Kesper wrote: >> b) Is there work on migrationg to Python3? > I don't think so. > >> Python2 will be phased out by upstream really soon now. > > Yes. We know. No problem If we have our own python2 ;-) Sad to hear

Re: issues with musicxml2ly

On 15.07.19 09:34, Michael Kesper wrote: Hi all, On 14.07.19 22:59, Knut Petersen wrote: Bug 1: Musicxml2ly is incompatible to the python2 distributed with the installers. Musicxml2ly needs at least python2 2.7.0, lilypond installers provide python 2.4.5 This leads me to two questions

Re: issues with musicxml2ly

Hi all, On 14.07.19 22:59, Knut Petersen wrote: > Bug 1: > Musicxml2ly is incompatible to the python2 distributed with the installers. > Musicxml2ly needs at least python2 2.7.0, lilypond installers provide python > 2.4.5 This leads me to two questions: a) What's the reason for s

Re: issues with musicxml2ly

Hi Knut, Thank you so much for your help and for the explanation, I really appreciate it. This solves the main issue I was having. Concerning the other two feature requests I made in my original in relation to supporting slur positioning and al niente hairpins in musicxml2ly (see http

Re: issues with musicxml2ly

Hi Gilberto! Try if replacing     musicxml ... with     python2 $(grep -o '"[^$^"]*$me"' `which musicxml2ly` | sed -e 's/"//g' -e 's/$me/musicxml2ly/')  ... Yes, that does seem to fix the issue! The .ly file created by musicxml2ly does not have the encoding and stra

Re: issues with musicxml2ly

-o '"[^$^"]*$me"' `which musicxml2ly` | sed -e 's/"//g' -e 's/$me/musicxml2ly/')  ... Yes, that does seem to fix the issue! The .ly file created by musicxml2ly does not have the encoding and strange character issues and compiles normally. Thanks for all the replie

Re: issues with musicxml2ly

or if you compiled lilypond. Try if replacing musicxml ... with python2 $(grep -o '"[^$^"]*$me"' `which musicxml2ly` | sed -e 's/"//g' -e 's/$me/musicxml2ly/')  ... fixes your problem (I assume python2 executes your system's python 2.7.12). Please repo

Re: issues with musicxml2ly

Hi Knut, Thanks a lot for your reply. I use Linux Mint 18.3, 64-bit, and my LilyPond is version 2.19.82. The default python interpreter in my installation is 2.7.12, which I think is what came with my Linux Mint 18.3 (I believe I've never bothered trying to update it since I do all my Python

Re: issues with musicxml2ly

Hi Gilberto! Let me know if I can help with anything else. Which operating system do you use? 32-bit or 64-bit? I suspect that you did not compile Lilypond yourself but used one of the installers. Am I right? If I'm right: Don't use the python interpreter distributed with lilypond, use

Re: issues with musicxml2ly

Just a small follow up, I forgot to mention that I my musicxml2ly version is 2.19.82. I am also attaching a .musicxml file generated by MuseScore and the .ly file generated by musicxml2ly. The .ly file does not compile and has the hidden characters and strange enconding I mentioned. test.musicxml

Re: [musicxml2ly] handling empty staffs

On 6/14/19, 9:35 AM, "Florian" wrote: Hi again, Carl Sorensen-3 wrote > I believe that this is less a bug in musicxml2ly and more a limitation of > musicxm2ly. MusicXML and Lilypond have fundamentally different concepts > of the

Re: [musicxml2ly] handling empty staffs

Hi again, Carl Sorensen-3 wrote > I believe that this is less a bug in musicxml2ly and more a limitation of > musicxm2ly. MusicXML and Lilypond have fundamentally different concepts > of the structure of music. These differences lead to inability to exactly > render the MusicXML

Re: [musicxml2ly] handling empty staffs

bug :) I hope we can avoid any manual post processing - that's why I'm using lilipond... I believe that this is less a bug in musicxml2ly and more a limitation of musicxm2ly. MusicXML and Lilypond have fundamentally different concepts of the structure of music. These diffe

Re: Aw: Re: [musicxml2ly] handling empty staffs

Hi Aaron, Aaron Hill wrote > Seems to be a case of the first context not being alive by the time the > other notes come along. If you manually added some spacer rests of > suitable length to the upper Staff... > > > \context Staff = "1" << >\mergeDifferentlyDottedOn

issues with musicxml2ly

Hello bug-squad, I ran into three issues when converting a .musicxml file generated with MuseScore into LilyPond: 1) the .ly file outut by musicxml2ly seems to have a weird encoding and outputs an error. There are many hidden characters which I had to remove manually in order to compile

Re: Aw: Re: [musicxml2ly] handling empty staffs

ot sure how this helps with musicxml2ly though. Is it capable of computing the length of music to be able to insert such spacer rests automatically? Or is there some way to link two contexts together so that they keep each other alive without needing manual interven

Aw: Re: [musicxml2ly] handling empty staffs

StaffErrorExample.ly Description: Binary data StaffErrorExample.musicxml Description: Binary data ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: [musicxml2ly] handling empty staffs

this is an error of musicxml2ly or lilipond … What do you think? I’ve attached the musicxml file, the ly and the generated svg and a screenshot of how it should look like… Thank you very much and with kind regards Florian Thank you for the report. However I didn't see anything attached to your

[musicxml2ly] handling empty staffs

measure both voices are the upper staff (E5, C5). This is a simplified version of an Hanon exercise where you usually start at a very low octave and repeatedly increase some note sequence up to a very high octave… I can’t tell whether this is an error of musicxml2ly or lilipond … What do you think

Re: [musicxml2ly] duplicated dynamics and hairpins when using multiple voices

Hi Florian, thanks for your report. Am So., 28. Apr. 2019 um 17:31 Uhr schrieb Florian : > > Hi, > Third attempt via nabble.com :) A remark: Ther are still no _attachments_. You do all inline, with the consequence making it impossible for me to simply download the musicxml-file. In the end I

Re: [musicxml2ly] duplicated dynamics and hairpins when using multiple voices

Hi, Third attempt via nabble.com :) 1. The musicxml file test.musicxml 2. The generated ly file test.ly 3. Screenshot from generated svg :

Re: [musicxml2ly] duplicated dynamics and hairpins when using multiple voices

nerated svg and pdf file Still no files. Neither directly, nor in the archives: http://lists.gnu.org/archive/html/bug-lilypond/2019-04/msg00039.html http://lilypond.1069038.n5.nabble.com/musicxml2ly-duplicated-dynamics-and-hairpins-when-using-multiple-voices-td22

Re: [musicxml2ly] duplicated dynamics and hairpins when using multiple voices

Hi, I don’t know why the first time sending files to the mailing list didn’t work - here’e my second attempt - I attached four files: 1. The musicxml file 2. The generated ly file 3,4 The generated svg and pdf file With kind regards /Florian > On 24 Apr 2019, at 07:23, Federico Bruni wrote:

Re: [musicxml2ly] duplicated dynamics and hairpins when using multiple voices

Hi Florian I can't see your attachments. Can you send them again? Il giorno mar 23 apr 2019 alle 18:54, Florian Grundig ha scritto: Hi all, I’ve encountered a strange behaviour when converting a musicXml document (exported from MuseScore 3.0.5) with two or more voices per staff in

[musicxml2ly] duplicated dynamics and hairpins when using multiple voices

Hi all, I’ve encountered a strange behaviour when converting a musicXml document (exported from MuseScore 3.0.5) with two or more voices per staff in combination with dynamics or hairpins -> the ly file contains the dynamics and the hairpins for each voice so they are also rendered several

Handling manual measure durations in musicxml2ly

Dear list, I am importing some scores of unmetered music into Lilypond via MusicXML, and naturally Lilypond is producing far superior results to Finale. To make the files appear as they do in other programs, I am trying to work out how to add support for manual measure durations in musicxml2ly

Re: musicxml2ly produces unexpected EOF in .ly file

by musicxml2ly in utilities.py) didn't  support unicode input prior to Python 2.7.3.  According to David Wright*  I misread. So we should upgrade Python in GUB? https://github.com/gperciva/gub/pull/6 I hope more people will be able to run GUB successfully. Only Phil can run it at the moment? I

Re: musicxml2ly produces unexpected EOF in .ly file

Il giorno dom 26 ago 2018 alle 16:12, David Kastrup ha scritto: Victor Rouanet writes: Le 26/08/2018 à 15:15, Victor Rouanet a écrit : Same result for me. According to Phil Homes in the lilypond-user topic, the shlex module (used by musicxml2ly in utilities.py) didn't support

Re: musicxml2ly produces unexpected EOF in .ly file

Victor Rouanet writes: > Le 26/08/2018 à 15:15, Victor Rouanet a écrit : >> Same result for me. According to Phil Homes in the lilypond-user >> topic, the shlex module (used by musicxml2ly in utilities.py) didn't >> support unicode input prior to Python 2.7.3. > Accord

Re: musicxml2ly produces unexpected EOF in .ly file

Le 26/08/2018 à 15:15, Victor Rouanet a écrit : Same result for me. According to Phil Homes in the lilypond-user topic, the shlex module (used by musicxml2ly in utilities.py) didn't support unicode input prior to Python 2.7.3. According to David Wright* I misread

Re: musicxml2ly produces unexpected EOF in .ly file

/.local/lilypond/usr/bin/python2.4 It's just my installation? Same result for me. According to Phil Homes in the lilypond-user topic, the shlex module (used by musicxml2ly in utilities.py) didn't support unicode input prior to Python 2.7.3. That would explain why the conversion only fails

Re: musicxml2ly produces unexpected EOF in .ly file

ersion were used by musicxml2ly when you tried? Yes, I was initially planning to report an issue about this wrong output, but I upgraded lilypond before and had to edit the musicexp.py again Le 24/08/2018 à 12:02, Federico Bruni a écrit : Il giorno ven 24 ago 2018 alle 11:33

Re: musicxml2ly produces unexpected EOF in .ly file

Il giorno ven 24 ago 2018 alle 12:11, Paul Hodges ha scritto: I was planning to report this. What's happening is that strings are being converted to 16-bit Unicode instead of UTF8, and so they are interspersed with nulls. If you remove the nulls with a capable editor, then that issue

Re: musicxml2ly produces unexpected EOF in .ly file

: musicxml2ly produces unexpected EOF in .ly file Good morning, I'm having an issue with musicxml2ly, installed with a manually downloaded version on lilypond 2.19.82. I exported a musicxml file from Musescore, then converted it to lilypond source with musicxml2ly without error. However, when

Re: musicxml2ly produces unexpected EOF in .ly file

Il giorno ven 24 ago 2018 alle 11:33, Victor Rouanet <"victor.rouanet"@gmx.fr> ha scritto: Good morning, I'm having an issue with musicxml2ly, installed with a manually downloaded version on lilypond 2.19.82. I exported a musicxml file from Musescore, then converted it to

musicxml2ly produces unexpected EOF in .ly file

Good morning, I'm having an issue with musicxml2ly, installed with a manually downloaded version on lilypond 2.19.82. I exported a musicxml file from Musescore, then converted it to lilypond source with musicxml2ly without error. However, when I try to compile it with lilypond, I get

Re: crash during musicxml2ly

Hello Frederic, On Sat, 14 Apr 2018 09:42:20 +, Frédéric Gohier <fgohie...@hotmail.com> wrote: > hello, > > I face a crash when run the command line : > /usr/local/bin/musicxml2ly --nd --nrp --npl --no-beaming -m > MusicXMLV2_from_sibelius7.xml > > the trace

Re: crash during musicxml2ly

the command line : /usr/local/bin/musicxml2ly --nd --nrp --npl --no-beaming -m MusicXMLV2_from_sibelius7.xml the traceback is : Traceback (most recent call last): File "/usr/local/bin/musicxml2ly", line 3277, in main() File "/usr/local/bin/musicxml2ly", line 3271, in main

crash during musicxml2ly

hello, I face a crash when run the command line : /usr/local/bin/musicxml2ly --nd --nrp --npl --no-beaming -m MusicXMLV2_from_sibelius7.xml the traceback is : Traceback (most recent call last): File "/usr/local/bin/musicxml2ly", line 3277, in main() File "/usr/local/

  1   2   3   >