Re: FretDiagrams Architecture
[EMAIL PROTECTED] writes: > circumstance, I would imagine that the FretDefinition would need a > duration, but the duration comes from the chord, so again, it seems that > the FretDefinition is tied to the chord, and probably shouldn't be a > separate music object. > > I view the \diagram as a modifier to the chord, not as a stand-alone > object. > > Can you help clarify my thinking on this? yes - music object is a little imprecise. It should be a FretDefinitionEvent (an event), similar to ArticulationEvent for -\fermata -- Han-Wen Nienhuys | [EMAIL PROTECTED] | http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: FretDiagrams Architecture
On Fri, 2004-11-19 at 07:38, Han-Wen Nienhuys wrote:
> * I suppose that this is still too difficult for "normal" users, and
> that we should also have an option
>
> a. to override fret diagrams for once, eg.
>
> \chordmode { d:add9 \frets "abc9312" }
>
> b. to override a fret diagram from now on
>
> \chordmode {
> \set rememberFretOverride = ##t
> d:add9 \frets "abc9312" d:add9
> }
>
>would print the 2nd chord with the same fret diagram
>
> Of course, we need to make sure that these once-exceptions print a
> warning when a transpose is attempted.
>
>
> * The \frets keyword would have to be added to parser.yy and
> lily-lexer.cc
>
> * The \frets command would be translated to a FretDefinition music
> object (see define-music-types.scm), which includes a
> fret-diagram-definition music interface symbol. The
> Fret_diagram_engraver will try to catch music objects that have
> fret-diagram-definition.
As I've been reviewing the parser and trying to implement this, it seems
to me that the \frets (I'd prefer to use \diagram, and use \Frets like
\Chords is used now, i.e. equivalent to \chordmode + \new FretDiagrams)
should create a FretDefinition, but that FretDefinition ought to be a
property of a Chord music object, rather than a separate music object.
I say this, because the Fret-diagram-engraver hunts for Chords, and uses
them to look up fret-diagrams in a table. Only when we want to override
the default fret-diagram is the \frets keyword brought into place.
OTOH, I suppose that you could be recommending that the parser create a
FretDefinition music object for every chord found in \chordmode, and the
Chord-name engraver would ignore FretDefinition objects, and the
Fret-diagram engraver would ignore Chord-name objects. In this
circumstance, I would imagine that the FretDefinition would need a
duration, but the duration comes from the chord, so again, it seems that
the FretDefinition is tied to the chord, and probably shouldn't be a
separate music object.
I view the \diagram as a modifier to the chord, not as a stand-alone
object.
Can you help clarify my thinking on this?
Thanks,
Carl
___
lilypond-devel mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: FretDiagrams Architecture
[EMAIL PROTECTED] writes:
> On Sun, 2004-11-21 at 05:25, Han-Wen Nienhuys wrote:
>
> > I think that
> >
> > a. we are storing chords in the wrong way. In retrospect, I find
> >
> >root + list of (step, alteration) tuples
> >
> > more logical
>
> So rather than using the pitches as the key for the hash table, it ought
> to be the chord structure, as is inferred in ChordNames, but not the
> chord name itself. Is that what you have in mind?
Not yet; this something to do when we change the representation of
Chord names internally.
>
> >
> > b. using the octave to store different variants is misuse of that
> > less-than-perfect storage model. I think that we should have some
> > kind of ChordAlternativeEvent to store the extra information.
>
> Something along the lines of
>
> \chordmode {
>d \alternative 1
> }
Yes.
--
Han-Wen Nienhuys | [EMAIL PROTECTED] | http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: FretDiagrams Architecture
On Sun, 2004-11-21 at 05:25, Han-Wen Nienhuys wrote:
> I think that
>
> a. we are storing chords in the wrong way. In retrospect, I find
>
>root + list of (step, alteration) tuples
>
> more logical
So rather than using the pitches as the key for the hash table, it ought
to be the chord structure, as is inferred in ChordNames, but not the
chord name itself. Is that what you have in mind?
>
> b. using the octave to store different variants is misuse of that
> less-than-perfect storage model. I think that we should have some
> kind of ChordAlternativeEvent to store the extra information.
Something along the lines of
\chordmode {
d \alternative 1
}
?
Carl
___
lilypond-devel mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: FretDiagrams Architecture
On Sun, 2004-11-21 at 05:15, Giancarlo Niccolai wrote: > Uhm, since you are working on the chords: is there any possibility to have > chord names also in other languages? I.e. Am in italian is LAm, Bsus4 is > SIsus4 (only the note name changes, the chord system is the same all over the > world); As there is an include to change note name, it may be sensible to > provide internationalized chord names. I haven't looked at the code yet, but > it seems that engraved chord names are just a font rendering operation, and > so having them internationalized should be trivial. Actually, I'm not working in ChordNames. Rather, I'm working on fret diagrams. I'm not much of an expert on chord names, so I'm probably not qualified to carry this out further. Also, fret diagrams are more than enough for my plate right now, with the limited time I have available for hacking. There is an internationalization system available for LilyPond, but I don't know anything of the details. I would expect that it could be tweaked to internationalize chord names. > > (Sorry, if I bomb you with mail and questions, but is important to me to get > a > grasp on the internal features of an engine to start working at it. I always > do lots of questions and document peeking before starting putting my hands on > a problem). It's fine with me to have you sending questions. I spent a lot of time trying to get a grasp on the internal features of LilyPond, and basically got nowhere. Once I got down to trying to _do_ something, then I found that my questions were much more relevant, and I was able to start to understand what's going on. Any help I can provide, I'm happy to. But I'm really a novice LilyPond programmer, not an expert. Carl ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: FretDiagrams Architecture
On Sun, 2004-11-21 at 09:24, Han-Wen Nienhuys wrote:
>
> there is nothing stopping you from entering the chord in \chordmode, i
> believe,
>
> exceptions = \chordmode
> {
> c:dim7-\markup { \fretdiagram "sitnhsoit" }
> }
>
> for ideas, check chord-modifiers-init.ly
>
Actually, once we have the \frets keyword, then I think we can do
exceptions = \chordmode
{
c:dim7 \frets "foobar"
}
and this will work quite nicely.
Carl
___
lilypond-devel mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: FretDiagrams Architecture
[EMAIL PROTECTED] writes:
>
> This is a good idea. It's got a lot more flesh on it than the skeleton
> I had worked out. I'll have to study the code some more in order to
> have all this make sense to me.
>
> I'd still like to have some syntax that allows me to enter a fret
> diagram for a chord name, rather than for a list of pitches, because
there is nothing stopping you from entering the chord in \chordmode, i
believe,
exceptions = \chordmode
{
c:dim7-\markup { \fretdiagram "sitnhsoit" }
}
for ideas, check chord-modifiers-init.ly
> So do you envision that the style sheet is created in engraver-init.ly
> (notation-context-init.ly)? That is, is the fretDefinitions assignment
> string part of notation-context-init.ly, along with the
> chordToFretDiagramTable assignment?
Yes.
> > * Remaining problem: who will enter those 720 different diagrams?
>
> I'll start with ones that I'm interested in, which will probably be a
> quite small subset of the 60 odd chords per tonality. My Gig Bag Book
> of Chords has 1008 chord diagrams. It also lists 23 different chords
> per tonality. I suspect I'll start with 7 chords per tonality (major,
> minor, maj7, 7, m7, dim, sus4), for an initial list of 84 chords.
>
> As mentioned above, I have future plans for automatically generating
> diagrams for non-included chords and alternate tunings.
>
> Thanks for the careful review of my proposal. You've given me enough
> guidance now that I believe I can move forward on implementation. If I
> have more questions, I'll be sure to let you know.
>
> Onward to World Domination!
To Infinity and Beyond!
--
Han-Wen Nienhuys | [EMAIL PROTECTED] | http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: FretDiagrams Architecture
[EMAIL PROTECTED] writes: > will produce two chord labels (both D), and two FretDiagrams (which will > be different items from the hash table). I think this feature could be > convenient for those who may prefer to have multiple fret diagrams for a > chord in a piece. > > What do you think? I think that a. we are storing chords in the wrong way. In retrospect, I find root + list of (step, alteration) tuples more logical b. using the octave to store different variants is misuse of that less-than-perfect storage model. I think that we should have some kind of ChordAlternativeEvent to store the extra information. -- Han-Wen Nienhuys | [EMAIL PROTECTED] | http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: FretDiagrams Architecture
Alle 04:17, domenica 21 novembre 2004, Carl Sorensen ha scritto:
> In working on this, I discovered another way to handle different fret
> diagrams for the same chord. ChordNames ignores the octave of the
> Chord, but chordmode keeps the octave. That means that we can access
> different fret diagrams for a D chord by changing the octave, i.e.
>
> mychords = \chordmode { d d,}
>
> <<
> \ChordNames {\mychords}
> \FretDiagrams {\mychords}
>
>
Uhm, since you are working on the chords: is there any possibility to have
chord names also in other languages? I.e. Am in italian is LAm, Bsus4 is
SIsus4 (only the note name changes, the chord system is the same all over the
world); As there is an include to change note name, it may be sensible to
provide internationalized chord names. I haven't looked at the code yet, but
it seems that engraved chord names are just a font rendering operation, and
so having them internationalized should be trivial.
(Sorry, if I bomb you with mail and questions, but is important to me to get a
grasp on the internal features of an engine to start working at it. I always
do lots of questions and document peeking before starting putting my hands on
a problem).
Giancarlo.
___
lilypond-devel mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: FretDiagrams Architecture
Alle 04:17, domenica 21 novembre 2004, Carl Sorensen ha scritto:
> On Fri, 2004-11-19 at 07:38, Han-Wen Nienhuys wrote:
> > * Although it is possible to make a #(set-fret-diagram-string ) , I
> > think we can use the mechanism now used for chord exceptions, ie.
> >
> > * I suppose that this is still too difficult for "normal" users, and
> > that we should also have an option
> >
> > a. to override fret diagrams for once, eg.
> >
> mychords = \chordmode { d d,}
>
> <<
> \ChordNames {\mychords}
> \FretDiagrams {\mychords}
>
>
> will produce two chord labels (both D), and two FretDiagrams (which will
> be different items from the hash table). I think this feature could be
> convenient for those who may prefer to have multiple fret diagrams for a
> chord in a piece.
>
> What do you think?
>
Makes sense; also because the freet diagram line and the chord name line ARE
two different contexts; I.e. you expect to have both "D" name and the diagram
on two different invisible logical staffs.
Bests,
Giancarlo Niccolai
___
lilypond-devel mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: FretDiagrams Architecture
On Fri, 2004-11-19 at 07:38, Han-Wen Nienhuys wrote:
> * Although it is possible to make a #(set-fret-diagram-string ) , I
> think we can use the mechanism now used for chord exceptions, ie.
> * I suppose that this is still too difficult for "normal" users, and
> that we should also have an option
>
> a. to override fret diagrams for once, eg.
>
> \chordmode { d:add9 \frets "abc9312" }
>
> b. to override a fret diagram from now on
>
> \chordmode {
> \set rememberFretOverride = ##t
> d:add9 \frets "abc9312" d:add9
> }
>
>would print the 2nd chord with the same fret diagram
>
> Of course, we need to make sure that these once-exceptions print a
> warning when a transpose is attempted.
In working on this, I discovered another way to handle different fret
diagrams for the same chord. ChordNames ignores the octave of the
Chord, but chordmode keeps the octave. That means that we can access
different fret diagrams for a D chord by changing the octave, i.e.
mychords = \chordmode { d d,}
<<
\ChordNames {\mychords}
\FretDiagrams {\mychords}
>>
will produce two chord labels (both D), and two FretDiagrams (which will
be different items from the hash table). I think this feature could be
convenient for those who may prefer to have multiple fret diagrams for a
chord in a piece.
What do you think?
Carl
___
lilypond-devel mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: FretDiagrams Architecture
On Fri, 2004-11-19 at 07:38, Han-Wen Nienhuys wrote:
> * We tack frets onto \chordmode{}, that is, we do
>
> chordScheme = \chordmode { d }
>
> << \new FretDiagrams \chordScheme
> \new ChordNames \chordScheme
> >>
>
> The \chordmode produce . In Fret_diagram engraver (contained
> in FretDiagrams context), we translate from this to the
> appropriate fret diagram. For the rest, FretDiagrams will be very
> similar to ChordNames
Yes, this is what I had in mind.
>
> * How do we generate the correct fret diagram from a chord? I think
> the alist idea is basically OK, and we should use it in a first
> implementation.
>
> The only problem is that we have 60 odd chords, times 12 tonalities =
> at least 720 different fingerings. That's a bit big to put into an
> alist. It's probably better to invent something using a hash-table or
> a tree. I believe GUILE doesn't come with code for trees
> out-of-the-box, but we should check a little better.
I'll start with an alist, and try to learn more about hash-tables and
trees in guile. I guess that we could build a tree based on the
sort-order (I think you use the term "lexicographical order" somewhere
in the code) of the pitches. I've made trees in scheme before as part
of a class assignment, so I could probably resurrect that code, even if
it is 21 years old.
>
> * The alist should be stored in a context property, i.e.
>
>\set chordToFretDiagramTable = ..
>
> * Although it is possible to make a #(set-fret-diagram-string ) , I
> think we can use the mechanism now used for chord exceptions, ie.
>
> fretDefinitions = {
> -\markup { \fretdiagram "xyz" }
> -\markup { \fretdiagram "pqz" }
> }
> ...
> and then in engraver-init.ly (note to self: rename this to
> notation-context-init.ly), we do
>
> chordToFretDiagramTable = #(translate-fret-exceptions fretDefinitions)
>
> the set-fret-exceptions translates the exceptions variable into a
> property setting; this is suitable for providing a "style sheet".
This is a good idea. It's got a lot more flesh on it than the skeleton
I had worked out. I'll have to study the code some more in order to
have all this make sense to me.
I'd still like to have some syntax that allows me to enter a fret
diagram for a chord name, rather than for a list of pitches, because
that's the way I think. I've already completed the code that gets the
pitches given a chord name.
So do you envision that the style sheet is created in engraver-init.ly
(notation-context-init.ly)? That is, is the fretDefinitions assignment
string part of notation-context-init.ly, along with the
chordToFretDiagramTable assignment?
>
> * Overrides of this style sheet can be done by constructing an
> \applycontext music expression, which takes the existing value of
> chordToFretDiagramTable and adds new exceptions to this.
I'll learn more about this.
>
> * I suppose that this is still too difficult for "normal" users, and
> that we should also have an option
>
> a. to override fret diagrams for once, eg.
>
> \chordmode { d:add9 \frets "abc9312" }
>
> b. to override a fret diagram from now on
>
> \chordmode {
> \set rememberFretOverride = ##t
> d:add9 \frets "abc9312" d:add9
> }
>
>would print the 2nd chord with the same fret diagram
>
> Of course, we need to make sure that these once-exceptions print a
> warning when a transpose is attempted.
Yes, and we could also have a warning if a chord is requested for which
no table entry exists.
>
>
> * The \frets keyword would have to be added to parser.yy and
> lily-lexer.cc
>
OK.
> * The \frets command would be translated to a FretDefinition music
> object (see define-music-types.scm), which includes a
> fret-diagram-definition music interface symbol. The
> Fret_diagram_engraver will try to catch music objects that have
> fret-diagram-definition.
OK, I'll figure out how to do this.
>
> FretDefinition should have a special transpose function, so we can
> print a warning when anyone tries to transpose it.
>
> * There is one thing I'm thinking about though. Should we do something
> sensible when the guitar players puts a clamp on the neck (they're
> called "Capo", aren't they) ? Can we get away with
>
>\new ChordNames \scheme
>\new FretDiagrams \transpose d c \scheme
>
Yes. It seems to me that the way it works is you transpose the
requested chord down by the number of half steps corresponding to the
capo location, get the fret diagram, and add the same number of half
steps to every fingering in the diagram. Should be quite easy to
implement.
> How about different instruments, retuned strings etc? My guess is that
> we can't do much except for the clamp, but maybe I'm overlooking
> something.
I see a lot of chord calculators on the Web, including some in Java, and
some that are GPL'ed. I believe that I can eventually write some code
to come up with plausible fret diagrams for chords, given the notes in
the c
