Re: [LAD] NSM - handling large files
From my user perspective - I use samples extensively, however I care very little about exporting projects. I do care about preserving them, but I have a special folder called Sessions where I save projects from all audio apps. Add my sample library to that and I can preserve everything. -- Louigi Verona http://www.louigiverona.ru/ ___ 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 03:48 AM, J. Liles wrote: The point of those guidelines is to allow users to know*exactly* what behavior they can expect. The chief difficulty I had with implementing LASH support in programs was that there was no answer as to what 'Save', 'Open', 'New', etc. should do when running under LASH. Left, as is, the effect of these operations would vary depending on how individual applications store their state (whether fully in RAM, in a fixed location on disk, etc.). This scenario is an absolute nightmare for both implementers and users. If following a few simple rules to disable certain menu options is enough to remove this ambiguity entirely, then why is that so hard for you to accept? Do you*want* to make things ambiguous and impossible to predict? I know I don't. The rules are not there to be draconian and imposing--They are there to allow people to have confidence in what running under session management means regarding where their data is stored. Makes me wonder about JackSession. Does it have the same problem here compared to LASH? \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
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. ___ 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 28.03.2012 um 14:24 schrieb Emanuel Rumpf xb...@web.de: Am 28. März 2012 05:46 schrieb David Robillard d...@drobilla.net: On Wed, 2012-03-28 at 03:27 +0200, Emanuel Rumpf wrote: 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? (Lets assume I haven't use a certain machine for half a year...) For many reasons: - deleting - I would like to know, if I'm allowed to delete a certain file, thus it's important to know if it is still used by any session - destruction - I'm planning to use a destructive application an a file and would like to know, if this file is used by any session, where this modification would cause trouble - duplication and release - one may intend to export all files (maybe of a certain type) for a certain session and send them to a friend. ... who could be a repository providing version control. Regards, - Burkhard - freeing disk space - I would like to remove all files not used (anymore) by any session (or by a _certain_ session). how else would I know ? -- E.R. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev ___ 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 30. März 2012 03:29 schrieb J. Liles malnour...@gmail.com: If all Linux Audio software dealt with external references in this way, archiving/export would be much less problematic. Finding a solution for externals, was the whole point of this discussion. After all the many arguments, I'm now feeling too, that symlinks are the right thing for NSM. Thank you everyone, for participating. Furthermore, in addition to the plain old symlinks, a truly robust solution might also store e.g. SHA1 hashes of external files, so that any mismatch is detectable. Interesting point. -- 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 Fri, 2012-03-30 at 16:47 +0200, Burkhard Wölfel wrote: On Wed, 2012-03-28 at 03:27 +0200, Emanuel Rumpf wrote: [...] - deleting - I would like to know, if I'm allowed to delete a certain file, thus it's important to know if it is still used by any session - destruction - I'm planning to use a destructive application an a file and would like to know, if this file is used by any session, where this modification would cause trouble - duplication and release - one may intend to export all files (maybe of a certain type) for a certain session and send them to a friend. ... who could be a repository providing version control. Good point. Better to achieve this kind of thing by simply dropping your (transparent file-based) session(s) in an RCS, which will do all of this a billion times better than any LAD session manager ever would. That said, I still think apps should be able to save non-destructively. Use git is a nice trick for geeks, not something that should ever be a strict dependency. -dr ___ 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 Fri, Mar 30, 2012 at 05:31:57PM +0200, Emanuel Rumpf wrote: Am 30. März 2012 03:29 schrieb J. Liles malnour...@gmail.com: If all Linux Audio software dealt with external references in this way, archiving/export would be much less problematic. Finding a solution for externals, was the whole point of this discussion. After all the many arguments, I'm now feeling too, that symlinks are the right thing for NSM. Thank you everyone, for participating. Furthermore, in addition to the plain old symlinks, a truly robust solution might also store e.g. SHA1 hashes of external files, so that any mismatch is detectable. Interesting point. Would there be anything against using hard links? Isn't it nice that you can delete the original files, knowing that that are save when used in a session. Portability would be a problem of course, and deleting files might become more difficult then you would like. But if you would be able to control this with the session manager, it might be a desirable feature. lieven ___ 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 Fri, Mar 30, 2012 at 09:07:07PM +0200, Lieven Moors wrote: Would there be anything against using hard links? A hard link makes the file pointed to part of the session directory, just as moving or copying the file would. There is no difference between a hard link and the original - both are hard links. So such a file is no longer recognisable as 'external' and the choice of including it or not in an archive or a copy no longer exists. That defeats the original purpose which is to have this choice. Apart from that, hard links are possible only within the same file system. There are good reasons to keep big audio files etc. on a separate one. That in itself is a motivation for 'external' data in first place. I don't want hundreds of Gigabytes of audio files on my /home partition, let alone in my home directory. Ardour makes this mistake of creating hard links if by chance it happens to be possible, and even if the user explicitly expressed his/her choice to keep a file out of the session directory. It's inconsistent and unreliable behaviour and only creates problems. 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] NSM - handling large files
Personally I prefer Ardour's behavior myself. I do keep my samples on an external drive, but in the end the ability to maintain a self-contained session for portability purposes is important to me. But to each their own. Seablade On Fri, Mar 30, 2012 at 4:53 PM, Fons Adriaensen f...@linuxaudio.orgwrote: On Fri, Mar 30, 2012 at 09:07:07PM +0200, Lieven Moors wrote: Would there be anything against using hard links? A hard link makes the file pointed to part of the session directory, just as moving or copying the file would. There is no difference between a hard link and the original - both are hard links. So such a file is no longer recognisable as 'external' and the choice of including it or not in an archive or a copy no longer exists. That defeats the original purpose which is to have this choice. Apart from that, hard links are possible only within the same file system. There are good reasons to keep big audio files etc. on a separate one. That in itself is a motivation for 'external' data in first place. I don't want hundreds of Gigabytes of audio files on my /home partition, let alone in my home directory. Ardour makes this mistake of creating hard links if by chance it happens to be possible, and even if the user explicitly expressed his/her choice to keep a file out of the session directory. It's inconsistent and unreliable behaviour and only creates problems. 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 ___ 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 Fri, Mar 30, 2012 at 05:14:50PM -0400, Thomas Vecchione wrote: Personally I prefer Ardour's behavior myself. I do keep my samples on an external drive, but in the end the ability to maintain a self-contained session for portability purposes is important to me. You always have that ability, even if you allow others not to use it. And if you don't allow that, as Ardour does when by chance it can, it's no longer an 'ability' but something forced onto you. 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] NSM - handling large files
Not awake enough to debate here, but my memory and your's of Ardour's behavior doesn't seem to be matching up I don't believe. But I ened more sleep before I really dig into that. Seablade On Fri, Mar 30, 2012 at 5:27 PM, Fons Adriaensen f...@linuxaudio.orgwrote: On Fri, Mar 30, 2012 at 05:14:50PM -0400, Thomas Vecchione wrote: Personally I prefer Ardour's behavior myself. I do keep my samples on an external drive, but in the end the ability to maintain a self-contained session for portability purposes is important to me. You always have that ability, even if you allow others not to use it. And if you don't allow that, as Ardour does when by chance it can, it's no longer an 'ability' but something forced onto you. 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] NSM - handling large files
On Fri, 2012-03-30 at 20:53 +, Fons Adriaensen wrote: On Fri, Mar 30, 2012 at 09:07:07PM +0200, Lieven Moors wrote: Would there be anything against using hard links? Nedko mentioned this idea on IRC as well... Apart from that, hard links are possible only within the same file system. ... but that's definitely a show-stopper -dr ___ 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 Fri, Mar 30, 2012 at 08:53:26PM +, Fons Adriaensen wrote: On Fri, Mar 30, 2012 at 09:07:07PM +0200, Lieven Moors wrote: Would there be anything against using hard links? A hard link makes the file pointed to part of the session directory, just as moving or copying the file would. There is no difference between a hard link and the original - both are hard links. So such a file is no longer recognisable as 'external' and the choice of including it or not in an archive or a copy no longer exists. That defeats the original purpose which is to have this choice. But if the hardlinks would be in an 'external files' directory managed by the session manager only, you would still have that choice when you make the archive. Though I agree this is only based on convention... Apart from that, hard links are possible only within the same file system. There are good reasons to keep big audio files etc. on a separate one. That in itself is a motivation for 'external' data in first place. I don't want hundreds of Gigabytes of audio files on my /home partition, let alone in my home directory. You could make a symbolic link to a directory with hardlinks managed by the SM. Then the SM would spread like a giant octopus ;-) Well, only kidding... I agree that the arguments against them are very strong. But I must say, there is something seductive about them. If you want to delete the originals without the fear of destroying your sessions, go ahead. If you want to cleanup a session, tell the session manager to delete the hardlinks for that session, and delete the originals yourself. If you want an archive, tell the SM to copy all the 'external files' directories. Session management can exist in parallel with normal filesystem activity. And most importantly, never worry about those dreadful broken links... But still I agree, on a more fundametal level, that hardlinks are a bad idea. lieven ___ 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 10:27 PM, Fons Adriaensen wrote: On Fri, Mar 30, 2012 at 05:14:50PM -0400, Thomas Vecchione wrote: Personally I prefer Ardour's behavior myself. I do keep my samples on an external drive, but in the end the ability to maintain a self-contained session for portability purposes is important to me. You always have that ability, even if you allow others not to use it. And if you don't allow that, as Ardour does when by chance it can, it's no longer an 'ability' but something forced onto you. On 03/30/2012 10:14 PM, Thomas Vecchione wrote: Personally I prefer Ardour's behavior myself. I do keep my samples on an external drive, but in the end the ability to maintain a self-contained session for portability purposes is important to me. But to each their own. aha. this discussion may still be in flux and i believe it's all about session management and not whether each application native behavior is wrong or right. aham ;) but ntl. let me see, ardour stores a world under its own session directory on a per session basis. you may call it that way or project, song, collection, whatever is more appropriate. check. otoh, qtractor doesn't do that but you (the human being) are in control, remenber? it's your choice anyway. and there's an exit option: you may chose anytime to save the whole (qtractor) session in a zip file container. in case you don't know, this is a pretty regular zip file (besides having an esquisite .qtz file suffix), just like (open|libre)office and .jar files are and, as far as my knowledge goes, are pretty portable stuff ;) again, the subject at hand is about session management and whether huge or small external files are to get reported to the SM from applications in its way to collect, map(*) and possibly massage--my nomenclature here--a managed-session-repertoire. (*) map: hashes, symlinks, hardlinks or whatever--it's a SM implementation detail anyhow otherwise, i may be way off base (which is not that rare:^)) cheers -- rncbc aka Rui Nuno Capela rn...@rncbc.org ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
