16 Sep
2008
16 Sep
'08
9:33 p.m.
Hello all,
(Hoping there's SC3 expert on the list)
I haven't been using SC3 for some time, but now I have
to revive some of my work from years ago. As before i'm
controlling it from Emacs.
The current release refuses to run my old code, apparently
because it loads/stores synthdefs from/to
~/share/SuperCollider/synthdefs instead of ./synthdefs.
Re-running all the definitions stores them in the new
place and then things work. But the last thing I want
is to have all synthdefs in one giant heap. They are
always very specific to a particular composition, and
I want to keeo them together with the other files for
each work.
Is there confituration option to make SC3 revert to
the old behaviour ?
More generally, I deeply dislike apps creating
non-specific directories such as ~/share. If SC3
wants a per-login directory it should be ~/.SC3
or something like that.
Ciao,
--
FA
Laboratorio di Acustica ed Elettroacustica
Parma, Italia
Wie der Mond heute Nacht aussieht !
Ist es nicht ein seltsames Bild ?
19 Sep
19 Sep
2:47 p.m.
Hi Fons,
On Tuesday 16 September 2008 19:30:33 Fons Adriaensen wrote:
Hello all,
(Hoping there's SC3 expert on the list)
yes, I'm here :)
I haven't been using SC3 for some time, but now I
have
to revive some of my work from years ago. As before i'm
controlling it from Emacs.
The current release refuses to run my old code, apparently
because it loads/stores synthdefs from/to
~/share/SuperCollider/synthdefs instead of ./synthdefs.
Re-running all the definitions stores them in the new
place and then things work. But the last thing I want
is to have all synthdefs in one giant heap. They are
always very specific to a particular composition, and
I want to keeo them together with the other files for
each work.
Is there confituration option to make SC3 revert to
the old behaviour ?
SynthDef.synthDefDir = "./synthdefs";
You might also be interested in using SynthDescLib, which is more geared
towards bundling a set of synthdefs.
More generally, I deeply dislike apps creating
non-specific directories such as ~/share. If SC3
wants a per-login directory it should be ~/.SC3
or something like that.
sk seems to prefer the ~/share/.. approach, so I think that's why we went
with that...
sincerely,
Marije
3:52 p.m.
On Fri, Sep 19, 2008 at 12:47:12PM -0400, nescivi wrote:
yes, I'm here :)
Hi Marije !
SynthDef.synthDefDir = "./synthdefs";
Thanks, but... the synthdefs get loaded, *and* copied
to ~/share... Any way to stop that once and for all ?
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.
Ciao,
--
FA
Laboratorio di Acustica ed Elettroacustica
Parma, Italia
Wie der Mond heute Nacht aussieht !
Ist es nicht ein seltsames Bild ?
6:13 p.m.
Hiho,
On Friday 19 September 2008 13:49:59 Fons Adriaensen wrote:
On Fri, Sep 19, 2008 at 12:47:12PM -0400, nescivi
wrote:
You can use the .send method instead... that way you avoid using the harddisk
for them at all...
yes, I'm here :)
Hi Marije !
SynthDef.synthDefDir = "./synthdefs";
Thanks, but... the synthdefs get loaded, *and* copied
to ~/share... Any way to stop that once and for all ? 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.
sincerely,
Marije
7:04 p.m.
On Fri, Sep 19, 2008 at 04:06:44PM -0400, nescivi wrote:
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.
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 ?
Ciao,
--
FA
Laboratorio di Acustica ed Elettroacustica
Parma, Italia
Wie der Mond heute Nacht aussieht !
Ist es nicht ein seltsames Bild ?
Hiho,
HiHo !
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.
20 Sep
20 Sep
2:57 p.m.
Hiho,
On Friday 19 September 2008 17:01:40 Fons Adriaensen wrote:
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...
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. 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
24 Nov
24 Nov
11:26 a.m.
nescivi wrote:
sorry for replying late: maybe this is a change we could push into 3.3?
cc'ing sc-dev ...
<sk>
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.
5972
days inactive
6041
days old
linux-audio-dev@lists.linuxaudio.org
6 comments
3 participants
participants (3)
-
Fons Adriaensen -
nescivi -
stefan kersten