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

Hans-Christoph Steiner hans at eds.org
Sat Mar 26 23:40:03 CET 2005

Basically all of the issues surrounding using libs can be eliminated by  
compiling externals as individual objects.  I have been working towards  
this for a while, so that you don't need to edit any prefs in order to  
have access to all of the available objects.  The only downside that  
has been confirmed with the individual files vs. libraries is that  
someone has to do the work to convert libs into individual objects.  I  
did this for IEMlib, it was actually much easier than I thought it  
would be, and I did it without even touching the IEMlib code.  Its all  
done in the externals/build/* build system.


On Mar 25, 2005, at 7:24 PM, B. Bogart wrote:

> Interaccess did bring up an issue of the Windows installer looking very
> different from the OSX. (new help menu) being confusing for new users.
> Other than this complaint I had not had any issues teaching on both OSX
> and Windows, BUT I was only teaching the Gem stuff.
> I'm pretty happy with the fact that .app don't require an installer. Of
> course I'm going to use this moment again to complain about the plist
> settings cannot be included inside the pd.app. This would mean you  
> could
> install PD just by dragging the .app into applications. I suppose there
> should be a way of having the .app start PD with certain flags that do
> not come from the plist?
> I suppose the PD.app should include the CVS abstractions. PixelTANGO is
> not in there, but its a big project... I would certainly consider it if
> it meant getting the most up2date abstractions into the pd.app
> automatically through the .app build system.
> Maybe we should have an IRC pd package/.app development meeting or a
> second channel on the usual dev meeting?
> Tom, could you define "identical" as in contains all the same
> abstractions and such, looks the same, and creates a similar
> Applications folder in "Program Files"? I think this is reasonable...
> We were discussing the PD documentation system at the last dev-meeting.
> are you on pd-dev? Basically we decided that the "help" menu should be  
> a
> list of all objects installed on the machine. this list should be
> searchable and would be dynamically generated from the
> abstraction/patch/lib help files. This is closely related to your
> catagorized inventory idea, since the menu should also be grouped by
> function. Do you have a skeleton about how the objects could be  
> organized?
> French Documentation is a great idea, I hope you get funding! Good  
> luck.
> B.
> Thomas Ouellet Fredericks wrote:
>> I needed an indentical XP and OSX package for my workshops.
>> My package is simply miller's version with the externals I need to
>> teach Pure Data.
>> I will also include three "complete" abstractions :
>> - one to play soud files (very similar to xgroove~ but with integrated
>> file loading and without crossfading),
>> - another to play video files
>> - and a last one to manage soud files.
>> The package will also include a huge list of conversion tools taken
>> from my lpn collection.
>> I would be happy to participate in a common distribution if:
>> 1) there is no installer ( I want my students to learn who to load  
>> librairies)
>> 2) I can include my abstractions in it.
>> 3) There is an identical XP version.
>> I also hope to get funds from the CIAM (ciam-art.org) to try to:
>> - port (or install) a lot of stuff to all versions
>> - make a categorized inventory of PD objects in French and English
>> - make a French version of the documentation
>> Tom
>> On Fri, 25 Mar 2005 16:41:20 -0500, B. Bogart <ben at ekran.org> wrote:
>>> I had the same thought HC.
>>> I had no idea Tom has an installer. Why did you start Tom?
>>> PixelTANGO has a development installer but Its my intension to  
>>> integrate
>>> it into the unified dot app. I have not worked out exactly how to do
>>> this because it was much easier to kludge a pixelTANGO app based on  
>>> the
>>> pd 0.38 than it was to understand the .app build system that did not
>>> work for me.
>>> Anyhow I think for pixelTANGO to be easily integrated into the  
>>> unified
>>> .app that some slight changes may be required. I think it is very
>>> important that some folders are exposed to the user in /Applications.
>>> For dumping their own abstractions etc.. In the case of pixelTANGO we
>>> need exposed folders for:
>>> scripts
>>> models
>>> fonts
>>> abstractions
>>> Examples
>>> "Examples" could be moved into the PD help menu when we get that  
>>> sorted
>>> out. Abstractions would be useful for everyone. If an end-user wants  
>>> a
>>> new version of an external without reinstalling the .app it would  
>>> also
>>> be handy to keep an extra folder exposed in there. I don't think it  
>>> is
>>> resonable for the user to "show package contents". Fonts and Models  
>>> are
>>> somewhat pixelTANGO specific, so perhaps they could go somewhere
>>> pixelTANGO specific... Scripts will by the pixelTANGO py scripts  
>>> which
>>> need to be in the path. I guess these could just be dumped into the
>>> abstractions folder... Any opinion on this? It may also make more  
>>> sense
>>> to have a scripts folder with py included in the package.
>>> I did realize that one cannot link from a folder on the outside of  
>>> the
>>> pd.app to a folder inside it. So I had to add redundant folders  
>>> outside
>>> the PD.app that were included in the search-path.
>>> Right now pixelTANGO is structured as:
>>> /Applications/PixelTANGO/PixelTANGO-Examples
>>>                         /PixelTANGO.app
>>>                         /models
>>>                         /fonts
>>>                         /Gem-Examples
>>>                         /abstractions
>>> You can download the .app (with bugs) from:
>>> www.ekran.org/ben/research/PixelTANGO-v0.3.2G4.tgz
>>> This version does not have the python script stuff yet.
>>> Anyhow worth a look in terms of how folders outside the .app could  
>>> work.
>>> b>
>>> Hans-Christoph Steiner wrote:
>>>> It would be great if we could all join forces on the MacOS X  
>>>> Pd.apps.
>>>> There would be much less duplicated effort then, and a much better  
>>>> and
>>>> more up-to-date Pd.app available.
>>>> The code is all there, its poorly documented I will admit, but I  
>>>> will
>>>> definitely answer any questions about it.  And, of course, we  
>>>> encourage
>>>> anyone who has something to contribute to become a developer in the
>>>> SourceForge project.
>>>> As for the Help submenus, it was an incomplete effort, it definitely
>>>> needs work.
>>>> .hc
>>>> On Mar 24, 2005, at 7:31 PM, Paris Treantafeles wrote:
>>>>> thanks - i'm trying it out .
>>>>> -p-
>>>>> On Thursday, March 24, 2005, at 07:07  PM, Thomas Ouellet  
>>>>> Fredericks
>>>>> wrote:
>>>>>> I also have a packaged os x pd at :
>>>>>> http://data-art.uqam.ca/telechargement.php
>>>>>> I also tried Burt's but it did not work.
>>>>>> Tom
>>>>>> On Thu, 24 Mar 2005 18:34:23 -0500, Paris Treantafeles
>>>>>> <paris at parisgraphics.com> wrote:
>>>>>>> Hi,
>>>>>>> I just got around to installing this and was wondering if it  
>>>>>>> only  runs
>>>>>>> on 10.3?
>>>>>>> I am using OS X v 10.2.8 and can run previous pd mac version   
>>>>>>> pd-0.38-2
>>>>>>> but when i try to run this one nothing happens at all.
>>>>>>> Thanks,
>>>>>>> paris
>>>>>>> On Wednesday, March 16, 2005, at 01:39  PM, Burt wrote:
>>>>>>>> Greetings again,
>>>>>>>> I have posted a new version of an installer for OS X.
>>>>>>>> http://pcm.peabody.jhu.edu/~sburt/pd/installing_pd_os_x.html
>>>>>>>> Rob Lycett requested that I add the comport library and its
>>>>>>>> documentation, so I did.  I was also frustrated by tcl/tk  
>>>>>>>> handling  of
>>>>>>>> submenus within submenus.  If anyone knows how to do this,  
>>>>>>>> please  let
>>>>>>>> me know.  So, I placed the 7.stuff subdirectories directly into  
>>>>>>>> the
>>>>>>>> Help menu which is not elegant and only temporary.  I also  
>>>>>>>> added a
>>>>>>>> zexy submenu to Help (which I had previously forgotten).  So,  
>>>>>>>> now
>>>>>>>> there should be easy to find documentation on basic PD objects,  
>>>>>>>> the
>>>>>>>> libraries Gem, vasp, pmpd, Han's hid, and Zexy, plus everything
>>>>>>>> inside
>>>>>>>> the stuff folder including (now) comport.
>>>>>>>> I feel that a better way to organize the Help menu (with my
>>>>>>>> segregated
>>>>>>>> library approach) would be to do it with submenus for PD and  
>>>>>>>> major
>>>>>>>> libraries and an extra folder for smaller things:
>>>>>>>> PD Documentation/
>>>>>>>>    HTML manual/
>>>>>>>>    control examples/
>>>>>>>>    audio examples/
>>>>>>>>    fft examples/
>>>>>>>> Gem/
>>>>>>>> pmpd/
>>>>>>>> vasp/
>>>>>>>> zexy/
>>>>>>>> extras/
>>>>>>>>    hid/
>>>>>>>>    comport/
>>>>>>>>    stuff/
>>>>>>>>       audio playpen/
>>>>>>>>       data-structures/
>>>>>>>>       soundfile-tools/
>>>>>>>>       synth/
>>>>>>>>       tools/
>>>>>>>> Unfortunately, this would require a restructuring of PD   
>>>>>>>> documentation
>>>>>>>> as it is now, and I would have to understand how to create
>>>>>>>> submenus  in
>>>>>>>> submenus in tcl/tk.  Can anyone do this?  What would be really  
>>>>>>>> cool
>>>>>>>> would be to adjust the Pd script so that Help documentation of a
>>>>>>>> particular library does not appear until the library is loaded.  
>>>>>>>>   That
>>>>>>>> way, we avoid users opening help patches and getting messages  
>>>>>>>> about
>>>>>>>> objects not existing (or worse yet, PD crashing).
>>>>>>>> Samuel Burt
>>>>>>>> _______________________________________________
>>>>>>>> PD-list at iem.at mailing list
>>>>>>>> UNSUBSCRIBE and account-management ->
>>>>>>>> http://iem.at/cgi-bin/mailman/listinfo/pd-list
>>>>>>> _______________________________________________
>>>>>>> PD-list at iem.at mailing list
>>>>>>> UNSUBSCRIBE and account-management ->
>>>>>>> http://iem.at/cgi-bin/mailman/listinfo/pd-list
>>>>> _______________________________________________
>>>>> PD-list at iem.at mailing list
>>>>> UNSUBSCRIBE and account-management ->
>>>>> http://iem.at/cgi-bin/mailman/listinfo/pd-list
>>>> ____________________________________________________________________ 
>>>> ____
>>>> ____
>>>> "Computer science is no more related to the computer than astronomy  
>>>> is
>>>> related to the telescope."
>>>>                                                     -Edsger Dykstra
>>>> _______________________________________________
>>>> PD-list at iem.at mailing list
>>>> UNSUBSCRIBE and account-management ->
>>>> http://iem.at/cgi-bin/mailman/listinfo/pd-list


                     There is no way to peace, peace is the way.
										-A.J. Muste

More information about the Pd-list mailing list