Bugged by an audio bug

[kL]

Has anyone experienced this?
I'm trying to ease into using Tracktion on the kind of predominantly audio tracks with lots of editing I usually do with Vegas (because of its stability) and am continually running into a vexing problem:
When a project gets to a point where there are lots of edits and a fair amount of tracks (but nowhere near too many for my hardware) audio will cut out of certain tracks for no reason, and always at the same place. The tracks when soloed are fine, but things just disappear when the whole mix is playing. It's as if Tracktion can only handle so many edits before it starts losing track (no pun intended) of where the clips come from.
The project renders fine, but it's embarrassing to tell someone, "This will render fine... you just can't hear it without odd dropouts now... while you're trying to mix it..."

[ModuLR]

Are you getting the "!" near the cpu meter? That could indicate that your hd might not be up to par for streaming a volume of audio from disk.

[kL]

CPU barely registering; I've got a 10k SCSI drive that can do projects three times as big in Vegas. It has to do with the amount of edits, not track count or CPU usage.

[Lunch Money]

Edits, in Tracktionese, refers to different 'arrangements' of the song, which is not what you're referring to I'm sure. Do you mean the number of cuts and cross-fades and so forth in your audio material?

Also, are your Vegas projects at the same bit rate and depth?

[kL]

I mean cuts, crossfades, moves of blocks of clips: what you do to alter the arrangement of a song in progress.
Yes, the Vegas projects are all 44.1/24 as well.

[kL]

I guess I have to go to Mackie with this one. I tried deleting the folder and reopening the project from an archive (a process that itself has bugs: it has to be done twice...) and the track has the same problems, in exactly the same places.
No one else who does extensive block moves with lots of audio has has had similar problems?

[valley]

I guess I have to go to Mackie with this one. I tried deleting the folder and reopening the project from an archive (a process that itself has bugs: it has to be done twice...)

Are you sure? I've never had that. What steps do you use? There are a couple of ways to import projects, it may be that you've happened to hit on one with a bug.

and the track has the same problems, in exactly the same places.
No one else who does extensive block moves with lots of audio has has had similar problems?

The only time I've had drop out problems is what the "!" disk throughput warning is showing. A couple of times that has seemed to be earlier than I might have expected, but it is infrequent, and certainly not replicable in the way you are describing.

Is there anything specific about the cutout points? Clips with localised filters starting at that point, or an automation change, or some such?

[kL]

No localised filters or automation, nothing notable except that it's the location of a big block move and the dropouts always happen in the spot and to the same tracks. It isn't a disk issue: no "!": there are only about 10 tracks of audio and my system can do upwards of 50. (In fact, I've never run out of tracks.) I've found that by freezing the two tracks that drop out the problem disappears (but not by freezing others...)
As far as the archive import, I do the following steps: open new project in a new directory. Import archive from the project window. Nothing shows up in the new project, though the edit from the archived project -- just the edit -- shows up in the previous project (the one defaulted to when the program loaded). Do it again: everything shows up.
Another odd anomaly you can perhaps help me with:
I split all tracks at both the mark in and mark out point and do a "select all clips within the marked region" and some -- not all -- of the newly split clips have the remainders (the areas beyond the split and outside of the marked region) selected as well. This happens everytime and is easily recreated.
Thanks.

[chico.co.uk]

Do the dropouts occur if you start playback slightly before the dropout area of the song, or only if you play the song right from the start? And what's "a big block move", I'm not sure i understand what's happening there? Does the audio pass through any vstis or effects?

[valley]

No localised filters or automation, nothing notable except that it's the location of a big block move and the dropouts always happen in the spot and to the same tracks. It isn't a disk issue: no "!": there are only about 10 tracks of audio and my system can do upwards of 50. (In fact, I've never run out of tracks.) I've found that by freezing the two tracks that drop out the problem disappears (but not by freezing others...)

That's strange! You're using a PC right?

I'll try and recreate that.

As far as the archive import, I do the following steps: open new project in a new directory. Import archive from the project window. Nothing shows up in the new project, though the edit from the archived project -- just the edit -- shows up in the previous project (the one defaulted to when the program loaded). Do it again: everything shows up.

I'll test those steps. That's not the way I normally import, so you may have found a bug.

Another odd anomaly you can perhaps help me with:
I split all tracks at both the mark in and mark out point and do a "select all clips within the marked region" and some -- not all -- of the newly split clips have the remainders (the areas beyond the split and outside of the marked region) selected as well. This happens everytime and is easily recreated.

That definitely sounds like a bug. I seldom have cause to split a number of tracks simultaneously, so I wouldn't have noticed it.

I'll check these later and pass them up the line since Beno isn't around.

[kL]

Thanks.