OUCH! Is this an audio-engine deal? Live4 vs. Cubase`

[equinoxworld]

I work almost exclusively in Live
But I also own CubeSX 1...

I have this very long ambient composition done in strictly Live.
It involves 14 tracks and a variety of plugins.
It's 28 minutes long.
This original Live set was based on loops of audio in a fair typical Ableton Live fashion.
As I began to get the production more worked out and dropped in a few more plugs in's... the CPU began to glitch out on me.
I had the basics of the arrangment fairly well worked out.
So I thought it would be best to render each of the 14 tracks to individual audio files. Then I could reload all the processed tracks into Live for a fresh start without any plugins, relieving the CPU.
(And let me say rendering 14 tracks @ 28min each took a fuck of a-long time to render)
None the less, once I had done this I was seriously dissapointed to discover- when I loaded these new files into a new Live set-with No plugins, the firewire drive (apparently) started crappin out (the little red D lighting up). I have three different FW-drives so I tried all three-{same story}. But this didn't make sense to me.?

So at this point I decided to run the same 14 tracks in Cubase to see if in fact it was the Hard-Drive.
':roll:'and what a ya know the full set of files ran just fine in Cubase.{Same files Same order} In fact I was even able to drop plugin's into it and kept runnin smoothly...

Lookin for ideas on the this one':?'

Here's my specs:
G4 dual 1.25 -2g ram
OS X.3.5
MOTU 828
Lacie FW drive
Live 4.0.4
Cubase SX 1.0.5

[bensuthers]

you have 2gb of ram, so load the files into ram instead of playing off hd.

[AdamJay]

you have 2gb of ram, so load the files into ram instead of playing off hd.

and one of the few G4 PowerMac's that has DDR ram no less.

[equinoxworld]

That's a good idea.
I had forgotten bout that feature.

Still doesn't answer the concern as to why SX can handle this and live can't....

I try the ram idea later and let ya know.

[forge]

That's a good idea.
I had forgotten bout that feature.

Still doesn't answer the concern as to why SX can handle this and live can't....

I try the ram idea later and let ya know.

the CPU hungry live issue comes up alot and it's important to remember that it's completely geared up for real time manipulation - it's not a traditional multitracker so there's alot of things eating up the CPU to do with making it all work in real time

[StompyJ]

forge is right,

To be able to do all of these wonderful real-time things we all love Live for, there has to be a tradeoff. In this case, the trade-off is vst efficiency for the moment. Also, don't forget Cubase has existed for over a decade, they've had time to treally tweak the standard they created. This is lives first release with any sort of VSTi ability. I'd expect them to be able to optimize as they go along

[dgkenney]

Are your buffer settings the same in Cubase as they are in Live? This can make a significant difference. Otherwise I'd have to say it's a trade off for Live's random access capabilities.

Dan

[Vercengetorex]

There is something else wrong here. Fourteen tracks with no FX lighting up your disk I/O error light just is not right. I am able to double that track count with my Lacie drive, and my 828MkII with no FX running, and I have a PowerBook 1gHz with only 512Mb DDR. You really need to investigate this matter further. Some more details would perhaps be helpful. What model Lacie drive do you have? How are your HDD's and your interface arranged on the firewire chain? What is your hardware buffer size in Live? any other pertinent details...

[raapie]

Hope you can solve it. on my old PIII850 pc with 768 ram 14 tracks (16 bit ) of several minutes of audio are causing 15% cpu load in Live4.04

with Nuendo that takes about 7%. Nuendo and Cubase are more effectient than Live (VST, VSTi's and audio playback).

[Sheridan]

I'd say cut that ambient piece down to 12 minutes and you'll be fine. Nobody wants to listen to something 28 minutes long anyway.

[rikhyray]

I think it is a good suggestion to split it. If it is for release as CD spliting it into parts is user friendly and if you want to perform it live , hmmm... don`t you interact with the audience ? Hard to say without hearing but at least reducing number of full size track and triggering the rest in session. Unless it is your " have a drink break" or "let me check the ladies tune"

[epilacs]

well since you have rendered each track,
you are set for mixdown in cubase.
i would consider recording each track separately
into cubase then using those tracks as the basis for your final mix
(in cubase)

live as a composition tool is essential.

mix, etc separately....

and, as an aside (not intended to start flame war)
live does not seem to be very mac friendly in terms of memory
usage, etc..forum search pretty much confirms this.
live has never performed as well on mac vs wintel

live is a great tool for compostion, and
of course for live performance, but to me it is just another
piece of the puzzle as far as actual recording etc

and making music should not be done with the thought
of live playing or listener consumption in mind.
make what you like, play whatever you want.
making tracks is totally different from performing live.

[equinoxworld]

Okay folks,
Here's a little bit of an update.
But first a bit of clairification

This is not a CPU issue. The cpu % runs in the low teens when running this set.
It's the little red "D" that lights up when it's dropping out.

This piece is not for live performance or anything quite like that.
It's more of an extended experimental morphing creation, utilizing Live's "Elastic Audio" capabilities. It's a production piece.
I'm not really interested in changing the length or it's overall structure.

So I looked at the ram suggestion...and that's not of any help because>>
The 14 tracks @24bit and 28+ minutes long add up to almost 6 gigs
and with Live booted up and just my systems call for memory to run there's only about 1.4 gig of ram available. I tried it. It didn't help.

As for the firewire chain question, I don't see why these exact same audio files from the exact same drive loaded into Cubase will play just fine, but not in Live.
As for the buffer setting, I tried dialing it all the way through to see how the different possible settings would help or not-- I was only able to make it worse not better.

Now the whole point here for me is I prefer using Live not Cubase, to take this piece to the next level... I not so comfortable working in Cubase - never spent much time with it.

Any other ideas on the source of this problem would be greatly appreciated.

Peace,
RH

[Vercengetorex]

If the little red "D" is lighting up, it is a disk throughput problem. Cubase buffers audio in ram before the playback head for an amount of time set in its preferences, while Live is designed to stream audio directly from disk.
How are your 828MkII and Lacie connected to your G4? Because Live is expecting the audio to be delivered from the HDD in near realtime, and the attempting to deliver that audio stream to the 828 in near realtime, a single firewire connection will cause an incontrovertable bottleneck. Is your Lacie a 7200 rpm drive? Almost their entire HDD line have been 7200 rpm for some time now, however it should be know that many of the compact "ultraportable" drives are only 4200 or 5400 rpm. This could easily account for your experiences.

[equinoxworld]

Verc... thanks for your great insights and questions!

My lacie fw is 7200 (80g)
But I think you may have touched on the heart of the issue, with the difference of how Cubase buffers and Live streams directly from the HD.
Considering that these 14 tracks occupy almost 6 gigs on my Lacie.
I wonder if the bandwidth just isn't there.

Hey with os X I do have the ability to create a (soft)-raid array.
Do you think if i partioned my FW HD and created a raid stripe array that would improve things?

Peace.
RH