Erik Sandberg wrote:
But in any case: Engravers (which produce a sheet-music-friendly grob graph)
and Performers (which produce some midi-friendly data structure), are both
subclasses of Translators. If you are going to produce Braille output (which
is my guess for some unknown reason), you could either create your own
subclass of Translator (which probably would resemble Engraver but be
simpler), or you could try creating a translator framework in Scheme (which
would be cooler but slower). Or, if Braille output is very similar to MIDI in
structure (I am clueless), it may be possible to refactor performers, so they
generate datastructures containing the union of interesting information for
MIDI and braille, and then create the braille output as a back-end behind
performers.
Hi Erik,
:D You guess right.
Looking from the other end (rather than shoe-horning something into the
stream-event side with Scheme) I have produced another Performance-type
class, called BrailleOutput derived from MusicOutput which does a
similar kind of thing and I can pick up the information that I need for
Braille from this.
However, if I go down that route, I would spit out another set of
"performer"-type modules analageous to "Note_Performer" etc perhaps
"Note_Embosser" (as was suggested by Han-Wen sometime back when I was
looking at it before) to catch events and do the backend stuff...which I
don't mind - the structure seems clear enough, but I did wonder if that
was the way to go. If anyone else were to generate a different output
type in the future, I can see a large escalation in the number of
modules and files accordingly.
This begs a bigger question as to what Han-Wen and Jan think about
future developments in this area and what structure and approach they
would like to see in terms of adding new output formats. The new stream
event stuff holds much promise for simplifying this area. If Han-Wen or
Jan is interested, I would be interested in getting their opinion on this.
The Braille output will require some parameters (e.g. output page width,
embosser character set) which could be satisfied with a \braille{}
block, so following the path that MIDI takes currently seemed like a way
to go, especially since a lot of what I need to do it just a case of
emulating what the MIDI stuff does anyway. I have already got an
incomplete implementation that goes so far using this method.
I've written some self-contained backend braille code both in scheme and
a version in C++ and that in itself seems pretty straightforward.
Although studying this is giving me a really interesting insight as to
how Lilypond fits together internally, I do find that producing the
Braille itself is a simple programming problem compared to shoehorning
it into Lilypond :P
Regards,
Ralph
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel