Re: Export to MusicXML

2018-10-16 Thread James

Hello Alex,

On 16/10/2018 5:49 am, Alex Roitman wrote:

Hello,

I apologize in advance if this was already asked and answered on this list.  
I’m looking into exporting some of my lilypond music into the MusicXML format. 
All I could find so far was the python-ly package that attempts to translate ly 
files into MusicXML.  It has some issues that could be fixed, and some that I 
don’t think could be so easily fixed, e.g. whether or not to place accidentals, 
beams, and so on.

It seems to me that the nature of the MusicXML format is such that in can only 
be correctly written when the music is interpreted in context.  Which is what 
lilypond does.  So I’m guessing that the right way to go about this is to 
create a new Translator, alongside Performer and Engraver, that instead of 
midi/graphical objects just dumps XML.

Finally, here are my questions:
1. Does this seem like a right approach?
2. Was this ever attempted and is there any work left that one can continue?

Thanks in advance for any help!
Alex


I am not sure about work that was 'left' (or attempted in the past) but 
I assume you have checked our issue tracker? (although a lot of the open 
issues are to do with musicxml2ly than anything else.


At first blush I'd say no. However I have only been with LP for ~ 6 
years and cannot recall anything in that time, but there may have been 
some work done previously, but I cannot see any 'abandoned' issues 
either - where you may see some remnant of previous work/patches.


Also see:

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

Which may have some of the kind of answers/information you might be seeking.


Regards

James




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


Re: Export to MusicXML

2018-10-16 Thread Jan-Peter Voigt
Hello Alex,

you don't have to apologize for this question! It comes up every now and
then, but has not been answered satisfyingly yet. My answers to your
questions are:
1. Yes
2. I wrote a rudimentary engraver-based solution last year which is
waiting for clean-up and completion to support MEI, MusicXML, Humdrum,
LilyPond (!) and any other format for which an export-module with a
defined API exists.
https://github.com/jpvoigt/lilypond-export/

The code in the project is able to export a MusicXML-File for a simple
lilypond-score. The resulting files are not always correct/functional so
this is more sketch of the idea. The base is an engraver that fetches
and collects events and on score-finalization calls the specified export
module with this (normalized) music collection.
The collection is some scheme-structure, but should probably be better a
normal LilyPond music-expression.

Just a little piece of something ;-)
HTH
Jan-Peter


Am 16.10.2018 um 06:49 schrieb Alex Roitman:
> Hello,
> 
> I apologize in advance if this was already asked and answered on this list.  
> I’m looking into exporting some of my lilypond music into the MusicXML 
> format. All I could find so far was the python-ly package that attempts to 
> translate ly files into MusicXML.  It has some issues that could be fixed, 
> and some that I don’t think could be so easily fixed, e.g. whether or not to 
> place accidentals, beams, and so on.
> 
> It seems to me that the nature of the MusicXML format is such that in can 
> only be correctly written when the music is interpreted in context.  Which is 
> what lilypond does.  So I’m guessing that the right way to go about this is 
> to create a new Translator, alongside Performer and Engraver, that instead of 
> midi/graphical objects just dumps XML.
> 
> Finally, here are my questions:
> 1. Does this seem like a right approach?
> 2. Was this ever attempted and is there any work left that one can continue?
> 
> Thanks in advance for any help!
> Alex
> 
> 
> ___
> 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: Export to MusicXML

2018-10-16 Thread Paul Morris

For Google Summer of Code 2015 David Garfinkle worked on MusicXML export.

(See mailing list archives: 
https://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=Garfinkle&submit=Search%21&idxname=lilypond-devel&max=20&result=normal&sort=score 
)


I don't know if the code he wrote was ever checked in somewhere, on a 
branch or something.  (It's not mentioned in the issue for this 
feature.)  I have a copy of it somewhere that he sent me, but I'd assume 
that Jan-Peter's work on this would be the better place to start / 
collaborate.


-Paul

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


Re: Export to MusicXML

2018-10-16 Thread Kieren MacMillan
Hi Jan-Peter,

> 2. I wrote a rudimentary engraver-based solution last year which is
> waiting for clean-up and completion to support MEI, MusicXML

> The code in the project is able to export a MusicXML-File for a simple
> lilypond-score. The resulting files are not always correct/functional so
> this is more sketch of the idea. The base is an engraver that fetches
> and collects events and on score-finalization calls the specified export
> module with this (normalized) music collection.
> The collection is some scheme-structure, but should probably be better a
> normal LilyPond music-expression.

