Re: Any thoughts on how to automatically avoid rest collisions in polyphonic music?

[David Bellows]

> I'm not sure about using << ... // ... >> to make it "infinitely
expandable"... wouldn't the output become illegible past 4 voices?  If
you're mechanically generating these parts, I'd say keep it to 2 voices
per staff, which is least problematic. In theory, it should be easy for
the program to allocate a new Staff for every two voices, right?

I say infinite but for now I'm limiting myself to 4 voices per staff.
But programmatically it's easy to add a "\\ voice_x" to the next line
and just close it at the end with a ">>". Or at least I found that to
be the case when I switched over (the old code was a nightmare). Plus,
when dealing with instruments that have two staves each voice has a
voice in each staff -- my software handles switching the voice to the
other staff as needed at middle-c. In any case I'll play around with
it to see if it makes a difference.

But I'm not sure I understand what you're saying about keeping it to 2
voices per staff. If this is a four voice fugue for piano or guitar or
something then what other staff would there be?

> but then there would be cases where collisions become
inevitable and lilypond may just give up trying to figure it out.  At
least, it would require manual intervention

Yeah, that's what I figure is going on which is why I was hoping
someone might have another trick/snippet/magical scheme function that
might help. I've thought about getting rid of rests altogether which
is, of course, non-standard but at least you'd be able to see the
notes clearly and still figure out what's going on. I'm not really
expecting musicians to play these scores, it's more so that the user
can have something pretty to look at (that's still fairly accurate).



On Wed, Oct 26, 2016 at 4:56 PM, H. S. Teoh <address@hidden> wrote:
> On Wed, Oct 26, 2016 at 04:52:18PM -0700, David Bellows wrote:
>> > Do you use the \voiceOne, \voiceTwo, \voiceThree commands in the
>> > generated parts?  Sometimes those can help, by rendering rests for
>> > each voice separately. Not sure if this is the solution you're
>> > looking for, though.
>>
>> I had been but keeping it all straight and making the process
>> infinitely expandable became a headache so now I use << voice1 //
>> voice2 // voice3 >> etc which is easy to just keep adding to. Would
>> using \voiceOne (etc) make that much of a difference?
>
> You can try it and see?  In my experience, it does help with placement
> of notes especially when you have rests in multiple voices. Lilypond is
> generally quite good at handling shifting notes/rests horizontally to
> make them fit, but that depends on how complex the music is. Some cases
> may be so complex it will always require manual intervention.
>
> I'm not sure about using << ... // ... >> to make it "infinitely
> expandable"... wouldn't the output become illegible past 4 voices?  If
> you're mechanically generating these parts, I'd say keep it to 2 voices
> per staff, which is least problematic. In theory, it should be easy for
> the program to allocate a new Staff for every two voices, right?
>
> You could have more, up to 4 per staff, if you use \voiceOne, \voiceTwo,
> ...  \voiceFour, but then there would be cases where collisions become
> inevitable and lilypond may just give up trying to figure it out.  At
> least, it would require manual intervention (recently I've been working
> on a complex 4-voice piano score and lots of manual intervention were
> needed to keep things straight and not turn into spaghetti on the page).
>
>
> T
>
> --
> If Java had true garbage collection, most programs would delete themselves 
> upon execution. -- Robert Sewell
>
> _______________________________________________
> lilypond-user mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/lilypond-user