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: GDP: Predefined commands vs. commonly teaked properties
On 9/21/07, Graham Percival [EMAIL PROTECTED] wrote: Should we keep @refcommands independent from @commonprop ? For example, look at Tuplets. Do you like it as it is, or should we move \tupletUp \tupletDown etc inside the Commonly tweaked properties ? I vote for combine. -- Trevor Bača [EMAIL PROTECTED] ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GDP: Predefined commands vs. commonly teaked properties
2007/9/22, Trevor Bača [EMAIL PROTECTED]: On 9/21/07, Graham Percival [EMAIL PROTECTED] wrote: Should we keep @refcommands independent from @commonprop ? For example, look at Tuplets. Do you like it as it is, or should we move \tupletUp \tupletDown etc inside the Commonly tweaked properties ? I vote for combine. -1; the @refcommands shorcuts are much simpler than the \overrides (to understand, and to use), and therefore IMO they should be above @commonprop, just like they're now. Or, another idea, on the opposite: if they got merged with @commonprops, we should mention the extensive definition of each @refcomman, so that users could see by themselves a concrete application of some of the commonly tweaked properties, and feel somehow invited to write their own shortcuts. The reason I'm mentioning that is because we already specify the full syntax on several pages,like in Special NoteHeads, or Improvisation. (If this option is eventually accepted, I'm ready to write the full explanation of each refcommand myself, btw) Valentin ___ 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
Re: GDP: welcome, helpers!
Michael Rasmussen wrote: Graham Percival wrote: I've posted initial instructions for GDP helpers here: http://opihi.cs.uvic.ca/~gperciva/helper.txt I'll take pitches for $100, er first week. Graham, for the git-able among us what is the path to the git repository? (let's keep this on the mailist, in case I mis-typed somebody's email address... and in case this encourages more people to join. :) Great! We have our first claim; Michael Rasmussen is doing Pitches. We're using the lilypond/gdp branch. The lilypond repo is... actually, I don't know. See the Developing pages on the lilypond website; the address is there. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
