SafetyNet

I'd like this feature. I've lost several compositions that the autosave didn't. Although I suppose it'd only save you when QC itself crashes, not when you have to force quit for other reasons or the machine kernel panics.

It might be handy as well if you could change the interval on the autosave as well, like Microsoft Word's Autosave Every ___ minutes.

Force-Quits are sometimes intercepted (it depends on the nature of the problem), but kernel panics can't be :( -- I've only had those happen with inferior ram though, so I'm not too worried about that happening personally (quirky 10.5.6 mystery hangs notwithstanding).

I've not looked extensively at the internals of autosaving (by extensive, I mean "at all"), but I don't know if there's a nice simple interface for that...

somewhat relatedly, it would be cool to have the autosaver do differential saves over time, so you could replay them and get a time-lapse composition construction.

I like the concept of autosave, but I don't use it because I tend to like to work on a composition, and then do a save as if it "branches off" from the main one...I can be wrong, but it seems like I was bitten by autosave and a crash once in the past (I think while I was moving something from one comp to another).. and I know I lost a bunch of stuff in one of the compositions due to some autosave glitch, so I disabled it after that. I guess I am "manual save" oriented. I don't like time machine either (please no internet flame)...

The idea of being able to have force quit, or crash stuff "save" as a copy or a different version (as opposed to "saving over" the comp) would be very desirable. What you describe sounds more like what autosave should actually be.

The time lapse idea is intriguing!

I completely agree with the save-over problem -- I hate that. (I actually took a few moments weighing that when coding it up -- I could take the document's original URL and save over it, but I would feel lousy if an experiment that crashed hosed an otherwise perfectly good composition, hence the not-saving-over behaviour.)

Glad you like the design -- hopefully I'll polish kinemecore 0.2 sometime soon to get the new goodies out to everyone...

(having had time machine save my behind a few times, I can't say I share your view on it, but I shan't push my agenda ;)

Hmm, I should have been more clear. I do like much of time machine, but I just don't put it on auto. I save once a day probably. Don't get me wrong, I can definitely envision scenarios where autosave would be ideal, but it seems to drain this poor macbook when it kicks on.

I like the time machine qtz the most :o)

On the save thingee... it is that not save over function that is one of those features that would really cut down on those hollow inside "oh crap I just lost a composition that I worked hours on and I probably would have still had, had I set time machine to autosave" feelings :o)

I just looked at the prompt in the picture... "lucky for you" lol

I've lost plenty of work in QC with those occasional crashes too.

Just so long as it doesn't save over the original file.. I quite often save my work, then make huge changes as an experiment. If the experiment doesn't work (which is pretty often), I definitely wouldn't want that saved over..

On a side note, I see you have the istat menus thing installed. No idea if it's actually related or not, but I had quite a few of those 'mystery hangs' lately, on both my work and home macs. I uninstalled that as it was one of the things I'd installed around the time the hangs started, and I've not had it happen since. I did uninstall other things, but that's probably the only one common between the two machines.

What happened when it hung was that some random app would hang, say itunes or mail. Force quit wouldn't close it (or it'd close the window, but the app would still show as running in the dock). I'd then load activity monitor, and that would hang while loading.. Only solution was a reboot (and sometimes a hard reset).

I'm actually using menumeters -- not iStats (which looks nearly identical, though more modernized).

Not sure if uninstalling it would help -- I use those graphs constantly while working. Memory leaks, infinite loops, and network/disk thrasher bugs are all immediately obvious with them, whereas there aren't any good tools for that sort of stuff otherwise. (Instruments, while very powerful, is extremely quirky in plugin-land, and the performance hit is nearly unbearable when trying to trigger something that takes non-trivial amounts of time to occur.)

I'll try to investigate...

