Clip Version management in the Pool

[tune.m.smith]

@Lukas posted a video about using clip versions.

I am trying to understand the hierarchy of events, clips and audio parts to keep file bloat and sessions organized as well as possible.

The hierarchy seems to flow in that order, but what gets tricky is managing the clip versions in the pool.

In the case of making multiple edits to an event (using 'strip silence' for example): that clip then becomes any number of individual events. If 'merge to audio part' is used on those events and then the audio part is duplicated, the duplicated events share the same clip version. If you 'separate shared copies' on any of those duplicated audio parts, it creates multiple clip versions based on where the silence was. This causes the clip versions to get out of control in the pool.​

This is especially problematic if some of the audio parts are deleted from the arranger. The numerous clip versions from those deleted audio parts still remain in the pool. The "remove unused files" doesn't take care of the unused clip versions.

What is a good way to manage the clip versions that were created but no longer used in the arranger? Bouncing the resulting strip silence audio event doesn't achieve the clean workflow of reducing file size bloat that I'm aiming for.

 

[SwitchBack]

AFAIK Studio One's file management is on a 'parent file plus edits' basis: It keeps a record of all edits made to the initial audio file AND it keeps that initial audio file. Progressive results of particular edits are saved in audio files to cache, but these versions are expendable because initial file plus record of edits can reproduce them. Until you bounce or create a clip version, which creates a new initial audio file. Which must be kept to be able to recreate further editing steps.

So I think you have to be sparse with clip versions to keep file load under control. Or you have to manage them yourself. And the cache directory can be deleted at all times (after closing the song that is).