Hi

I've added functionality to make ob-lilypond act in a consistent org-babel way by default (think ob-dot).
The previous modus operandi is now known as arrange-mode and is selected by setting ly-arrange-mode to t

More details including examples are at http://github.com/mjago/ob-lilypond

Patch: 

Included examples are as follows...

 - Export org file with lilypond fragments to pdf using eps (high quality vector graphics)
   - org source: https://github.com/mjago/ob-lilypond/raw/master/examples/basic-mode/pdf-example/pdf-example.org
   - resultant pdf: https://github.com/mjago/ob-lilypond/blob/master/examples/basic-mode/pdf-example/pdf-example.pdf?raw=true
 - Export org file with lilypond fragments to html using png
   - org source: https://github.com/mjago/ob-lilypond/raw/master/examples/basic-mode/html-example/html-example.org
   - resultant html: https://raw.github.com/mjago/ob-lilypond/master/examples/basic-mode/html-example/html-example.html

Regards

Martyn

On 1 Jul 2011, at 13:01, Christian Moe wrote:

> On 6/30/11 8:10 PM, Eric Schulte wrote:
>> Martyn Jago<martyn.jago@btinternet.com>  writes:
>>> (...)
>> Great, I've just moved this into the Org-mode core and added it to the
>> list of Babel languages.
> 
> Great!
> 
>>> 
>>> One distinction that has occurred to me (especially following comments on
>>> the mailing list) is that of "babel language" and "babel language work-flow".
>>> In other words, I can visualise refactoring ob-lilypond to be no more than
>>> a specification of the Lilypond syntax, and working in parallel, on a
>>> work-flow implementation for Lilypond that is "opinionated" in terms of
>>> adjusting org-babel settings away from their defaults / removing work-flow
>>> noise etc. ( org-lilypond.el ) ? Would this make sense, and if so where would
>>> it live (aligned to org-babel / a native Emacs mode perhaps)?
>>> I hope that makes sense.
>>> 
>> 
>> That sounds like a good idea.  Ideally ob-lilypond should include just
>> those elements expected by the code block interface, namely functions
>> for session/external evaluation, for expanding variables in code block
>> bodies, and for returning results to Org-mode.  I think that it would be
>> a good idea to develop an external org-lilypond to support a more
>> comprehensive workflow.
> 
> I like this.
> 
> I certainly see that the already complex task of making arrangements like those in Martyn's examples should be made as easy as possible.
> 
> As for the comparatively simple use cases I brought up, once they're supported by ob-lilypond I'd be perfectly happy to throw header arguments at them.
> 
> Yours,
> Christian