I'm thinking about the best way to create an Undo function for the table, coll, and detonate objects (particularly detonate). I'm imagining something like this (just musing out loud):
-- One of the objects (let's say a table) is created with a given name, and saved with that name: "user_table"
-- This is automatically saved (unseen by the user) with another name, like "table_1"
-- Every time it's changed, there's another table saved with a new name: "table_2" etc. (using a counter or inc/dec and sprintf)
-- Clicking a particular button or hitting a key will revert back to the most recent one in the list by reading it back in.
-- Clicking a different button will Redo, in the opposite direction.
Not really that tricky, I think, but I imagine there could be issues with knowing whether there actually exists a particular file with that name (i.e., have you come to the end of the Redos?)
Also, when you're *done* with the object (which could be a closebang, or a button one can click to "finalize" the state) -- you'd want to delete all the other ones and re-save the final version (or, I suppose the current version could be resaved each time, with both the user-given filename AND the hidden "table_5" or whatever). How could Max delete these Undo files automatically?
I guess a coll could be used to keep a running list of table values: each entry is a particular level of Undo, and contains a list of all the table values. However, I don't see this working for Detonate. Also, table gives the "bang when edited" message out its right outlet. How can one tell when Detonate has been changed (in order to re-export another Undo file)?
Working with other apps like Reason, Fruity Loops, and all other sequencers for that matter, Undo is the most crucial element. It would be really great to implement this to expand the functionality of tables and Detonate.
Thanks for any musings you may have on this...