[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [partcombine] honouring Voice context name

From: Dan Eble
Subject: Re: [partcombine] honouring Voice context name
Date: Wed, 7 Jun 2017 22:21:09 -0400

> On Jun 7, 2017, at 19:48, Carl Sorensen <address@hidden> wrote:
> On 6/7/17 5:30 PM, "Kieren MacMillan" <address@hidden>
> wrote:
>>> Could it not leave the parts where they are (continuous parts in
>>> exactly one voice context per part) and change their context properties
>>> instead?
>> Not sure I quite understand what you're suggestingŠ
> So the current partcombine creates the named voices (if they don't already
> exist) and puts the music events into the appropriate voices.
> but I think that my most common
> use case is not continuous parts in exactly one Voice context per part.  I
> think my most common use case is two sequential music expressions that are
> not yet assigned to any Voice context.

I think we’re just looking at it differently.  You’re considering the arguments 
to partcombine.  My perspective was that eventually the events in those 
expressions are interpreted in a voice context.

I was trying to explain that there are two related aspects of the current 
implementation that might be unnecessary:

  * using more voices than there are parts
  * distributing fragments of a part to different voices

It is worth investigating the possibility of changing the part combiner from an 
event router to a property setter.  If that is feasible, Kieren’s concerns 
about voice naming would still need to be addressed, but without the 
complication of the extra voices that exist only as an implementation artifact.

reply via email to

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