Some time in the not too distant past, Han-Wen wrote:
>I hope that you are aware that I will reject contributions that looks like
>this
>
> if (chord_type_i == 0/*maj*/)
> {
> pitch_arr_.push(Musical_pitch(0, 0, 0)); // Create a major
> chord...
> pitch_arr_.push(Musical_pitch(2, 0, 0));
> pitch_arr_.push(Musical_pitch(4, 0, 0));
> }
> if (chord_type_i == 1/*min*/)
> {
> pitch_arr_.push(Musical_pitch(0, 0, 0)); // Create minor chord...
> pitch_arr_.push(Musical_pitch(2, -1, 0));
> pitch_arr_.push(Musical_pitch(4, 0, 0));
> }
> if (chord_type_i == 2/*aug*/)
> {
>
>If you need to resort to this, use struct initializers (or better yet,
>get the info from GUILE)
I don't understand your objection. The way I see it, the chord routines
have two different functions: First, create a chord from a given label
supplied by the user and second, label a chord from a collection of pitches
that the user supplies. Chord construction necessitates building a string
of pitches from a list--is this what you object to? I agree, if that's the
case--I would rather have a two dimensional array of pitches rather than
having to push them one at a time. Also, I noticed in the parser that it
creates a chord object only to throw it away after translating the pitches
into a Simultaneous_music object. The problem with this approach is that
you lose everything that tells you what the chord is--its identifier, its
inversion, the additions, and subtractions. That's why I'm using the 'back
door' approach here and encoding it into the pitch_arr_ so that the
information doesn't get lost. Ideally, the Simultaneous_music object would
have a chord object inside of it so that all of that info doesn't get lost
(and would keep the ugliness factor or going through the back door down).
And don't even get me started on the whole translating a group of pitches
into a chord label idea (which is an even hairier subject than I care to
talk about at the moment)!
-- Shamus
