lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [frogs] Re: tablature: ties and harmonics (issue1669041)


From: Carl Sorensen
Subject: Re: [frogs] Re: tablature: ties and harmonics (issue1669041)
Date: Wed, 30 Jun 2010 09:52:21 -0600



On 6/30/10 1:48 AM, "Marc Hohl" <address@hidden> wrote:

> Carl Sorensen schrieb:
>> [...]
>>>> http://codereview.appspot.com/1669041/diff/26001/27004#newcode130
>>>> scm/define-grob-properties.scm:130: (bracket-width ,number? "Width of
>>>> the harmonic angle bracket.")
>>>> Why do we need bracket-width?  Why can't we just use the pre-existing
>>>> width property?
>>>>      
>>> Hm, Neil proposed to use a more descriptive name for this property, IIUC.
>>> Done.
>>>    
>> 
>> Well, if we want to have this be part of the parenthesis-interface, then we
>> may want to go ahead with bracket-width.
>>  
> Ok, done.
>>  
>> [...]
>> If instead of making the whiteout and the stencil different stencils, we
>> combined them, then parenthesize-stencil would work great.  But this might
>> not be possible if we need to have the stencil and the whiteout on separate
>> layers.  As an alternative, parenthesize-stencil could be modified to take
>> white-padding as an argument.  There's nothing that says we can't modify
>> scm/stencil.scm so that it works better for tablature.  It's much better,
>> IMO, to have one general-purpose piece of code than to have two separate
>> special-purpose code chunks.
>>  
> So I tried to extend the parenthesize-stencil function in scm/stencil.scm.
> It compiles without error, but the regression file is cluttered up.

Can you tell me what you mean by "the regression file is cluttered up"?  Can
you tell me which examples fail the regression test for graphical output?
(The changes that indicate different amounts of memory don't bother me a
bit).

> 
> I feel that this is not the right approach, either. I still don't understand
> why I have to shift the TabNoteHead #'layer at all. As far as I see it,
> HarmonicParenthesesItem #'stencils is a list of stencils, containing the
> left and the right angle bracket, which are placed either side of the
> TabNoteHead #'stencil. So the order in which the stancils are placed
> should not change anything at all, but if the TabNoteHead #'stencil is set
> *before* the HarmonicParenthesesItem #'stencils, it seems that some
> whitespace occurs between the angle brackets, overriding the
> already placed TabNoteHead.

Have you looked at the list of stencils created by
parenthesis-item::calc-parentehesis-stencils grob

and 

map stencil-whiteout (parenthesis-item::calc-parentehesis-stencils grob) to
see how they differ?

Sometimes lists get reversed during LilyPond processing.  Perhaps this is
happening to this list.  You might see what happens if you reverse the list
of stencils....



> If on the other hand the whiteout would not appear, we could just use the
> parenthesize-tab-note-head function defined in scm/tablature.scm.
> This function could detect whether we have a harmonic and in this case
> would place the parentheses just further apart.
> 
> Furthermore, I have a bad feeling to misuse your time reviewing my patch
> for error seeking issues, but I am stuck here.

I don't view it as a misuse of time.  But right now I'm very busy, so I may
not get to it very quickly....

> I like the general idea of
> not defining the same functionality over and over again, but on the
> other hand,
> the parenthesize-stencil function in scm/stencil.scm does not seem to
> be used anywhere else ...

Parenthesize-stencil will be used for the new chord namer, so we need to
keep it in stencil.scm and keep the current functionality.


Thanks,

Carl




reply via email to

[Prev in Thread] Current Thread [Next in Thread]