linuxaudio.org

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 :

quoted text
> 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

quoted text
> 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

quoted text
> of such data,

yes

> so that it could e.g. show a list of it upon

quoted text
> 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

Linux-audio-dev@lists.linuxaudio.org

http://lists.linuxaudio.org/listinfo/linux-audio-dev