|
From: | Keith OHara |
Subject: | Re: Part combiner: separate split state and voice names |
Date: | Sat, 29 Nov 2014 22:17:25 -0800 |
User-agent: | Opera Mail/12.16 (Win32) |
On Sat, 29 Nov 2014 18:09:34 -0800, Dan Eble <address@hidden> wrote:
On Nov 29, 2014, at 18:48 , Keith OHara <address@hidden> wrote:Oh, so you meant let the Scheme portion dictate to partcombine_iterator which _input_ voice, as it iterates the music expression produced by \partcombine, to use.My reasoning probably needs more clarification. The iterator takes sequences of events and routes them into voices. So, I thought that where now the Scheme portion produces simply ‘unisilence, it might produce something like (’silence “shared” #f) to tell the iterator that both parts are silent, the first part should be placed into the voice named “shared”, and the second part should be dropped. That’s what I meant by telling the iterator which output voice to use. Telling the iterator which input to use would be something like defining new states ‘unisilence1 and ‘unisilence2.
Adding the new split-state tags 'unisilence1' and 'unisilence2' would preserve the relative roles of the \partcombine function and the part_combine_iterator The function \partcombine analyzes the music to describe which part or parts must be printed and when they should be combined in chords. That analysis is what you want to improve so that \partcombine {R1 R1} {R1 r4 b2.} reports that the first beat of the second measure is not really 'unisilence', but 'silence2'. The part_combine_iterator takes the results of \partcombine and decides what events to send to what Voices. Maybe you can make \partcombine completely take over the routing decisions. Then maybe the iterator would be reduced to following orders, and keeping track of which voices need to start or stop multimeasure rests. If \partcombine can only assume part of the responsibility for routing decisions, though, I seems cleaner to enhance the set of split-state tags to completely describe the results of \partcombine's analysis, rather than tell part_combine_iterator (partially) how to do its job.
[Prev in Thread] | Current Thread | [Next in Thread] |