[PD] Re: Mac OS X installer with library documentation
Hans-Christoph Steiner
hans at eds.org
Sat Mar 26 23:28:37 CET 2005
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.
Also, the 'abstractions' folder is more a place for things like
performances patches, complete patches that are meant to be used as
applications. Objects written in Pd, also called abstractions, are
basically like any other object, whether written in C, C++, Pd, etc.
(not quite, but we're getting there). So these kind of abstractions
would be in 'extra' or '~/Library/Pd/Externals'.
The reason why the Windows installer is so out of date is that I no
longer use Windows, so I don't maintain the Windows stuff anymore. We
need a Windows maintainer, my only desire when handing it over is that
the Windows distro be as 'Windows-like' as possible, much like what
we've done with the Pd.app for MacOS X. This means using an installer,
for example, with the standard "Next... Next... Finish". That's what
basically all Windows users expect.
The stated intention of the package maintainers is to make Pd distros
consistent across platforms. In order for this to happen, we need
build systems that work so that one person can easily compile for
multiple platforms. We also need to develop a versioning scheme for
the packages themselves.
We'd love to have anyone join the SourceForge project who wants to work
towards the common goals. That means working in the established ways
and if you think the established ways should change, getting agreement
from the developer community. This is generally not difficult since
there isn't not a lot of overlap between developers, most work on
distinct parts of Pd.
That's the overview, now I'll answer some specific questions...
.hc
On Mar 25, 2005, at 7:34 PM, B. Bogart wrote:
> Hey again Tom,
>
> Well pixelTANGO is not really an application... or is it? Being a
> collection of abstractions and externals (all of which are already in
> CVS) Indeed they all work together and are one unit... Maybe pixelTANGO
> has more in common with Gem than an Application. I guess the Gem stuff
> would not go in "applications"? /Applications/PD/Applications is also
> pretty confusing on OSX.
>
> The only problem with extra being inside pd.app is that the end user
> need to "open Package contents" and go messing around in there looking
> for extra, if they need to add thier own external. Personally I find
> this unpalletable.
>
> Good idea about the plist, but how does the settings file know where
> its
> relative to? (the pd binary?) so paths would be something like
> ../../Extra ?
>
> Good discussion!
>
> So I'm seeing three different and closely related problems here:
>
> 1. The organization of the "help" menu in PD.
> 2. The organization of the "doc" folder in PD
> 3. The organization of the folders in "Applications" or "Program Files"
>
> Of course in linux there is no #3... I guess this stuff would move into
> /usr/local/lib/pd ?? PixelTANGO fonts for example??
>
> BB.
>
> Thomas Ouellet Fredericks wrote:
>> I also agree on the need for the DOC, ABSTRACTIONS, APPLICATIONS
>> (where pixelTANGO could be) and EXTRA should be extracted form the
>> pd.app.
>>
>> Also it would also make a lot of things easier if the path settings
>> made in the PATH... window of Pure Data could be relative to pd.app
>> and not always absolute.
>>
>> Tom
>>
>>
>> On Fri, 25 Mar 2005 17:27:12 -0500, Thomas Ouellet Fredericks
>> <iamonthebeach at gmail.com> 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
>>>>>
>>>>
>>>>
>>>>
>>
>>
________________________________________________________________________
____
If you are not part of the solution, you are part of the problem.
- Eldridge Cleaver
More information about the Pd-list
mailing list