SE Users with Cubase - How do you deal with bouncing tracks?

[rgames]

Until I got SE I never had to deal with bouncing tracks until the project was complete and ready for mix-down (I ran the Horizon libraries across 2 or 3 machines). Now, unfortunately, I run out of RAM because I'm limited to one machine and I have to bounce tracks. (Bummer... really slows me down).

So, for those of you stuck with one machine using Cubase, what's your procedure for bouncing tracks? Since getting the VI SE I've found that I can generally get 30 or so tracks at a time loaded into RAM (I have 4 GB). After that, I have to start bouncing. The problem is that a lot of the tracks only have brief sections here and there and by bouncing the entire track I use up a LOT of disk space with silence. It also takes a long time to do the bounces because it requires a lot of user intervention in Cubase.

Any suggestions out there? Thanks,

rgames

[Paul]

Hi rgames,

check out the "optimize RAM" option on the "Perform" Page.

You will also find a Video Tutorial that explains this feature here [:)]

Best,

Paul

[rgames]

Hi Paul - thanks for the tip. I've tried using the RAM save features in the past (with VI and Halion) but I still find it more beneficial to bounce the tracks.

Whether I bounce or RAM save, I still have to wait on the playback and I'm forced to do it realtime with RAM save. Also, with both bouncing and RAM save, I have to re-load the VI to edit the track. So, in terms of the hassle factor, RAM save is actually a bit more of a hassle.

The real reason I choose to bounce is that I get ALL of the memory back, not just the memory from the unused samples. I also get back all of the memory used by the (too many) VI instances because I close them down. I think each VI instance takes something like 15 MB of RAM, so if I bounce 10 tracks, that's an extra 150 MB right there that I can't get with RAM save.

It's not an issue for folks with individual VI's because each section has its own license so they can spread it out across multiple machines; those of us with SE are forced to put the entire orchestra on one machine. I generally keep about 30 VI instances active at a time; at 15 MB each, that's 450 MB I've lost just to the sampler, itself! If the VI were multitimbral, that would free up a bunch of memory right there because I wouldn't need 30 instances.

If VSL REALLY wants to do the right thing, you should allow at least two licenses for SE users. [;)] That would help me (and others, I assume) out a bunch!

Thanks,

rgames

[Conquer]

Hi rgames. I don't use Cubase but I understand your problem. It takes a long time to bounce 30 tracks, it would take a long time to bounce down only the brief sections where instruments play because there might be a lot of them in an individual track and it takes a long time to play tracks all the way through in real time to perform the RAM optimisation.

The solution depends on how you construct your music, but at some point you need to say 'that part's finalised' and either bounce or RAM-optimise the VI(s) which played it. I would suggest you try to identify the most important structural parts and sequence them first: for example, if a piece was mainly driven by strings, finish all the string parts then bounce or optimise the strings VI's. For sections where the strings don't play or recede into the background, use a piano (a small GM sound would do) as a guide to sketch out the arrangement till the strings come back.

Make a point of leaving decorative, non-essential or purely textural parts till last, that way you could hopefully record the 'spine' of your piece, free up some RAM and move on to the next important instrument or ensemble (brass, say).

It's not an ideal way of working because you lose the ability to continually tweak parts as the arrangement grows, but there again having to make a decision about a part before moving on the next might speed things up. A bit like in the old days when people had to figure out how to fit their recordings into 24 tape tracks (or in the case of The Beatles, four tape tracks!)

[rgames]

Hi Conquer,

I do tend to separate the composition and orchestration processes but sometimes there's just not enough time to do so.

@Another User said:

It's not an ideal way of working

Agreed - and one I never had to endure until I got the SE. Grrrrrr...... [8o|]

If VSL would just let us run it on (at least) two machines then I would say the VI SE is the biggest leap forward I have had the joy to experience as a user of sample libraries. As it is now, I'm not that much better off than I was using Halion and Opus 1/2 - the hassles I dealt with using Halion are gone but they've been replaced with equally encumbering hassles.

Thanks,

rgames

[pulse777]

hi,

what all members said is right, and till the next 2 generations in CPU-development it will be [:)]
but sometimes it helpful to stop making permanent changes and "make decisions".

just one more tip:
if you bounce a track, you will change the settings in cubase, vsl-daemon, etc.. so you cant (sometimes) at all come back, to what you did before...
so - at the point you do a bounce - make a saveversion of the "old" arr. then you can go back at anytime, copy old midi-takes into the new arr to work it out again, etc.

another tip in workflow:
try to use just simple sounds (not the preset-patches) like portamento... on all tracks, so you can open more instances and first play the whole song/score/etc (with a bad sound)... then you can update every tarck with keychanges, cc-controlled vibrato or velocity and make the arr come to life..

greez from germany
markus