Hiho, On Friday 19 September 2008 17:01:40 Fons Adriaensen wrote: > > > I mean, the *.sc files are on an NFS disk - not even > > > on my own machine. And I don't want anything copied > > > to my $HOME just because I'm running them - I'm not > > > even creating new synthdefs, just using the ones I > > > have and there are quite happy where they are. > > > > In that case, I am guessing you are running scsynth on another machine > > too... then SynthDef.send is recommended in any case. > > No, sclang and scsynth are running locally. But the source > files are on a shared directory (in this case on a remote > machine, but that's really irrelevant)- what is relevant is > that they are not in any way associated with me as a user. > And consequently there is no point in storing anything in > my $HOME. > > None of the *.sc files I'm running is creating new synthdefs, > they are just using the precompiled ones stored in the local > synthdef directory, and this worked perfectly before. So the > choice between .send or .write is irrelevant.
ok, a quick look at the source code shows that you have two options now: 1. use the userAppSupportDir 2. set an environment variable SC_SYNTHDEF_PATH, and this overrides The work directory option apparently has disappeared... I can check if there is an interest in adding it again with the other sc-devs. On OSX there is an option to make a standalone version of the whole app, which makes everything local to that version... maybe if we can come up with a strategy how this could work for Linux (maybe also a static build of sclang, scsynth and everything?), then we can make use of a similar way of determining the resource paths as under OSX standalone... > The whole idea of using $HOME/share just doesn't make any > sense, for several reasons. > > First, it's a contradiction just as ./private/public > would be. Nothing in my home directory is ever shared, > no other user has any access there. > > Second, it's as wrong as > > ~/share/g++/objectfiles or > ~/share/ardour/peak-files > > would be. > > If anything has to be shared, the worst place to put it > is in a user's home. No sane sysadmin would ever think > of doing such a thing. > > Third, if I want to backup a SC project, or just share it, > or send it to someone else, then I'd expect all data to > be under a single directory. > > > Is this ~/share thing Linux-specific or cross-platform ? On each OS, there is a userAppSupportDir, where files are stored or created that are user specific. The actual path of these is different on each platform. I think the specific name of "share" is relatively arbitrary, and probably stems from Stefan Kersten's habit for local testing of things, without installing things to /usr/local/. As far as I am concerned it could indeed be called ~/.SuperCollider. Some files are written by SC during runtime, so this has to be a directory to which the user running the app can write to. Also, the structure allows for users to customize their SC on a multi-user system (e.g. as found in many schools), so that they can write their own classes and put them somewhere without clogging other people's experience with SC. For bundling projects, or sets of extension classes, there is the Quark system, which supports (or even assumes use of) svn, and allows you to install those classes upon demand, by creating symlinks from the local copy of the repository to the Extensions path. Alternatively, you can either use a symlink for your classes to the home dir, or use a config file to determine which classes are loaded and which not. sincerely, Marije _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
