Save Options

[Chris Northcross]

Anyone have any best practices for saving while working in Studio Artist? I'm getting more proficient with saving my paint patches and my sessions as I go along (naming convention for saving my sessions consists of 'project' name + version number i.e. dragon_01) but not so with my history sequences or PASeqs (outside of the final version). Once I get done with saving, I sometimes feel like I've lost a bit of direction in where I'm going. I prefer to plow ahead until I get to a place where I feel comfortable stopping and saving but I've been burned one too many times by a crash not to stop. Have any of you ever had to wrestle with this?

[Synthetik]

To be honest i can run 3.5 all day doing demos and not have it crash ever. So if you do run into problems you should email the crash logs into techsupport AT syntheti DOT com with a description of problem so we can track any potential issues and fix them.

If you are going to be running the program for long periods of time, here are a few things to be aware of. I recently had some email back and forth consultation with someone who leaves studio artist running for days at a time and would eventually run into a crash. What we determined was 2 things.

First, he had automatic history recording turned on as a preference and was unaware of this. So his session history was recording all the time growing bigger and bigger and taking up more and more memory.

Second, he had all his Path : Path Layer Record Option flags turned on. So every manual and automatic paint stroke was also being recorded as bezier paths into the layer's bezier path frame. For hours and hours and hours, growing bigger and bigger and bigger. Since in 3.5 you need to manually erase the bezier path frame, these record option flags only add bezier paths to the existing bezier path frame when turned on. So again he was using more and more and more memory over time.

Eventually he would run out of virtual memory and run into problems. When he turned both of these options off he found using Studio Artist for really long extended periods of time because much more stable, his crash problems essentially went away.

Occasionally someone finds a memory leak issue with some particular operation. So doing something like an ip op with a particular set of parameters would leak memory. This kind of problem could eventually cause a crash since memory is leaking every time the operation is performed. We like to fix this kind of thing quickly if there are problems like this, so if you think you are running into this kind of thing again letting us see the crash log along with a description of the problem is the quickest way to resolve the issue. The Activity Monitor utility application is a good tool for a user to track this kind of thing. If you are doing something repeatably and studio artist's memory consumption continued to go up and up over time then this would be an indication of this kind of problem. Again, we fix these kinds of problems as soon as we are made aware of them, and do a lot of testing to try and uncover and fix them before you even get your hands on a new release.

[liveart]

chris you are not alone. I also have developed the habit of saving as I go along. For the PASeqs I have a naming convention which describes the sequence in a way which is meaningful to me. "quick Oil" for example. So while working out the sequence I name the file Inprocess___. I tend to overwrite the inprocess file with each sequential save until get to the final.

Sometimes the exploration of a process takes a right (or left) turn in this case I rename the inprocess file instead of overwriting it. I can't really say that this should qualify as a best practice though.

I do have one thing that took me a while to figure out but that I now find very useful. If I am working on a Multilayer Pas. Then the final name includes the layer composite settings " 3layerwatercolor 50max20addsc" for example. This may lead to unwieldy file names but at least I have the info on how to set my layers 4 months from now. The first layer is of course the default replace so the 50 max would describe the composite setting for the second layer and the 20 addsc(aled) the third. It would be nice if SA would automatically remember the layer composite settings.

I have the record history button or stroke recording only when I need it. I have worked out that it is possible to drag operation commands between the history session and the PASeq session so I have a system where I am recording the history or PASeq but not both at any given time. Because of this I am usually using the history as sort of a scratch board, with fairly frequent erasing to replay the current development of the PASeq then try a few new steps and if I like what I get drag these over to the PASeq. But sometimes in the process it is possible that the roles get reversed and I am recording to the PASeq while replaying the history. It all makes sense at the time.

Saving frequently can be a bit of a distraction. A recovery autosave that gave the option to re-open the program with the settings at last use might be helpful. But it might just add to memory management issues.


I do want to add that the crashes I get most frequently do not throw up a error or log. The program just quits. If I am working out a preset when it does this I may not remember the setting modulations that I had just done which caused the crash. So that there really is nothing to send to Tech support if it is not reproducible. If I am working on a Pas and it happens the chances of reproducing are dependent upon how recently I saved. John if there is a way to capture an error log for these one time events that I can send in let me know.


I do want to encourage everyone to send their reproducible crashes to tech support. I do find that each successive build has been more stable.

[Dee Flouton]

"... it is possible to drag operation commands between the history session and the PASeq session so I have a system where I am recording the history or PASeq but not both at any given time."

Had no idea this was possible-thanks for sharing.

[Synthetik]

There's no really a way to capture an error log from a 'one time event'. You could use SnapzPro or some other screen capture program to capture the onscreen control settings as an image. Sometimes a 'hang' might be the program was asked to do something that takes a really long time, so it might come back again if left to finish.

For example, the growth bundle path load path shapes can be configured so that the path is so complex it takes a really long time to draw. In an ideal world you'd be able to stop any operation at any point, but doing so would involve interlacing speed critical code with endless calls back to the user interface, slowing things down to a ridiculous level. The geodesic brush types are another example of this kind of thing in that you could set them up so that they would draw for a really long time before stopping. A really complex MSG preset drawing into a very large canvas size might be another example.