Re: MusicXML and GuileV2

[pls]

Hi David,

thanks for the hint. We'll keep it in mind. For now we extended John's stub a 
little bit. See https://github.com/Philomelos/lilypond-ly2musicxml.

Cheers,
patrick
Am 30.08.2012 um 19:04 schrieb David Kastrup:

> 
> Looking in the GuileV2 manual, I find
> 
> File: guile-2.0.info,  Node: Standard Library,  Next: GOOPS,  Prev: Guile 
> Modules,  Up: Top
> 
> 8 Standard Library
> ******************
> 
> * Menu:
> 
> * statprof::             Statistical profiler
> * sxml apply-templates::  A more XSLT-like approach to SXML transformations
> * sxml fold::            Fold-based SXML transformation operators
> * sxml simple::          Convenient XML parsing and serializing
> * sxml ssax::            Functional-style XML parsing for Scheme
> * sxml ssax input-parse::  The SSAX tokenizer, optimized for Guile
> * sxml transform::       A higher-order SXML transformation operator, 
> `pre-post-order'
> * sxml xpath::           XPath for SXML
> * texinfo::              Parse texinfo files or fragments into `stexi', a 
> scheme representation
> * texinfo docbook::      Transform a subset of docbook into `stexi'
> * texinfo html::         Transform `stexi' into HTML
> * texinfo indexing::     Extract an index from a piece of `stexi'
> * texinfo string-utils::  String utility functions used by the texinfo 
> processor
> * texinfo plain-text::   Render `stexi' as plain text
> * texinfo serialize::    Render `stexi' as texinfo
> * texinfo reflection::   Enable texinfo across Guile's help system
> 
> Considering that for MusicXML export we want to write valid XML, perhaps
> manipulate it, it would appear to make sense to not develop an
> independent implementation of XML input/output but rather make use of
> the existing work.
> 
> So it is another reason to speedily move to Guilev2 now that 2.17 has
> been started.
> 
> This would also seem to form an excellent starting point for having
> LilyPond interpret MusicXML directly, bypassing converters as well as
> the ly parser.  While this would not offer the full tweaking power and
> expressivity of ly, it would certainly be a good way of interfacing in a
> machine-readable manner.  If one wanted to wax poetic, one could view
> the ly/MusicXML pairing as a variation on the full/stripped theme that
> PostScript/PDF provides as input to Ghostscript: one a full,
> human-writable programming language, one a content-focused collection of
> elements.
> 
> -- 
> David Kastrup
> 
> 
> _______________________________________________
> lilypond-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/lilypond-devel