[PD] Re: Mac OS X installer with library documentation
Thomas Ouellet Fredericks
iamonthebeach at gmail.com
Fri Apr 1 06:20:17 CEST 2005
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).
On Mar 30, 2005 1:11 PM, B. Bogart <ben at 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
> 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.
> 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
More information about the Pd-list