1. Why would it be "better" as a normal Lilypond music-expression?

2. Is it currently in a state where someone with limited Scheme chops, but good 
XML chops, could take the MusicXML portion to the goal line? 

Thanks,
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


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


Re: Export to MusicXML

2018-10-16 Thread Paul Morris

On 10/16/2018 10:48 AM, Paul Morris wrote:

I don't know if the code he wrote was ever checked in somewhere, on a 
branch or something.  (It's not mentioned in the issue for this feature.)


I've now added the GSOC 2015 code to the issue and put a link to 
Jan-Peter's work there as well. 
https://sourceforge.net/p/testlilyissues/issues/665/


-Paul

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


Re: Export to MusicXML

2018-10-16 Thread David Kastrup
Paul Morris  writes:

> For Google Summer of Code 2015 David Garfinkle worked on MusicXML export.
>
> (See mailing list archives:
> https://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=Garfinkle&submit=Search%21&idxname=lilypond-devel&max=20&result=normal&sort=score
> )
>
> I don't know if the code he wrote was ever checked in somewhere, on a
> branch or something.  (It's not mentioned in the issue for this
> feature.)  I have a copy of it somewhere that he sent me, but I'd
> assume that Jan-Peter's work on this would be the better place to
> start / collaborate.

I posted it a few times on the mailing list, having acted as the mentor.
One problem is that it will be of best utility once Guile-2 (and the
respective XML libraries) are in use, and it's more a technological
starting point than a result-oriented one.  Of course, the ultimate goal
is the same.

-- 
David Kastrup

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


Re: Export to MusicXML

2018-10-16 Thread James Lowe

Hello

(we seemed to have lost Alex along the way on this thread)

On 16/10/2018 3:48 pm, Paul Morris wrote:

For Google Summer of Code 2015 David Garfinkle worked on MusicXML export.

(See mailing list archives: 
https://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=Garfinkle&submit=Search%21&idxname=lilypond-devel&max=20&result=normal&sort=score 
)


I don't know if the code he wrote was ever checked in somewhere, on a 
branch or something.  (It's not mentioned in the issue for this 
feature.)  I have a copy of it somewhere that he sent me, but I'd 
assume that Jan-Peter's work on this would be the better place to 
start / collaborate.


-Paul


You can see it still here

https://docs.google.com/document/d/12zLGWrf6a_0J9H44Coo25s-pYsv-zH_g-oBqw6Shnrc/edit?usp=sharing,

(I checked)

Also see: 
http://lists.gnu.org/archive/html/lilypond-devel/2016-03/msg00167.html



James


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


Re: 2.20 plans.

2018-10-16 Thread Phil Holmes



- Original Message - 
From: "David Kastrup" 

To: 
Sent: Monday, October 08, 2018 4:35 PM
Subject: 2.20 plans.




Hi,

I don't think there is much of a point in delaying more.  I've recently
made another run through patches that should be in 2.20 and pushed to
stable/2.20 branch.

I think further integration work is as likely to destabilize as to
stabilize stuff (if I not already did so), so the plan is to have
a) let Phil release 2.19.83 as soon as he wants
b) release 2.20.0 from that state (with a few cherry-picks on top) about
a week after the last urgent "stop the presses" call.  Those would
involve synching up documentation and bug fixes so obviously important
that one would rather see them in than give them some time for testing.

This will be followed (as soon as the state of download/web pages and
Phil's resources permit) with releasing 2.21.0 to get an unstable
version to refer to.

--
David Kastrup



I've been trying a GUB build today.  It's failed rather strangely.  At first 
I got:


Command barfed: cd /home/gub/NewGub/gub/downloads/lilypond/git && git fetch 
git://git.sv.gnu.org/lilypond.git 
stable/2.20:refs/heads/git.sv.gnu.org/lilypond.git/stable/2.20


Tail of log/gub.log 
*** Stage: download (lilypond, darwin-x86)
invoking cd /home/gub/NewGub/gub/downloads/lilypond/git && git fetch 
git://git.sv.gnu.org/lilypond.git 
stable/2.20:refs/heads/git.sv.gnu.org/lilypond.git/stable/2.20
fatal: Unable to look up git.sv.gnu.org (port 9418) (Name or service not 
known)
Command barfed: cd /home/gub/NewGub/gub/downloads/lilypond/git && git fetch 
git://git.sv.gnu.org/lilypond.git 
stable/2.20:refs/heads/git.sv.gnu.org/lilypond.git/stable/2.20



I thought that might be down to a network problem, so I tried the network 
and it looked OK so I ran the make again and this time I got:



Tail of target/freebsd-x86/log/lilypond.log 
building package: freebsd-x86::lilypond
*** Stage: download (lilypond, freebsd-x86)
*** Stage: untar (lilypond, freebsd-x86)
invoking cd /home/gub/NewGub/gub/downloads/lilypond/git && git fetch 
git://git.sv.gnu.org/lilypond.git 
stable/2.20:refs/heads/git.sv.gnu.org/lilypond.git/stable/2.20

 Tail of target/freebsd-x86/log/lilypond.log

Traceback (most recent call last):
File "bin/gub", line 233, in exceptional_build
build (settings, options, files)
File "bin/gub", line 229, in build
b.build_source_packages (names)
File "bin/../gub/buildrunner.py", line 334, in build_source_packages
self.spec_build (spec_name)
File "bin/../gub/buildrunner.py", line 262, in spec_build
deferred_runner.execute_deferred_commands ()
File "bin/../gub/runner.py", line 167, in execute_deferred_commands
cmd.execute (self.logger)
File "bin/../gub/commands.py", line 48, in execute
buildspec.source.update_workdir (buildspec.expand ('%(srcdir)s'))
File "bin/../gub/repository.py", line 699, in update_workdir
self._update_workdir_shallow (destdir)
File "bin/../gub/repository.py", line 707, in _update_workdir_shallow
barf
NameError: global name 'barf' is not defined


Any thoughts of where to go from here?


--
Phil Holmes 



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


Re: Export to MusicXML

2018-10-16 Thread Alex Roitman
I saw the code link, and I will check it out soon, thank you all!

Alex

> On Oct 16, 2018, at 8:32 AM, David Kastrup  wrote:
> 
> Paul Morris  writes:
> 
>> For Google Summer of Code 2015 David Garfinkle worked on MusicXML export.
>> 
>> (See mailing list archives:
>> https://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=Garfinkle&submit=Search%21&idxname=lilypond-devel&max=20&result=normal&sort=score
>> )
>> 
>> I don't know if the code he wrote was ever checked in somewhere, on a
>> branch or something.  (It's not mentioned in the issue for this
>> feature.)  I have a copy of it somewhere that he sent me, but I'd
>> assume that Jan-Peter's work on this would be the better place to
>> start / collaborate.
> 
> I posted it a few times on the mailing list, having acted as the mentor.
> One problem is that it will be of best utility once Guile-2 (and the
> respective XML libraries) are in use, and it's more a technological
> starting point than a result-oriented one.  Of course, the ultimate goal
> is the same.
> 
> -- 
> David Kastrup
> 
> ___
> 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: Export to MusicXML

2018-10-16 Thread Alex Roitman
Thank you Jan-Peter!  This looks really promising, and I’d love to contribute.

I’m only vaguely familiar with Scheme so I’ll probably take a bit of time to 
get my hands dirty with that.  Would it be OK to bug you with questions every 
now and then? Is this list a good place, or should I just email you privately?  
I promise I won’t abuse your kindness :-)

Alex

> On Oct 16, 2018, at 2:04 AM, Jan-Peter Voigt  wrote:
> 
> Hello Alex,
> 
> you don't have to apologize for this question! It comes up every now and
> then, but has not been answered satisfyingly yet. My answers to your
> questions are:
> 1. Yes
> 2. I wrote a rudimentary engraver-based solution last year which is
> waiting for clean-up and completion to support MEI, MusicXML, Humdrum,
> LilyPond (!) and any other format for which an export-module with a
> defined API exists.
> https://github.com/jpvoigt/lilypond-export/
> 
> The code in the project is able to export a MusicXML-File for a simple
> lilypond-score. The resulting files are not always correct/functional so
> this is more sketch of the idea. The base is an engraver that fetches
> and collects events and on score-finalization calls the specified export
> module with this (normalized) music collection.
> The collection is some scheme-structure, but should probably be better a
> normal LilyPond music-expression.
> 
> Just a little piece of something ;-)
> HTH
> Jan-Peter
> 
> 
> Am 16.10.2018 um 06:49 schrieb Alex Roitman:
>> Hello,
>> 
>> I apologize in advance if this was already asked and answered on this list.  
>> I’m looking into exporting some of my lilypond music into the MusicXML 
>> format. All I could find so far was the python-ly package that attempts to 
>> translate ly files into MusicXML.  It has some issues that could be fixed, 
>> and some that I don’t think could be so easily fixed, e.g. whether or not to 
>> place accidentals, beams, and so on.
>> 
>> It seems to me that the nature of the MusicXML format is such that in can 
>> only be correctly written when the music is interpreted in context.  Which 
>> is what lilypond does.  So I’m guessing that the right way to go about this 
>> is to create a new Translator, alongside Performer and Engraver, that 
>> instead of midi/graphical objects just dumps XML.
>> 
>> Finally, here are my questions:
>> 1. Does this seem like a right approach?
>> 2. Was this ever attempted and is there any work left that one can continue?
>> 
>> Thanks in advance for any help!
>> Alex
>> 
>> 
>> ___
>> 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


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


