hanwenn | 1 Mar 03:44 2010
Picon

Re: Instanciable scheme engraver (issue216066)

lgtm

http://codereview.appspot.com/216066/show
Marc Hohl | 1 Mar 10:00 2010
Picon

Re: Enhancement: tabalture chord repetition (issue224082)

nicolas.sceaux <at> gmail.com schrieb:
>
> http://codereview.appspot.com/224082/diff/1/3
> File ly/chord-repetition-init.ly (right):
>
> http://codereview.appspot.com/224082/diff/1/3#newcode51
> ly/chord-repetition-init.ly:51: #(define-public (tab-repeat-chord
> previous-chord location duration articulations)
> It would be  better to define a generic repetition function, taking the
> event types that should be kept for NoteEvents. default-repeat-chord and
> tab-repeat-chord would then use this function.  I'm writing it on other
> post.
Done. Thanks for this improvement!

Marc

http://codereview.appspot.com/224082/show
Marc Hohl | 1 Mar 10:30 2010
Picon

Re: Issue 659: alternate segno symbol (issue181144)

Marc Hohl schrieb:
> n.puttock <at> gmail.com schrieb:
>> Hi Marc,
>>
>> LGTM, though I still think this is a lot of effort for a very obscure
>> and little-used symbol.
> [...]
Should the new segno sign be included in the documentation?
If yes, where?

Apart from that, are there any further objections to this patch set?

Greetings,

Marc

http://codereview.appspot.com/181144/show
Nicolas Sceaux | 1 Mar 11:01 2010
Picon

Re: Enhancement: tabalture chord repetition (issue224082)

Le 1 mars 2010 à 10:00, Marc Hohl a écrit :

> nicolas.sceaux <at> gmail.com schrieb:
>> 
>> http://codereview.appspot.com/224082/diff/1/3
>> File ly/chord-repetition-init.ly (right):
>> 
>> http://codereview.appspot.com/224082/diff/1/3#newcode51
>> ly/chord-repetition-init.ly:51: #(define-public (tab-repeat-chord
>> previous-chord location duration articulations)
>> It would be  better to define a generic repetition function, taking the
>> event types that should be kept for NoteEvents. default-repeat-chord and
>> tab-repeat-chord would then use this function.  I'm writing it on other
>> post.
> Done. Thanks for this improvement!
> 
> Marc
> 
> http://codereview.appspot.com/224082/show

Shouldn't there be a few words of explantion about using q and
\tabChordRepetition somewhere in 2.4.1 "Common notation for fretted
strings"?

Apart from that, it's ok AFAICT.

nicolas
Graham Percival | 1 Mar 11:18 2010
Picon

Re: Issue 659: alternate segno symbol (issue181144)

On Mon, Mar 1, 2010 at 9:30 AM, Marc Hohl <marc <at> hohlart.de> wrote:
> Should the new segno sign be included in the documentation?
> If yes, where?

In the feta font (I think that's included/font-table.ly), and in NR
1.2.5 rehearsal marks, in the example wi ththe other segno signs.

(if I understand the matter at hand... I'm sick and not thinking
clearly, so if this seems like totally off-base advice, ignore it)

Cheers,
- Graham
Marc Hohl | 1 Mar 12:07 2010
Picon

Re: Enhancement: tabalture chord repetition (issue224082)

Nicolas Sceaux schrieb:
> Le 1 mars 2010 à 10:00, Marc Hohl a écrit :
>
>   
>> nicolas.sceaux <at> gmail.com schrieb:
>>     
>>> http://codereview.appspot.com/224082/diff/1/3
>>> File ly/chord-repetition-init.ly (right):
>>>
>>> http://codereview.appspot.com/224082/diff/1/3#newcode51
>>> ly/chord-repetition-init.ly:51: #(define-public (tab-repeat-chord
>>> previous-chord location duration articulations)
>>> It would be  better to define a generic repetition function, taking the
>>> event types that should be kept for NoteEvents. default-repeat-chord and
>>> tab-repeat-chord would then use this function.  I'm writing it on other
>>> post.
>>>       
>> Done. Thanks for this improvement!
>>
>> Marc
>>
>> http://codereview.appspot.com/224082/show
>>     
>
> Shouldn't there be a few words of explantion about using q and
> \tabChordRepetition somewhere in 2.4.1 "Common notation for fretted
> strings"?
>   
I'll have a look at it.

(Continue reading)

Marc Hohl | 1 Mar 12:20 2010
Picon

Error in fretted-strings.itely? (was: Re: Enhancement: tabalture chord repetition (issue224082))

Marc Hohl schrieb:
> Nicolas Sceaux schrieb:
>> Le 1 mars 2010 à 10:00, Marc Hohl a écrit :
>>
>>  
>>> nicolas.sceaux <at> gmail.com schrieb:
>>>    
>>>> http://codereview.appspot.com/224082/diff/1/3
>>>> File ly/chord-repetition-init.ly (right):
>>>>
>>>> http://codereview.appspot.com/224082/diff/1/3#newcode51
>>>> ly/chord-repetition-init.ly:51: #(define-public (tab-repeat-chord
>>>> previous-chord location duration articulations)
>>>> It would be  better to define a generic repetition function, taking 
>>>> the
>>>> event types that should be kept for NoteEvents. 
>>>> default-repeat-chord and
>>>> tab-repeat-chord would then use this function.  I'm writing it on 
>>>> other
>>>> post.
>>>>       
>>> Done. Thanks for this improvement!
>>>
>>> Marc
>>>
>>> http://codereview.appspot.com/224082/show
>>>     
>>
>> Shouldn't there be a few words of explantion about using q and
>> \tabChordRepetition somewhere in 2.4.1 "Common notation for fretted
(Continue reading)