(Relatedly, they flattened the priority levels severely in 10.5.6, and nice 20 apps seems to harm nice 0 apps much more severely... not sure if I'm a fan of this update...)

The latest 10.5.6 seems to have introduced quirks in a number of things that worked ok before (not just talking about QC). I haven't been in the mood to sit down and replicate/track down these problems, because I have had more stuff to do than I can fit in a day lately.

This would be a phenomenal idea. Perhaps have some way to identify what caused the crash and disable whatever part of the composition caused it? Not really sure if that's possible though. Of maybe different levels of "disabled-ness", Everything disabled, Problem areas disabled, or fully enabled.

By the time SafetyNet kicks in, the damage has already been done, and it's A Really Bad idea to try anything too fancy -- saving to disk is a stretch, but I figure the attempt is worth it.

Backtracking is something we've entertained, but QC already does that, so we couldn't really do it better.

Disabling the portion that crashed isn't really feasible -- a non-executing patch can crash it (i.e. make a new composition, drop in a math expression, type in "atan2(x)" for the expression, and it crashes, even though nothing is "running" in the composition to disable. You can also crash the math expression patch by simply entering that equation into the input port too (Again, nothing is running).

When an app crashes (which is required for this to activate), it means that something wrote to a piece of memory that it shouldn't have, or it tried reading memory that it isn't allowed to read -- If you force it to continue from the former, it'll likely happen (for every byte that gets written -- a comp can write billions of bytes per second, so this would be really annoying and mostly useless. In the latter case, terrible things can happen (for example, it could overwrite parts of the program, causing other weird behaviour or problems); crash overriding, while possible, is almost never productive :(

[Sorry for the brief discourse into Operating Systems and Protected Memory models... really cool, fun stuff, but unfortunately no magic :(]

wow, one more time you are adding a beautiful feature to QC.... Nothing to say it's perfect ;)

I've wondered about that... and I don't feel like triggering a crash, b/c I'm still waking up... but when you hover over the math expression it states in the description that you can actually do atan(x) or atan2(x), for example. Is that just a typo on Apple's part?

atan(x) is proper math. There are times, however, where you need atan2 (which is the same as atan, but takes 2 arguments instead of 1, because x can be N/0, which would give garbage with just 1 argument).

The problem comes when you try to do 2-argument functions (atan2 is the only one that I can think of) -- if you only specify 1 argument (atan2(x)), the parser freaks out and crashes (apple's bug). If you give it 2 arguments (atan2(x, y)), it doesn't crash, but it doesn't work either (another bug).

I'm more of a manual-saver than auto-saver like George but for some reason I switched QC autosave on a while back (guess I lost something to a crash). Now when I do a Save a Copy As… then Revert to Saved I don't go back to where I expect. (I still manually save when I'm working in JS patch due to many bittens thrice shy).

How often does autosave actually do it?

Running KinemeCore 0.4 beta (20090430) if that changes anything.

usefuldesign.au wrote:
I'm more of a manual-saver than auto-saver like George but for some reason I switched QC autosave on a while back (guess I lost something to a crash). Now when I do a Save a Copy As… then Revert to Saved I don't go back to where I expect. (I still manually save when I'm working in JS patch due to many bittens thrice shy).

How often does autosave actually do it?

Running KinemeCore 0.4 beta (20090430) if that changes anything.

What is it that you end up reverting to... I would think that it would revert to the one you were working on (not the "save copy as" version)?

For a second I thought you were implying I did use the auto-save... something about the sentence structure made that ambiguous. Heresy!

Thinking about this x months later, it makes good sense that the obvious autosave function besides saving crashing files is a "save all new changes or save version as?" type of prompt at the end of working on a qtz., if you've been enabling an auto save type feature. Instead of writing over the current, it could automatically make a working copy upon opening (transparently to the user), and only save over if chosen at the end of file editing, if you are running in an auto-save mode. That's not already there is it? It's been too long since I've used that.

I was under the impression that auto-save saves over the original file every time that you would do any change to become "save-able", including jiggling and releasing patches on the editor, and that once you exceed your undo levels, you're locked in to whatever it's become.

you should be careful with the QC built in auto save. or at least do not enable that and then open last edited comp in case something goes wrong. i mean if your comp crashes and your auto saving the crashes and opening last comp then you will keep opening a comp that crashes. if its a bad enough crash and you can't get qc to run again you need to trash the prefs.

Haha correction: Like george, I'm more of a manual-saver…

Yeah I sometimes like to abort mission back to last time I saved but want to hang on to my mission (ie. not abort so much as hang-out for a while there man…) in case I forget the steps I was taking (even though they got me in a mess!).

There seems to be a file called filename (Autosaved) while file is open. My tests tell me it is time based (about 3 minutes after first change since last save or auto-save). Revert to save ignores autosaved file (but I had the impression it used the auto-save before now) so it should work okay I guess…

Yeah, good point I remember you saying something along those lines before, Dust.

To avoid start up crashes you can set your preferences so that only the editor opens by default.

yeah i know i have said it a few times. apparently no one else has got them selves into that predicament or wants to admit it. actually have been pretty good about the crashes lately, usually stupid user error stuff like a duplicate plug in. actually kineme core was giving me a headache the other day. all these back trace errors. had no idea what was going on. then i retraced my steps and i hit slim titlebar in core and possibly slim scroll not sure but that broke it for good. trashed net.kineme.core and qc prefs got it working again for a few min then same thing all over again backtrace nswindow errors. it worked for a couple of weeks then just wants to be bad now, even with the new version.

I definitely HAVE gotten into that predicament of continual crashing when I first started using QC and fully admit it :) That's why the first thing I do when I install QC on any system is to disable the Viewer from running automatically when I open a composition (as I indicate above). To me this ranks as a really good idea in general.

I've never been able to devise a composition that would outright crash QC from just opening the Editor (and setting the Viewer to not auto open)... only either give exceptions or just not open the file.

Slim title bar definitely doesn't work, in that it won't undo when you uncheck it on Kinemecore right now, and what I need to do to make it "normal" again is to uncheck it and restart QC... which reverts everything.

I wonder if the backtrace errors come from using OSC or similar things(?)... at least that happened to me when using the Leopard version in SL. Before the new version of Kinemecore came out, I noticed that would happen if I had the core installed and used the stock OSC examples... but I hadn't tried it since the new version came out yet. It's always a good idea to send in those errors, crash logs, and whatever is in the Console, etc. to Chris or info@kineme.net... ( I almost never have Console.app open, but it is always informative and makes me go "why don't I always have this open?" Definitely using it all of the time now in SL).

As a first-time poster, I want to say thanks for the great work you've done to make QC better.

I just installed KinemeCore to use the "full screen on launch" feature for my kiosk display. I also have a launchd process restarting my composition when it crashes (particle effects seem to do it eventually). Problem is, every time it restarts the composition, I get the proud SafetyNet dialog box over what is supposed to be a public display! Can this be disabled, or is there a workaround? QC Visualizer is the most stable way to run this composition, so I don't think moving off it will help.

the message shouldn't show up in QCVisualizer, just the editor. There's no built-in way to disable that message, but it should be trivial to make a one-off build with it disabled, and then make it a preference option in a future release.

Sorry, I did mean the editor is the most stable environment, so I need it for that. A one-off build would be much appreciated, but yes, a checkbox for that functionality would be a good solution. Or maybe the dialog only shows the first time, or take a cue from TextEdit and autosave an alternate file in the background and restore to that after crashing.

The cause of the crashing (lot of particles + high resolution + time), I'll save for another thread now that I'm registered.

cwright wrote:
the message shouldn't show up in QCVisualizer, just the editor. There's no built-in way to disable that message, but it should be trivial to make a one-off build with it disabled, and then make it a preference option in a future release.

Are there better ways to run a .qtz in 'turn-the-key' cases like this? For example the performance loss inherent in view comps in the QC editing app.