lilypond-devel
[Top][All Lists]
Advanced

[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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]