Jonathan Kulp | 1 Mar 12:47 2010
Picon

Re: Error in fretted-strings.itely? (was: Re: Enhancement: tabalture chord repetition (issue224082))

On Mon, Mar 1, 2010 at 5:20 AM, Marc Hohl <marc <at> hohlart.de> wrote:
Marc Hohl schrieb:
Nicolas Sceaux schrieb:
Le 1 mars 2010 à 10:00, Marc Hohl a écrit :

 
nicolas.sceaux <at> gmail.com schrieb:
 
http://codereview.appspot.com/224082/diff/1/3
File ly/chord-repetition-init.ly (right):

http://codereview.appspot.com/224082/diff/1/3#newcode51
ly/chord-repetition-init.ly:51: #(define-public (tab-repeat-chord
previous-chord location duration articulations)
It would be  better to define a generic repetition function, taking the
event types that should be kept for NoteEvents. default-repeat-chord and
tab-repeat-chord would then use this function.  I'm writing it on other
post.
     
Done. Thanks for this improvement!

Marc

http://codereview.appspot.com/224082/show
   

Shouldn't there be a few words of explantion about using q and
\tabChordRepetition somewhere in 2.4.1 "Common notation for fretted
strings"?
 
I'll have a look at it.
At the beginning of Documentation/notation/fretted-instruments.itely, it says:

<at> warning{String numbers <at> strong{must} be defined inside a chord
construct even if there is only a single note.}

But something like c4\4 works pretty well, and IIUC, the comments
in lily/tab-note-heads-engraver.cc verify that string numbers are
allowed within and outside chord constructs. So, while adding
some remarks about  \tabChordRepetition, should I delete the <at> warning{...} ?

Marc


There is a reason for this warning, I'm sure. (I think I'm the one who put it there). Before deleting it, try using the string number orientation command and see if it has any effect on the string number when it's not inside a chord construct. 

Jon 

--
Jonathan Kulp
http://www.jonathankulp.com
_______________________________________________
lilypond-devel mailing list
lilypond-devel <at> gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Jonathan Kulp | 1 Mar 13:20 2010
Picon

Re: Error in fretted-strings.itely? (was: Re: Enhancement: tabalture chord repetition (issue224082))

On Mon, Mar 1, 2010 at 5:47 AM, Jonathan Kulp <jonlancekulp <at> gmail.com> wrote:
On Mon, Mar 1, 2010 at 5:20 AM, Marc Hohl <marc <at> hohlart.de> wrote:
Marc Hohl schrieb:
Nicolas Sceaux schrieb:
Le 1 mars 2010 à 10:00, Marc Hohl a écrit :

 
nicolas.sceaux <at> gmail.com schrieb:
 
http://codereview.appspot.com/224082/diff/1/3
File ly/chord-repetition-init.ly (right):

http://codereview.appspot.com/224082/diff/1/3#newcode51
ly/chord-repetition-init.ly:51: #(define-public (tab-repeat-chord
previous-chord location duration articulations)
It would be  better to define a generic repetition function, taking the
event types that should be kept for NoteEvents. default-repeat-chord and
tab-repeat-chord would then use this function.  I'm writing it on other
post.
     
Done. Thanks for this improvement!

Marc

http://codereview.appspot.com/224082/show
   

Shouldn't there be a few words of explantion about using q and
\tabChordRepetition somewhere in 2.4.1 "Common notation for fretted
strings"?
 
I'll have a look at it.
At the beginning of Documentation/notation/fretted-instruments.itely, it says:

<at> warning{String numbers <at> strong{must} be defined inside a chord
construct even if there is only a single note.}

But something like c4\4 works pretty well, and IIUC, the comments
in lily/tab-note-heads-engraver.cc verify that string numbers are
allowed within and outside chord constructs. So, while adding
some remarks about  \tabChordRepetition, should I delete the <at> warning{...} ?

Marc


There is a reason for this warning, I'm sure. (I think I'm the one who put it there). Before deleting it, try using the string number orientation command and see if it has any effect on the string number when it's not inside a chord construct. 

Jon 

--

Actually, when I run the following example I get no string number at all:

\relative c' { c\5 }

If I put it in chord  brackets it works:

\relative c' { <c\5> }

This is true for both 2.12 and the latest build from source (yesterday).

Jon
 

--
Jonathan Kulp
http://www.jonathankulp.com
_______________________________________________
lilypond-devel mailing list
lilypond-devel <at> gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Marc Hohl | 1 Mar 19:50 2010
Picon

Re: Error in fretted-strings.itely?

Jonathan Kulp schrieb:
> [...]
>
>
>
>
>     There is a reason for this warning, I'm sure. (I think I'm the one
>     who put it there). Before deleting it, try using the string number
>     orientation command and see if it has any effect on the string
>     number when it's not inside a chord construct. 
>
>     Jon 
>
>     --
>
>
> Actually, when I run the following example I get no string number at all:
>
> \relative c' { c\5 }
>
> If I put it in chord  brackets it works:
>
> \relative c' { <c\5> }
>
> This is true for both 2.12 and the latest build from source (yesterday).
Ah, sorry for the noise - as I normally write normal staves in 
combination with
tablature staves, I make the string number transparent, so I don't see
any difference, and the tablature placing is correct in both cases.

Thanks for clarification!

Marc
>
> Jon
>  
>
> -- 
> Jonathan Kulp
> http://www.jonathankulp.com

Gmane