Re: [frogs] Re: Capo-ChordNames

[Carl Sorensen <c_sorensen@xxxxxxx>]

On 8/10/10 3:38 PM, "Wols Lists" <antlists@xxxxxxxxxxxxxxx> wrote:

>    On 10/08/10 14:39, Carl Sorensen wrote:
>>  
>>>  
>>> If it gets me into Scheme and C++
>>>>> I'll be well pleased.
>>>  
>>  
>> At the moment, probably not too much Scheme (although you might want to try
>> writing the CapoEngraver in Scheme).
>> 
>>  
>  Actually, I was thinking that writing this engraver first might be a good
> idea, seeing as it should set capoFret as a side effect. oops :-) If Mike gets
> back to me with some scheme engravers to investigate, I'll try that route if I
> can (or I'll just try and find a few candidates myself).

You're welcome to write a CapoEngraver first if you want to.  I wouldn't
recommend this, though.  The output of the CapoEngraver can be created right
now as a \mark, so it's not strictly needed.  The modification to the
ChordNamesEngraver is necessary to get the output you want, so I think
that's where you should start.

>  
>>  
>>  
>>>  
>>>>> 
>>>>> I'll look at your long email, probably respond, and then hack at it and
>>>>> come back with more questions :-)
>>>  
>>  
>> Sounds great.
>> 
>> But there's some wrong advice in my email, because I wasn't thinking about
>> having *both* chord names created by the engraver.  You'll want to follow up
>> more on your original approach, i.e. having both pitches and capo_pitches.
>> Then you'll need to call the chordNameFunction twice, once with pitches,
>> bass, inversion and once with capo_pitches, capo_bass, capo_inversion.  Then
>> you'll need to combine the two markups into one, probably with another
>> scheme call.
>>  
>  Actually, I was wondering if I could take a different approach ...
>  
>  I've twigged that scm_call_4 simply calls the procedure in argument 1 with
> four more arguments. It MIGHT be possible to rewrite that instead. I've got a
> nasty feeling, however, that there are a whole bunch of chord name functions,
> so that's probably a non-starter :-(

Yes, I think it's a non-starter.  The modularity we're trying to enforce is
to have a scheme procedure that turns pitches, bass, and inversion into a
markup.  That way, if someone wants a different chord name function, they
just add it in.  And it shouldn't have to handle the capo stuff.

>  
>  Do you know if I'll need capo_inversion, or can I just use inversion? Don't
> worry about investigating if you don't know, it's more experience for me :-)
> but it's quicker to ask than duplicate knowledge :-)

I don't know the answer to this question.  I haven't looked carefully at the
data type of inversion.  It may be that the inversion data doesn't change
based on the chord root.  If so, you can just use inversion.

>  
>>  
>> 
>> vertical/horizontal should be a context property, rather than a keyword.
>> 
>> I'm not sure yet about capo_fret.  It could be a context property, or it
>> could be part of the structure of a capoEvent.
>> 
>> For getting started, I'd recommend making it a context property, and
>> avoiding the use of a capoEvent.
>> 
>> Then you'd do something like
>> 
>> \set ChordNames.capoFret = #3
>> \set ChordNames.capoOffset = #'horizontal
>> 
>> to set up the engraver properly.
>>  
>  Okay. Next task. Actually sit down and start writing some code, then post it
> to the list to see if it makes sense :-)

Sounds great to me!

Carl



---
----
Join the Frogs!