Re: Export to MusicXML

2018-10-16 Thread Urs Liska


Am 16. Oktober 2018 20:13:29 MESZ schrieb Alex Roitman :
>Thank you Jan-Peter!  This looks really promising, and I’d love to
>contribute.
>
>I’m only vaguely familiar with Scheme so I’ll probably take a bit of
>time to get my hands dirty with that.  Would it be OK to bug you with
>questions every now and then? Is this list a good place, or should I
>just email you privately?  I promise I won’t abuse your kindness :-)

Please use this list, as there are several others who may be interested and / 
or helpful.

Urs

>
>Alex
>
>> On Oct 16, 2018, at 2:04 AM, Jan-Peter Voigt  wrote:
>> 
>> Hello Alex,
>> 
>> you don't have to apologize for this question! It comes up every now
>and
>> then, but has not been answered satisfyingly yet. My answers to your
>> questions are:
>> 1. Yes
>> 2. I wrote a rudimentary engraver-based solution last year which is
>> waiting for clean-up and completion to support MEI, MusicXML,
>Humdrum,
>> LilyPond (!) and any other format for which an export-module with a
>> defined API exists.
>> https://github.com/jpvoigt/lilypond-export/
>> 
>> The code in the project is able to export a MusicXML-File for a
>simple
>> lilypond-score. The resulting files are not always correct/functional
>so
>> this is more sketch of the idea. The base is an engraver that fetches
>> and collects events and on score-finalization calls the specified
>export
>> module with this (normalized) music collection.
>> The collection is some scheme-structure, but should probably be
>better a
>> normal LilyPond music-expression.
>> 
>> Just a little piece of something ;-)
>> HTH
>> Jan-Peter
>> 
>> 
>> Am 16.10.2018 um 06:49 schrieb Alex Roitman:
>>> Hello,
>>> 
>>> I apologize in advance if this was already asked and answered on
>this list.  I’m looking into exporting some of my lilypond music into
>the MusicXML format. All I could find so far was the python-ly package
>that attempts to translate ly files into MusicXML.  It has some issues
>that could be fixed, and some that I don’t think could be so easily
>fixed, e.g. whether or not to place accidentals, beams, and so on.
>>> 
>>> It seems to me that the nature of the MusicXML format is such that
>in can only be correctly written when the music is interpreted in
>context.  Which is what lilypond does.  So I’m guessing that the right
>way to go about this is to create a new Translator, alongside Performer
>and Engraver, that instead of midi/graphical objects just dumps XML.
>>> 
>>> Finally, here are my questions:
>>> 1. Does this seem like a right approach?
>>> 2. Was this ever attempted and is there any work left that one can
>continue?
>>> 
>>> Thanks in advance for any help!
>>> Alex
>>> 
>>> 
>>> ___
>>> 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
>
>
>___
>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: 2.20 plans.

2018-10-16 Thread David Kastrup
"Phil Holmes"  writes:

