Hi @all 
is it possible to remove unused files from a project? (like in the pool in Cubase)
And a second question:
I import an audio file in VST Live with the name xyz.mp3 (as example). After import I´ve noticed that i forgot something to print in the file. → I delete the file in the song (no files in “Song Media Files” visible). Then I go back to Cubase, do the edits and bouce it again (same name). When I import it in VST Live the software use the “old” file.
Any ideas?
VSTL copies the files to the Project folder when you import. I’m guessing you are replacing the file in its original location. When you update the file do not import, just copy to the project folder and overwrite the original.
Maybe “Save Archive” will do the trick. It only copies files used in the project. Then you can remove the older files. Is that what you want?
That’s an option if you don’t have to do it several times a day. 
Is the other problem with the same filename a “caching” problem?
Sees like the problem is not as expected.
Here a detailed description. I hope you can help @musicullum
Any ideas what i do wrong? Or what i can test?
Not sure what you want. Cubase works differently.
A media clip in VST Live will show “Media Offline” when a file cannot be found. the Song/Song Media Files list is just a display list information of which files are used in the project. If you want to get rid of some, you will need to remove clips referencing those, but maybe you mean something else?
If you mean to clean up files in folders like “MIDI”, that we cannot do. VST Live never deletes media files. Deleting files means they may then be missing in other projects referencing those, .vlprj files could be anywhere on the planet. Just perform “Save Archive” now and then (especially, if you imported or removed a lot of clips/files) and continue to work in the archive folder. If all goes well, delete the old one.
pic is too small to see clip info, maybe there is an offset indeed?
Check Song/Song media files to see where VST Live found the file.
Zoom is max 
Here you can see the difference to the playhead. When i switch to “time” instead of “bars” it´s round about 20ms.
Live found the file in the audio folder in the project folder.
@musicullum I’ve just been through the problem on a remote session with @kraimor and it appears that MP3 import is the issue. If we bring in a WAV file it is fine. Also looked at the MP3 in spectral layers and the timing is fine there.
Together with Clive we did a screensharing session and have figured out the problem.
I always used *.mp3 format to export from Cubase.
Clive mentioned i should test wave files.
In the following screenshot you see the behaviour of VST LIVE when importing a mp3 file and a wave file. The mp3 file (see channel name) contains the offset.
The wave file is right where it should be
I´ve opened the mp3 file in Spectral Layers → no offset.
Therefore we think the offset is introduced in the conversion/import process in VST Live.
Hope this helps
I cannot stay silent anymore!
Dude, if you seriously make music, you use MP3 format only for sharing finished product to friends. MP3 can be also used as demo for your customers. MP3 always damages the source. ALWAYS! You can try 192 kbps as well as 256 kbps, but it always will be changed a little.
From Cubase or other DAW export only WAV for use in another projects especially if the alignement is very important.
P.S. I record hour to two hours of audio of interviews in mp3 format (192 kbps), then I align it to video in Vegas and always I should stretch mp3 clip to match with end position of video. WAV file would be some gigabytes.
MP3 files have a small gap at their start.
I’ve run into issues with people I collaborate with using them. Always use a WAV or AIFF or something similar in a project to avoid the issue.
mp3 works in contrast to wav with frames. As a result of that, there is a gap at the beginning and/or end of the song. So what you see is system-inherent of the file format. If this is important for you, and that will be for every musician, you should always use wav.
Yes it does, thanks. We’ll have a look.
Should work w/o initial gap with the next version.
