Werner LEMBERG wrote:
> > An example of a useful dashed bezier-sandwich arpeggio would be when
> > indicating arpeggios presumed to have been accidentally omitted from
> > a manuscript, within an urtext edition.
>
> I don't think so. The proper way would be rather to use an arpeggio
> typeset wi
On Fri, Apr 17, 2009 at 09:39:07PM -0600, Carl D. Sorensen wrote:
>
> On 4/17/09 9:16 PM, "Graham Percival" wrote:
>
> > That said, I must admit that CG 5 doesn't go into details of how
> > to manually deal with input/new to input/lsr. The format changes
> > slightly. It's dealt with the pytho
On 4/18/09 6:03 AM, "Graham Percival" wrote:
> On Fri, Apr 17, 2009 at 09:39:07PM -0600, Carl D. Sorensen wrote:
>>
>> On 4/17/09 9:16 PM, "Graham Percival" wrote:
>>
>>> That said, I must admit that CG 5 doesn't go into details of how
>>> to manually deal with input/new to input/lsr. The
On 4/17/09 10:20 PM, "Carl Sorensen" wrote:
>
>
>
> On 4/17/09 1:47 PM, "joenee...@gmail.com" wrote:
>
>>
>> http://codereview.appspot.com/41099/diff/1021/59
>> File lily/bezier.cc (right):
>>
>> http://codereview.appspot.com/41099/diff/1021/59#newcode275
>> Line 275: Bezier::subdivide
> Using a smaller design size might work with a squiggle-arpeggio, but
> for composers who use the slur-arpeggio (I think Grieg was one?),
> typesetting a thinner curve might be too subtle a difference.
Ah, I haven't thought of the slur-arpeggio. Yes, I've meant the
squiggle-arpeggio.
Werne
On Sat, Apr 18, 2009 at 08:26:57AM -0600, Carl D. Sorensen wrote:
>
> On 4/18/09 6:03 AM, "Graham Percival" wrote:
>
> > On Fri, Apr 17, 2009 at 09:39:07PM -0600, Carl D. Sorensen wrote:
> > Not only that, but with a minimum of effort. IMO, people adding
> > new features should only be required
On 4/18/09 8:57 AM, "Graham Percival" wrote:
> On Sat, Apr 18, 2009 at 08:26:57AM -0600, Carl D. Sorensen wrote:
>>
>> On 4/18/09 6:03 AM, "Graham Percival" wrote:
>>
>>
>> One of the issues with regtests is that when a bug is found, a regtest is
>> added to demonstrate the bug, and then w
On Sat, Apr 18, 2009 at 09:06:34AM -0600, Carl D. Sorensen wrote:
>
> On 4/18/09 8:57 AM, "Graham Percival" wrote:
>
> > No, no -- when a programmer writes a regtest for a new feature,
> > the minimal "documentation" work is that he copies it or runs a
> > python script or something to put it in
On 4/18/09 9:24 AM, "Graham Percival" wrote:
> On Sat, Apr 18, 2009 at 09:06:34AM -0600, Carl D. Sorensen wrote:
>>
>> On 4/18/09 8:57 AM, "Graham Percival" wrote:
>>
>>> No, no -- when a programmer writes a regtest for a new feature,
>>> the minimal "documentation" work is that he copies i
On Sat, Apr 18, 2009 at 09:32:10AM -0600, Carl D. Sorensen wrote:
>
> On 4/18/09 9:24 AM, "Graham Percival" wrote:
>
> >> Why is it harder to leave the old version up than to take it down when we
> >> move to the new stable version? What am I missing?
> >
> > Time. What happens if somebody ad
On 4/18/09 9:22 AM, "Marc Hohl" wrote:
> Carl D. Sorensen schrieb:
>> People who care strongly about tablature (of which I am *not* one) should be
>> the people who make the decision about what the default should be. In fact,
>> I don't think there's anybody on the core development team who
On 4/18/09 9:53 AM, "Graham Percival" wrote:
>
> Mao, aren't I a genius for setting this up two years ago? ;)
Yes, you are, obviously (another quote for Valentin). ;)
>
> Cheers,
> - Graham
>
> PS about a year ago, I had exactly the same discussion with Mats.
> I'm going to bet that it'l
On 4/18/09 8:54 AM, "Werner LEMBERG" wrote:
>> Using a smaller design size might work with a squiggle-arpeggio, but
>> for composers who use the slur-arpeggio (I think Grieg was one?),
>> typesetting a thinner curve might be too subtle a difference.
>
> Ah, I haven't thought of the slur-arpeggi
I think something like the following needs to go in the CG under
Documentation Work somewhere -- Probably after TWEAKS in section 3.4.
"If a new snippet created for documentation purposes will compile in
the current LSR version, the snippet should be added to the LSR, and a
reference to the snipp
2009/4/18 Graham Percival :
> LSR should be the latest stable, which means 2.12.something.
> Valentin is supposed to be coordinating this with Sebastiano, but
> he's off spending time on other things right now.
> *scowl*
OK, you win. I'm giving Seba a ping right now.
Regards,
Valentin
2009/4/18 Carl D. Sorensen :
>
>
>
> On 4/17/09 1:34 PM, "n.putt...@gmail.com" wrote:
>> http://codereview.appspot.com/41099/diff/1021/52
>> File Documentation/user/expressive.itely (right):
>>
>> http://codereview.appspot.com/41099/diff/1021/52#newcode634
>> Line 634: @lilypondfile[verbatim,lily
2009/4/18 Carl D. Sorensen :
>
> I think something like the following needs to go in the CG under
> Documentation Work somewhere -- Probably after TWEAKS in section 3.4.
>
> "If a new snippet created for documentation purposes will compile in
> the current LSR version, the snippet should be added t
On 4/18/09 4:55 PM, "Neil Puttock" wrote:
> 2009/4/18 Carl D. Sorensen :
>> [Snip original proposal on LSR snippets]
>
> It still needs ignoring like input/new snippets until an LSR update's been
> done.
>
>> [Snip original proposal on input/new snippets]
>
> I think this is the simplest op
2009/4/19 Carl D. Sorensen :
> Perhaps, but I think it's a good idea to actually test how the snippet shows
> up in the docs, because there's documentation, not just LilyPond, in the
> snippet. Is there another way to do this that's easier than making the
> slight change to the snippet and copyin
2009/4/15 Carl D. Sorensen :
> So why can't we define an AutoBeamPlaceHolder grob description (defined in
> scm/define-grobs.scm), which has an auto-beam-setting-interface (defined in
> scm/define-grob-interfaces.scm)? It would have no engraver, but I can't see
> that having an engraver is necess
On Fri, 2009-04-17 at 22:17 -0600, Carl D. Sorensen wrote:
>
>
> On 4/17/09 1:47 PM, "joenee...@gmail.com" wrote:
>
> > Very pretty slurs!
>
> Thanks!
>
> >
> >
> > http://codereview.appspot.com/41099/diff/1021/59
> > File lily/bezier.cc (right):
> >
> > http://codereview.appspot.com/41099
On 4/18/09 7:56 PM, "Joe Neeman" wrote:
> On Fri, 2009-04-17 at 22:17 -0600, Carl D. Sorensen wrote:
>
>>> http://codereview.appspot.com/41099/diff/1021/62#newcode347
>>> Line 347: SCM dash_details)
>>> Since dash_details seems to just be a list of Reals, perhaps its better
>>> to have a vect
On 4/18/09 5:45 PM, "Neil Puttock" wrote:
> 2009/4/19 Carl D. Sorensen :
>
>
>> What are the formatting issues when copying snippets into input/lsr? The
>> only thing I've run into is getting the whole header output if you don't put
>> "% begin verbatim" after the header.
>
> I was thinki
On Sat, 2009-04-18 at 21:08 -0600, Carl D. Sorensen wrote:
>
>
> On 4/18/09 7:56 PM, "Joe Neeman" wrote:
>
> > On Fri, 2009-04-17 at 22:17 -0600, Carl D. Sorensen wrote:
> >
> >>> http://codereview.appspot.com/41099/diff/1021/62#newcode347
> >>> Line 347: SCM dash_details)
> >>> Since dash_det
On Sat, Apr 18, 2009 at 11:55:31PM +0100, Neil Puttock wrote:
> Another option (though still not ideal since it suffers from the same
> formatting issues as pasting snippets verbatim from input/new ->
> input/lsr) is to use the same name for the regtest as the new snippet,
> then the docs will auto
On 4/18/09 9:26 PM, "Joe Neeman" wrote:
> On Sat, 2009-04-18 at 21:08 -0600, Carl D. Sorensen wrote:
>>
>>
>> On 4/18/09 7:56 PM, "Joe Neeman" wrote:
>>
>>
>> If I do change to static typing, then I should have one routine that is
>> called from all three places, something like scm2dash_d
On Sat, Apr 18, 2009 at 09:16:47PM -0600, Carl D. Sorensen wrote:
>
> > I don't mind what you do, so long as it doesn't break compilation. :)
>
> OK, so how about this for proposal 3 for something to go into the CG:
Here's my proposal: since this will change in 6 weeks and it isn't
urgent, we le
27 matches
Mail list logo
