CoolEdit is by far the best wave editor for speech. (Most editors, like SoundForge, are primarily for music.) CoolEdit can do pitch-changing, or speeding up or slowing down, all very cleanly, with minimal weird artifacts. I work in speech and hearing sciences, and use CoolEdit constantly for all sorts of things. Available from Syntrillium.com. Not free, but inexpensive for all its capability.

This is actually a simplification of a script I've been using in my modeling of neurological problems. I don't do any photorealistic animations, so if you want to take this and run with it, that's fine with me, as long as you include a credit for the "initial idea" or something like that. The best way to learn programming is to modify and expand an existing program (script) that you like. Since you have the various other characters, you're in a better position to make this work universally, develop your Python skills, and maybe even make some money! An idea: One thing that would make this more convenient for others, is to set up the two main variables as parameter dials, so they can be changed without having to dig into the .PY file. I think Python can do that; maybe the dials would be added to the Body of the selected figure.

Well, I don't know either, except that Poser seems to treat "plain geometrical parameters" like yRotate or Bend, differently from "morph parameters" which derive from a morph target. Here's version 3, which seems to do a good job of simply skipping the parameters that aren't present. I tried it on the Skeleton, which lacks several of the morphs and parameters, and it went through without errors, setting only the joints that were actually there.

I suspect the only really universal solution is just to skip the face morphs entirely. I looked at the Python functions, and there are ways to find a universal name for body parts and parameters, but morphs are completely unique. IOW, the Brow Down morph for Vicky seeks a completely different target than the Brow Down for Posette. There may be a way to enumerate all face morphs and operate on them as a list....... but that won't do either, because that list will include things like lip size and "heart-shaped face" morphs, which shouldn't be wiggled. There's no blind automatic way to distinguish the permanent shape morphs from the expression morphs.

Thanks for positive feedback. I don't have any of the fancier characters, so I can't really help with that. You've probably found the best solution, unless there are some "underlying' constant names for those morphs. Here's a slightly improved version, which fixes two things: 1. The original depends on having the FPS at 10, which is where I always set it. Improved version prorates for actual FPS so the Strength parameter can remain same for different frame speeds. 2. Even when "Use Limits" is checked, Poser applies nonsensical limits like -10000000000 for the face morphs. Random wiggling tends to go both ways equally, and thus tends to return to center, but if Strength is set fairly large, the morph settings can reach numbers like 4 or 5 easily, which makes the face turn into a Picasso painting. With these limit settings, no abstract art can happen. Of course, this makes even more places you have to edit for different characters!

PS. One thing I didn't make clear in the internal instructions: You should set up your frame count before running the script. Put your characters and props in their initial position, set animation for 300 frames at 15 fps (or whatever) then select the figure to wiggle, then activate the script.

Okay, attached here is a 'squirmy' script for you. The instructions are contained inside the file, in the upper remarks section. There are several constant values in the script that can be altered to change the strength and frequency of wiggles, but the present settings look about right to me. I'm assuming you know the basics of editing and running .PY scripts.

The Hither dial is important in closeups; it controls how close to the lens an object can be without distortion. For instance: your character is holding a glass out toward the camera as if to say "Cheers". As you focus in on the face, with the line of sight being along the exxtended arm, the glass and then the hand will break up into weird cubist fantasies...... unless you adjust the Hither dial. In general, setting Hither to 0 will get everything to show properly. (Actually, I don't know why you'd even want to leave Hither at the default setting; maybe far-distant shots look better that way, but I don't ever need a far-distant shot!)

I found that Memorize All / Restore All does the job a bit more simply. Save present PZ3, go to last frame, Memorize All, cut Frame count down to 1, then Restore All. Immediately save as new PZ3, and you have the starting frame for next 'cut'.

Agree that the Python forum is dead, probably should be closed so that folks don't waste their time posting things in a blind alley. I've been working on a closely related topic, modeling the movements of neurological disorders like CP and Tourette's. I'll see if I can spin off more moderate 'fidgety' and 'squirmy' scripts!

Now, I wish a REAL software company would have purchased Poser.<< That's the last thing I would wish. The big companies aren't interested in pushing a product unless it has potential for selling to nearly every computer user in the world. Poser will remain a 'niche' product, though its market (I'd guess) is at the larger end of 'niche'. Curious Labs doesn't have the massive resources of a Microsoft, but with only two or three major products in its stable, it does have the motivation to give full attention and focus to Poser.

If I wanted to put a necklace around Vicki's neck, I would import the obj, scale it accordingly, orient near the part of her body that I want it on and then I parent it to her neck (as well as parent a hat to the head or ring to a finger) ? << Yes, that's right. One thing you'll need to get used to: after parenting, the meaning of the xTrans, yTrans, zTrans dials is changed. Those measurements are now relative to the parent, which can be strange if you're not expecting it. Also the scale parameters will change, and sometimes a prop will become weirdly distorted upon parenting. So parenting should be used sparingly, only when you really need the prop to move with the arm or neck. If everything is stable, it may be better to leave the prop unparented. >> What if I wanted Vicki on a platform, like sitting on a box or standing on a stage or sitting in a chair? Would I pose her first and then just move her to appear standing or sitting on the prop? Do I have to parent something here e.g, feet to prop, or hips to chair ? << Same general idea. If you are going to move the box or platform and want Vicki to remain in the same place relative to the object, then parent her Body to the object. (For instance, if you want her to sit in an office chair that moves, or a wheelchair, parenting is definitely necessary.) But if the object is never going to move, then parenting is not necessary and may create an opportunity for errors that wouldn't be there otherwise, because of the scaling and trans parameters abovementioned.

Will the human actions also work for the default P4Fem?

Three things: 1. Poser should keep track of which directory you last used for each type of file. If I picked up the PZ3 from folder P, and then saved a rendered BMP into folder B, Poser should know enough to save the modified PZ3 back into folder P instead of putting it in B where I won't be expecting to find it! By the same token, an exported .OBJ should go by default into the last place I found an .OBJ. 2. A "snap-to" action in animation, as in LifeForms, so that a complex walk can be developed without having to readjust every single frame to avoid the ice-skating effect. Alternately, export an animation file that LifeForms will accept. 3. Consistent rotation. In Poser's present system, the yRotate operates about an object's own axis, but xRotate and zRotate operate with respect to the universe. This makes some moves essentially impossible and others extremely difficult, requiring huge trial-and-error rotations of all three dials to make what should be a small increment. (If you've never run into it, try this: take a Box prop, scale it into a book shape so you can see where it is; set xRotate and zRotate to 90, then try to rotate the book itself in each direction. You'll find that two of the dials make the same actual move, leaving one direction without any way to adjust it.) It would be much easier to arrange things if all three rotations acted about the object's own axis.

Poser's speed in building an animation depends far more heavily on CPU speed (MHz) than on graphics. (The vast majority of applications really don't need CPU speed, but Poser is a definite exception to the rule.) When I switched from an old 133 MHz processor to an 800, my animation speed improved dramatically. On a PC, adding more RAM can also help; I don't know if that holds for a Mac.