Seconded. IMO something like [getdir] should be included with vanilla, perhaps as part of get canvas info functionality.
I’m using [getdir] for things like this in PdParty and I have a few abstractions for working with paths (p_*): https://github.com/danomatika/rc-patches/tree/master/rc https://github.com/danomatika/rc-patches/tree/master/rc
On May 29, 2017, at 10:30 AM, pd-list-request@lists.iem.at wrote:
From: Antoine Rousseau <antoine@metalu.net mailto:antoine@metalu.net> Subject: Re: [PD] Execute command from Pd Date: May 29, 2017 at 6:40:26 AM MDT To: Roman Haefeli <reduzent@gmail.com mailto:reduzent@gmail.com> Cc: Pd-list <pd-list@lists.iem.at mailto:pd-list@lists.iem.at>
When I distribute the script together with my Pd project, I'd rather want it relative to the patch, otherwise the script won't be found on other users' machines.
As you need [ggee/shell], then why not using also [ggee/getdir] to know where your patch is located ?
Antoine Rousseau http://www.metalu.net http://metalu.net/ __ http://www.metaluachahuter.com/ http://www.metaluachahuter.com/compagnies/al1-ant1/
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Mon, 2017-05-29 at 13:15 -0600, Dan Wilcox wrote:
Seconded. IMO something like [getdir] should be included with vanilla, perhaps as part of get canvas info functionality.
I can't think of any case where relative to Pd's start location is useful (on macOS it seems to always be /, no matter where you double- clicked a patch). On the other hand, I can think of quite a few cases where relative to patch would be desired. [shell] is only one example. But also when opening patches by message to Pd, it would make much more sense to load them relative to the current patch (though that might not be an advertised feature of Pd).
If the notion that relative to patch is superior to relative to Pd would find wide adoption, we often wouldn't even need something like [getdir].
But I agree, that something like [getdir] in vanilla would be handy.
Roman
I’m using [getdir] for things like this in PdParty and I have a few abstractions for working with paths (p_*): https://github.com/danomat ika/rc-patches/tree/master/rc
On May 29, 2017, at 10:30 AM, pd-list-request@lists.iem.at wrote:
From: Antoine Rousseau antoine@metalu.net Subject: Re: [PD] Execute command from Pd Date: May 29, 2017 at 6:40:26 AM MDT To: Roman Haefeli reduzent@gmail.com Cc: Pd-list pd-list@lists.iem.at
When I distribute the script together with my Pd project, I'd rather want it relative to the patch, otherwise the script won't be found on other users' machines.
As you need [ggee/shell], then why not using also [ggee/getdir] to know where your patch is located ?
Antoine Rousseau http://www.metalu.net%C2%A0__%C2%A0http://www.metaluachahuter.com/
Dan Wilcox @danomatika danomatika.com robotcowboy.com
- Roman Haefeli reduzent@gmail.com [2017-05-29 22:58]:
On Mon, 2017-05-29 at 13:15 -0600, Dan Wilcox wrote:
Seconded. IMO something like [getdir] should be included with vanilla, perhaps as part of get canvas info functionality.
I can't think of any case where relative to Pd's start location is useful (on macOS it seems to always be /, no matter where you double- clicked a patch). On the other hand, I can think of quite a few cases where relative to patch would be desired. [shell] is only one example. But also when opening patches by message to Pd, it would make much more sense to load them relative to the current patch (though that might not be an advertised feature of Pd).
If the notion that relative to patch is superior to relative to Pd would find wide adoption, we often wouldn't even need something like [getdir].
But I agree, that something like [getdir] in vanilla would be handy.
In cases where pd is started from the command line one could write a wrapper script that gets the directory of the patch file that would have to be passed to pd as argument. The script could then relay this info to pd using pdsend probably.
(2cents) P
On 29/05/17 23:30, Peter P. wrote:
In cases where pd is started from the command line one could write a wrapper script that gets the directory of the patch file that would have to be passed to pd as argument. The script could then relay this info to pd using pdsend probably.
pd has a -send command line argument that is useful for this kind of thing. Using pdsend from a startup script is prone to a race condition (how do you know when pd is ready to recieve the message?).
Claude
-
Claude Heiland-Allen -
Dan Wilcox -
Peter P. -
Roman Haefeli