[EMAIL PROTECTED] writes:
> >Currently it is not. But if we decide that we're going to do some
> >kind of Label => Chord mapping, we should make this mapping an
> >extension of existing system, and not attach some arbitrary coding
> >with duct-tape onto existing structures.
>
> 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 \
> >minor, and it can be fixed. (Because it is minor, it was the first
> >thing I saw)
>
> I completely agree--having to go through four different files to get what
> you want is *not* a good way to implement things. You (well, mainly Jan)
> were asking for me to post what I had even though I knew it was far from
> complete, so I post and get blasted for it. But that's beside the point.
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!"?)
> >2. How do we offer end-user customizability of every mapping between
> > names (labels) and pitches
>
> This can probably be done in the same manner as the language customizations
> that you already have in place. The question then is, how do you pass that
> information to the Chord object?
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.
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.
>
> >PS. Please don't get upset with me because I am critical of the things
> >you make. It's nothing personal: I am critical of almost everything,
> >including stuff I write myself.
>
> I've tried not to, but it's awfully tough not to when people call your
> approaches stupid!
> It's not a good way to encourage development!
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.
--
Han-Wen Nienhuys, [EMAIL PROTECTED] ** GNU LilyPond - The Music Typesetter
http://www.cs.uu.nl/people/hanwen/lilypond/index.html
