seejayjames

I can't do this myself, but would there be a way (C external probably, or mxj) to access your current patcher as text, copy the text into a new file, then save it automatically with a name like yourpatch_1.pat? Then, each time there's a change (or maybe each time one clicks a certain button, or perhaps based upon a timer), a new read of the current state of the patcher is saved to yourpatch_2, _3, etc. (which would then be the current state).

Then through a keystroke or clicking, the previous states of your patch would be loaded. It certainly wouldn't be as slick as an undo that's incorporated at the program level, but it might give some leeway. When you're done for the moment, save the patch with a new name so that the next time, the undo files will be using that new name. One could automatically delete the undo files upon closebang, or do it manually if you're leery...

Probably there's reasons why this wouldn't work, but I read stuff about filein etc. in C, and am wondering whether it could work.

Undos with tables and multisliders etc. are doable using coll, and quite useful, but that's of course only part of the patch. It would be great to extend the overall Undo function of Max without having to manually save versions with new names all the time.

possible-idea-for-max-undo

> It would be great to extend the overall Undo function of Max without

> having to manually save versions with new names all the time.

How often does it actually happen, that you have to redo a whole patch?

In my experience this happens maybe once or twice a year, and the 

overall time (lets assume 10 years) to redo it usually would be less 

than would be needed to program such a beast. (And in most cases it was 

caused by a crash and an undo wouldn't help in this case...)

If it happens all the time to you, you should look at your programming 

style. If you encapsulate a lot, you don't come across clutter problems 

too much. And missing undo levels force you to better programming style. 

In the end it might even be an advantage that its only half a level of 

undo. (It would be one level, if I would get back my connections after a 

And doing it by hand is so fast: switch to finder, cmd-d, switch back.

This is almost like clicking somwhere, I'd assume its probably faster.

Seejay James wrote:
> It would be great to extend the overall Undo function of Max without
> having to manually save versions with new names all the time.

How often does it actually happen, that you have to redo a whole patch?
In my experience this happens maybe once or twice a year, and the 
overall time (lets assume 10 years) to redo it usually would be less 
than would be needed to program such a beast. (And in most cases it was 
caused by a crash and an undo wouldn't help in this case...)
If it happens all the time to you, you should look at your programming 
style. If you encapsulate a lot, you don't come across clutter problems 
too much. And missing undo levels force you to better programming style. 
In the end it might even be an advantage that its only half a level of 
undo. (It would be one level, if I would get back my connections after a 
misstype into an objectbox).

And doing it by hand is so fast: switch to finder, cmd-d, switch back.
(I am sure its not slower on windows)
This is almost like clicking somwhere, I'd assume its probably faster.

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


It's true, I haven't seen the need to undo in Max nearly as much as in (say) Photoshop, Flash, or Reason/Fruity Loops/sequencer of choice, etc. And I didn't mean losing a whole patch from a crash or anything, I meant active history states of the patch you're working on that you can quickly go back and forth through (as in a seq program, or Word, or this forum editor window). You're definitely right about how the limitation helps with programming style/efficiency and so forth, but like any limitation or non-limitation with tools or languages, lots of things may change (often subtly) during your development/experimentation process. The very ability to do certain things (in software, art, and life) often makes other things seem not as "possible", "desirable", “appropriate”, or other perceptions.

There's a lot of one's own psychology, aesthetic, and ability that manifests in one's patches/choices, and much of it--particularly during any learning process--is experimental, where mistakes can be quite beneficial but can also be frustrating. It’s nice to be able to experience those attempts/experiments/mistakes, then be able to readily “get back out” of them, particularly if getting back out would require a long series of complex or tiresome operations that you’d have to recreate manually (not to mention remember).

Max is definitely different than most programs, though, in that through learning the various levels of complexity and logic, you can start building more complete levels of interaction and control in the actual *executed* patches that you or others can interact with. There’s where any kind of “undo” or other functionality you could ever want (and admittedly where it’s more performatively appropriate than during development) can be created, and in one sense, is the whole point of developing stuff in Max in the first place.

I suppose being used to so much undo availability in most programs just got me to thinking about why it wasn’t implemented as such in Max (and I’m sure there are a myriad of reasons, many of which are probably beyond me). Then I thought about how other programs maintain their undo/history states (which I’m also only vaguely clear on) and wondered my something similar couldn’t be done with just the file that your current Max patch’s state/interface represents. Within Max itself, could there possibly be some kind of automation created that opens a second instance of the current patch as text, then renames/saves/closes it, all hidden, and your current patch/file now has the latest undo state number in its name? Perhaps not enough file control is built in to the actual application itself, which is probably a good thing---maybe a separate application or process would be required, if it’s even feasible. I dunno, am just throwing it out there...

Probably this topic has been overdiscussed, so my apologies. Don’t get me wrong---Max is absolutely fantastic, by far the most engrossing and fascinating program I’ve ever used!

It's true, I haven't seen the need to undo in Max nearly as much as in (say) Photoshop, Flash, or Reason/Fruity Loops/sequencer of choice, etc. And I didn't mean losing a whole patch from a crash or anything, I meant active history states of the patch you're working on that you can quickly go back and forth through (as in a seq program, or Word, or this forum editor window). You're definitely right about how the limitation helps with programming style/efficiency and so forth, but like any limitation or non-limitation with tools or languages, lots of things may change (often subtly) during your development/experimentation process. The very ability to do certain things (in software, art, and life) often makes other things seem not as "possible", "desirable", “appropriate”, or other perceptions. 

I suppose being used to so much undo availability in most programs just got me to thinking about why it wasn’t implemented as such in Max (and I’m sure there are a myriad of reasons, many of which are probably beyond me). Then I thought about how other programs maintain their undo/history states (which I’m also only vaguely clear on) and wondered my something similar couldn’t be done with just the file that your current Max patch’s state/interface represents. Within Max itself, could there possibly be some kind of automation created that opens a second instance of the current patch as text, then renames/saves/closes it, all hidden, and your current patch/file now has the latest undo state number in its name? Perhaps not enough file control is built in to the actual application itself, which is probably a good thing---maybe a separate application or process would be required, if it’s even feasible. I dunno, am just throwing it out there... 

Possible idea for Max Undo?