Re: [LAD] Non Session Management
Am 27. März 2012 03:23 schrieb David Robillard d...@drobilla.net: ... What you end up with is a few directories with specific roles. ... ... Figuring this all out was a long process of trial and error, but now that I write it down it seems clear it can't be simplified without failing to meet a requirement. I am all ears for arguments to the contrary, though. Thanks for pointing out, David. 1. I don't totally agree with using symlinks: - I tend to think, that file-systems are not as efficient as databases - I feel that symlinks pollute the file-system - What if any of the symlink to symlink is deleted - do applications still know, where the file is which they had been pointing too ? - Some apps would want to store additional info relating to the file (meta-data, tags, related info, ...), thus requiring a simple database anyway. - having symlinks leaves the user with the question how to reliably copy a directory, without messing up everything (dereference yes/no, follow links yes/no ...), something that is critical to deside 2. I don't totally agree with a file- vs. copy-directory: I mean: is there really a semantic difference between a created, a modified file and a copy ?? I think no. After modification, creation, duplication, etc., soon you won't be able to say, weather a file is a any of the above. I mean: For one app it can be a file (original), while for another it can be a copy / reference / whatever. For an app, there may be a semantic difference for A: existing files a user added, which are ORIGINALS (thus refs), never-modified ones B: files the app created or modified, thus copied - files that are NEWONES (thus real and refs) note: a modified or created file can become an ORIGINAL for a different application ! that's what I meant above, in 2. C: files that are HISTORY, the user may want to delete these anytime, to store space - a history-file can become an original - what now ? My conclusion: - - 1. large files should never go to the session directory 2. Lfiles shared between apps have to be managed by a (super-) instance that knows what's going on - the session-manager - otherwise it's completely undefined/unclear what happens 3. Lfiles newly created (recorded / modified ) - for ALL sessions - go to a common NSM-Lfiles directory 4. The session manager knows, of EVERY reference to files inside the NSM-Lfiles dir., distinguishing between - CURRENT_REFS (files currently used by any instance) - HISTORY_REFS (file not currently used by any instance) (this is equal ALL_FILES minus CURRENT_REFS) - EXTERNAL_REFS (files referenced by any instance, but not contained in the NSM-Lfiles dir. and NOT created/recorded/modified by any instance ) 5. this means, the user is disallowed to manually reference/link to any of the files contained in the NSM-Lfiles dir (because the SM wouldn't know about it) 6. The SM knows all files-in-use and is able to move unused history-files to a dustbin (no app is allowed to use/reference files within the dustbin). The dustbin can manually be deleted by the user anytime. 7. The SM allows Lfiles (CURRENT_REF + EXTERNAL_REFS) for a certain session or app to be copied to a user-defined directory (export-function) 8. The SM allows HISTORY_FILES to be moved to a dustbin folder. (not including CURRENT_REFS or EXTERNALS) IF I did not forget / oversee anything critical, this looks like a well managed and reliable approach to me. Any opinions ? -- E.R. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Non Session Management
On Mon, Mar 26, 2012 at 05:15:09PM -0700, J. Liles wrote: Fons, I'd like to hear more about this use case. Currently one of the strong points of NSM is that applications with heavy state (e.g. large audio files) know *exactly* where to put the state at the time they join the session. This eliminates the need for undesirable hacks with just storing a link to the heavy state (as was generally required with LASH). I felt like this was one of the primary requirements of Non-DAW which was not addressed by other session managers. But as far as sharing heavy state between multiple clients in a session, I have not considered the issue. It is certainly possible to permit something like that, and even as it is right now two clients could work something out peer-to-peer using the NSM server's 'broadcast' capability. If several different sessions need to share the same data, then I would say that it's reasonable just to have it stored outside of the session root, preferrably symlinked from within the session so that it could be picked up by a simple archiving process. You may have misread what I wrote, it's not about data shared between clients in a single session (but that is an interesting twist that I havent' considered so far). It's a about essentially read-only and possibly huge data sets shared between sessions. Given a multitrack recording, I may be required to make a 3rd order Ambisonic mix originally, another for some discrete speaker set used at a concert some months later, and a Wave Field Synthesis one at any time. They all use the same recorded and edited tracks, but the tools and methods used are completely different in each case, and I would really not want to combine them into a single session. If only because someone using any of these forms should not be required to have the tools for all the other ones. Nor would I want the the shared data to be duplicated - not only because it's a wast of disk space, but also because it may be reviewed and modified as well (e.g. correcting bad edits) and such changes should be picked up by all sessions using the data. My POV about 'external' data (that is data not saved as part of a session) is that if the user (or an app on behalf of the user) declares that some data is external to the session then the SM should just accept this as a fact an go on doing its thing. It is then of course the user's responsability to take care of such data if a session is transferred or archived. I would expect a SM to have a tool to 'ls' a session (providing a list of required apps etc.), and ideally such a tool should be able to mention any dependencies on external data. Using symlinks is indeed a simple solution, at least on Unixy systems. It provides the required functionality, archiving tools usually can be told to follow symlinks or not, and to the SM any symlink in a session directory is an indication of 'external' dependencies. And it doesn't require any extensions to the SM protocol - creating a symlink is a declaration of external data. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Non Session Management
Am 27. März 2012 21:41 schrieb Fons Adriaensen f...@linuxaudio.org: ... Nor would I want the the shared data to be duplicated In my scenario, this would match EXTERNAL_REF It would only be copied to Lfiles directory, if modified. Obviously there are cases, where this is not desirable and destructive editing is preferable. The app could offer this as an option, as you are pointing out below. - not only because it's a wast of disk space, but also because it may be reviewed and modified as well (e.g. correcting bad edits) and such changes should be picked up by all sessions using the data. My POV about 'external' data (that is data not saved as part of a session) is that if the user (or an app on behalf of the user) declares that some data is external to the session then the SM should just accept this as a fact an go on doing its thing. It is then of course the user's responsability to take care of such data if a session is transferred or archived. I would expect a SM to have a tool to 'ls' a session (providing a list of required apps etc.), and ideally such a tool should be able to mention any dependencies on external data. Another useful tool: ' list-session-deps Lfile/audio.wav ' that would list all sessions and applications with current-references to that file. -- E.R. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] HDSP 9652 and Behringer ADA8000
Hi Everyone Im would like to experiment using microphone arrays ( 24 channels ) and I am just wondering if it is possible for me to use 3 units of Behringer ADA8000 connected via ADAT to HDSP 9652. My tools run only with ALSA supported devices and I checked through ALSA website, the HDSP 9652 seemed to be OK. Im just wondering if the set-up I mentioned is possible ? Will there be any issue at all if i use the ADA8000 as far as ALSA is concerned ? Thank you very much, I really would appreciate any suggestions or comments. Thank you Phil ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Non Session Management
A second scenario The simple one (simple for the SM, not for the apps): - applications decide themself how to handle large-files - but still tell the SM about all files currently used, when the session is saved This allowed the SM to: - tell the user if a certain file is part of any session registered at the SM - export all files used by a session - optionally, either as symlinks, or as copy to a specified directory - verify and warn, if a referenced file is missing (although, maybe this should be left to the app then too) Would this suffice ? -- E.R. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Non Session Management
On Tue, 2012-03-27 at 14:24 +0200, Emanuel Rumpf wrote: Am 27. März 2012 03:23 schrieb David Robillard d...@drobilla.net: ... What you end up with is a few directories with specific roles. ... ... Figuring this all out was a long process of trial and error, but now that I write it down it seems clear it can't be simplified without failing to meet a requirement. I am all ears for arguments to the contrary, though. Thanks for pointing out, David. 1. I don't totally agree with using symlinks: - I tend to think, that file-systems are not as efficient as databases I am having a hard time imagining anything *less* likely to be adopted than trying to cram a *database* down everyone's throats to save some files! ;) I think I'll just avoid going into the why and say: not in a million years. - What if any of the symlink to symlink is deleted - do applications still know, where the file is which they had been pointing too ? What if a file is deleted? What if the entire file system is wiped? Users can remove files, film at eleven. Nothing to do with symlinks. - Some apps would want to store additional info relating to the file (meta-data, tags, related info, ...), thus requiring a simple database anyway. So? Apps can store whatever they way. If you are crazy and want to store a binary database in there instead of a sane file format, feel free. No session manager that forces everyone to use some database would ever fly. This is obvious. - having symlinks leaves the user with the question how to reliably copy a directory, without messing up everything (dereference yes/no, follow links yes/no ...), something that is critical to deside That is inherent to any solution with links to external resources. Links to external resources are a requirement. If you want to move a session, use a smart tool that can fix the links, or archive it. 2. I don't totally agree with a file- vs. copy-directory: I mean: is there really a semantic difference between a created, a modified file and a copy ?? The argument for these having to be separate is because otherwise the copies would pollute the namespace. Also remember files can be created before save time. For an app, there may be a semantic difference for A: existing files a user added, which are ORIGINALS (thus refs), never-modified ones B: files the app created or modified, thus copied - files that are NEWONES (thus real and refs) note: a modified or created file can become an ORIGINAL for a different application ! A file outside the session is a file outside the session. Happening to be in a directory that happens to be a different session makes no difference. that's what I meant above, in 2. C: files that are HISTORY, the user may want to delete these anytime, to store space - a history-file can become an original - what now ? You keep bringing up this what if the user deletes a file that is used problem as if there could possibly be a solution. Obviously there can not be. Yep, users can delete files. That is not a criticism of any particular solution. In reality this is not a problem. Users have a pretty good idea that if they go screwing around with e.g. their ardour session and start deleting files, something is probably going to break. Don't Do That. 1. large files should never go to the session directory Why? What exactly is large? Just because a file is large doesn't mean I don't want it in a session. It is a requirement to be able to roll up a self-contained archive of a session *if* you want to. 2. Lfiles shared between apps have to be managed by a (super-) instance that knows what's going on - the session-manager - otherwise it's completely undefined/unclear what happens Why? It's perfectly clear. A file is a file. 3. Lfiles newly created (recorded / modified ) - for ALL sessions - go to a common NSM-Lfiles directory Doesn't really matter. You can use one. You can use many. Whatever. 4. The session manager knows, of EVERY reference to files inside the NSM-Lfiles dir., distinguishing between - CURRENT_REFS (files currently used by any instance) - HISTORY_REFS (file not currently used by any instance) (this is equal ALL_FILES minus CURRENT_REFS) - EXTERNAL_REFS (files referenced by any instance, but not contained in the NSM-Lfiles dir. and NOT created/recorded/modified by any instance ) 5. this means, the user is disallowed to manually reference/link to any of the files contained in the NSM-Lfiles dir (because the SM wouldn't know about it) And why does the Grand Centralized Session Manager File Authority need to do this? What exactly is the problem that all these rules and authority solve? 6. The SM knows all files-in-use and is able to move unused history-files to a dustbin (no app is allowed to use/reference files within the dustbin). The dustbin can manually be deleted by the user anytime. The only thing you need to be able to clean up
Re: [LAD] Non Session Management
On Wed, 2012-03-28 at 03:27 +0200, Emanuel Rumpf wrote: A second scenario The simple one (simple for the SM, not for the apps): - applications decide themself how to handle large-files - but still tell the SM about all files currently used, when the session is saved Files are files. Size does not have any impact on how any of this has to work (aside from the fact that files could possibly be very large meaning redundant copies are not acceptable). Trying to define a small file and large file category just makes everything more complicated for no particular reason. This allowed the SM to: - tell the user if a certain file is part of any session registered at the SM Why would the user care? The chose it, presumably they know where it is anyway. -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
