[LAD] SC3-- Help !

[nescivi]

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