One of my track has very long stem loading times

[deepndark]

It may take over 5 minutes before all the stems load. I have another tunes that have as many stems but are loading normally.
My PC is Intel i7 3,4 hgz with 16Gb memory so it's not like why it does that. It's just a case of that tune.

[Kenni]

Are the stems bigger/longer than the other project you're talking about? Also, does it use combinator/nnxt patches with a lot of samples in them? In my experience I get long loading times when I use the big 24-bit patches from Reason Pianos in projects that have a lot of (big) stems in them.

And finally, SSD hard drives do reduce loading times, if the stems and patches are located on them that is.

[jengstrom]

Do you mean A. stems loading as in the graphics/audio goes from blank/silent to audio waveform in audio clips in Reason?

Or B. stems loading as in the calc indicator activity not being finished yet?

Or C. as Kenni suggests, sample load time in sampler devices?

If it's the first one, it's a bit strange, since that is bottlenecked only by disk reads AFAIK, so that should always reflect the read-speed of the .record-file and the corresponding generated files in the scratch disk folder.

If it's the second one, it could be expected in some cases -- if the recordings inside your audio clips could be long, and/or stretched by a large factor (especially if there are long recordings inside) and/or contain recordings which have a different sample rate than the audio interface in Preferences.

In the second case, you can bounce the clips and clean out the excess unused recording material to resolve the issue.

[deepndark]

Hi, the option A. and B. The waveforms still slowly appear and the Calc is also not finished.

Edit: and no, the track has no lots of NNXTs or other samplers.

[selig]

Maybe that one tune has audio at a higher sample rate, or is using time stretching (or both)?

[deepndark]

Maybe that one tune has audio at a higher sample rate, or is using time stretching (or both)?

Yes, I have speeded it up with timestretching, ok, makes sense that this is the reason for slow loading times.

[jengstrom]

When I wrote "reflect the read-speed of the .record-file and the corresponding generated files in the scratch disk folder" -- I meant this boils down to the file sizes of the stretched files and original .record-file, the disk hardware for those folders, and how much that/those disks are used by other things at the same time, and the condition of the file system (fragmentation level and to some degree the amount/age/complexity of the folder trees of files).

Regarding stretched clips, Reason will try to avoid recalculating them when you open a song, by searching for the calced results from last time in the Scratch Disk Folder. If you need to calculate again, that means files have been thrown out of the Scratch Disk Folder since last time, because the total contents exceeded Reason's soft size limit for the Scratch Disk Folder (currently 30 Gbytes).

[deepndark]

When I wrote "reflect the read-speed of the .record-file and the corresponding generated files in the scratch disk folder" -- I meant this boils down to the file sizes of the stretched files and original .record-file, the disk hardware for those folders, and how much that/those disks are used by other things at the same time, and the condition of the file system (fragmentation level and to some degree the amount/age/complexity of the folder trees of files).

Regarding stretched clips, Reason will try to avoid recalculating them when you open a song, by searching for the calced results from last time in the Scratch Disk Folder. If you need to calculate again, that means files have been thrown out of the Scratch Disk Folder since last time, because the total contents exceeded Reason's soft size limit for the Scratch Disk Folder (currently 30 Gbytes).

Ah ok, thank you for the clarification. I don't know, maybe my CCleaner has deleted these files from my harddrive? I just opened this song and it loaded the files quickly.