Hi Han-Wen,
Thanks for your response.
The second option is what I think is best.
The Braille reads like unbroken text and is not structured positionally in
music like usual notation, since this kind of visual structure has no meaning
to a blind person.
If you care to look at the examples on http://www.brl.org/music/index.html
(you need the SimBraille truetype font to see the effect properly), they show
that where Braille notation is shown, even with conventional notation, it is
shown as normal sequential text. However, even Braille music has the concept
of a bar measure, which is used as the delimeter of structures such as
multi-voice phrases etc.
So far, I have generated Braille equivalents of notes, with accidentals, codes
for specifying octavation and length and the same for rests, attached to note
events as you suggested. This makes the music spacing extremely distorted and
I have a lot more to add to the Braille. It has to be separate, if
accompanied by normal notation, floating above as sequential text, not
aligned with the normal notation.
I know it sounds a bit bizarre, and would seem to be both missing the
notational point, and bucking the trend of everything else, but having seen a
few examples, I think that it really has to be that way. It is also partially
the reasoning for my considering a separate font. A small amount of
conventional notation often generates a substantially larger amount of
Braille to represent it. Therefore, it would make sense to leave the
conventional notation to format and space itself out and present the Braille
above (or below!) doing it's own thing.
For example, a single note can require up to 6 Braille characters to fully
describe it, including 3 characters to specify from which set of lengths it
comes from, 1 character to specify the octave, 1 character for sharp/flat
etc, and the single character which defines the length and name of note
combined. If the note is a 256th, then there is an extra 2 characters. It can
get very long winded, although this is more the exception.
On a related note (sorry to go on!) since I am tackling time/key signatures, I
have been studying the related engravers to get the details on how they are
generated, and although it all seems to make sense to me, I am becoming aware
that a lot of the new Braille code is effectively copied from the other
engravers to do largely the same thing. This instinctively seems wrong to me
and I wonder if I am barking up the wrong tree.
I'm quite open to a little peer review and suggestions from other quarters.
Therefore, I suggest that I wrap up neatly what I have done so far and send
it up as a possible experiemental addition for scrutiny, especially since
this is my first major piece of work for the cause!
What do you think?
Regards,
Ralph
Han-Wen wrote:
Since Braille is read as prose and is not formatted as per the
characteristics of printed conventional music, I am looking at
generating the text for a staff and planting it as a prose section above
as discussed previously. However, it *might* be long and I would prefer
it to word wrap rather than tramming off the end of the staff and/or
continuing with the next system as a break aligned object.
Can anybody tell me if there is an easy way to do this as things stand,
or will I have to program in a special item formatting object to achieve
this? I'm happy to have a go at this if there is no alternative already
available.
I don't really understand: you want to put braille code next to
staves. Should the braille texts be synchronized with musical events
or not? Or are they to be synchronized only at line breaks (ie. at the
left end of a system), and then follow their own formatting?
What happened with the incremental path of starting with a \markup
command that prints braille dots?
___
Lilypond-devel mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/lilypond-devel
