cachemanager files?

[gak]

Why on earth would I have a file under my E drive that has a crap load of stuff that says "cachemanager" as the file name?

It's in the folder I keep all my projects/presets/etc.

?

[platzangst]

Reason makes a lot of temporary files as you work, particularly if you do things like stretching or shifting audio clips. The idea is that with those files for reference, Reason doesn't have to do a lot of re-calculating of those kind of things each time you open the project file - it just references the appropriate cache file. You can delete those files with no problem, but you may experience delays when opening up some complex projects if you do.

You can also set Reason to place those files in a folder of your choosing.

[Theo.M]

Thanks for that explanation platzangst.

I was also wondering bout this on my windows lappy - i am sure the mac must do it too but i never noticed it.

[gak]

Thanks platzangst.

[Vince-Noir-99]

Is it normal that I get around 20GB of .cachemanger files after a couple of hours of work on a session? In this session I have one ~3min stereo audio track with some slicing and pitch adjustments. The audio track is not being tweaked, however after some mixing and MIDI editing I find the cache folder at around 20GB each time. I deleted it and after the next session it repopulates.

It's not really an issue for me right now, but going over 20GB for a single song is not going to be nice with my storage standards... This is way too much. Do you reckon if I render the offending audio track (assuming that's the reason) I'll be able to contain such huge cache creation?

Cheers

[platzangst]

Is it normal that I get around 20GB of .cachemanger files after a couple of hours of work on a session? In this session I have one ~3min stereo audio track with some slicing and pitch adjustments. The audio track is not being tweaked, however after some mixing and MIDI editing I find the cache folder at around 20GB each time. I deleted it and after the next session it repopulates.

It's not really an issue for me right now, but going over 20GB for a single song is not going to be nice with my storage standards... This is way too much. Do you reckon if I render the offending audio track (assuming that's the reason) I'll be able to contain such huge cache creation?

Cheers

Well, look, anytime you mess around with an audio clip you're going to get potential cache inflation. You're pitch shifting, and if you're making slices so as to, say, quantize a live performance, you'll also be doing some time-shifting. So let's suppose that a Reason project file not only has to keep track of all the changes you made, but also keeps the original audio clip in for reference. If you pull 3 minutes of 44.1 kHz/16 bit audio off a CD, that's going to run approximately 30 MB. If you use audio quality higher than that, you're going to be dealing with progressively higher files just to start with, and then there's whatever audio editing you do inside Reason.

I can't say for certain how Reason handles it, but I think it's safe to say the more complex and detailed your alterations of the original clip are, the more likely you are to get larger files as Reason stores more and more pitch/time calculations. Every time you open that project, it will recalculate those alterations if it doesn't have a .cachemanager file handy, regardless of whether you make any newer alterations.

I have no idea what conditions exist to get you to 20 GB for one song, but I wouldn't consider it impossible or even unlikely, depending on the factors I've outlined above. I also don't know for sure if simply rendering the track will reduce that - you might have to actually delete the original, non-rendered track out of your project to stop it from recalculating it, and I shouldn't have to repeat the standard warnings about destructive editing and backups and the like. If I were you, I'd carefully back my project up before experimenting to see if that works.

[jengstrom]

Those files are supposed to be scratch disk folder contents. If Reason puts such files anywhere except the scratch disk folder, that would be unexpected and should be reported.

What platzangst describes is not really how Reason works. Reason always keeps only the original audio first recorded or bounced and can never change audio data - it makes new recordings instead.

It works like this:

1. Every time you change the way the original is edited, Reason immediately prepares to preview the sound in real time, and asks for high quality offline rendered version.

2.A. If the same edited state of the same audio is in the scratch disk -> proceeds to step 3.B.
2.B. Not in scratch disk -> play preview and start calculating high quality offline rendered audio in the background

3.A. If you make another edit before the high quality version is ready, goes back to step 1.
3.B. When the offline rendered version is ready, keep it in the scratch disk, and replace the preview in what's heard (crossfaded in).

Then, when you make another edit, it starts again from step 1., always working on the original audio data in the clip, i.e. never re-processing a processed audio unless you ask for it (by bouncing to new recording).

The scratch disk doesn't continue to grow forever. Each time before Reason creates a new file there, it first trims the total size of the scratch disk down to a maximum of 30 Gbytes plus anything needed for the currently open songs.

There are no important files in the scratch disk, since Reason can re-create all files there from the originals in the song document files, but it can take time.

[Vince-Noir-99]

Thanks for the insights, Platzangst and Jengstrom!

So I proceeded with the following test:

1) Opened the session and rendered the sliced & pitched audio track
2) Disabled stretch for the new track
3) Deleted the original edited track
4) Saved as a new Reason project
5) Quit Reason
6) Emptied cache (at this point filled up again as usual several GBs)
7) Emptied trash (ocd behaviour )
8) Launched the new Reason session with the rendered & unstretched audio
9) Checked the cache folder: it populated before my eyes as the session loaded up to a mere 2.4MB

So I guess the moral of the story is to be careful with pitch and stretch, kids!
And once happy with a massive edit, print as a new track.
Again, it's not the way of handling data surprising, but rather the huge amount of space it may take for a single track.
Hopefully this is helpful for anyone dealing with some sudden mysterious reduction of disk space