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