"Keith OHara" writes:
> In any case, if you want to retire the part-combine-iterator, you need
> new code to properly break rests. I think there are still bugs with
> \partcombine when rests overlap changes of state, so the rewrite might
> solve some bugs.
There are "still bugs" with \partcombi
"Keith OHara" writes:
> On Sun, 26 Apr 2015 05:37:14 -0700, Dan Eble wrote:
>
>>> I think \context...{} segments make a better implementation of
>> \partcombine than re-routing outlets in the part-combine-iterator.cc
>>
>> I believe that would work, but it looks less tidy than keeping the
>> ori
On Sun, 26 Apr 2015 14:35:33 -0700, Dan Eble wrote:
If there existed a command to redirect the sequential iterator’s output to
another Voice context without requiring a wrapper context, it could not
function in a parallel sequence; the commands would have to be injected into
the part sequenc
On Apr 26, 2015, at 13:11 , Keith OHara wrote:
>
> On Sun, 26 Apr 2015 05:37:14 -0700, Dan Eble wrote:
>
> If you were thinking of a separate sequence of {... s1 \change Voice = "one"
> s2...} in parallel with the part, then the \change method could be more tidy.
Yes, that is exactly what I h
Although, this is not the final patch for this topic, James, may I ask
you to run patchy against it?
https://codereview.appspot.com/223420043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On 2015/04/13 02:22:15, Carl wrote:
I think that this is a great start. You're working in a really
complex area,
and trying to sort it out. Good for you!
I've made some specific comments below. I think the separation
between list
creation and markup creation needs to be made stronger an
Reviewers: Jean-Charles,
https://codereview.appspot.com/227470043/diff/1/Documentation/learning/fundamental.itely
File Documentation/learning/fundamental.itely (right):
https://codereview.appspot.com/227470043/diff/1/Documentation/learning/fundamental.itely#newcode3193
Documentation/learning/fu
I can't compile LP at the moment, but LGTM from eye-balling. How
pleasing it took just two extra lines!
Trevor
https://codereview.appspot.com/226700043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/li
On Sun, 26 Apr 2015 05:37:14 -0700, Dan Eble wrote:
I think \context...{} segments make a better implementation of \partcombine
than re-routing outlets in the part-combine-iterator.cc
I believe that would work, but it looks less tidy than keeping the original
part intact and wrapping it in
On 2015/04/26 02:35:34, Carl wrote:
baseMoment does have another use. It is used to define the major
beaming groups
for automatic beaming.
...
And this use of baseMoment is important for subdivision; subdivision
is only
possible at units of baseMoment.
Thanks,
Carl
OK, so I "wi
> I presume this is owing to the changes to font handling that Masamichi has
> made, and I also presume that I can fix this by updating GUB. Problem is,
> I'm confused with how to go about the latter. My current GUB build
> environment is cloned from https://github.com/trueroad/gub and is built f
> On Apr 25, 2015, at 15:17 , Keith OHara wrote:
>
> Current \partcombine does not collect segments into sequential music groups,
> but it could do so. The analysis pass of \partcombine looks at the music
> globally to find the transition points that it puts in 'split-list, so a next
> pass
Probably a request for help from Masamichi, but if anyone else can help,
please chime in.
My GUB build this morning has failed as follows:
config.status: creating config.hh
configure: WARNING: unrecognized options: --enable-shared,
--disable-static, --disable-silent-rules, --with-ncsb-dir
WARNI
13 matches
Mail list logo
