[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bmc2ly: Braille music to LilyPond conversion
From: |
David Kastrup |
Subject: |
Re: bmc2ly: Braille music to LilyPond conversion |
Date: |
Mon, 12 Nov 2012 14:47:13 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux) |
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, I think it would be quite hard to implement. I have
> looked at how to start such an endeavour at least two times in the
> past and have never really understood the internals of LilyPond enough
> to end up anywhere useful. I guess what we need is a function that
> receives music expressions and translates them into braille music,
> outputting to some file. However, the transformations required to
> produce proper braille music are quite involved. I'd be happy to work
> together with anyone with enough Lily internals knowledge who would be
> interested to attack this problem.
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.
> Still, some of the algorithms necessary to produce proper braille
> music could be (depending on the time signature and number of notes
> per measure) quite computational expensive. For instance, BMC has one
> test case (bwv988 variation 3, \time 12/8) which needs about 4 seconds
> of CPU time on a modern CPU, and that is C++ code compiled to binary
> code. Granted, this is an extreme case, and most other material I
> have found yet doesn't explode so must complexity-wise, but I still
> wonder if pure Scheme is a good approach for that.
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.
--
David Kastrup