Re: When C++, and when scheme

[Michael Welsh Duggan]

Han-Wen Nienhuys <address@hidden> writes:

> 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.

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
(address@hidden)