Han-Wen Nienhuys <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] writes: >> I am working on a revamping the audio output portion of Lilypond, and >> find myself in need of advice. The idea is to use a set of >> translators (performers) to convert the music into a time-ordered >> output-generic representation of the music, and to do the conversion >> into the final output format (MIDI files, for example) completely in >> scheme. >> >> In the process, I have been using a variant on Audio_elements to build >> this representation. But I find myself wondering what that gains me. >> Is there any reason to use a set of C++ objects instead of straight >> Scheme to make this representation? More generically, when do you >> think objects should be in C++, and when in Scheme? If I stick with >> C++ objects (which I am loathe to do without a good reason), I will >> need to write a set of scheme accessor methods, regardless. > > There is no clear cut recipe to determine what is best, but I myself > are more fluent in C++ (and often prefer it for things). Also, using > C++ classes as framework makes it easier to do data-hiding. > > If I were you, I would try to mimick the setup of the notation > backend. This is what I wrote earlier about revamping MIDI, > > The problem with lily ATM is that it lacks the infrastructure to get > the right information about the right performance aspects in the right > places. The plan is to tackle that first, and then put some simple > effects. > > Concrete: > > * The plan is to make the MIDI work like the notation backend: with > Snobs (Sound objects) that can interlink and be tweaked with > \override. The Snobs are yield a format-independent sound description, > which are further processed by a backend into MIDI. > > * Then I add simple constructions, such as stress on the 1st note of a > slur/1st note of a bar. I should do some reading up on what are the > most important facets of getting a credible performance.
Okay. I'll make a first pass at Snobs, then. Shouldn't be too hard, and not all that different from what I was doing in the first place. I'll start by stealing the property code from Grobs, then add the other functionality when it turns out that I need it. My goal is to start simple, and only add complexity when necessary. For my initial foray, I have created a seperate \audio block, similar to \layout and \midi, so I can compare the eventual outputs side-by-side. Once I get something that has close to the functionality of the original audio output code, I'll start sending you patches. > the advantage is that all mechanisms for administrative work > (eg. \override) is already in place. I would scrap the entire current > MIDI backend; it's ancient code, and as such a bad place to start > from. I definitely agree with that last. I've already started creating a set of framework Scheme functions for output to MIDI file format. -- Michael Welsh Duggan ([EMAIL PROTECTED]) _______________________________________________ lilypond-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/lilypond-devel
