lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

MusicXML and GuileV2


From: David Kastrup
Subject: MusicXML and GuileV2
Date: Thu, 30 Aug 2012 19:04:17 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux)

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]