[PD] Re: Mac OS X installer with library documentation

Hans-Christoph Steiner hans at eds.org
Sun Apr 3 17:23:06 CEST 2005


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!





More information about the Pd-list mailing list