Re: [LAD] SC3-- Help !

From: nescivi <nescivi@email-addr-hidden>
Date: Sat Sep 20 2008 - 19:57:03 EEST

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
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Sat Sep 20 20:15:03 2008

This archive was generated by hypermail 2.1.8 : Sat Sep 20 2008 - 20:15:04 EEST