On Mar 27, 2005, at 12:01 AM, simon wise wrote:
On 27 Mar 2005, at 8:28 AM, Hans-Christoph Steiner wrote:
The Pd .app and Win installer should be viewed as any other
application: a set of code that users don't modify. This is key to
keeping it consistent across platforms and distributions. User
modifications should be kept elsewhere. For example, in MacOS X, we
could have standard folders like ~/Library/Pd/Externals and
~/Library/Pd/Help which are added to the path by default.
Therefore, when upgrading, users won't have to redo all of their
changes, they can just delete the Pd.app and put the new one in place
and all of their customizations would remain in place. This also
means that extra, doc, etc. should remain enclosed inside of Pd.app.~/Library/Application Support/Pd (or /Library/Application Support/Pd)
would be the usual OSX place to put directories intended to be used by
the user, many .apps use search paths like~/Library/Application Support/Pd/subfolder /Library/Application Support/Pd/subfolder $PATH_TO_APP/Contents/Resources/subfolder
for every subfolder that should have both default/built-in parts and
custom user parts - that way it gives the possibility for a general
local set of defaults as well as individual user additions, and if
like me you have a couple of users set up (one with system and
application preferences for current live performance situations, the
other for the rest of the time so that I can switch back to my
performance settings very quickly and easily) then it is easy to set
up a particular set of extras and preferences to use in a show, while
still keeping a more general set.
I like the idea of keeping the subfolder names the same, but the
"Application Support" gets really long. And there are precedents for
the ~/Library/Pd way, like ~/Library/Mail.
The same could be done with the .plist - so that the $HOME one took
precedence, but the one inside Pd.app could easily be used to share a
version with certain externals and defaults already set. An extra item
in the .plist to make pd launch with only these defaults would make it
possible to have a specially set up .app for a particular patch - set
to open that patch on launching without worrying about other
preferences that may have been set for that user. I am using .command
files with the -open and other flags for this purpose, but it opens
with the Terminal window in front and the Wish interface.A structure like this would also make it easy to have different sets
of externals for different kinds of work by creating new users (maybe
one for Gem/video work and another for audio work) with their
associated preferences, external collections etc being quite distinct.
Various Pd-*.command files could easily swap in and out various
~/Library/Preferences/org.puredata.*.plist files to start different
configs.
Finally it would be a nice touch for the installer to put symbolic
links to pd, pdsend, pdreceive etc from their old locations in
/usr/local so that they are in the right place for scripts which may
not know where to find Pd.app and and so they are in the terminal
search paths.
Yes it would be indeed. I was planning a Pd-for-UNIX.pkg to do stuff
like that, also including the headers. Feel free to beat me to it.
.hc
Maybe some useful models (gvim and gvim.app which work a bit
differently to Vim.app) could come from the OSX version of Vim see:
http://macvim.org/OSX/Simon Wise
"Computer science is no more related to the computer than astronomy is
related to the telescope."
-Edsger Dykstra
Hey HC (again!)
Having system abstractions in one folder extra/ in the pd.app and the user-added abstractions in a separate place ~/Library/Pd/extra is a problem for pixelTANGO.
In pixelTANGO we have a folder of abstractions abstractions/
Inside this abstraction is an fx/ sub-folder that contains special purpose abstractions. These abstractions are just pixel effects and they all have a standard interface. These abstractions are dynamically read into PD and instanciated. (via dir2abstractionArray.pd) The PD patch needs to contain the path to these abstractions, just the search-path is not enough. Currently they are hard-coded in /Applications/PixelTANGO/abstractions/fx
This is the watched folder for new abstractions that user may (hopefully will) contribute. To search both the pd.app abstractions folder and the home directory in the patch would be pretty damn complex... (it is already complex!!)
I do really like the idea of being able to add custom externals in my home directory and replacing only the pd.app to only replace the standard objects. I don't know how to resolve this conflict.
B.
Hans-Christoph Steiner wrote:
I like the idea of keeping the subfolder names the same, but the "Application Support" gets really long. And there are precedents for the ~/Library/Pd way, like ~/Library/Mail.
The same could be done with the .plist - so that the $HOME one took precedence, but the one inside Pd.app could easily be used to share a version with certain externals and defaults already set. An extra item in the .plist to make pd launch with only these defaults would make it possible to have a specially set up .app for a particular patch - set to open that patch on launching without worrying about other preferences that may have been set for that user. I am using .command files with the -open and other flags for this purpose, but it opens with the Terminal window in front and the Wish interface.
A structure like this would also make it easy to have different sets of externals for different kinds of work by creating new users (maybe one for Gem/video work and another for audio work) with their associated preferences, external collections etc being quite distinct.
Various Pd-*.command files could easily swap in and out various ~/Library/Preferences/org.puredata.*.plist files to start different configs.
Finally it would be a nice touch for the installer to put symbolic links to pd, pdsend, pdreceive etc from their old locations in /usr/local so that they are in the right place for scripts which may not know where to find Pd.app and and so they are in the terminal search paths.
Yes it would be indeed. I was planning a Pd-for-UNIX.pkg to do stuff like that, also including the headers. Feel free to beat me to it.
.hc
Maybe some useful models (gvim and gvim.app which work a bit differently to Vim.app) could come from the OSX version of Vim see: http://macvim.org/OSX/
Simon Wise
"Computer science is no more related to the computer than astronomy is related to the telescope." -Edsger Dykstra
Are you sure it is better to store the extra externals, projects and abstractions in a user specific directory. Max/Msp for XP stores those in a common folder (I think c:\program files\common\max).
Tom
On Mar 30, 2005 1:11 PM, B. Bogart ben@ekran.org wrote:
Hey HC (again!)
Having system abstractions in one folder extra/ in the pd.app and the user-added abstractions in a separate place ~/Library/Pd/extra is a problem for pixelTANGO.
In pixelTANGO we have a folder of abstractions abstractions/
Inside this abstraction is an fx/ sub-folder that contains special purpose abstractions. These abstractions are just pixel effects and they all have a standard interface. These abstractions are dynamically read into PD and instanciated. (via dir2abstractionArray.pd) The PD patch needs to contain the path to these abstractions, just the search-path is not enough. Currently they are hard-coded in /Applications/PixelTANGO/abstractions/fx
This is the watched folder for new abstractions that user may (hopefully will) contribute. To search both the pd.app abstractions folder and the home directory in the patch would be pretty damn complex... (it is already complex!!)
I do really like the idea of being able to add custom externals in my home directory and replacing only the pd.app to only replace the standard objects. I don't know how to resolve this conflict.
B.
Hans-Christoph Steiner wrote:
I like the idea of keeping the subfolder names the same, but the "Application Support" gets really long. And there are precedents for the ~/Library/Pd way, like ~/Library/Mail.
The same could be done with the .plist - so that the $HOME one took precedence, but the one inside Pd.app could easily be used to share a version with certain externals and defaults already set. An extra item in the .plist to make pd launch with only these defaults would make it possible to have a specially set up .app for a particular patch - set to open that patch on launching without worrying about other preferences that may have been set for that user. I am using .command files with the -open and other flags for this purpose, but it opens with the Terminal window in front and the Wish interface.
A structure like this would also make it easy to have different sets of externals for different kinds of work by creating new users (maybe one for Gem/video work and another for audio work) with their associated preferences, external collections etc being quite distinct.
Various Pd-*.command files could easily swap in and out various ~/Library/Preferences/org.puredata.*.plist files to start different configs.
Finally it would be a nice touch for the installer to put symbolic links to pd, pdsend, pdreceive etc from their old locations in /usr/local so that they are in the right place for scripts which may not know where to find Pd.app and and so they are in the terminal search paths.
Yes it would be indeed. I was planning a Pd-for-UNIX.pkg to do stuff like that, also including the headers. Feel free to beat me to it.
.hc
Maybe some useful models (gvim and gvim.app which work a bit differently to Vim.app) could come from the OSX version of Vim see: http://macvim.org/OSX/
Simon Wise
"Computer science is no more related to the computer than astronomy is related to the telescope." -Edsger Dykstra
Thomas Ouellet Fredericks wrote:
Are you sure it is better to store the extra externals, projects and abstractions in a user specific directory. Max/Msp for XP stores those in a common folder (I think c:\program files\common\max).
max/msp need not be a reference for us (esp. on windoze) xp must not be a reference for us.
i am sure we need a system-specific path _and_ a user specific path.
the system-path is normally not writable by ordinary users (you need to be admin to write to c:\programmes\common\max - at least on my systems ;-)) and people should not need to bother the admin with every external/abstraction they want to be installed on a machine.
now you might say: but hey, i AM the admin of my box. and i say: but nowadays even windows has multiple users, and the multi-user concept is not only there to not grant the evil hacker the right to format your hard-disk. it is there because sometimes a bunch of people work on the same machine and they should be separated. now hans says: but IO, you are the only one who is actually running multi-user systems. all people i know (but you) have admin rights on the machines they are using. and i answer: this is no valid argument against doing things properly. most people didn't think that they would ever need privilege separation when they were using dos, and where did it lead us ?
mfg.a.sd IOhannes
From my end I am not arguing the VALUE of having both the pd.app extra AND the ~/Library/pd/extra paths. Though this method is harder for a new user, and I mean a lot harder, about as hard as the concept of /usr/local/lib/pd on OSX STILL is for people.
Anyone have a suggestion to the pixelTANGO problem of a special dynamic abstractions folder? If allowing pixelTANGO to watch both an internal extra folder to the pd.app AND an external one in the users ~/ satisfies everyone then I can go this way... name-conflicts would be pretty ugly though... If two abstractions have the same name then they would have different paths and not stomp on one and other, BUT the ; pd-abstraction.pd messages I suppose would not work since they would be bound to both abstractions with the same base-name?
B.
IOhannes m zmoelnig wrote:
Thomas Ouellet Fredericks wrote:
Are you sure it is better to store the extra externals, projects and abstractions in a user specific directory. Max/Msp for XP stores those in a common folder (I think c:\program files\common\max).
max/msp need not be a reference for us (esp. on windoze) xp must not be a reference for us.
i am sure we need a system-specific path _and_ a user specific path.
the system-path is normally not writable by ordinary users (you need to be admin to write to c:\programmes\common\max - at least on my systems ;-)) and people should not need to bother the admin with every external/abstraction they want to be installed on a machine.
now you might say: but hey, i AM the admin of my box. and i say: but nowadays even windows has multiple users, and the multi-user concept is not only there to not grant the evil hacker the right to format your hard-disk. it is there because sometimes a bunch of people work on the same machine and they should be separated. now hans says: but IO, you are the only one who is actually running multi-user systems. all people i know (but you) have admin rights on the machines they are using. and i answer: this is no valid argument against doing things properly. most people didn't think that they would ever need privilege separation when they were using dos, and where did it lead us ?
mfg.a.sd IOhannes
IOhannes m zmoelnig wrote:
Thomas Ouellet Fredericks wrote:
Are you sure it is better to store the extra externals, projects and abstractions in a user specific directory. Max/Msp for XP stores those in a common folder (I think c:\program files\common\max).
user-specific externals and abstractions should not go there, but into a directory specified by the user itself as a user-specific preference. That is how Max should be used, and what is better not changed in Pd.
max/msp need not be a reference for us (esp. on windoze)
sure their design is not perfect, but peeping there and comparing with `ours' is not such a bad idea at all. The two environments are very similar. They are struggling with the very same difficulties, so it would be very strange if none of their solutions had any advantages over proposals discussed here.
Some advantages of Max configuration: it is message-based under the hood, uses patches for all sorts of dialog windows, is more open, flexible, more consistently the Pd way of design.
Krzysztof
That's a good point which I forgot. My main point is that we should
try to set things up so that the Pd.app never needs to be modified, so
that upgrades are just a matter of deleting one Pd.app and swapping in
the new one. (This applies to all platforms, of course, just not the
.app part;).
In the MacOS X way, there are two mirrored locations for such
application extensions: system (/Library/Pd) and user (~/Library/Pd).
So on Windows we could have "C:\Program Files\Common\Pd" and
"C:\Documents and Settings\username...blah blah...\Pd". On UNIX, the
same idea "/usr/local/lib/pd" and "~/lib/pd", or something like that.
.hc
On Mar 31, 2005, at 11:20 PM, Thomas Ouellet Fredericks wrote:
Are you sure it is better to store the extra externals, projects and abstractions in a user specific directory. Max/Msp for XP stores those in a common folder (I think c:\program files\common\max).
Tom
On Mar 30, 2005 1:11 PM, B. Bogart ben@ekran.org wrote:
Hey HC (again!)
Having system abstractions in one folder extra/ in the pd.app and the user-added abstractions in a separate place ~/Library/Pd/extra is a problem for pixelTANGO.
In pixelTANGO we have a folder of abstractions abstractions/
Inside this abstraction is an fx/ sub-folder that contains special purpose abstractions. These abstractions are just pixel effects and
they all have a standard interface. These abstractions are dynamically read into PD and instanciated. (via dir2abstractionArray.pd) The PD patch needs to contain the path to these abstractions, just the search-path
is not enough. Currently they are hard-coded in /Applications/PixelTANGO/abstractions/fxThis is the watched folder for new abstractions that user may
(hopefully will) contribute. To search both the pd.app abstractions folder and
the home directory in the patch would be pretty damn complex... (it is already complex!!)I do really like the idea of being able to add custom externals in my home directory and replacing only the pd.app to only replace the standard objects. I don't know how to resolve this conflict.
B.
Hans-Christoph Steiner wrote:
I like the idea of keeping the subfolder names the same, but the "Application Support" gets really long. And there are precedents for the ~/Library/Pd way, like ~/Library/Mail.
The same could be done with the .plist - so that the $HOME one took precedence, but the one inside Pd.app could easily be used to share
a version with certain externals and defaults already set. An extra item in the .plist to make pd launch with only these defaults would make it possible to have a specially set up .app for a particular patch - set to open that patch on launching without worrying about other preferences that may have been set for that user. I am using .command files with the -open and other flags for this purpose, but it opens with the Terminal window in front and the Wish interface.A structure like this would also make it easy to have different sets of externals for different kinds of work by creating new users
(maybe one for Gem/video work and another for audio work) with their associated preferences, external collections etc being quite
distinct.Various Pd-*.command files could easily swap in and out various ~/Library/Preferences/org.puredata.*.plist files to start different configs.
Finally it would be a nice touch for the installer to put symbolic links to pd, pdsend, pdreceive etc from their old locations in /usr/local so that they are in the right place for scripts which may not know where to find Pd.app and and so they are in the terminal search paths.
Yes it would be indeed. I was planning a Pd-for-UNIX.pkg to do stuff like that, also including the headers. Feel free to beat me to it.
.hc
Maybe some useful models (gvim and gvim.app which work a bit differently to Vim.app) could come from the OSX version of Vim see: http://macvim.org/OSX/
Simon Wise
"Computer science is no more related to the computer than astronomy
is related to the telescope." -Edsger Dykstra
http://at.or.at/hans/
Ah, Ok, I finally understand why you need this setup for pixelTANGO.
You are banging against the current limitations of abstractions as
objects: the path issues. It seems that the [pwd] object that Frank
proposed would help out here, but I don't know the status of it.
.hc
On Mar 30, 2005, at 1:11 PM, B. Bogart wrote:
Hey HC (again!)
Having system abstractions in one folder extra/ in the pd.app and the user-added abstractions in a separate place ~/Library/Pd/extra is a problem for pixelTANGO.
In pixelTANGO we have a folder of abstractions abstractions/
Inside this abstraction is an fx/ sub-folder that contains special purpose abstractions. These abstractions are just pixel effects and
they all have a standard interface. These abstractions are dynamically read into PD and instanciated. (via dir2abstractionArray.pd) The PD patch needs to contain the path to these abstractions, just the search-path
is not enough. Currently they are hard-coded in /Applications/PixelTANGO/abstractions/fxThis is the watched folder for new abstractions that user may
(hopefully will) contribute. To search both the pd.app abstractions folder and the home directory in the patch would be pretty damn complex... (it is already complex!!)I do really like the idea of being able to add custom externals in my home directory and replacing only the pd.app to only replace the standard objects. I don't know how to resolve this conflict.
B.
Hans-Christoph Steiner wrote:
I like the idea of keeping the subfolder names the same, but the "Application Support" gets really long. And there are precedents for the ~/Library/Pd way, like ~/Library/Mail.
The same could be done with the .plist - so that the $HOME one took precedence, but the one inside Pd.app could easily be used to share a version with certain externals and defaults already set. An extra item in the .plist to make pd launch with only these defaults would make it possible to have a specially set up .app for a particular patch - set to open that patch on launching without worrying about other preferences that may have been set for that user. I am using .command files with the -open and other flags for this purpose, but it opens with the Terminal window in front and the Wish interface.
A structure like this would also make it easy to have different sets of externals for different kinds of work by creating new users (maybe one for Gem/video work and another for audio work) with their associated preferences, external collections etc being quite
distinct.Various Pd-*.command files could easily swap in and out various ~/Library/Preferences/org.puredata.*.plist files to start different configs.
Finally it would be a nice touch for the installer to put symbolic links to pd, pdsend, pdreceive etc from their old locations in /usr/local so that they are in the right place for scripts which may not know where to find Pd.app and and so they are in the terminal search paths.
Yes it would be indeed. I was planning a Pd-for-UNIX.pkg to do stuff like that, also including the headers. Feel free to beat me to it.
.hc
Maybe some useful models (gvim and gvim.app which work a bit differently to Vim.app) could come from the OSX version of Vim see: http://macvim.org/OSX/
Simon Wise
__ ____
"Computer science is no more related to the computer than astronomy is related to the telescope." -Edsger Dykstra
¡El pueblo unido jamás será vencido!
PWD works fine, BUT since the folder is watched by an abstraction, not by the parent PWD only returns the parent value. According to Miller there is no way to get the path an abstraction was loaded from. So the path has to be in a standard place. in TOT I think this had to be absolute due to ~ replacement, but I see in python we can do ~ replacement so I should be able to get the home directory path.
What I'm worried about is reading abstractions from two different places into one array... at the moment I'm just thinking of concatenating the two lists (with absolute paths) and just ignoring the fact they come from different places.
I don't know how the ; pd-abstraction.pd stuff will work with possible duplicate names... Also its harder (impossible) to open pixelTANGO abstractions as a basis of new user contributions (since they would be burried down in the .app.)
*sigh*
B.
Hans-Christoph Steiner wrote:
Ah, Ok, I finally understand why you need this setup for pixelTANGO. You are banging against the current limitations of abstractions as objects: the path issues. It seems that the [pwd] object that Frank proposed would help out here, but I don't know the status of it.
.hc
On Mar 30, 2005, at 1:11 PM, B. Bogart wrote:
Hey HC (again!)
Having system abstractions in one folder extra/ in the pd.app and the user-added abstractions in a separate place ~/Library/Pd/extra is a problem for pixelTANGO.
In pixelTANGO we have a folder of abstractions abstractions/
Inside this abstraction is an fx/ sub-folder that contains special purpose abstractions. These abstractions are just pixel effects and they all have a standard interface. These abstractions are dynamically read into PD and instanciated. (via dir2abstractionArray.pd) The PD patch needs to contain the path to these abstractions, just the search-path is not enough. Currently they are hard-coded in /Applications/PixelTANGO/abstractions/fx
This is the watched folder for new abstractions that user may (hopefully will) contribute. To search both the pd.app abstractions folder and the home directory in the patch would be pretty damn complex... (it is already complex!!)
I do really like the idea of being able to add custom externals in my home directory and replacing only the pd.app to only replace the standard objects. I don't know how to resolve this conflict.
B.
Hans-Christoph Steiner wrote:
I like the idea of keeping the subfolder names the same, but the "Application Support" gets really long. And there are precedents for the ~/Library/Pd way, like ~/Library/Mail.
The same could be done with the .plist - so that the $HOME one took precedence, but the one inside Pd.app could easily be used to share a version with certain externals and defaults already set. An extra item in the .plist to make pd launch with only these defaults would make it possible to have a specially set up .app for a particular patch - set to open that patch on launching without worrying about other preferences that may have been set for that user. I am using .command files with the -open and other flags for this purpose, but it opens with the Terminal window in front and the Wish interface.
A structure like this would also make it easy to have different sets of externals for different kinds of work by creating new users (maybe one for Gem/video work and another for audio work) with their associated preferences, external collections etc being quite distinct.
Various Pd-*.command files could easily swap in and out various ~/Library/Preferences/org.puredata.*.plist files to start different configs.
Finally it would be a nice touch for the installer to put symbolic links to pd, pdsend, pdreceive etc from their old locations in /usr/local so that they are in the right place for scripts which may not know where to find Pd.app and and so they are in the terminal search paths.
Yes it would be indeed. I was planning a Pd-for-UNIX.pkg to do stuff like that, also including the headers. Feel free to beat me to it.
.hc
Maybe some useful models (gvim and gvim.app which work a bit differently to Vim.app) could come from the OSX version of Vim see: http://macvim.org/OSX/
Simon Wise
__ ____
"Computer science is no more related to the computer than astronomy is related to the telescope." -Edsger Dykstra
¡El pueblo unido jamás será vencido!
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list