I've got this 30min piece of music with 5 tracks, one audio and 4 vsti's, 3 of the tracks have automation on (not complex).
When it renders it is only has 9min long instead of 30 mins. The red markers are in the correct place and when I render I select the 'render between markers' box and the render selected tracks box (I select all the tracks to be rendered.)
I've just rebooted and tried again and I got the 'the rendered file is blank' error message when it finished.
Is this a known issue?
My hunch is that it's tripping up with automation on long edits (as the automation kicks in about 9mins into the piece)
I'm using PC v2.0.1.4 as the latest version is very unstable on my setup and kept on quiting without warning.
Still getting rendering problems
-
- KVRAF
- 2009 posts since 9 Apr, 2003 from Cornwall, UK
-
- KVRist
- 83 posts since 7 Jul, 2004
Learn SX2 ...
I had trouble exporting all my tracks when i was using sx1 it would jus quit on my, but hasen't happened yet with sx2 ...
what program u running?
using PC v2.0.1.4 as the latest version
what that?
cheers!
I had trouble exporting all my tracks when i was using sx1 it would jus quit on my, but hasen't happened yet with sx2 ...
what program u running?
using PC v2.0.1.4 as the latest version
what that?
cheers!
-
- KVRAF
- Topic Starter
- 2009 posts since 9 Apr, 2003 from Cornwall, UK
I think your in the forum. This is the Raw Materials Software forum that supports Trackion.jeffreyjames wrote:Learn SX2 ...
-
- KVRAF
- 12977 posts since 29 Sep, 2003 from Ottawa, Canada
If your automation is at 9:00 and the rendering gets goofed up at 9:00, then it's at least a good guess for a starting point for trouble-shooting.
Even though it's a looong piece of music, I would suggest rendering at 1x speed, with the automation curve and plug-in visible, and see if you can see anything.
Unfortunately, if there are no visual clues, that's a sizeable chunk of your life you'll want back.
Since rendering is sample-accurate, try switching to "minutes and seconds" readout for your timeline, zoom RIGHT in on where the automation starts, and mark down exactly (to the ms) where that first node is. Compare to the render that's becoming blank a third of the way through and see if that zeroes in on the area.
(or, just overlay the rendered clip on top of the one containing automation).
Which plug-in are you using? I don't personally have a list in my head of plug-ins with 'known issues', but at there might be someone who can help, or this thread might become useful to someone using the 'search' function in the future to trouble-shoot.
---------
Another possibility is that your CPU or HDD are overloading during render. Even though rendering makes us 'think' that fewer resources are being used because it just goes blank and then spits out a new file, the fact is that all of your tracks are being processed-- this means that anything that gets loaded into RAM for the edit stays there, all tracks will combine for higher CPU and HDD load, etc.. If any of those 3 things (RAM, CPU, HDD) get overloaded during regular editing, 'end-to-end' is disabled and playback stops. I wonder if something at least 'similar' is happening. (actually, I think a RAM overload will simply corrupt any work being done... not sure that Tracktion will be able to cope with RAM overload during render the same way it does during editing, which is to stop loading things into memory).
I would suggest bouncing down some of your tracks first (the one with automation is a good candidate!) to see if that helps.
Greg
Even though it's a looong piece of music, I would suggest rendering at 1x speed, with the automation curve and plug-in visible, and see if you can see anything.
Unfortunately, if there are no visual clues, that's a sizeable chunk of your life you'll want back.
Since rendering is sample-accurate, try switching to "minutes and seconds" readout for your timeline, zoom RIGHT in on where the automation starts, and mark down exactly (to the ms) where that first node is. Compare to the render that's becoming blank a third of the way through and see if that zeroes in on the area.
(or, just overlay the rendered clip on top of the one containing automation).
Which plug-in are you using? I don't personally have a list in my head of plug-ins with 'known issues', but at there might be someone who can help, or this thread might become useful to someone using the 'search' function in the future to trouble-shoot.
---------
Another possibility is that your CPU or HDD are overloading during render. Even though rendering makes us 'think' that fewer resources are being used because it just goes blank and then spits out a new file, the fact is that all of your tracks are being processed-- this means that anything that gets loaded into RAM for the edit stays there, all tracks will combine for higher CPU and HDD load, etc.. If any of those 3 things (RAM, CPU, HDD) get overloaded during regular editing, 'end-to-end' is disabled and playback stops. I wonder if something at least 'similar' is happening. (actually, I think a RAM overload will simply corrupt any work being done... not sure that Tracktion will be able to cope with RAM overload during render the same way it does during editing, which is to stop loading things into memory).
I would suggest bouncing down some of your tracks first (the one with automation is a good candidate!) to see if that helps.
Greg
Last edited by Lunch Money on Sat Oct 01, 2005 6:20 pm, edited 1 time in total.
-
- KVRAF
- Topic Starter
- 2009 posts since 9 Apr, 2003 from Cornwall, UK
cheers lunch, I'll do some more testing tonight and get back with the results.
-
- KVRAF
- 12977 posts since 29 Sep, 2003 from Ottawa, Canada
I'm not sure if this applies to you, but I'm beginning to believe that a certain 'Audio Workstation tweak' is best left ignored.
Some tweak guides I've seen have recommended disabling the page file, because physical RAM is obviously faster than HDD-based "memory".
But I don't see the trade-off as being worth it. I'd rather have that extra cushioning. I take the 'safer' tweak that also gets recommended: setting a stationary page file, which means just setting the minimum and maximum file size as the same number.
--
And in a non-helpful but fun and slightly-related aside:
If you have a dual monitor setup, or just shrink T into a smaller window, try locking one of your automated plug-ins onto the desktop while you render. It's pretty nifty seeing the knobs whizzing all over the place at 30X speed.
Greg
Some tweak guides I've seen have recommended disabling the page file, because physical RAM is obviously faster than HDD-based "memory".
But I don't see the trade-off as being worth it. I'd rather have that extra cushioning. I take the 'safer' tweak that also gets recommended: setting a stationary page file, which means just setting the minimum and maximum file size as the same number.
--
And in a non-helpful but fun and slightly-related aside:
If you have a dual monitor setup, or just shrink T into a smaller window, try locking one of your automated plug-ins onto the desktop while you render. It's pretty nifty seeing the knobs whizzing all over the place at 30X speed.
Greg
-
- KVRAF
- Topic Starter
- 2009 posts since 9 Apr, 2003 from Cornwall, UK
ok, found the problem: Tracktion neglected to tell me there was not enough room on the partition of the hard drive I was exporting to.
Tracktion never indicates when it finds a drive that don't have enough room to save either an edit or wav file (or I guess any other type of file). This can mean you can loose an archive or edit or export and you'd never know
Every app since window 3.1 tells you when the drive is full.
Come on mackie you know this is basic stuff
Tracktion never indicates when it finds a drive that don't have enough room to save either an edit or wav file (or I guess any other type of file). This can mean you can loose an archive or edit or export and you'd never know
Every app since window 3.1 tells you when the drive is full.
Come on mackie you know this is basic stuff
-
- KVRAF
- 12977 posts since 29 Sep, 2003 from Ottawa, Canada
Agreed. Glad you found the problem, though! I'm not entirely convinced that every audio app will have this feature, either, though. An app like Word (even with complex linked hierarchal documents) always knows precisely how large it is.
It would take more work to do it with a render... effectively, it would have to render twice, sort of... the first 'pass' wouldn't actually accumulate rendered data, but would keep a tally of how many bytes will be used by the actual render, and then after that it would render. That's the only way to actually do it accurately.
Conversely, though, surely you can get within the 'ballpark' by knowing the length of the edit, and the destination bit-rate/depth. Then Tracktion could say, "There is not enough space on your hard drive to complete this render" anyhow. The end user doesn't even need to know or care that you MAAAyyyy actually be able to squeak it in. If the drive's that full, it needs pruning anyhow. I'm sure the "ballpark warning" would be more appreciated than no warning at all.
Greg
Glad you found the problem, though! I'm not entirely convinced that every audio app will have this feature, either, though. An app like Word (even with complex linked hierarchal documents) always knows precisely how large it is.It would take more work to do it with a render... effectively, it would have to render twice, sort of... the first 'pass' wouldn't actually accumulate rendered data, but would keep a tally of how many bytes will be used by the actual render, and then after that it would render. That's the only way to actually do it accurately.
Conversely, though, surely you can get within the 'ballpark' by knowing the length of the edit, and the destination bit-rate/depth. Then Tracktion could say, "There is not enough space on your hard drive to complete this render" anyhow. The end user doesn't even need to know or care that you MAAAyyyy actually be able to squeak it in. If the drive's that full, it needs pruning anyhow.
I'm sure the "ballpark warning" would be more appreciated than no warning at all.Greg