MOTUNATION (formerly UnicorNation) is an independent community for discussing Digital Performer and other MOTU audio software and hardware. It is not affiliated with MOTU.
Forum rules
This forum is for seeking solutions to technical problems involving Digital Performer and/or plug-ins on MacOS, as well as feature requests, criticisms, comparison to other DAWs.
kurtl wrote:Open DP and Activity Monitor. Play any large mix you might have going. Notice how much processing power is being used by DP. Then open up the mixing board window with all of the tracks shown, with the meters on. In my research, meters use about 20% to 30% more processing power. Now simply disable "show meters" in that Mixing window and the usage goes away. This isn't discussed much in the forum, but it gives my lowly G5 1.8 single plenty of power for between 50 to 60 trks with plugins.
Holy crap. I'm on a 1GHz G4, with two beautiful monitors showing every window imaginable. I ran a project that ate 110% of my CPU, and just by closing the mixer window it dropped to 54%. HALF of the computer was chugging away at the level meters.
Thanks.
Edit: interesting, though, that the DP Audio Performance window shows no change at all.
Hmm, that's strange, because I have recently found on my low-powered 800 MHz 384Mb iMac that I never get CPU spikes when the Mixing window takes up most of my puny 14" screen, but when I leave Track view up, I almost always get CPU spikes, even on single-track simple waveforms on playback.
Granted, I haven't sorted through all the other advice here yet as I have such pressing deadlines that I just have to move forward at this point in time, with the idea that I'll start experimenting with the advice in this topic in a few weeks time.
The point once again is simply that there are a lot of factors involved, and what works for one person may not be beneficial to the other. I suspect it has to do with whether one has active busses in the Mixer window or not.
-On the preference window , check the "show background processing window". So whenever you see that window appear , give your CPU a chance , and wait that it finishes its tasks....
-Leave the buffer as high as possible when mixing or if you use "cue mix" for tracking.
-Changing the sampling rate/bit depth in "configure hardware" first instead of " MOTU audio setup" helps.
Definitely some good suggestions. Aside from many of the aforementioned tips, I would highly recommend a utility app such as Cocktail or Mac Janitor which run your systems routine maintenance "cron" scripts. These usually run during the late hours of the night, but if you turn your Mac off regularly or unexpectedly, then they may not run as often as needed. Cocktail also has a "Pilot" which runs these scripts, cleans caches, and repairs permissions (it can also be scheduled). I will also chime in about DiskWarrior; keeping a clean/organized file directory for your drives is essential for us media whores. I've also picked up a few things from learning to optimize FCP (System Preferences, installation order, etc.). If you think DP is bad, haha, try playing/capturing uncompressed HD with fiber channel RAID's and questionable video card drivers! Check out http://www.larryjordan.biz for more info.
It puts a little historical graph in your menubar, so you can tell how hard your CPU's been chugging over the past few minutes. It also gives more detail than DP's meter (User vs System), and it reports very different percentages than DP does... Watch 'em side-by side.
I do live recordings of large track counts (32+), and usually DP grabs a lot from the CPU when tracks are first armed. Once recording starts, it chugs along at a steady pace. But every 15 minutes or so, Menu Meters reports a gradual ramping up of CPU usage towards 100% for about 30 seconds. Then it levels off. No effect on the recording, but it sure is nerve-wracking...
---------
Also, here's an extreme trick: in times of major processor impact, try switching to the finder and "hiding" DP. For the thrill of it, I've flown blind like that and found that processor useage drops a lot! It's like playing chicken on a dark road with your car's lights off.
Trash your DP prefs.
You can keep a copy of the prefs you want and need, but I found some serious crashes were cured once I flushed out the prefs. I still have to go back every once and while and do it.
To kind of go off what kurtl said earlier, I almost always use the activity monitor (I think version 1.5 as of this writing). If you open up the activity monitor and use the floating CPU window (you can place it in the lower left-hand corner of your screen where it always stays on top of any other windows and doesn't take up hardly any screen real-estate at all), it provides much more precise metering of your CPU performance as opposed to DP's performance meter. It gives you instant feedback as to what your CPU is doing and you can actually watch the CPU levels jump quickly and then fall back down when doing CPU intensive things like open a new instance of a VI, or adjust settings in the hardware configuration menu. Even though the activity monitor adds a little more overhead to your CPU while running with DP, its a great tool to help keep you aware of how hard your CPU(s) are working at a given moment.
Creat a new account to use DP--you can disable everything in this new account.
You can even do this every 6 months to basically be starting with a new machine and clean settings.
Make sure you install your plugs and settings in the system library area vs user library area, otherwise, when you create a new account and delete the old, you will be deleting the old plugs, settings, etc.
willtompkins wrote:I would highly recommend a utility app such as Cocktail or Mac Janitor which run your systems routine maintenance "cron" scripts.
For those of you who don‘t feel comfortable with tools:
-open the shell (it‘s called "terminal")
-type "sudo periodic daily weekly monthly"
-type in the password
-wait a while till it‘s finished
-quit the shell
Thought I post here too what helped me 2 days ago...
Cleaning :
user cache
system cache
deep cache
This solved a problem, where a bad Formac driver caused wrong QT behaviour, but deleting of all related to Formac installation didn't help, the mac still remembered somehow the previous
configuration, although the driver wasn't installed anymore, and restart applied.
Maybe someone could chime in and explain more in detail what
Cleaning :
user cache
system cache
deep cache
actally does
i've also had major problems with BTD recently (since 4.6) but hoping this resolves in DP5. I met up with Magic Dave at a conference recently and he recommended trying the trick of flying the Bounce to a different disk to the audio data as well (eg desktop). He also suggested I made sure I updated my OS from 10.3.6 to 10.3.9 (not done yet as i'm in the middle of a project!). The BTD starts as normal and then just gets halfway thru and then freezes. I have to force quit from that point.
The other sure-fire crasher is anything to do with changing the studio size or settings with a project open. Always takes a dive when i confirm the settings.
I used to have a problem between DP4 to 4.5 with the 'application unexpectedly quit' on exit, but just a nuisance never anything more problemmatical. Seems to have gone in 4.61 (though i'd gladly have it back to have my BTD back!)
At the moment I'm flying mixes out via a tc finalizer to a HHB CDR830 and then importing the resulting .AIF file into the Mac for CD compiling (yawn - but it works!)
One question - i can understand comments about the iLok software, but this leaves me with a bit of a problem with Symphonic Instrument. Anyone have a workround yet?
Nice to be back on Unicornation - been away a while - feels like home again!
i've also had major problems with BTD recently (since 4.6) but hoping this resolves in DP5. I met up with Magic Dave at a conference recently and he recommended trying the trick of flying the Bounce to a different disk to the audio data as well (eg desktop). He also suggested I made sure I updated my OS from 10.3.6 to 10.3.9 (not done yet as i'm in the middle of a project!). The BTD starts as normal and then just gets halfway thru and then freezes. I have to force quit from that point.
The other sure-fire crasher is anything to do with changing the studio size or settings with a project open. Always takes a dive when i confirm the settings.
I used to have a problem between DP4 to 4.5 with the 'application unexpectedly quit' on exit, but just a nuisance never anything more problemmatical. Seems to have gone in 4.61 (though i'd gladly have it back to have my BTD back!)
At the moment I'm flying mixes out via a tc finalizer to a HHB CDR830 and then importing the resulting .AIF file into the Mac for CD compiling (yawn - but it works!)
One question - i can understand comments about the iLok software, but this leaves me with a bit of a problem with Symphonic Instrument. Anyone have a workround yet?
Nice to be back on Unicornation - been away a while - feels like home again!
It may be obvious, but if you've been with DP since pre-4.x releases and you use VIs on multiple sequences in a project, learn how to use the (relatively new) V-rack for virtual instruments.
I generally have two instances of GPO and an instance of Kontakt running inside and a rarely have a crash, although I often spike the CPU bandwidth. Prior to using V-racks, I usually maxed CPU at either one VI in each of three sequences, or one sequence with three VIs in a project. Now I can have at least eight sequences all using the same three VIs.
Thsi maybe an obvious extension of the tip to keep your music on a separate hard drive from the system, but also keep your DP projects on a separate hard drive from your VI samples (3 drives total). Another trick is to spread the traffic load across multiple data busses, rather than load up everything on one bus.
For instance, use a PCI audio interface and a Firewire HD; or an ATAPI HD for the Mac system, a SCSI HD for music, and a Firewire audio interface. Using a Firewire HD for music along with a Firewire audio interface, and a Firewire MIDI controller puts all the traffic on one, serial bus; not a good thing.
The other thing that can save CPU bandwidth is making sure your graphics options are lean. Turn off continous scroll, only have the top window follow the counter, and "pop" the window you're doing editing on out of the consolidated display so that not all panes in the CD are following the counter.
And if you run two monitors, use the two video ports on a single graphics card (if available), rather than one port on each of two graphics cards.
If you're using multiple FireWire interfaces (896HD, 896, Traveler, etc), I documented my experiments to milk as many simultaneous recording tracks as possible without knocking out DP:
