Reviewers: marc, p.l.schmidt_gmx.de,
Message:
I've taken Marc's harmonic.ly and moved the scheme functions into
scm/tablature.scm, the music functions into ly/engraver-init.ly, and the
test music into input/regression/tablature-harmonic-functions.ly.
I've also added docstrings for the functions
On 11/27/10 1:03 PM, "Marc Hohl" wrote:
> Am 27.11.2010 14:36, schrieb Carl Sorensen:
>> [...]
>> No, it's not a syntax error, any more than
>>
>> \time 4/4 c4 c c |
>>
>> is a syntax error.
>>
>> I'm fine to throw an error instead of a warning, so that the output will say
>> the file failed.
Marc,
Do you have a regtest file that uses the custom fret label?
Thanks,
Carl
On 11/27/10 11:46 AM, "Marc Hohl" wrote:
> Am 27.11.2010 15:27, schrieb Carl Sorensen:
>> [...]
>> TabNoteHead supports the text-interface, which has a 'text property. It's
>> in the Internals reference.
>>
>
Am 27.11.2010 14:36, schrieb Carl Sorensen:
[...]
No, it's not a syntax error, any more than
\time 4/4 c4 c c |
is a syntax error.
I'm fine to throw an error instead of a warning, so that the output will say
the file failed. But it's a music error, not a syntax error.
Thanks for your exam
Am 27.11.2010 15:27, schrieb Carl Sorensen:
[...]
TabNoteHead supports the text-interface, which has a 'text property. It's
in the Internals reference.
Thanks for clarification - I just saw that you included this in your
recent patch,
in combination with the harmonic/parentheses stuff - gr
Thanks, Marc. That was a mistake I made in resolving merge conflicts.
http://codereview.appspot.com/2723043/diff/103001/scm/tablature.scm
File scm/tablature.scm (right):
http://codereview.appspot.com/2723043/diff/103001/scm/tablature.scm#newcode291
scm/tablature.scm:291: (grob-interpret-marku
On 11/27/10 2:24 AM, "Marc Hohl" wrote:
> Am 27.11.2010 02:41, schrieb Carl Sorensen:
>>
>>
>> On 11/24/10 12:40 AM, "Marc Hohl" wrote:
>>
>>
>>> Am 24.11.2010 00:41, schrieb Neil Puttock:
>>>
On 23 November 2010 23:30, Carl Sorensen wrote:
> Pushed,
On 11/27/10 2:38 AM, "David Kastrup" wrote:
> Marc Hohl writes:
>
>> Am 27.11.2010 10:17, schrieb David Kastrup:
>>> carl.d.soren...@gmail.com writes:
>>>
>>>
Yes, the assumption is that the string specification needs to be in
the same order as the note specification. When the
On 11/27/10 2:17 AM, "David Kastrup" wrote:
> carl.d.soren...@gmail.com writes:
>
>> Yes, the assumption is that the string specification needs to be in
>> the same order as the note specification. When the documentation is
>> done, we'll need to be sure that is mentioned. If you specify the
>
On 11/27/10 1:22 AM, "Trevor Daniels" wrote:
>
>
> Carl Sorensen wrote Saturday, November 27, 2010 4:10 AM
>
>> Neil found a bug in the code. What happens when
>> someone requests an open string that isn't present
>> in the tuning?
>
>> I've got the code fixed to issue a warning. After
>
On Sat, Nov 27, 2010 at 11:32:57AM -, Phil Holmes wrote:
> http://www.holmessoft.co.uk/homepage/lilypond/imagediffs.htm
... you're creating 3d images for aliens with eyes arranged
vertically instead of horizontally?
Cheers,
- Graham
___
lilypond-de
Le 26/11/2010 23:18, Carl Sorensen disait :
On 11/26/10 2:41 PM, "Trevor Daniels" wrote:
Carl Sorensen wrote Friday, November 26, 2010 6:43 PM
On 11/26/10 10:51 AM, "Valentin Villenave"
wrote:
Er, are you suggesting that
@file{this/is/a/very/long/path/towards/myfile.scm} should be
printed
On Sat, Nov 27, 2010 at 10:32 AM, Graham Percival
wrote:
> Once bitten, twice shy. I would have been happier if the patch had
> been up for review for at least 24 hours, to give developer in all
> time zones a chance to comment.
I've sent not one, but *three* patches for "review" successively. I
On Sat, Nov 27, 2010 at 10:58:42AM +0100, Valentin Villenave wrote:
> On Sat, Nov 27, 2010 at 4:18 AM, Graham Percival
> wrote:
> > Tail of target/linux-x86/log/lilypond-installer.log
> > File "bin/../gub/commands.py", line 458, in execute
> > header_length = len (script % loc
On Sat, Nov 27, 2010 at 4:18 AM, Graham Percival
wrote:
> Tail of target/linux-x86/log/lilypond-installer.log
> File "bin/../gub/commands.py", line 458, in execute
> header_length = len (script % locals ()) + 1
> KeyError: 'target_cpu'
That would be my check-architecture p
Marc Hohl writes:
> Am 27.11.2010 10:17, schrieb David Kastrup:
>> carl.d.soren...@gmail.com writes:
>>
>>
>>> Yes, the assumption is that the string specification needs to be in
>>> the same order as the note specification. When the documentation is
>>> done, we'll need to be sure that is m
On Sat, Nov 27, 2010 at 8:30 AM, Trevor Daniels wrote:
>
> I don't think that was unreasonable. This was correcting
> an equally big patch which we all agreed was wrong, and
> which was already in master. It was equivalent to reverting
> the bad patch, but without destroying the good bits within
Am 27.11.2010 10:17, schrieb David Kastrup:
carl.d.soren...@gmail.com writes:
Yes, the assumption is that the string specification needs to be in
the same order as the note specification. When the documentation is
done, we'll need to be sure that is mentioned. If you specify the
notes and
Am 27.11.2010 02:41, schrieb Carl Sorensen:
On 11/24/10 12:40 AM, "Marc Hohl" wrote:
Am 24.11.2010 00:41, schrieb Neil Puttock:
On 23 November 2010 23:30, Carl Sorensen wrote:
Pushed, thanks.
That was quick, thanks!
I'm sorry I'm a bit late, but thi
carl.d.soren...@gmail.com writes:
> Yes, the assumption is that the string specification needs to be in
> the same order as the note specification. When the documentation is
> done, we'll need to be sure that is mentioned. If you specify the
> notes and the strings in reverse order, it's likely
Hello Carl,
your code looks great (at least at a quick glance),
but it looks as you didn't rebase after my patch
correction concerning the custom fret label was applied.
http://codereview.appspot.com/2723043/diff/103001/scm/tablature.scm
File scm/tablature.scm (right):
http://codereview.appspo
Am 27.11.2010 09:22, schrieb Trevor Daniels:
Carl Sorensen wrote Saturday, November 27, 2010 4:10 AM
Neil found a bug in the code. What happens when someone requests an
open string that isn't present
in the tuning?
I've got the code fixed to issue a warning. After
issuing the warning, we
On Fri, Nov 26, 2010 at 07:10:25PM -, Phil Holmes wrote:
> Done this - comparing .39 with .40. I did a pixel-by-pixel
> comparison, allowing a leeway of 1 in pixel brightness (range is 0
> It identified 21 files with changes.
Wow, I was expecting much more! In that case, this is definitely
Graham Percival wrote Saturday, November 27, 2010 12:59 AM
On Fri, Nov 26, 2010 at 11:31:06PM +0100, Valentin Villenave
wrote:
On Fri, Nov 26, 2010 at 10:41 PM, Trevor Daniels
wrote:
> OK; I agree. Patch looks good.
Thanks! I've pushed this patch, and merged translation onto
master
Carl Sorensen wrote Saturday, November 27, 2010 4:10 AM
Neil found a bug in the code. What happens when
someone requests an open string that isn't present
in the tuning?
I've got the code fixed to issue a warning. After
issuing the warning, we have two choices:
1 -- leave the improper
25 matches
Mail list logo
