>> I said it was ugly! :-p So basically, you'd have something like c-\maj7
>> instead of c-maj.7. That would be workable. Only where would the
>> definitions go? And how would the user be able to configure them? I
know
>
>I was also thinking of a separate mode (like note mode) that lets you
>leave off the \
That sounds like a good idea to me (you could actually write c-maj7!
Hurrah!). But isn't that what the ChordNames context is (a separate mode)?
Would you implement it in a similar way as the notename-language definitions
are?
>Well, I'm sorry. But as long as there I can't see code, I can't be sure
>what we are discussing; I always want to see code (Wasn't this a
>Linus quote, "Show me the code!"?)
Sure, that's fine. I won't take too much offense at your criticisms... ;-p
>I still think that should be *no* separate Chord object.
>
>Why?
>
>Simple: if a chord is constructed as a set of notes, you automatically
>can print out the chords (as notes), play them in MIDI and transpose
>them. If you put stuff inside Chord objects, you have to duplicate
>code to get printing, playing, and transforming right. I won't have
>duplicate code in Lily.
But you still have to check that pitch list against a known list of chord
constructs, going both in the encoding and decoding phases. Talk about
wasteful duplication! How would you propose to prevent that? I'd have to
take a closer look at the internals of Lily to be sure, but I believe that
if you designed it correctly you wouldn't have any unnecessary duplication
of code with a separate Chord object.
>If you think you can do it without substantial code duplication, then
>show me the code that does so.
>
>And just to remind you, you can easily tack on some extra information
>onto a Simultaneous_music, by putting adding a request to it. Even if
>you are right about storing extra info (like chord names), I still
>don't see why you need a Chord object.
You can *probably* get away without it, of course with the provisos that the
notes are stored in order, and the bass tone comes as a separate entity and
additions/subtractions are separate. I'm not sure how you would go about
attaching a request to a Simultaneous_music object as of yet, but it sounds
like a promising approach (how about a code fragment?). I'll have to do
some more digging into the source...
>To tell you the truth: good development doesn't need to be encouraged:
>Most useful patches were made without me knowing about it, and offered
>to me without my encouragement.
Yes, but to discourage development with destructive criticism can only slow
your project down. As I've said before, I'm not averse to *constructive*
criticism...
-- Shamus
