[LAD] (no subject)
a href=http://enacte.cl/components/02efpk.html; http://enacte.cl/components/02efpk.html/a___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] NSM - handling large files
On 03/30/2012 12:27 PM, Paul Davis wrote: re: the central media location - in rui's defense i'd like to point out that it took cubase more than 10 years to move away from something fairly close to his model. Ok, that will be 5 yrs for Rui then ;) Serious though. What does this mean for Qtractor and NSM in theory? Qtractor can't apply to the strict session saving rules of NSM atm and not in the near future? If so, is there a solution for this from the perspective of Qtractor and NSM? Are there other applications with this same 'problem'? Best regards, \r ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] NSM - handling large files
On Mon, Apr 2, 2012 at 9:11 AM, rosea.grammostola rosea.grammost...@gmail.com wrote: On 03/30/2012 12:27 PM, Paul Davis wrote: re: the central media location - in rui's defense i'd like to point out that it took cubase more than 10 years to move away from something fairly close to his model. Ok, that will be 5 yrs for Rui then ;) Serious though. What does this mean for Qtractor and NSM in theory? It wouldn't be a problem if qtractor either kept all new media in its per-application area of the session directory when running under NSM or at least symlinked to the external files. There is precedent for applications using completely different project formats when under SM (for example, Yoshimi's .state files [although that functionality appears to be broken in the stable release of yoshimi]). A session is something that applications /participate/ in, and participation means having to do some things differently in order to cooperate with the session manager for the user's benefit, so IMHO none of this is asking too much. And, anyway, it's not /really/ a problem in practice until you want to trasnport a session, and in that case you'd just have to follow whatever qtractor's procedure is for doing that. It's an interesting point and one that I'll need to state explicitly in the next version of the API. Qtractor can't apply to the strict session saving rules of NSM atm and not in the near future? If so, is there a solution for this from the perspective of Qtractor and NSM? Are there other applications with this same 'problem'? There are probably a few. I think Freewheeling also tries to store all recorded loops in a central place in the users home directory. It's a pretty unusual thing to do though and the truth is that the vast majority of applications don't have heavy state and keep all project information in memory and save/restore it from a single file. Anyway, from my perspective, correcting the problem is as simple as adding a rule to the NSM API that states: * When connected to a session, the client *MUST* store all new media (recorded audio, etc.) related to the open project in the project path provided by the `open` message. I can't imagine why Rui or anyone else would have a problem with this, as it is exactly equivalent to the user saying Please store my precious data somewhere predictable that I have predefined instead of in whatever random place the application developer thought would be good. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] NSM - handling large files
Am 2. April 2012 19:17 schrieb J. Liles malnour...@gmail.com: Anyway, from my perspective, correcting the problem is as simple as adding a rule to the NSM API that states: * When connected to a session, the client *MUST* store all new media (recorded audio, etc.) related to the open project in the project path provided by the `open` message. I thought - that's what we would not want: store large files in the session dir !? because duplicating a session should stay a light and fast process. That is, why I had been proposing an nsm-large-files directory (outside of the session-folder), for those, but actually, it doesn't matter, _where_ NSM-clients store their large-files, as long as they create symlinks for them in the session folder. (maybe the sub-directory for symlinks should be defined as part of the API. proposition: external-file-links). -- -- -- -- Remember my definitions: What is a large-file ? - every (larger) file, that is not required to immediately be copied if, a session is cloned. - every file, where a reference is enough in the first place What is NO-large-file ? - data that is required to access large-files (references, symlinks) - that is lightweight (~ below 1MB) (some config-values) - has to be read by the SM to initialize the client -- -- -- -- I can't imagine why Rui or anyone else would have a problem with this, as it is exactly equivalent to the user saying Please store my precious data somewhere predictable that I have predefined instead of in whatever random place the application developer thought would be good. My exact intention. Regards, Emanuel -- E.R. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] NSM - handling large files
nb. all this applies whether the external files symlinking are implemented or not (will that be an option or shall be mandatory by SM protocol design?); Do all target filesystems support symbolic links? ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] NSM - handling large files
Am 2. April 2012 20:39 schrieb Paul Giblock pgib...@gmail.com: Do all target filesystems support symbolic links? yeah ? what would happen to the links, if one copied the session folder to his/her fat32 usb-stick ? simply don't !! ? or de-reference... -- E.R. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] NSM - handling large files
On Mon, Apr 2, 2012 at 12:07 PM, Paul Giblock pgib...@gmail.com wrote: I didn't necessarily mean for transport or archival. I imagine just dereference it is one of the motivations for links in the first place. I was more concerned about windows users, or people with large external (fat32) drives who wish to use this filesystem for their live session storage. I just checked and NTFS at least supports symlinks. Anyone attempting to store their production audio sessions on a fat32 filesystem is certifiably insane anyway... ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] NSM - handling large files
On Mon, Apr 2, 2012 at 11:29 AM, Emanuel Rumpf xb...@web.de wrote: I thought - that's what we would not want: store large files in the session dir !? because duplicating a session should stay a light and fast process. Personally, I'm fine with having large files in my session directories. In fact, that's exactly where I want them. Why would one one to duplicate a session with a lot of pre-recorded audio? And, anyway, this could be made to work by just storing that common audio wherever you want and making 'external' references to it in the session (and hopefully the application involved uses the symlink technique we've discussed for referring to external files)--all without the SM having to know anything about it. That is, why I had been proposing an nsm-large-files directory (outside of the session-folder), for those, but actually, it doesn't matter, _where_ NSM-clients store their large-files, as long as they create symlinks for them in the session folder. Right. As long as there are symlinks it's fine, except that I think it should be the user deciding where things are stored rather than individual applications. Remember, you can always write a simple shell script that moves WAVE files etc. into a central location outside of the session directories and replaces them with symlinks. Again, this would be the user deciding what to do and the SM or the application doesn't have to know anything about it. I think this is very much a corner case anyway. Normally, one wants all the project data and media to be stored on the same filesystem, as close together as possible, and doesn't care about being able to duplicate a session with gigabytes of audio data (because... why are you doing that anyway and why are you doing it so frequently that just creating the symlinks yourself is too much trouble). Unless the use case is very compelling, it's hard to justify adding any complexity or requirements to either the SM or the client applications. Remember, this is Unix--we don't have to stuff all the functionality into one tool. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] NSM - handling large files
On Mon, Apr 2, 2012 at 3:11 PM, J. Liles malnour...@gmail.com wrote: On Mon, Apr 2, 2012 at 12:07 PM, Paul Giblock pgib...@gmail.com wrote: I didn't necessarily mean for transport or archival. I imagine just dereference it is one of the motivations for links in the first place. I was more concerned about windows users, or people with large external (fat32) drives who wish to use this filesystem for their live session storage. I just checked and NTFS at least supports symlinks. Anyone attempting to store their production audio sessions on a fat32 filesystem is certifiably insane anyway... Can't agree with that. USB Thumb Drives for instance are still one of the most common ways to transport sessions and other data and are often formatted FAT32 for interoperability purposes. Seablade ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] NSM - handling large files
Can't agree with that. USB Thumb Drives for instance are still one of the most common ways to transport sessions and other data and are often formatted FAT32 for interoperability purposes. Seablade Luckily tar files do support symlinks. Some folks even create a ext2 fs formatted loopback file on the fat32 partition. Of course it's a problem if you try to extract that tar file onto a fat32. Cheers, Tim ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] NSM - handling large files
Am 2. April 2012 21:22 schrieb J. Liles malnour...@gmail.com: Personally, I'm fine with having large files in my session directories. In fact, that's exactly where I want them. Why would one want to duplicate a session with a lot of pre-recorded audio? Maybe with recorded audio, you wouldn't - although maybe you would (see below). If you work with samples, OTHO, why would you want the (same!) samples to be stored in the sessions folder and even in duplications ? To waste some space ? And, anyway, this could be made to work by just storing that common audio wherever you want and making 'external' references to it in the session That was our conclusion for using symlinks. The clients would be advised, to create them in ../nsm-session/external-file-links/ (and hopefully the application involved uses the symlink technique we've discussed for referring to external files)--all without the SM having to know anything about it. right ..., except that I think it should be the user deciding where things are stored rather than individual applications. Most applications allow that anyway, and if not - it would not hurt much to change this. Remember, you can always write a simple shell script We can always create shell scripts for anything, but aren't we talking about some kind of management !? NSM has some nice rules already, to make things behave smooth. Now add a few sensible rules, to make sure that audio-file management works equally well. These are really very simple points, I say. example: - clients MUST create symlinks for all external files used - in the directory ../session/external-file-links/ - clients are ADVISED to store large-files in /nsm/large-files/ (and create symlinks for them as in previous point) I think this is very much a corner case anyway. I think no, but very much depends on personal work-flow. I use to do different Versions of _the same_ project, with some minor or major differences. So my workflow would be: - create a session - if happy with a state, duplicate - continue work with the duplicate. since many/most files stay the same, there is no reason to copy the files over different session directories. -- E.R. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] NSM - handling large files
A new thought: Lets say we did store the session as tar.gz, and we de-referenced the symlinks. Means: We have all files related to the session th the tar.gz. So far, so good. Now we re-import the session to NSM: We extract that tar.gz in the NSM sessions-folder. Note: instead of symlinks we have now real files in the symlinks directory (because we de-referenced before creating the tar.gz). Real files should not go to the symlinks directory. But we could have a simple script, to move these files to the nsm-large-files/ folder and re-create the symlinks. Now we should have a state very similar to where we began. (exception: we did not restore the file-paths we've had originally, but symlinked to the nsm-large-files folder instead) I think this is acceptable - the session stayed valid at least. -- 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
Apart from the Qtractor scenario (which seems not to be an impossible hurdle to take), there is one question left for me and that is: *Is it needed to remove JackSession support, in order to add NSM support?* I don't expect this to be true, but afaik JackSession is disabled in the NSM Yoshimi patch. I suspect that distro maintainers wants all available session options to be enabled for their users. Other question might be if NSM is able to run crossplatform, but I believe the answer is YES (correct me if I'm wrong). Then of course you have the issue whether devs wants to apply to the strict NSM rules, but apart from issues reported by Rui, I didn't hear any arguments against it from developers yet. Regards, \r ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
