Re: The \\ construct for simultaneous voices

[Dan Eble]

I invite you to search the archives for a patch from me. I posted some improvements (maybe last year?) for use with vocal music. Han Wen wanted something more general, which I started but became too busy to complete. I was going to have the C++ part combiner consult a state machine (defined in scheme) with state names corresponding to the list generated by \partcombine, whose nodes hold the names of output contexts to receive part A notes, part A rests, part B notes, etc, and whose edges hold the text to put out when a transition happens.

voicecombine =

   (dfe-make-voice-combine-music parser (list part1 part2)))

--
Dan

Currently, for instrumental music, I'm using a modified copy of the partcombine scm (attached) which skips solo/a2 analysis, keeps unisons and close notes pointing the right directions, and combines simultaneous rests properly. There are still shortcomings involving multi-measure rests. (Please don't ask for a proper patch, as I have no time.) You'll also need something like this to combine voices with the different options: #(define-music-function (parser location part1 part2) (ly:music? ly:music?)

part-combiner.scm
Description: Binary data

On 2009-09-13, at 19:18 , Anthony W. Youngman wrote:

In message <blu0-smtp76a410ac3d24e8496e9aaa94...@phx.gbl>, Kieren MacMillan <kieren_macmil...@sympatico.ca> writes

Hi Reinhold, Wol, et al:

I've been thinking about implementing something like that myself (basically controlling combined/split voices via context properties, overriding the bad

choices the partcombiner makes).

What say we make a serious effort at rewriting the partcombiner from the ground up? There are at least three of us who want and are willing to tackle the problem, learn/improve our Scheme as necessary, etc. I can't think of very many feature fixes that would have a bigger bang-for-the-buck.

I'm game. My two problems are (1) finding time, and (2) I'll need a fair bit of hand-holding to start off with, I expect. I'm very much a procedurally trained programmer (C, Fortran, *decent* BASICs).

Cheers,
Wol
--
Anthony W. Youngman - anth...@thewolery.demon.co.uk



_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel