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 <[email protected]>: > 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. _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
