Re: Performance and MIDI
Ralph Little escreveu: Hi, The code behind MIDI output and Performance seem to be pretty much tightly tied together. Was it ever intended that Performance be used for other output types? The Performance class contains specific MIDI references. It was intended as such, but we never got round to it, and there seems little interest in building anything like this. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Performance and MIDI
On Friday 21 September 2007, Ralph Little wrote: Hi, The code behind MIDI output and Performance seem to be pretty much tightly tied together. Was it ever intended that Performance be used for other output types? The Performance class contains specific MIDI references. I was under the impression that MIDI output was but one implementation of the Performance facility, but that does not now seem to be the case. I don't remember exactly, but I think performers generate some kind of intermediate data structure (containing the information interesting to MIDI generation), this data structure is then is converterted into MIDI. So yes, it's likely that much of the information produced by performers are very midi specific. It is also possible that you can generate non-MIDI from the intermediate format, just as you can generate either gnome or tex output from grobs/stencils. Long ago, Han-Wen suggested to make a major rewrite of the MIDI back-end, to produce richer output. I think one part of this would be to improve the intermediate data structure generated by performers. I don't think this ever was done. 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. Erik ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Performance and MIDI
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
Performance and MIDI
Hi, The code behind MIDI output and Performance seem to be pretty much tightly tied together. Was it ever intended that Performance be used for other output types? The Performance class contains specific MIDI references. I was under the impression that MIDI output was but one implementation of the Performance facility, but that does not now seem to be the case. Regards, Ralph ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
