Re: Performance and MIDI

[Ralph Little]

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