Logic Pro 8 Softsynths at 96K

Tom Swift

Logician
I had a situation today where we were trying to bounce down about 20 tracks of various softsynths, including EXS24s , Stylus, and sculpture. No recorded audio tracks. The producer asked us to provide 24bit/96Khz files for importing into Pro Tools. We failed because every time we tried we got system overloads "system overload. The audio engine was not able to process all required data in time." (-10011) .
Even with all tracks muted except the one sound we were trying to bounce. Even trying to bounce the klopgeist click failed. Also tried recording the sound via a bus to an audio track failed. We went back to doing it at 44.1 and that succeeded, forcing us to ask the producer to make the sample rate conversion on his end.
While watching the 4 processors with "system usage" meter- I noticed severe "spiking" on a couple of the processors.(MacPro 2.66x4 with buffer set to 512 in Logic. MOTU 828). Is it that these synths don't like 96K? Other culprits? HELP!!! :errr:
 
Muting tracks does not release your DSP using Logic's default behavior. I suggest you try to export tracks by first removing any unused plugins (grayed out plugins) so they don't confuse you in the next step, which is to disable all other synths and plugins applied to them (gray them out by opt+clicking). Do it to everything except your current track to be bounced. This will release all DSP and make it available to the track in question. If this still doesn't work, by a new 8-core Mac and enjoy the 16 new CPU meters now available. Wish I had the dough for it. 🙂
 
Upvote 0
Don't remember what Logic's default behavior is in L8 - I have mine set to the tradition "slow response" setting (preferences>audio>general). That will save CPU if the user mutes using the track header mute buttons and not the channel strip mute buttons. I didn't see the OP say what version of Logic he was using - before L8 the are no choices but "slow response".

And yes, 96k is more demanding. Alienimplant has some good ideas on how to work around it - I'm going to try the suggestion of looking into a new tower this year myself. 😎
 
Upvote 0
Going to 96 will be an absolutely walloping CPU hit if you typically work at 44 and find the computer already roughly has its limits there, especially working with softsynths. I just felt this needed saying, as nobody had said it yet 🙂 It's not that the softsynths don't like 96, but roughly speaking you're just asking the computer to do more than double the work in the same amount of time. And also you multiply the hits that the individual cores in your computer are taking.

So as alienimplant has said, I think the only way out of this, if it's crucial that you generate a source at 96 and have to do it in realtime because you're going through a MOTU (IE you can't bounce 'in the box', in which case you could do it offline I imagine and instantly solve all problems)... is to maybe look at exporting/bouncing one track at a time. I don't know how many tracks you have. Maybe you would then reassemble these bounces yourself, or maybe send the individual tracks to the producer.

96 may not be crucial - maybe check with the producer. They may just ask everyone for everything at 96 out of habit. Certainly if they are prepared to accept your 44 files and upsample them, that indicates they weren't worried about it re: sound quality or resolution, but just want 96 because it fits their rig setup. EIther that or they don't know entirely what they're doing, but now I'm going off topic 🙂

Muting regions on non-playing tracks can save CPU in a way that muting a track through its channel strip won't. Something else that may help is that I believe all plugins and instruments on one track must be assigned to the same core in the computer. So for instance if one core always spikes at a particular part of a track, while others still seem to have decent room left, try splitting some of the plugins from the trouble track across two tracks, via some kind of aux or bus send. This doesn't reduce overall CPU useage but may stop a particular spike.
 
Upvote 0
Something else that may help is that I believe all plugins and instruments on one track must be assigned to the same core in the computer. So for instance if one core always spikes at a particular part of a track, while others still seem to have decent room left, try splitting some of the plugins from the trouble track across two tracks, via some kind of aux or bus send. This doesn't reduce overall CPU useage but may stop a particular spike.

This is true. In particular it can save one (or more) core(s) from overloading, creating the overload message.

Check out this link to Apple's site and their explanation:

http://support.apple.com/kb/HT3161
 
Upvote 0
Going to 96 will be an absolutely walloping CPU hit if you typically work at 44 and find the computer already roughly has its limits there, especially working with softsynths. I just felt this needed saying, as nobody had said it yet 🙂 It's not that the softsynths don't like 96, but roughly speaking you're just asking the computer to do more than double the work in the same amount of time. And also you multiply the hits that the individual cores in your computer are taking.

So as alienimplant has said, I think the only way out of this, if it's crucial that you generate a source at 96 and have to do it in realtime because you're going through a MOTU (IE you can't bounce 'in the box', in which case you could do it offline I imagine and instantly solve all problems)... is to maybe look at exporting/bouncing one track at a time. I don't know how many tracks you have. Maybe you would then reassemble these bounces yourself, or maybe send the individual tracks to the producer.

96 may not be crucial - maybe check with the producer. They may just ask everyone for everything at 96 out of habit. Certainly if they are prepared to accept your 44 files and upsample them, that indicates they weren't worried about it re: sound quality or resolution, but just want 96 because it fits their rig setup. EIther that or they don't know entirely what they're doing, but now I'm going off topic 🙂

Muting regions on non-playing tracks can save CPU in a way that muting a track through its channel strip won't. Something else that may help is that I believe all plugins and instruments on one track must be assigned to the same core in the computer. So for instance if one core always spikes at a particular part of a track, while others still seem to have decent room left, try splitting some of the plugins from the trouble track across two tracks, via some kind of aux or bus send. This doesn't reduce overall CPU useage but may stop a particular spike.

Nothing is going THROUGH the motu-it;s just the sound card we're using. Also There are NO plug ins on any of the instruments, just raw sound.
 
Upvote 0
Hmm, why couldn't you do an offline bounce? The MOTU interface can't do this? And why the hell didn't I think of that? LOL. I use it all the time myself.

The MOTU has NOTHING to do with this as it's only the sound card we're using. The culprit (as discussed on Apple's list) may stem from switching the SR to 96 on a project originally started at 44.1.
In theory, as there was no recorded audio yet, it should have worked. But it doesn't . Something in the underpinnings of Logic doesn't like it.

AND as stated in the original post-we DID try offline. With all due respect, please read posts correctly before offering your wisdom. I do, however, appreciate you trying to help.
 
Upvote 0
Ah, that makes more sense then.

Sorry Alien. I reread my original post and it's not clear that the project was created at 44.1 and then we were switching to 96. Maybe if we'd started a new project at 96K and imported the midi sequence from the 44.1 version we wouldn't have had the problem. Anyway, as suggested on earlier replies, there really isn't a problem with making the bounces at 44.1 and then having Tools convert them into what the producer wanted.(96K)
 
Upvote 0
Back
Top