[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Performance and MIDI

From: Ralph Little
Subject: Re: Performance and MIDI
Date: Sat, 22 Sep 2007 10:13:13 -0700
User-agent: Thunderbird (Windows/20070728)

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]