When C++, and when scheme

[Han-Wen Nienhuys]

address@hidden 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.

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.

-- 

 Han-Wen Nienhuys   |   address@hidden   |   http://www.xs4all.nl/~hanwen