This is true that its difficult for the user to know what library a particular object is from, unless they were taught a particular library. (gem/pdp objects are generally easy to recognize)

Do you have an example on how this could be organized?

Part of the lib-centric approach was that it would be very easy for the makefiles, since they just need to create a directory of the libs name in a correct place and thats it. How I guess the same goes for putting stuff in a directory containing objects of a certain class... as long as we all agree on what catagories each lib/object belongs to. for example the whole class of experimental algorithms.. Control yes.. but something special as well. (chaos, PSO, ANN, etc..)

Maybe something like:

Manual Control-Examples (includes zexy control objects) Audio-Examples/ (includes zexy audio objects) Playpen/ Soundfile-Tools/ Synth/ Sound-Files/ (ALL included WAV files.) FFT-Examples Data-Structure-Examples Visual-Examples/ Vector (includes Gem) Pixel (includes PDP, PiDiP, framestien (alive?), Physical-Modeling-Examples (pmpd, dyn~ ?) Object-Reference/ Control/ Audio/ FFT/ Data-Structures/ Visual-Vector/ Visual-Pixel/ Physical-Modeling Writing-Externals

Or if help-* becomes *-help then Object reference could all be flat without submenus/subdirs.

What this approach implies is the integration of functionality into a more cohesive form. Sections for types of interaction.. Vector vs Pixel is problematic but having all the visual objects in one directory/menu is probably too confusing... To make this work the relationship between libraries needs more consideration. (how PDP relates/overlaps with Gem and framestein etc.. Maybe this could be discussed tonight on IRC. (but I'll have only a little time.)

I think we're getting somewhere! Thanks for the feedback HC.

One sticky point may be author recognition. Each library has its own name and identity and organizing them outside of that name may irk some people.

B>

Hans-Christoph Steiner wrote:

I definitely agree that the docs directory structure needs to be reorganized, but I don't think that it should be based on the libraries. If there is going to be some hierarchy, I think it should be based on object functionality instead. That is a much more intuitive way to navigate for help.

.hc

On Mar 16, 2005, at 4:12 PM, B. Bogart wrote:

...

Hey all,

I proposed a few things on pd-dev a while back.

I think we really do need to revaluate the doc/ structure and make it standard.

I think the best solution for the help menu is to have the hierarhcy generated directly from the directories in the doc/ folder. The build scripts will put the reference/docs in standard places, and when those are installed they will automagically come up in the help menu.

Your structure is very similar to my ideas, except I'm unclear why "extras" are separate from "libs" I'm not sure if they is less confusing to the end user.

Also the "stuff/" catagory is confusing, and seems a little too organized without being clear "audio playpen" what does that mean? Where does this stuff comefrom? I'm guessing its not in PD docs, from CVS perhaps? Oh! I just looked and it is in PD! I did not realize all that new stuff was in there. I still think the organization leaves a bit to be desired.

I'll note here also that the "help-*" name format is damn ugly when you see the 5.reference folder in the pull-down menu. (and you can't jump to a certain entry because everything starts with "h") The jump-to thing works fine on OSX, 38-2 tcl 8.4.9, how about on ther platforms?

So what if the "doc" PD folder looks like:

Manual Control-Examples Audio-Examples/ Playpen/ Soundfile-Tools/ Synth/ Sound-Files/ (ALL included WAV files.) FFT-Examples Data-Structure-Examples Gem-Examples pmpd-Examples zexy-Examples iemlib-Examples PiDiP-Examples Object-Reference/ Gem/ pmpd/ zexy/ iemlib/ PiDiP/ . . . Writing-Externals

"reference" is very different from the other catagories, so I think it should not be bundled with the rest. Also 6.externs is more code examples than documentation, so that should not be visible in the PD menu and have a more descriptive name. Same goes for the "sound" folder that should be inside "audio" and/or have a more descriptive name. X.wav should also be moved to this folder. Stuff like "audio-playpen" should be in "audio examples" if needbe perhaps in a "toys" subfolder. Same goes for soundfile-tools and "synth". This should be integrated into the audio Examples. I'm not sure what to do with "tools" Maybe these should be in a separate PD pull-down menu next to help, since they are really not "help" nor documentation for that matter. "Tools" left of "Help". "Object reference" will contain the help files for all EXTERNALS in the format of *-help.pd. LIBS will have thier own directory in "Object Reference" with the name of the lib.

Which generates a cascading menu that looks like:

Manual Control-Examples Audio-Examples FFT-Examples ------------ <- seperator Gem-Examples pmpd-Examples zexy-Examples iemlib-Examples PiDiP-Examples

---

Object-Reference

I can work on doing the code for this but we absolutly need a better standard for where all this stuff goes first, so that we can have the help menu generated from the doc/ directory dynamically. Only those externals/libs installed will be included in the menu.

I'll wait for the discussion before I start working on this...

Feedback?

B>

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@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list

---

---

              ¡El pueblo unido jamás será vencido!

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list

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@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@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list

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@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@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://iem.at/cgi-bin/mailman/listinfo/pd-list

---

PD-list@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

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@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@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@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list

---

PD-list@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@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list

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@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@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@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@iem.at mailing list >>UNSUBSCRIBE and account-management -> >>http://iem.at/cgi-bin/mailman/listinfo/pd-list > > >_______________________________________________ >PD-list@iem.at mailing list >UNSUBSCRIBE and account-management -> >http://iem.at/cgi-bin/mailman/listinfo/pd-list >

---

PD-list@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@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list

A relative path would be great, I don't think anyone is opposed to
having this functionality, I think its only a matter of someone
implementing it. I know I'd like it. IIRC, Frank was leading an
effort to work on that, but more on the abstraction-level.

.hc

On Mar 25, 2005, at 5:31 PM, 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@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@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@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@iem.at mailing list >> UNSUBSCRIBE and account-management -> >> http://iem.at/cgi-bin/mailman/listinfo/pd-list > > > _______________________________________________ > PD-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://iem.at/cgi-bin/mailman/listinfo/pd-list >

---

PD-list@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@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list

"Looking at things from a more basic level, you can come up with a more
direct solution... It may sound small in theory, but it in practice, it
can change entire economies."

 - Amy Smith

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.

.hc

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@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@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@iem.at mailing list >> UNSUBSCRIBE and account-management -> >> http://iem.at/cgi-bin/mailman/listinfo/pd-list > > > _______________________________________________ > PD-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://iem.at/cgi-bin/mailman/listinfo/pd-list >

---

PD-list@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@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

I totally agree that namespace pollution is a real problem that we
should strive to control. This can be done while also including
everyone's objects without changing the way Pd currently operates.

If we have the core objects directly in the standard path (../extra),
then we can have the various additions in subfolders of that path. As
long as the objects are compiled as individual files, they can be
instantiated separately. A while back, I posted an example of this
using various [prepend]s. It was like this: [object_name], [subfolder/object_name], [subfolder2/object_name]. All
of these were different versions of "object_name" running in the same
patch. The only problem here (AFAIK) is the help file namespace, and
there is probably a way around that.

So we could do this with vast amount of objects sorted into various
extra categories, like 'deprecated' (and even things like
'deprecated/gem'), 'contrib' (a free-for-all location), 'cyclone'.
Also, we can do things like 'cxc', 'grill', 'iem', and 'ggee' for the
various versions of [prepend].

I plan on trying this with the next Pd.app that I build.

.hc

On Mar 28, 2005, at 10:29 AM, Krzysztof Czaja wrote:

hi Hans,

the real problem is namespace pollution. Just imagine people's anger, when their patches are broken by someone adding yet another little odd external to cvs build system, and the name they have chosen for their abstraction changes meaning without even a slightest warning.

The predefined set should not exceed a few hundred names, with every addition carefully thought out and clearly advertised. Otherwise, Pd will grow into an unmaintainable, amorphous monster, that collapses under its own weight.

All predefined classes should have their functionality cast in stone. Everything else should be explicitly declared for a patch.

The actual evil are not libraries, but using the "-lib" option, and likewise the "-path" option, as Pd's name resolution mechanism.

Krzysztof

Hans-Christoph Steiner wrote:

...

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

"If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an
idea, which an individual may exclusively possess as long as he keeps
it to himself; but the moment it is divulged, it forces itself into the
possession of everyone, and the receiver cannot dispossess himself of
it."

                                                 - Thomas Jefferson

On Wed, 30 Mar 2005, Krzysztof Czaja wrote:

PPS. Explicit use of GG's qualifiers is ugly and takes too much space. Some kind of abstraction-scoped "import" mechanism would be necessary, anyway ([declare]?).

Hi,

I have an external lying around called [using], which implements the scoping on a global level. I agree that having it per abstraction would be better. I think Krzysztof's analysis of the technical problems is to the point, nothing that can't be solved, but to make it consistent for all types of externals and libraries we would need some changes. Anyhow, as the scoping problem exists for abstractions too, it would be a good idea to solve this inside Pd some day, with [declare], [using] [import] or whatever it will be called.

Guenter

All of this stuff should be thought of in the same way as other parts
of Pd: a part of the app itself, and not meant to be user editable. I
have been thinking that we need to have a section of included
abstractions that are not meant to be help or tutorials, but functional
programs written in Pd. We need to think of how best to incorporate
this. Maybe it would make the most sense to have this stuff in a
folder outside of the app, like a standard distro of apps built with
Pd.

As for figuring out the .app build system, I am now done with my
Masters thesis, so I have breathing room to answer all your questions
and develop documentation for this build system so more people can use
it and contribute to it. I am also planning a big crunch working on
my big TODO list for Pd and the Pd.app in particular.

.hc

On Mar 25, 2005, at 4:41 PM, B. Bogart 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@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@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list

---

PD-list@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@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list

        "The arc of history bends towards justice."
                                                           Dr.  

Martin Luther King, Jr.

hi

make an alias while it's visible thanks to tinkertool. when you hide it again you'll still be able to see the alias

cheers rene.

&gt;From: Nicholas Ward &lt;nicholas.ward@cs.tcd.ie&gt; &gt;To: pd-list@iem.at &gt;Subject: [PD] simple annoyance in OS X &gt;Date: Mon, 28 Mar 2005 20:31:06 +0100 &gt; &gt;Hi. Just a quick OS X annoyance Im trying to sort out. Ive installed &gt;PD in /usr/local/lib/pd. All runs fine but if i want to open a patch &gt;that is in say /usr/local/lib/pd/examples/ from within pd using &gt;file open I cant see the folder usr. I used tinker tool so I can &gt;see the folder from finder but I cant see it from with in PD. &gt; &gt;Is there a fix for this. &gt; &gt;Thanks all &gt; &gt;nicky &gt; &gt; &gt;_______________________________________________ &gt;PD-list@iem.at mailing list &gt;UNSUBSCRIBE and account-management -&gt; &gt;http://iem.at/cgi-bin/mailman/listinfo/pd-list