Re: Braille export

[David Kastrup]

Mario Lang <address@hidden> writes:

> David Kastrup <address@hidden> writes:
>
>> Mario Lang <address@hidden> writes:
>>
>>> David Kastrup <address@hidden> writes:
>>>
>>>> Would it be useful if LilyPond could export BMC?
>>>
>>> Of course!  Actually, thats something that blind people are wishing
>>> for for a long time so that they could make use of the huge body of
>>> LilyPond music on Mutopiaproject for instance.
>>
>> I am skeptical that sighted people can easily make use of the huge body
>> of LilyPond music on Mutopiaproject at the moment.
>
> I am not sure what you are hinting at.

Mutopia does not appear actively maintained, and scores will not
necessarily compile under newer versions of LilyPond.  There is a lot of
work for convert-ly involved, and particularly in the earlier parts of
2.x, the conversion rules might not have been very thorough.

>> It would probably raise more interest to first tackle MusicXML export
>> and then use the code as a starting base for doing Braille as well.
>
> Definitely.  I haven't come to that conclusion yet because off-list
> discussions with people involved in LilyPond and MusicXML in the past
> have suggested to me that the LilyPond community has no interest in
> being able to export to ("an evil format like") MusicXML :-).

I don't know of any active developers considering MusicXML "evil".
There may be some more interest in _importing_ it better (to provide a
migration path to LilyPond, or use LilyPond as a typesetting backend
without needing to track developments of the LilyPond language itself).
But I don't think there is opposition to the format as such.  It is just
not human-readable/writable all that much, and so is no substitute for a
good LilyPond language itself.

>> Computers are fast enough nowadays that the choice of implementation
>> language is almost irrelevant compared to the choice of algorithm and
>> consequently the algorithmic complexity.
>
> Having experienced the difference between compiled and interpreted
> languages first hand, I tend to disagree.

Of course there is a difference, but it is a constant factor, and the
"gets unusable for large-scale applications" threshold is much more
determined by algorithmic complexity.

> Guess I am a bit biased since I spent a few weeks recently finding
> optimisations for my current algorithm.

I remember working in the area of digitized map processing and trying to
find my way through a large-scale, heavily optimized algorithm (partly
written by someone with a PhD in computer science) which it was my task
to improve, as it took days to process large amounts of data and was
increasingly getting unstable under the partaken optimizations.  I tried
for a week finding my way around it, but it was beyond me and I proposed
letting me rewrite it from scratch.  The purpose of the algorithm was to
determine for a sort-of rectangular grid to look for the closest contour
line in eight directions and do a weighted average.  Contour lines were
digitized with a humongous amount of line pieces.  I basically inverted
the logic of the algorithm: instead of searching from each raster point
to the next contour line, I used line drawing algorithms on each contour
line to figure out where it crossed raster lines and diagonals, and
afterwards used just the intersection data from the raster lines
corresponding to each data point.

After shaking out the compilation errors and initial segfaults and
stuff, I got stuck without getting anywhere since the program showed no
immediately obvious problem but just terminated after running for about
two minutes.

After two days of trying to figure out the root cause of the premature
termination by debugging in various manners, I finally tried to see
whether the problem could be guessed from visualizing the output.

It turned out that the output was fine.

Taught me a lesson about "optimization" and "computer scientists".

> So I take it you suggest it would be best to start with a Scheme-based
> implementation, basically similar to what articulate.ly does?

I don't really like the coding of articulate.ly.  If you take a look at
scm/display-lily.scm, you'll find a macro with-music-match which is used
a lot in define-music-display-methods.scm.  Scheme is suited rather well
for this kind of pattern-based coding, and it would likely be feasible
to create a suitable framework where one can specify conversion patterns
in a reasonably straightforward way.

-- 
David Kastrup