Go Back   Cockos Incorporated Forums > REAPER Forums > REAPER Q&A, Tips, Tricks and Howto

Reply
 
Thread Tools Display Modes
Old 05-31-2020, 03:22 PM   #1
chip mcdonald
Human being with feelings
 
chip mcdonald's Avatar
 
Join Date: May 2006
Location: NA - North Augusta South Carolina
Posts: 4,294
Default Does splitting tracks create a CPU penalty?

It occurs to me that internally Reaper may create pointers/functions for parts of a split track as if they are discrete tracks, from a resource standpoint?

It seems like some projects seem to end up being CPU hogs despite not having a lot of *tracks*, but maybe a lot of splits? Going through a recent project there is one that has "a lot" of splits, "not a lot" of tracks or effects, but seems to be pegging the CPU?

In other words,

1) are 16 tracks with, say, 4 split items per track an equivalent resource suck or akin to having 128 discrete tracks?

I've been fairly capricious when it comes to doing splits;

2) should I consider this akin to making a new track resource wise? Hard to judge by the performance meter.


3) If this is the case does gluing them back free resources?
__________________
]]] guitar lessons - www.chipmcdonald.com [[[
WEAR A FRAKKING MASK!!!!
chip mcdonald is offline   Reply With Quote
Old 05-31-2020, 04:46 PM   #2
foxAsteria
Human being with feelings
 
foxAsteria's Avatar
 
Join Date: Dec 2009
Location: Oblivion
Posts: 10,254
Default

What's a split track? You mean split media item I guess? I tend to have more item splits in projects than I could begin to count, but I've only noticed a performance hit when splitting MIDI items with the option to truncate MIDI splits turned off in prefs.

OTOH, my brother uses Ableton for sampling records and when he starts making lots of splits, the RAM usage quickly brings his machine to its knees because Live keeps a copy of the entire file in memory for each split.

I doubt Reaper does that too because I've never run into such an issue, but it's easy to test if gluing helps, yea?

Lots of routing is what I notice the biggest hit from in smaller projects. I've also seen projects eat up a lot of resources just because somehow the tracks all ended up with many more channels than they needed.
__________________
foxyyymusic
foxAsteria is offline   Reply With Quote
Old 05-31-2020, 04:58 PM   #3
karbomusic
Human being with feelings
 
karbomusic's Avatar
 
Join Date: May 2009
Posts: 29,260
Default

Quote:
Originally Posted by chip mcdonald View Post
1) are 16 tracks with, say, 4 split items per track an equivalent resource suck or akin to having 128 discrete tracks?
No, it would be 128 discrete item objects in memory, not tracks. The mere existence of the items would only increase memory, not CPU generally - though interacting with them could - however, people use dynamic split for example which creates 100s if not thousands of splits and, number of splits in items hasn't really hit my radar as far as CPU goes unless it was a fairly large number.

So, it would be helpful to see a repro in a project file, without plugins if possible, so we know all the variables at play, who what and how much of. Iteration of and or processing of a lot of items is more likely than their mere existence - but everything has a ceiling hence the need for who/what/where, are there item FX at play etc.
__________________
Music is what feelings sound like.
karbomusic is offline   Reply With Quote
Old 06-05-2020, 09:30 AM   #4
chip mcdonald
Human being with feelings
 
chip mcdonald's Avatar
 
Join Date: May 2006
Location: NA - North Augusta South Carolina
Posts: 4,294
Default

Thanks
__________________
]]] guitar lessons - www.chipmcdonald.com [[[
WEAR A FRAKKING MASK!!!!
chip mcdonald is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 09:37 AM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.