[EMAIL PROTECTED] writes:
> My scheme isn't really up to much and the kind of code required to add
> Braille output will be more comfortable in C++ in my view.
> Modifying the grammar is trivial to add a \braille block. Where I take it
> from this is a bit of a mystery...
There are two options:
* To write a third translator type (we now have Engravers for
normal typesetting, and Performers), by making a derived class
from Translator. This new type (let's call it "Embosser"), can
setup data structures to print braille dots in any way that
you see fit. A lot of work, advantage: but you will not be
burdened by any constraints of the printed
output backend.
Disadvantage: you have to redo all formatting. If you go this
route, it might be easier to make a generic (musicxml)
outputter in lily, and write a separate application to convert
from the generic output to dots
* Write alternative engravers, that produces graphical objects
printing dots. This allows you to reuse spacing, line breaking
etc, and makes it easier to test if the dots are printed
correctly.
Once all the dots are printed correctly, make a separate
"printing backend" (next to the PostScript, TeX, and SVG one)
to drive a braille printer.
> I'm not entirely sure of the linkage between here (the bison parser) and
> midi output itself.
> In the meantime, I will keep on hacking.
>
> I feel that I need a crash course in basic Lilypond architecture to get me
> going..... :(
> Any takers?
There is a section in the user manual discussing internal
design. Other than that, the best guide is studying the source code
itself. If you take the second route, you can start out small by
making a single engraver and grob-type, eg. one that prints dots
corresponding to note heads only.
Good luck.
--
Han-Wen Nienhuys | [EMAIL PROTECTED] | http://www.cs.uu.nl/~hanwen
_______________________________________________
Lilypond-devel mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/lilypond-devel
