Hello Frank, [About multi-level Undo :] >>We were saying, tweet, tweet, that transition to an OO design is >>neccessary to implement such features. And that they'd be >>relatively easy once that transition was made. >where do you base this on Thomas ? Multi-level undo requires details for each edit to be captured & stored as the program performs the edit. Later when undo/ redo is desired, the edit details are retrieved from storage and applied in reverse/ forward direction. Single-level undo currently exists for some types of edit. This stores a single previous state, probably by storing the entire affected part which is simple but not memory efficient to store many. No redo is available. Both mechanisms (multi-level undo/redo and single undo only) are fairly simple. Any difficulty lies in connecting the undo mechanism with the code performing the edits. There are many hundreds of points in the program where an edit is required, generally in response to some user interaction. When an edit is required it is possible either for that code to directly perform the edit, or for it to be delegated to a centralized routine which performs all edits of that type. Comparing these two approaches, the first requires connecting the undo mechanism to every one of hundreds of varied code fragments which directly perform edits. The second requires only a few connections to the centralized routines, reducing complexity by factors between 10 and 100 (!). That second method, has effectively separated the request for an edit from the task of performing the edit. In OO parlance, the interface 'move that note' has been abstracted from the implementation details of how that note is actually moved. Looking further, the storage of edit details are separate from performing the edit. So the undo storage should also be abstracted, though the complexity advantage is not as huge. Now implementing an undo or redo onto the data model (the bytes in memory representing those notes, CCs, etc) is identical to, or the reverse of, performing the edit initially - apart from the fact that these operations driven from the undo list should not be recorded into the undo list. So an interface is needed for all basic operations without any undo recording. Then the interface for undoable edits calls down to the lower-level basic operation interface after recording undo details via the undo storage interface. Now when all these implementations are separate from their interfaces, details can be changed within the implementation without altering parts of the program which call the interface. So details such as the number of undo steps stored can be changed, or new event types (automation) added, without huge complex interactions throughout the entire code base. [Addressing a few technical issues of OO :] Some people (Emagic, Ray, Yoonchi, other programmers) may perceive certain limitations with the OO paradigm. Ray mentioned decreased performance due to multiple levels of call-thru delegation overhead, which is indeed significant if thousands of loop iterations perform such deep call-thrus. Bulk interfaces where the loop iterates at the bottom solve this problem. The other issue is the treatment of small data objects (eg individual notes & other MIDI events), and the fact that memory allocation for many small objects is inefficient and slow. However these may be effectively & efficiently abstracted using one 'controller' object which is the interface to store & control many smaller items, or the 'flyweight' design pattern which is vaguely related. Object-oriented approaches deliver reduced complexity, by better structuring program functionality, organizing inter-connections, and reducing dependence. This delivers increased reliability & easier coding. OO techniques may be applied in a non-OO language, but OO languages allow much simpler & better naming of object routines since they distinguish between same-named routines (delete) for different object types (track, note, HyperSet definition...). Is that enough for now? Cheers, Thomas