Re: Write a custom backend?

[David Kastrup]

Knut Petersen <address@hidden> writes:

> Am 13.09.2016 um 14:04 schrieb David Kastrup:
>>
>>> I believe the output backend principle is a good sign of extensibility
>>> but is it really the case? How to instruct Lilypond to use a custom
>>> one, then?
>> You'd have to make use of one of the existing translator groups (like
>> Engraver_group or Performer_group) which might me more accurately called
>> translator groupers: there is currently no way to define those in
>> Scheme.
>>
>> Personally, I'd consider it a great project to convert _all_ of Midi
>> generation to Scheme.
>>
> Why? We need more details of the music going into \midi{}, but it is
> necessary to rewrite the code in scheme first?

The Midi code is opaque, its data structures are closed and inaccessible
from Scheme.  Changes in Midi are programmed by very few people who
actually are acquainted with the C++ code.  That means that they are
rarely reviewed well.  If you see just how much work is done in the
LilyPond mailing lists by fiddling with the Scheme-accessible data
structures and procedures and algorithms of engravers, the corresponding
work actually happen in Midi is insignificant.  And it's not like people
don't ask about it.  But almost anything would require changes in C++
and recompilation.

Of course it is not "necessary to rewrite the code in Scheme first"
before making changes to it.  But for one thing, not a lot will happen
without it, for another, without some generally useful output definition
possibilities, backends like Braille, MusicXML, and others will require
individual programming and end up, if at all, individually maintained.

That's why I said "great project".  Not "prerequisite".

-- 
David Kastrup