Re: [Haskell-cafe] haskore -> lilypond -> typesetting?
"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
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
Abjad, which is a Python library, is probably worth study here for its
integration and general re-embrace of Lilypond as a compositional tool.
http://www.projectabjad.org/
Note that in Lilypond one can define a Scheme function over for example a
set of notes.
Al Matthews
-- http://fatmilktv.com
On Aug 21, 2013 12:41 PM, "Stephen Tetley"
"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
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
participants (2)
-
Al Matthews -
Stephen Tetley