[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).


Tom

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
> /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
> >
> >
> 
> 
>




More information about the Pd-list mailing list