> I've been trying a GUB build today.  It's failed rather strangely.  At
> first I got:
>
> Command barfed: cd /home/gub/NewGub/gub/downloads/lilypond/git && git
> fetch git://git.sv.gnu.org/lilypond.git
> stable/2.20:refs/heads/git.sv.gnu.org/lilypond.git/stable/2.20
>
> Tail of log/gub.log 
> *** Stage: download (lilypond, darwin-x86)
> invoking cd /home/gub/NewGub/gub/downloads/lilypond/git && git fetch
> git://git.sv.gnu.org/lilypond.git
> stable/2.20:refs/heads/git.sv.gnu.org/lilypond.git/stable/2.20
> fatal: Unable to look up git.sv.gnu.org (port 9418) (Name or service
> not known)
> Command barfed: cd /home/gub/NewGub/gub/downloads/lilypond/git && git
> fetch git://git.sv.gnu.org/lilypond.git
> stable/2.20:refs/heads/git.sv.gnu.org/lilypond.git/stable/2.20
>
>
> I thought that might be down to a network problem, so I tried the
> network and it looked OK so I ran the make again and this time I got:
>
>
> Tail of target/freebsd-x86/log/lilypond.log 
> building package: freebsd-x86::lilypond
> *** Stage: download (lilypond, freebsd-x86)
> *** Stage: untar (lilypond, freebsd-x86)
> invoking cd /home/gub/NewGub/gub/downloads/lilypond/git && git fetch
> git://git.sv.gnu.org/lilypond.git
> stable/2.20:refs/heads/git.sv.gnu.org/lilypond.git/stable/2.20
>  Tail of target/freebsd-x86/log/lilypond.log
>
> Traceback (most recent call last):
> File "bin/gub", line 233, in exceptional_build
> build (settings, options, files)
> File "bin/gub", line 229, in build
> b.build_source_packages (names)
> File "bin/../gub/buildrunner.py", line 334, in build_source_packages
> self.spec_build (spec_name)
> File "bin/../gub/buildrunner.py", line 262, in spec_build
> deferred_runner.execute_deferred_commands ()
> File "bin/../gub/runner.py", line 167, in execute_deferred_commands
> cmd.execute (self.logger)
> File "bin/../gub/commands.py", line 48, in execute
> buildspec.source.update_workdir (buildspec.expand ('%(srcdir)s'))
> File "bin/../gub/repository.py", line 699, in update_workdir
> self._update_workdir_shallow (destdir)
> File "bin/../gub/repository.py", line 707, in _update_workdir_shallow
> barf
> NameError: global name 'barf' is not defined
>
>
> Any thoughts of where to go from here?

"barf" sounds like an intentionally undefined function, "called" in
order to get a backtrace.

When I learnt programming, long long ago in the time of punch cards, my
mentor used "CALL HUGO" for this purpose.  Indeed this triggered a
_runtime_ error on the Fortran 77 compiler of the Cyber 175.

I guess this is the same trick, just for Python.  So now we have a
backtrace.  We just need to figure out what reason "barf" is getting
called for.  What's in line 707 of repository.py ?

-- 
David Kastrup

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


Re: Export to MusicXML

2018-10-16 Thread Jan-Peter Voigt
Hi Alex,

you're very welcome! And I'm always open for questions and discussions
about the code. For general questions you should use the list so that
others can join or at least follow the discussion. (I think Urs said so
already). If we get to the point where direct communication is
reasonable we can also exchange jabber, skype, slack or signal contacts.

Jan-Peter




Am 16.10.18 um 20:13 schrieb Alex Roitman:
> Thank you Jan-Peter!  This looks really promising, and I’d love to contribute.
> 
> I’m only vaguely familiar with Scheme so I’ll probably take a bit of time to 
> get my hands dirty with that.  Would it be OK to bug you with questions every 
> now and then? Is this list a good place, or should I just email you 
> privately?  I promise I won’t abuse your kindness :-)
> 
> Alex
> 
>> On Oct 16, 2018, at 2:04 AM, Jan-Peter Voigt  wrote:
>>
>> Hello Alex,
>>
>> you don't have to apologize for this question! It comes up every now and
>> then, but has not been answered satisfyingly yet. My answers to your
>> questions are:
>> 1. Yes
>> 2. I wrote a rudimentary engraver-based solution last year which is
>> waiting for clean-up and completion to support MEI, MusicXML, Humdrum,
>> LilyPond (!) and any other format for which an export-module with a
>> defined API exists.
>> https://github.com/jpvoigt/lilypond-export/
>>
>> The code in the project is able to export a MusicXML-File for a simple
>> lilypond-score. The resulting files are not always correct/functional so
>> this is more sketch of the idea. The base is an engraver that fetches
>> and collects events and on score-finalization calls the specified export
>> module with this (normalized) music collection.
>> The collection is some scheme-structure, but should probably be better a
>> normal LilyPond music-expression.
>>
>> Just a little piece of something ;-)
>> HTH
>> Jan-Peter
>>
>>
>> Am 16.10.2018 um 06:49 schrieb Alex Roitman:
>>> Hello,
>>>
>>> I apologize in advance if this was already asked and answered on this list. 
>>>  I’m looking into exporting some of my lilypond music into the MusicXML 
>>> format. All I could find so far was the python-ly package that attempts to 
>>> translate ly files into MusicXML.  It has some issues that could be fixed, 
>>> and some that I don’t think could be so easily fixed, e.g. whether or not 
>>> to place accidentals, beams, and so on.
>>>
>>> It seems to me that the nature of the MusicXML format is such that in can 
>>> only be correctly written when the music is interpreted in context.  Which 
>>> is what lilypond does.  So I’m guessing that the right way to go about this 
>>> is to create a new Translator, alongside Performer and Engraver, that 
>>> instead of midi/graphical objects just dumps XML.
>>>
>>> Finally, here are my questions:
>>> 1. Does this seem like a right approach?
>>> 2. Was this ever attempted and is there any work left that one can continue?
>>>
>>> Thanks in advance for any help!
>>> Alex
>>>
>>>

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


