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
instead ?
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)
Either way:
- 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 ...
create_file_export_for_current_state__copy_refs_to_real_files
- 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 <fons(a)linuxaudio.org>rg>:
On Mon, Mar 26, 2012 at 10:32:38PM +0200, Emanuel
Rumpf wrote:
- where would audio apps store large (audio)
files ? a custom path ?
That is something that needs to be looked at.
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
a directory path as part of the current configuration.
right a path - a reference
but what about modified/copied files? (see above)
But it would be better if the SM were aware of the
existence
of such data,
yes
so that it could e.g. show a list of it upon
request.
This would then require apps to explicitly declare
paths to external data. It would probably be a rather simple
extension to NSM.
And a very useful one, improving integrity.
--
E.R.