Stephen Torri: > What I original sought to do, for the most part have completed, was a > editor that would allow me to create guitar chord diagrams that could be > displayed above a measure in the notation editor.
It sounds like the chord is an accessory to the notes, that is, basically just (?) a graphical object. If so, then it's perhaps best just to condense it into simple primitive data and store that in a single Event of type Fretboard or similar, instead of trying to store the performance note events in it. In almost all cases, given a choice of a representation that is simple to play in MIDI and one that is simple to edit in notation, we go for the former. So we don't much like performed note events to be hidden within other containers than the plain linear Segment. > In my diagram I sought to clean up the Event class. This sort of thing is a fine exercise, but at G says it's unlikely to go very far unless it offers some very obvious advantage. Event is a pretty highly evolved class, and while it has some inelegant implementations and occasional poor choices of name, it doesn't contain much that isn't necessary for some real-world reason. > What I did was: > > 1) Move all PropertyMap related template functions to the PropertyMap > class. Since they are inlined template functions working only on the > internal structure inside the PropertyMap object it did not seem > advantageous to keep them in the Event class. IIRC PropertyMap is used elsewhere too, in contexts where we don't need these other functions. An intermediate wrapper might be OK, if perhaps superfluous. > 2) Simplified the Event interface to the six basic functions Moving the rest to where? > 3) Inserted the EventDB class > a: Purpose: Provide the data structure for containing Event class > objects. > b. Internal Data structure: > 1. Map: > a) Key: Memory address of Event pointer (0x40385445) > b) Data: Pointer to Event object Guillaume has pointed out the flaw here - the std::multiset already exists, is efficient, gives us the API we need for Segment, and is well ordered in a controllable way. What he didn't mention is that we also subtly depend on properties of the multiset iterator in quite a lot of places. > c. Advantage: Eliminates need to have Subordering number. This could be better named - it's actually a real ordering used for notation to ensure that events at the same time appear in the right order, i.e. clefs and keys before notes etc. > > - entered chords to override ones generated automaticaly for chord > > name ruler This refers to the ruler (gui/chordnameruler.cpp) that optionally appears at the top of each view (Settings -> Show Chord Name Ruler). It uses the Chord classes in base/Sets.h and chord naming classes in base/AnalysisTypes.h to extrapolate out a chord name for each apparent chord in the event stream. The point is that this is currently read-only, and it would be good to be able to override it. > 1. Why are the Event Exceptions inside the class? Because they are only thrown by the Event, and are specific to it, so that's the obvious place. At least that's the theory - I think we may have other code that uses them, in which case it's bad code. > 2. Why are more than one class declared in the same header file? Because they're related classes and it's easier to skip about within a single file than between files. At least, some of us think so. Actually, probably all of the main developers agree that it's _sometimes_ better to keep more than one class in the same file, although we probably disagree as to extent. Also, we tend to have a wide coverage of classes in a single directory - splitting out classes into individual files would make each directory even more unwieldy, unless we also split up the directories. That would be good in principle regardless, although C++ is still not Java and I don't think we should pretend it is. However, none of this will happen while we're using CVS (without our own repository) because we don't want to lose version history. Chris ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Rosegarden-devel mailing list [email protected] - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
