seejayjames

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...

 -- 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)

good-way-to-implement-undos

> 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

> -- 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.

In general this could work. But I would use a pattrstorage for that. 

just store some sets in a high program number area... delete them with a 

closebang. Only drawback, it would not work with detonate, as I believe 

detonate isn't pattr ready, but it would work with all the other pattr 

> 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

With detonate you would actually want to have an undo within the objects 

window. I guess this has to be done within the object. Might be a 

Seejay James wrote:
> 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.

In general this could work. But I would use a pattrstorage for that. 
just store some sets in a high program number area... delete them with a 
closebang. Only drawback, it would not work with detonate, as I believe 
detonate isn't pattr ready, but it would work with all the other pattr 
ready objects...

> 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.

With detonate you would actually want to have an undo within the objects 
window. I guess this has to be done within the object. Might be a 
worthwhile feature request.

-- 
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com


Stefan, thanks for the illuminating response. I experimented a bit and got a good working Undo with a table. I used a coll this time around, and have a line to do a "portamento" of sorts between the settings. Next I'll use a pattr for its interpolation possibilities.

It's definitely nice to have an easily-accessible string of Undos when filling in table data (it's a short, 16-item list of note values). It wasn't totally straightforward, but by the time I got it done, it made sense enough. I just use the keys "z" and "x" to scroll back and forth through the "history". Nice!

Do you know about using Max to delete files you've created? i.e., detonate... for a string of Undos, exporting the file each time one edits the data, using a different name and saving it in a temp location. For that matter, how might one even know that the detonate has been edited? Doesn't seem like a "bang" is available as with the table object. Maybe something possible with the two "extra" outlets available in detonate?

eh, I think it would be better to create a bunch of pseudo login names and give a thousand replies to a post requesting multiple undos. Don't try and od this max sid,e you'll just waste a ridiculous amount of time.

eh, I think it would be better to create a bunch of pseudo login names and give a thousand replies to a post requesting multiple undos.  Don't try and od this max sid,e you'll just waste a ridiculous amount of time.


Not sure what you mean about the thousand pseudo-posts... Something about there being a lot of call for Undos? I was talking about Undos only in the context of tables and Detonate, not the patchers themselves.

However, looking at thispatcher it seems like there's *almost* a way to do a rough Undo function for patchers, but there seems to be no way to have it automatically save the patcher with a new name each time there's a change (or you hit a key). It would be like doing a Save As... but without a dialog, just automatically numbered in a series. When you're finally done, do a real Save As... on the current state with a new name, then delete the long string of Undo state files (wouldn't be tough, they'd all be lined up alphabetically/numerically).

Using inc/dec and sprintf you can keep a list of numerically-ordered patcher names easily enough. So you just do a click or keystroke and you'll get a Save As... ready to simply hit Enter and save the current newly-named state. Do you know of any way to automatically "hit Enter" in that case? Not that it's a big deal, but more automation is nice. You could then use pcontrol to open the previous (Undo) patch, and keep scrolling backwards. Each time you went another state back, close any other windows in the series.

I was interested in what you said about the keyboard macros -- those aren't set in Max, are they?

And where could I find this Max toolbox for the UI stuff? Sorry if this is overly obvious, but it sounds interesting. Thanks!

And where could I find this Max toolbox for the UI stuff? Sorry if this is overly obvious, but it sounds interesting.  Thanks!

i figured ***** undo, lets experiment. for times when i am not suree whether my next step in composition will be worth loosing the current one, i 2programmed a copy/paste algorhytm. so i can revert to my preveious good result.

i used the time i saved not programming a complex undo system, for programming a system that generates my data.

i figured ***** undo, lets experiment. for times when i am not suree whether my next step in composition will be worth  loosing the current one, i 2programmed a  copy/paste algorhytm. so i can revert to my preveious good result.

i used the time i saved not programming a complex undo system, for programming a system that generates my data.


Good way to implement Undos?