I'm trying to figure out different use cases:
- an app loads an audio file (reference to orig file)
---possibility: file moves -> ref. has to be adjusted
- the app is non-destructive, for changes, a copy is produced (where?)
- the session is being duplicated - the new session keeps the refs to
original audio files, (but creates copies, for files which have been
modified ?? or refer.s them too ? refs. them too, I suggest. )
The problem here is, that files could quickly distribute (and
cross-link) over MANY different directories. Maybe a common directory
for all audio-files modified by ANY session-capable application
pros: For all instances, we knew at least their files location.
Different instances could link to the same file (creating a new copy,
only when modifying)
- There has to be a method to quickly find (maybe even auto-search)
files to fix defect links and re-assign paths.
- modified (thus copied) files have to be stored anywhere. (what about
a common directory ?)
-at least for exportation, there should be a method to transform all
references to actual files within (a copy of) the instances project
directory, allowing a package-of-all-related-files valid at a certain
time (state) to easily become created.
- a function called ...
- in the instances project dir, there should be a list of all related
(external) references (as Fons suggsted)
For the SM to be aware of this list and its format, maybe it should
become a fixed part of the API !?
- the SM could provide methods to scan for missing references and
allow (the user) to fix them
Am 26. März 2012 23:40 schrieb Fons Adriaensen :
> An app can always cheat the SM.
But it is not allowed to - educate it to follow the law ;)
> Even if the SM forbids symbolic links in a session directory
It should proscribe that.
> all it takes for an app is saving
> But it would be better if the SM were aware of the existence
> so that it could e.g. show a list of it upon
Linux-audio-dev mailing list