Hello,
On 27 April 2012 10:51, Colin Hall wrote:
> On Fri, Apr 27, 2012 at 10:40:56AM +0100, James wrote:
>> > articulate.ly is not really ported to the new way of working with
>> > EventChord: it just converts the new representation to the old one at
>> > invocation time and goes from there with
On Fri, Apr 27, 2012 at 10:40:56AM +0100, James wrote:
> > articulate.ly is not really ported to the new way of working with
> > EventChord: it just converts the new representation to the old one at
> > invocation time and goes from there with the old code.
> >
> > As a consequence, bug compatibili
On Fri, Apr 27, 2012 at 11:04:20AM +0200, David Kastrup wrote:
> James writes:
>
> > This also occurs on 2.14.2. We've had some changes made to
> > articulate.ly recently for 2.15.x - phew! So this isn't a regression
> > in LP code.
>
> articulate.ly is not really ported to the new way of workin
Hello,
On 27 April 2012 10:04, David Kastrup wrote:
> James writes:
>
>> This also occurs on 2.14.2. We've had some changes made to
>> articulate.ly recently for 2.15.x - phew! So this isn't a regression
>> in LP code.
>
> articulate.ly is not really ported to the new way of working with
> Event
James writes:
> This also occurs on 2.14.2. We've had some changes made to
> articulate.ly recently for 2.15.x - phew! So this isn't a regression
> in LP code.
articulate.ly is not really ported to the new way of working with
EventChord: it just converts the new representation to the old one at
Hello,
On 27 April 2012 02:42, Nick Payne wrote:
> The example below builds without error and gives the output I want. However,
> if I include articulate.ly, then the output is garbaged even though I
> haven't used \unfoldRepeats \articulate, and I get the following warnings in
> the log:
>
> /ho
