[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: How hard is something like CADB to do?
From: |
David Kastrup |
Subject: |
Re: How hard is something like CADB to do? |
Date: |
Sun, 31 Aug 2008 22:58:04 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) |
Ok, this provides food for thought and some initial pointers where to
look further. Thanks!
"Carl D. Sorensen" <address@hidden> writes:
> On 8/30/08 3:49 PM, "David Kastrup" <address@hidden> wrote:
>
>> David Kastrup <address@hidden> writes:
>>
>> [...]
>>
>>> So the problems boil down to
>>>
>>> a) the graphical representation (which requires fixed vertical space and
>>> not normally additional horizontal space)
>
> This is not particularly hard. Initially it could be done as a markup
> (like fret diagrams were). Eventually it could become a context.
>
>>> b) some sort of fingering engine which one can feed the necessary
>>> information for choosing its priorities
>
> This would likely be done in scheme. The tablature code is an example
> of this.
Ok, somewhere to look.
>>> How would one go about implementing something like that in lilypond?
>>> How would the work get structured? What would require working on
>>> the kernel, what on subsystems? How well can the subsystems be
>>> separated?
>
> To get it done with a context, you would need to write some C++ code,
> along with some lilypond code and some scheme code. The FretBoards
> context would likely serve as a template for this work, I would
> imagine.
Have to look there.
>>> How much intelligence can one reasonably program into the fingering
>>> engine without having it explode in complexity? It is thinkable to
>>> tell it something like TeX's "badnesses" as overall penalties for
>>> changing rows, changing bellows direction, and then let it minimize
>>> over that?
>
> Hard for me to say, since I don't understand how this works. But lots
> of the layout decisions are made in scheme code, so I would guess this
> is doable.
Ok.
>>> Or have a draft mode where, say, one has it pick one fingering
>>> according to explicit priorities and indicate alternative fingerings
>>> in different markup (small print, in parens or something), so that
>>> one can incrementally override bad automatically chosen fingerings
>>> until arriving at a good solution, in sort of a feedback loop?
>
> I don't see any problem with this -- but I don't know how one would
> calculate these things.
> My take on this is that you will need to do the following:
>
> 1. Write some C++ code to implement a translator
>
> 2. Write some Scheme code to implement an engraver
>
> 3. If you want to add to the input syntax, make changes to the
> parser. But I think it's possible you can do this with just named
> chords in chordmode, which wouldn't require parser changes.
I think that in general a mechanism to provide instrument/pitch specific
hints would be nice, so that I can have some Lilypond input that can be
made to crank out instrument-specific fingerings and tablature for
different instruments and transpositions.
> The job is a fairly big job, but it can be started small and worked at
> in manageable chunks.
Ok, thanks.
>> It was also a question about how well-prepared Lilypond is for
>> embedding algorithms for what amounts to fingering instructions
>> (converting to any kind of tablature has this problem: the more
>> sparingly you can use hints for generating instrument-specific
>> instructions, the better).
>
> LilyPond is extremely well-prepared for embedding algorithms. You
> will have a great deal of flexibility in implementing your tablature.
Good.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum