Do's ans Don't's for a Crash free DP

Spikey Horse · Post by **Spikey Horse** » Sun Jan 22, 2006 6:13 am

So there has been some talk on the stability of DP and the idea came up (sort of, well at least in my mind) that it could be in part due to the user's way of working as much as the actual set up.

So I thought it might be worthwhile to try and uncover what exactly it is that people might be doing (or not doing) which makes DP prone to crashing or seemingly immune from it?

It's not an easy question to answer - how do you use DP? - but it's still an interesting enough question to ponder because I suspect maybe some of things we do in DP are so habitual we don't fully realise they may be a major factor in making DP's operation either a

or a

And also some of us might be better at spotting (conciously or not) patterns of behaviour when working with DP which lead to crashes, hangs, small fires etc and so learn to work a slightly different way to avoid them.

Here's one off the top of my head: although I don't get quits or hangs very often, one sure fire way for me would be to try and switch the instance of a CPU hungry VI by simply opening that VI's drop down menu and selecting the new instance. (Especially true if going from an AU to a VST (using audioease VST wrapper). DP will then usually close the current VI and just before the new one opens -QUIT!. So I always delete the VI first, then save, then open the new instance in its place- never a problem.....and it's a habit now, I don't even think about doing it another way.

So if you have definate 'no no' or a 'yes yes' or even a 'not sure if this is bad' ways of using DP then post them here ......

G5 dual 1.8
10.3.9
1 GB
DP 5 - OK I mean 4.61

chrispick · Post by **chrispick** » Sun Jan 22, 2006 1:22 pm

Okay, I'll bite... Things I do to prevent DP from crashing:

1. Flush undo often.

You can diminish a project's size and efficiency significantly sometimes just by clearing out the undo. Why have your project retain past steps you know you won't return to?

2. Remove unused soundbites often.

Another efficiency step. Do you need to have every edit committed and file imported itemized in your soundbite window the whole time? Clear out the dead weight.

3. Merge soundbites as soon as you can.

DP is more efficient at addressing contiguous files. This step can be especially helpful if you're into super-fast techno music style edits. Merge them into one file.

4. Don't switch out plug-ins or instruments while transport is operating.

Real-time audio playback and processing is tasking enough on a CPU without you switching out sound modules simultaneously. This seems common sense procedure to me, but I read about people trying this sometimes. A good rule-of-thumb for all situations: Stop transport, then delete or switch out.

5. Keep an eye on CPU performance.

If your CPU meter is approaching peak, the next process you do might push it over the edge. Increase your buffer size or stop transport to adjust a proc-heavy parameter (e.g., Some high-end synth VIs can use up a third of your proc's power. Fiddling with their parameters while your CPU's working hard can cause overload).

NOTE: If you use a third-party PCI card like the UAD-1, you may find your internal CPU peaking once the procs reach a higher level of use. If so, you can to adjust DP work priority to low to allow greater efficiency.

6. When you've finished tracking VI MIDI, print the VI's audio, then clear the VI out of the project.

Most soft samplers and VIs allow you to save settings outside of your DP project. Use this ability to clear them out when you're done with them.

EDIT: If you're using DP5 or higher, you can now simply disable the VI. That way, the VI and its specific settings remain part of your project.

7. Work at rates your system can handle.

Some systems can handle multiple 96K / 24bit files. Others can't. Know your system's limitations. You need to have fast drive i/o to work with higher file rates.

8. Don't run other apps while running DP.

DAW work requires a lot of CPU attention; it's selfish that way. Close other apps while using DP.

9. Have sufficient system RAM.

Soft samplers and VIs can eat up RAM pretty fast. You want to maintain enough RAM overhead to accommodate this and allow the CPU to access it for other processes. Rule-of-thumb: RAM is one of those areas where it's best to get more than you think you'll need.

10. Save multiple versions of your project.

This doesn't really prevent crashing, but it is good insurance against file corruption issues. I typically start with a project called, say, "SongName v01," then save as higher numbers (v02, v03, etc.) as I progress into composition, tracking and mixdown. That way, I always have a project I can revert to if if things go awry with the latest one.

11. Keep your audio files, apps and sample data on separate drives.

A lot drive-spinning occurs when doing DAW work. If you're tasking a single drive to i/o audio files, stream samples and deal with app minutae, then you're overtaxing that drive.

qo · Post by qo » Sun Jan 22, 2006 2:39 pm

To ensure an absolutely, 100%, crash-free DP experience, my advice is don't launch DP

You can still look at the icon in the dock, and even open the Applications folder and browse through DP's folder. And, you can copy projects your friends have done to your hard drive. But, if you resist the temptation to click on DP's dock icon, you will have have travelled a long way down the road to stability.

OK, kidding aside, don't change hardware settings too much. And, definitely don't change settings with e.g. Apogee's FireMix except prior to launching DP (Timeline taught me this a while back).

Also, DP doesn't deal very gracefully with unplugging/replugging audio hardware. This is almost like uninstantiating all your VIs and reinstantiating them and the root of the crash problems in this space is probably tied to Spikey's advice about changing VIs.

qo · Post by qo » Sun Jan 22, 2006 2:42 pm

Do get in the habit of looking at and saving your crashlogs. Try to get a feel for them. BE the crashlog.

Check if they all point to the same place, or if they are pointing to random places. If the latter, then start to suspect your hardware (e.g. RAM). If the former, then mail it to MOTU and tell them how you are reproducing it.

Shooshie · Post by **Shooshie** » Sun Jan 22, 2006 5:00 pm

Habits I brought with me from OS9:

Launch Sequence:
1) Boot the interfaces first.
2) Restart (or turn on) the computer
3) Launch DP in fresh RAM (don't boot anything else up first)
4) Make no hardware changes (on or off) before shutting down DP.
5) Keep your system clean. Do you really need every shareware app you can find on Versiontracker?

New Habits for OSX:
1) Don't boot Dashboard before opening DP, or if you do, use a utility like DashOff to quit it.
2) Flush Undo periodically, but only when you're sure you don't need it anymore.
3) Save often
4) Repair Permissions. I've become more and more convinced of this. They get messed up by installers and other apps.
5) Careful when using other apps that access Core Audio or Core MIDI. That includes Jack, Soundflower, or anything else that messes with your internal software ports.
6) Don't try to run more VIs than you can run. Think of your CPU as a bee. It's very, very busy, but it's just one bee. You're already asking it to pretend that it's a hive, but when you ask it to be the clover, the air, the world, the honey, and everything else, sometimes it just sits down and says "no."
7) Use MOTU's MIDI interfaces.
8 ) Separate your workflow to different hard drives that can access their disks independently from each other (partitions don't count). When Apple needs to do a system call, while MOTU is writing to disk, while your favorite VI is chugging away merrily, thinking it's the only app in the world, you open up the odds that pretty soon they're all three going to need something at the same time that simply isn't there, and when one of them has to wait, things could get very nasty. Use your head. Figure out the workflow. Separate different needs to different drives.

There are surely more. I'll add them if/when I think of them. These are pretty essential and basic. I always abide by these, 100% of the time. If I don't, and it crashes, I think, "I deserved that." But I do. And it doesn't.

Shooshie

dtobocman · Post by **dtobocman** » Sun Jan 22, 2006 5:33 pm

"Mute frees system resources" is a big help in avoiding crashes and headaches. It's in Automation setup...

This feature frees purges any plugins from RAM on a muted track. The downside is that you can't make on-the-fly mutes of audio-based tracks. The upside is that you don't have to delete tracks to make them "inactive." The best part is that your CPU is not bogged down by stuff you're not even asking it to do, so... less crashes.

chrispick · Post by **chrispick** » Sun Jan 22, 2006 6:02 pm

Shooshie wrote:7) Use MOTU's MIDI interfaces.

All due respect, but I'm not sure about this one. Aren't most of the people having MIDI problems using MOTU MIDI interfaces? I've never used one and have never had a MIDI problem. M-Audio and Tascam interfaces have always worked great with my DP set-ups.

Shooshie · Post by **Shooshie** » Sun Jan 22, 2006 6:10 pm

chrispick wrote:
Shooshie wrote:7) Use MOTU's MIDI interfaces.
All due respect, but I'm not sure about this one. Aren't most of the people having MIDI problems using MOTU MIDI interfaces? I've never used one and have never had a MIDI problem. M-Audio and Tascam interfaces have always worked great with my DP set-ups.

Gotta admit, you're right, Chris. But I've never personally had any trouble due to the MTP-AVs on my system, at least not until I installed MOTU's latest "Universal Audio Update" last month. I uninstalled it, reinstalled my old drivers, and everything has been fine.

Shooshie

Shooshie · Post by **Shooshie** » Sun Jan 22, 2006 6:11 pm

dtobocman wrote:"Mute frees system resources" is a big help in avoiding crashes and headaches. It's in Automation setup...

This feature frees purges any plugins from RAM on a muted track. The downside is that you can't make on-the-fly mutes of audio-based tracks. The upside is that you don't have to delete tracks to make them "inactive." The best part is that your CPU is not bogged down by stuff you're not even asking it to do, so... less crashes.

Yes, it frees resources, but some people might find that it introduces delays when muting/enabling tracks.

Shooshie

dtobocman · Post by **dtobocman** » Sun Jan 22, 2006 7:52 pm

Shooshie wrote:
dtobocman wrote:"Mute frees system resources" is a big help in avoiding crashes and headaches. It's in Automation setup...

This feature frees purges any plugins from RAM on a muted track. The downside is that you can't make on-the-fly mutes of audio-based tracks. The upside is that you don't have to delete tracks to make them "inactive." The best part is that your CPU is not bogged down by stuff you're not even asking it to do, so... less crashes.
Yes, it frees resources, but some people might find that it introduces delays when muting/enabling tracks.

Shooshie

Read what I wrote about the downside.

Shooshie · Post by **Shooshie** » Sun Jan 22, 2006 8:32 pm

dtobocman wrote:
Shooshie wrote:
dtobocman wrote:"Mute frees system resources" is a big help in avoiding crashes and headaches. It's in Automation setup...

This feature frees purges any plugins from RAM on a muted track. The downside is that you can't make on-the-fly mutes of audio-based tracks. The upside is that you don't have to delete tracks to make them "inactive." The best part is that your CPU is not bogged down by stuff you're not even asking it to do, so... less crashes.
Yes, it frees resources, but some people might find that it introduces delays when muting/enabling tracks.

Shooshie
Read what I wrote about the downside.

DOH!

We're still friends, right?

Shooshie

paradeatw · Post by **paradeatw** » Sun Jan 22, 2006 8:49 pm

1 - Print VIs
2 - Merge sound bites
3 - Delete unused sound bites
4 - Turn off FFT and any unused EQs within Master Works EQ
5 - Bang the UAD card instead of DPs internal processing
6 - Bounce tracks when finished with heavy processing
7 - Don't stare DP directly in the eyes

Wish i had more to contribute, but i have to admit - my sessions have been crash free... i think it only blew up just a few times in a year...

Shooshie · Post by **Shooshie** » Sun Jan 22, 2006 9:05 pm

Come on, Guys. Pour it out. These are going in the Tips sheet.

Shooshie

alexff · Post by **alexff** » Mon Jan 23, 2006 2:26 am

All good tips.

Here's my contribution:

If you're starting to max DP out, don't change the memory/location points while playing a sequence/song.

On my system, this is almost bound to bring on a crash.

philbrown · Post by **philbrown** » Mon Jan 23, 2006 4:51 am

If you don't need beat detection, turn it off in the preferences.

Turn off all sleep options - or - set up your Mac sleep options in such a way that the Mac will never go to sleep with DP running and especially while playing back and recording.

Turn off any Mac networking you don't need. Run as "non-networked" and as "dedicated DP-only" as you can for your needs.

As much as your workflow permits, don't keep every pgm you own open at the ready. Use them as needed or in the combinations that you need and no more than that. IOW, run DP-only if feasible, or as few pgms as you can for functionality.

My personal experience is: don't use Aggregate Devices. This completely hosed a G4 and had to reformat from the ground up to solve it. YMMV

If you can arrange your workflow so as not to have networked MIDI interfaces I would recomment that.

If you can arrange your workflow so you don't need to switch audio interfaces mid-flow I would recommend that.

If you need low buffer settings for low-latency VI response, raise them back up when finished so your Mac's not working so hard. Whether you need to quit to do this is a matter of discussion, I do this without quitting with no problems.

This is not absolute, but it's a biggie for me:
Occasionally a certain specific set of actions done very rapid-fire will crash a program (not just DP). Sometimes slowing down and letting the computer accomplish each step can help. A good rule of thumb is let your computer catch up with your commands rather than getting too far ahead of it. This especially applies to older or slower computers or ones heavily taxed.

Unless needed for your workflow get rid of all extraneous downloaded stapled-on utility skin hotkey enhancement crap, I mean stuff. Think 'lean and mean' or 'less is more' both about DP, plug-ins, add-ons etc and Mac system add-ons as well. If you do need one, add one at a time and make sure there are no ill-effects and if so dump it and all associated files if possible. If in doubt, and it's important to your workflow, people here can usually help you as to which are proven to play nice with DP (like Quikeys for example).

Phil