[Sc-devel] Re: [commit?] SynthDef default dir moves to inside
userAppSupportDir
Scott Wilson
i at scottwilson.ca
Mon Oct 1 19:39:39 PDT 2007
On 1 Oct 2007, at 14:42, Dan Stowell wrote:
> 2007/9/28, Scott Wilson <i at scottwilson.ca>:
>>
>> On 28 Sep 2007, at 17:24, Julian Rohrhuber wrote:
>>
>>>> 2007/9/26, nescivi <nescivi at gmail.com>:
>>>>> Hiho,
>>>>>
>>>>> On Wednesday 26 September 2007 10:24:42 Dan Stowell wrote:
>>>>>> Wait a minute. This doesn't account for the server looking for
>>>>> a local
>>>>>> "synthdefs" folder when it boots.
>>>>>>
>>>>>> If I set the environment variable SC_SYNTHDEF_PATH correctly
>>>>> in the
>>>>>> Server.program string then I can get the synthdefs loaded, but it
>>>>>> isn't a pretty solution.
>>>>>>
>>>>>> Any thoughts?
>>>>>>
>>>>>> To change where the server looks would not be difficult. In
>>>>>> World_LoadGraphDefs() we'd just change from using
>>>>>> sc_GetResourceDirectory() to sc_GetUserAppSupportDirectory(),
>>>>> although
>>>>>> an extra tweak would probably be needed for the standalone.
>>>>>
>>>>> how would that work for running scsynth on a remote computer?
>>>>
>>>> What remoteness issues are you thinking of? One issue would be
>>>> that we
>>>> might not be able to guarantee that ...userappsupportdir/synthdefs
>>>> has
>>>> been created.
>>>
>>> this may be an issue when the remote computer only has an instance
>>> of the server. Otherwise, the directory should exist automatically?
>>> --
>>
>> Sorry if I'm misunderstanding here, but I think you can only 'send'
>> defs to a remote server, not 'load' them anyway. Or? So how is this
>> an issue?
>
> AFAIK the only issue is that the server currently looks for a folder
> in the current working directory (*not* inside userAppSupportDir) when
> it boots. So it would need to be changed to do this, and perhaps even
> to create the dir if not there already (?). Not a big change I
> suspect...?
Looking is fine, but as it doesn't write defs, and as a remote client
can't write defs locally either, I don't see what the problem is.
S.
More information about the Sc-devel
mailing list