<p>Abjad, which is a Python library, is probably worth study here for its integration and general re-embrace of Lilypond as a compositional tool.</p>
<p><a href="http://www.projectabjad.org/">http://www.projectabjad.org/</a></p>
<p>Note that in Lilypond one can define a Scheme function over for example a set of notes.</p>
<p>Al Matthews <br>
-- <a href="http://fatmilktv.com">http://fatmilktv.com</a></p>
<p>On Aug 21, 2013 12:41 PM, "Stephen Tetley" <<a href="mailto:stephen.tetley@gmail.com">stephen.tetley@gmail.com</a>> wrote:<br>
><br>
><br>
> "Here's one I did earlier..."<br>
><br>
> <a href="http://www.flickr.com/photos/44929957@N03/4459628487/lightbox/">http://www.flickr.com/photos/44929957@N03/4459628487/lightbox/</a><br>
><br>
> This is Haskore implementation of Chick Corea's "Child Song 6" rendered to LilyPond - I don't imagine Mr. Corea's publishers will be sending me a takedown request any time soon.<br>
><br>
> There's a lot missing from Haskore that is needed to make good scores - the renderer of the above took a lot of effort with metrical grouping but the result is still abysmal. <br>
><br>
> I doubt mathematics can help (common practice) music typesetting much - Western notation has had a thousand years to develop without the constraint of a regular syntax; so if Lilypond is horrible it is mostly the fault of what it tries to typeset (it does make some unwarranted mistakes like over-restricting the characters it can use for "variable" names and its parenthesizing is horrible).<br>
><br>
><br>
> On 21 August 2013 14:05, Johannes Waldmann <<a href="mailto:waldmann@imn.htwk-leipzig.de">waldmann@imn.htwk-leipzig.de</a>> wrote:<br>
>><br>
>> I tried using lilypond ( <a href="http://www.lilypond.org/">http://www.lilypond.org/</a> )<br>
>> for typesetting of sheet music.<br>
>><br>
>> While the output looks nice, the input language IMHO is quite horrible,<br>
>> because the underlying data/execution model is underspecified.<br>
>> For some parts, it tries to describe the logical structure of the score;<br>
>> but for others, the layout; and in addition it has several non-obvious<br>
>> context-dependencies (but see below), preventing modularity.<br>
>><br>
>> Is there a better option? E.g., starting from a clear mathematical model,<br>
>> as in Haskore, and use lilypond only as a PDF rendering engine?<br>
>><br>
>> Do I want hly / hts perhaps? <a href="http://rd.slavepianos.org/?t=hly">http://rd.slavepianos.org/?t=hly</a><br>
>><br>
>><br>
>> As I see it, the main high-level design problem<br>
>> is that the source language needs partial evaluation annotations<br>
>> for abstractions applications: sometimes they should be expanded<br>
>> (for MIDI rendering, always) and sometimes not (in typesetting,<br>
>> to create repetition marks instead of actually repeating notes).<br>
>><br>
>><br>
>> PS: I agree that some of lilypond's context dependencies<br>
>> (relative pitch, implicit note length) do really save<br>
>> large amounts of tedious typing: "c4 e g a c1" is much more economical<br>
>> than "[c 1 qn, e 1 qn, g 1 qn , a 1 qn, c 2 fn]"<br>
>> which I guess is the Haskore equivalent.<br>
>><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> Haskell-Cafe mailing list<br>
>> <a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
>> <a href="http://www.haskell.org/mailman/listinfo/haskell-cafe">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> Haskell-Cafe mailing list<br>
> <a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
> <a href="http://www.haskell.org/mailman/listinfo/haskell-cafe">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
><br>
</p>