"Here's one I did earlier..." http://www.flickr.com/photos/44929957@N03/4459628487/lightbox/
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. 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. 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). On 21 August 2013 14:05, Johannes Waldmann <waldm...@imn.htwk-leipzig.de>wrote: > I tried using lilypond ( http://www.lilypond.org/ ) > for typesetting of sheet music. > > While the output looks nice, the input language IMHO is quite horrible, > because the underlying data/execution model is underspecified. > For some parts, it tries to describe the logical structure of the score; > but for others, the layout; and in addition it has several non-obvious > context-dependencies (but see below), preventing modularity. > > Is there a better option? E.g., starting from a clear mathematical model, > as in Haskore, and use lilypond only as a PDF rendering engine? > > Do I want hly / hts perhaps? http://rd.slavepianos.org/?t=hly > > > As I see it, the main high-level design problem > is that the source language needs partial evaluation annotations > for abstractions applications: sometimes they should be expanded > (for MIDI rendering, always) and sometimes not (in typesetting, > to create repetition marks instead of actually repeating notes). > > > PS: I agree that some of lilypond's context dependencies > (relative pitch, implicit note length) do really save > large amounts of tedious typing: "c4 e g a c1" is much more economical > than "[c 1 qn, e 1 qn, g 1 qn , a 1 qn, c 2 fn]" > which I guess is the Haskore equivalent. > > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
