From: David Kastrup
To: Dan Eble
Cc: Kieren MacMillan , LilyPond Development
Team
Bcc:
Date: Thu, 08 Jun 2017 12:03:04 +0200
Subject: Re: [partcombine] honouring Voice context name
Dan Eble writes:
>> On Jun 7, 2017, at 09:34, Kieren MacMillan
>> wrote:
>>
>> As a f
Dan Eble writes:
>> On Jun 7, 2017, at 09:34, Kieren MacMillan
>> wrote:
>>
>> As a first step, I would offer that we should figure out how (if?)
>> the "one" context can be funnelled seamlessly into the "shared" and
>> "solo" contexts — as I see it, that's the main problem with lyrics
>> getti
Hi Dan (et al.),
> 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 on
> On Jun 7, 2017, at 19:48, Carl Sorensen wrote:
>
> On 6/7/17 5:30 PM, "Kieren MacMillan"
> 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
On 6/7/17 5:30 PM, "Kieren MacMillan"
wrote:
>Hi Dan,
>
>> If we¹re going to ask that kind of question, let¹s mention a more
>>radical redesign.
>
>I would be happy with a "radical redesign", if that's what it takes to
>(a) solve some of the problems I face with partcombine on a daily basis,
>or
Hi Dan,
> If we’re going to ask that kind of question, let’s mention a more radical
> redesign.
I would be happy with a "radical redesign", if that's what it takes to (a)
solve some of the problems I face with partcombine on a daily basis, or (b)
establish a good base for future development/im
> On Jun 7, 2017, at 09:34, Kieren MacMillan
> wrote:
>
> As a first step, I would offer that we should figure out how (if?) the "one"
> context can be funnelled seamlessly into the "shared" and "solo" contexts —
> as I see it, that's the main problem with lyrics getting disconnected (etc.).
Hi Dan,
> The part combiner can also route events to “shared”, “solo”, and “null”
> contexts. If you took the step you’re proposing, the next question would be
> why can’t a person control those other names too? If there is going to be
> user control, should it be more comprehensive?
Absolut
On Jun 6, 2017, at 15:30, Kieren MacMillan
wrote:
>
>> I guess what you are saying is that if the parts to be combined are each
>> context-specced-music, use those contexts.
>
> Exactly.
The part combiner can also route events to “shared”, “solo”, and “null”
contexts. If you took the step yo
Hi Carl,
Thanks for the quick response.
> I guess what you are saying is that if the parts to be combined are each
> context-specced-music, use those contexts.
Exactly.
> If they are not, use the default contexts.
In that case, wouldn't parameterized (rather than internally hardcoded) names
h
On 6/6/17 12:45 PM, "lilypond-devel on behalf of Kieren MacMillan"
wrote:
>Hello all,
>
>I'm looking at make-directed-part-combine-music, and wondering why the
>voice names are hard-coded ("one" and "two")Š
>
>It seems to me that if a Voice context passed to partcombine is already
>named, that na
Hello all,
I'm looking at make-directed-part-combine-music, and wondering why the voice
names are hard-coded ("one" and "two")…
It seems to me that if a Voice context passed to partcombine is already named,
that name should be honoured by partcombine. Only if the context is not already
named s
12 matches
Mail list logo