Re: Export to MusicXML

2018-10-16 Thread Jan-Peter Voigt
... by the way: what is the current state of guile2 in lilypond?
I recently noticed some mails on the list.

Jan-Peter

Am 16.10.18 um 17:32 schrieb David Kastrup:
> Paul Morris  writes:
> 
>> For Google Summer of Code 2015 David Garfinkle worked on MusicXML export.
>>
>> (See mailing list archives:
>> https://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=Garfinkle&submit=Search%21&idxname=lilypond-devel&max=20&result=normal&sort=score
>> )
>>
>> I don't know if the code he wrote was ever checked in somewhere, on a
>> branch or something.  (It's not mentioned in the issue for this
>> feature.)  I have a copy of it somewhere that he sent me, but I'd
>> assume that Jan-Peter's work on this would be the better place to
>> start / collaborate.
> 
> I posted it a few times on the mailing list, having acted as the mentor.
> One problem is that it will be of best utility once Guile-2 (and the
> respective XML libraries) are in use, and it's more a technological
> starting point than a result-oriented one.  Of course, the ultimate goal
> is the same.
> 


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


Re: Export to MusicXML

2018-10-16 Thread Jan-Peter Voigt
Hi Kieren,


Am 16.10.18 um 16:54 schrieb Kieren MacMillan:
> Hi Jan-Peter,
> 
>> 2. I wrote a rudimentary engraver-based solution last year which is
>> waiting for clean-up and completion to support MEI, MusicXML
> 
>> The code in the project is able to export a MusicXML-File for a simple
>> lilypond-score. The resulting files are not always correct/functional so
>> this is more sketch of the idea. The base is an engraver that fetches
>> and collects events and on score-finalization calls the specified export
>> module with this (normalized) music collection.
>> The collection is some scheme-structure, but should probably be better a
>> normal LilyPond music-expression.
> 
> 1. Why would it be "better" as a normal Lilypond music-expression?
hm, did I misorder my words? Now I think it maybe be better to store the
music in plain lilypond expressions e.g. SequentialMusic. Right now the
music is stored in an alist by measure and moment. That way the exporter
can easily iterate over the measures and moments and place the events in
the resulting export format, but my intuition says that it might be
better if the exporter modules rely on something lilypond can reuse
itself directly. In other words: I think it would be better *not* to
create another structure.
But it is just something to have in mind and to consider while
developing further.

> 2. Is it currently in a state where someone with limited Scheme chops, but 
> good XML chops, could take the MusicXML portion to the goal line? 
Right now it is a sketch of an idea, so it might or might not fulfill
anyones needs:

1. it is incomplete in that it doesn't translate all elements.
2. the MusicXML is created "manually" with simple string-concatenation.
That is not a problem if the resulting file is correct, but ...
3. some files are incorrect and cannot be loaded by MuseScore

It would be very helpful to have an XML-lib at hand for the export. I
started a simple function that takes an alist structure end writes it as
XML. But I am hesitant to really use that because if it is injected it
might stop the integration of the standard libs when they are available.

Jan-Peter

> 
> Thanks,
> Kieren.
> 
> 
> Kieren MacMillan, composer
> ‣ website: www.kierenmacmillan.info
> ‣ email: i...@kierenmacmillan.info
> 


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