Max Neupert wrote:

hi list, james,

i've put the gem.pd_darwinCVS.tar from your site in extras (replaced

you shoud untar the file you downloaded (pd is looking exactly for Gem.pd_darwin if you try to load Gem)

the old one), but it still tells me at startup: GEM: Graphics Environment for Multimedia GEM: ver: 0.90 release GEM: compiled: May 25 2004 ... how do i know if i have the CVS version now or still the old one - and if it's the old one from where does it come?

add "-verbose" the the startup-flags.

fmg.asdr IOhannes

hey max,

On Oct 23, 2005, at 8:12 AM, Max Neupert wrote:

i've put the gem.pd_darwinCVS.tar from your site in extras
(replaced the old one), but it still tells me at startup: GEM: Graphics Environment for Multimedia GEM: ver: 0.90 release GEM: compiled: May 25 2004 ... how do i know if i have the CVS version now or still the old one -
and if it's the old one from where does it come?

...actually, this is my oversight: the gem.pd_darwinCVS.G4.tgz on my
site is incredibly old, so I wouldn't bother with it...if you want
the current gem.pd_darwin from cvs, it is available inside the pd++-. 39-1Beta.tgz application package: just right click (or ctrl-click)
the app, select "show package contents", then navigate to Contents/ Resources/extra and you'll find Gem.pd_darwin, among other
things...but remember that this particular one is compiled for 10.4.x
(I currently don't have a machine running less, and also don't have
the time to set up an "sdk" compile)...

good luck, james

I beg to differ.

I must say that after doing a lot of annoying copying and shifting and
all that, that the semisimplicity of Hans' installer has been wonderful. And
because I just tried PixelTango, I was impressed that even more things are
installed automagically.

It would, however, be good to have instructions of how to update easily.

cheers,

tim

On Oct 24, 2005, at 9:24 AM, Lorenz Schori wrote:

hi hans & james, hi list

i appreciate the efforts you two do for packing pd for osx.
pd-extended really helped me to jump into pd a little while ago.
however allow me to give some comments:

1. the osx package is not the right place for externals. i suggest

using standard "Library/Application Support" directory. 2. it does not make much sense to distribute all externals together.
while it is okay for standard ones (the ones in the build system),
pdp, gem, flext and other complex packages will likely have to be
updated/changed in closer intervals. i propose to just provide pd core with standard externals (identical
to millers distribution) + better tcl/tk, packing only externals and
tell the user to install those into the right place. then a simple
install script wrapping "defaults write" (as a suggested before) would
make sure that the path and lib settings in pd point to the right
place. i did not look into the documentation mechanism of pd, so i
think there will be the real problem of my approach.

comments welcome.

cheers lorenz

Am 24.10.2005 um 06:24 schrieb Hans-Christoph Steiner:

...

Lots of good fixes, thanks Jamie. I'll be incorporating them into
the main build system soon. Some comments:

• When I use the Help->Browser menu, it seems to be copying a ton of

files each time I use the menu. I know that Miller introduced this
hack for Mac OS X with 0.39, but it seems to have gone wild with
pd++.

• It runs for me on 10.3.9, including Gem, but I can't get the new

Gem window behavior to work. For me, its still the old-style,
Cmd-click to move and never gain focus.

• can you post how you compiled pdp/pidip somewhere? Ideally, I

think we'd import a stable version of pdp into the CVS (currently, it
seems to be pdp 0.12.2) so this could become part of the standard
build system.

.hc

On Oct 21, 2005, at 12:37 PM, james tittle wrote:

...

http://homepage.mac.com/tigital

...in the puredataStuff directory there is an archive containing
pd++0.39-1Beta.tgz...this is built in a similar way to Hans'
releases, but includes a ton of fixes, such as:

• the flext system is now working, but only xsample/dyn~/pool

included atm

• uses tcl/tk 8.4.10
• 10.4.x only, as far as I can tell
• pdp 0.12.4 & pidip 0.12.19 both included (static linked libs)!

mainly used via the pdp/gem bridges, but [pdp_glx] should also
work...also don't forget [pdp_ieee1394] for video input, with fixes
(more to come)

• pdp2gem, gem2pdp, pix_2pdp
• latest gem, zexy, miXed, cyclone cvs
• gem window is now "frontable", so it [gemmouse] works (and it

generally behaves like a real window should)

• tons of externals from cvs: I'll try to produce a list

...comments welcome! Especially interested to see if this fixes
some "slow interface" problems people have complained about of
late...

l8r, james

ps: as soon as I can sort out a problem with scons, devel_0_39 will
be available (and of course desiredata after that!)

---

PD-announce mailing list PD-announce@iem.at http://lists.puredata.info/listinfo/pd-announce

---

---

                        http://at.or.at/hans/

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list

----- Tim Boykett TIME'S UP::Research Department \ / Industriezeile 33b A-4020 Linz Austria X +43-732-787804(ph) +43-732-7878043(fx) / \ tim@timesup.org http://www.timesup.org

http://www.timesup.org/fieldresearch/setups/index.html

Hello,

I second that. I wanted to install Pd. It's already quite hard to
find which package to install over another one. Moreover, coming from
Max/MSP, it's quite difficult to figure what is installed with
package. Then, a extra "external folder" would be nice, especially
when you need to update some externals, indeed.

Julien.

Le 24 oct. 05 à 09:45, Lorenz Schori a écrit :

hi tim

it is certainly not the goal to make things more complicated nor to
include less stuff. what i propose is just to move the externals
out of the package into a more accessible, managable and natural
(for osx users) place, plus to modularize externals a bit (standard/ gem/pdp/flext/...). this way it will be easier to upgrade pd and
different external packages independantly from each other.

lorenz

Am 24.10.2005 um 09:40 schrieb Ti Bo:

hi

different pd versions: actually i wonder how pd/linux deals with this
problem. does msp version look into other paths as devel? are they
configured at runtime? i thougth about an additional standard path in
osx determined at compile time from the version information (like "~/ Library/Application Support/Pd/0.39-msp/extra" + "~/Library/ Application Support/Pd/0.39-msp/doc"). fink: i think it would be easy to just pack debians and throw it into
fink. for advanced users (with several pd versions/flavours) this
would be fine. however the advantage of the pd.app is that pd files
get double-clickable on desktop and messing around with the command
line will not be nessesary. i think for most osx users it would be
comfortable to just link the externals statically with the requred
libraries. flext: i don't know if this is possible and i'm not sure if this
makes sense: how about just linking flext statically into pd binary?
if i have to compile flext for each pd version/flavour anyway i don't
see a drawback to just include it (appart from eventual stability
issues).

lorenz

Am 24.10.2005 um 17:33 schrieb Frank Barknecht:

Hallo, Lorenz Schori hat gesagt: // Lorenz Schori wrote:

...

it is certainly not the goal to make things more complicated nor to include less stuff. what i propose is just to move the externals out of the package into a more accessible, managable and natural (for osx users) place, plus to modularize externals a bit (standard/gem/pdp/ flext/...). this way it will be easier to upgrade pd and different external packages independantly from each other.

But is there a way to handle dependencies as cleanly as e.g. Debian does it? For example you would need different flext packages for pd-devel and ps-MSP, IIRC. Some externals which use private headers may need to be recompiled for a a new upstream version. With a single package it is easy for Mac users to get matching versions of everything.

I guess it would be the best to get in contact with the Fink team and provide regular Fink packages of Pd and Pd externals?

Ciao

Frank Barknecht _ ______footils.org_ __goto10.org__

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list

The point of the way that the Pd.app is structured now is that you are
not supposed to edit it at all. You make all of your additions to
folders like ~/Library/Application Support/Pd/Externals and
~/Library/Application Support/Pd/Doc. That way you can upgrade Pd
without messing with your setup, among other advantages.

This has been discussed in the past a far amount. If you are
interested, I suggest checking out the archives.

Also, in my next release, I'll be enabling the new Plugins management
feature that you'll see in the Info panel of the Pd.app.

.hc

On Oct 24, 2005, at 1:13 PM, Lorenz Schori wrote:

hi

different pd versions: actually i wonder how pd/linux deals with this
problem. does msp version look into other paths as devel? are they
configured at runtime? i thougth about an additional standard path in
osx determined at compile time from the version information (like
"~/Library/Application Support/Pd/0.39-msp/extra" +
"~/Library/Application Support/Pd/0.39-msp/doc"). fink: i think it would be easy to just pack debians and throw it into
fink. for advanced users (with several pd versions/flavours) this
would be fine. however the advantage of the pd.app is that pd files
get double-clickable on desktop and messing around with the command
line will not be nessesary. i think for most osx users it would be
comfortable to just link the externals statically with the requred
libraries. flext: i don't know if this is possible and i'm not sure if this makes
sense: how about just linking flext statically into pd binary? if i
have to compile flext for each pd version/flavour anyway i don't see a
drawback to just include it (appart from eventual stability issues).

lorenz

Am 24.10.2005 um 17:33 schrieb Frank Barknecht:

...

Hallo, Lorenz Schori hat gesagt: // Lorenz Schori wrote:

...

it is certainly not the goal to make things more complicated nor to include less stuff. what i propose is just to move the externals out of the package into a more accessible, managable and natural (for osx users) place, plus to modularize externals a bit (standard/gem/pdp/ flext/...). this way it will be easier to upgrade pd and different external packages independantly from each other.

But is there a way to handle dependencies as cleanly as e.g. Debian does it? For example you would need different flext packages for pd-devel and ps-MSP, IIRC. Some externals which use private headers may need to be recompiled for a a new upstream version. With a single package it is easy for Mac users to get matching versions of everything.

I guess it would be the best to get in contact with the Fink team and provide regular Fink packages of Pd and Pd externals?

Ciao

Frank Barknecht _ ______footils.org_ __goto10.org__

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list

"[W]e have invented the technology to eliminate scarcity, but we are
deliberately throwing it away to benefit those who profit from scarcity."

    -John Gilmore

I see little advantage to this complexity. Why do you need to update
only parts of the Pd.app? Why not just download a whole new Pd.app?
Bandwidth is cheap enough these days. Having a build that has
consistent versions of the various bits of code that are known to work
with each other is huge.

If someone really needs such a specifically tailored Pd.app, it would
be easy enough for them to do it themselves by copying the *.pd_darwin
files into place.

.hc

On Oct 30, 2005, at 9:55 AM, B. Bogart wrote:

Hey all,

I've finally gotten to this thread.

Anyhow I think Lorenz's proposal of having multiple packages does make sense for upgrading, but there is still something to be said for the ease of installation with everything included. For example my pixelTANGO.app (which will be part of the main release eventually) is messed up once and a while because people don't read the instructions
to drag and drop the directory and the plist file.

If the .app was totally modular then it would make the installation
that much worse, to install say 4 packages to get a fully loaded pd as
before.

Mind you if we could combine the OSX pkg and mpkg stuff with the .app then we may be able to do something where there is a single
installation that installs all the required modules automagically (extra externals, flext pdp etc..) and still being easy for the user. This would be back to an installer though, which simply includes a .app.

Then in the future one (correct me if I'm wrong) upgrade say only the flext external modules, only Gem, only the CVS externals seperatly... Maybe even reinstalling PD itself but using the old externals. (if possible).

Until there is a ppc pure::dyne (I'm not holding my breath) seems the .app is the best way to get people into PD as fast and painless as possible.

.b.

Lorenz Schori wrote:

...

hi

different pd versions: actually i wonder how pd/linux deals with this problem. does msp version look into other paths as devel? are they configured at runtime? i thougth about an additional standard path in osx determined at compile time from the version information (like "~/ Library/Application Support/Pd/0.39-msp/extra" + "~/Library/
Application Support/Pd/0.39-msp/doc"). fink: i think it would be easy to just pack debians and throw it into fink. for advanced users (with several pd versions/flavours) this
would be fine. however the advantage of the pd.app is that pd files get double-clickable on desktop and messing around with the command line will not be nessesary. i think for most osx users it would be comfortable to just link the externals statically with the requred libraries. flext: i don't know if this is possible and i'm not sure if this
makes sense: how about just linking flext statically into pd binary? if i have to compile flext for each pd version/flavour anyway i don't see
a drawback to just include it (appart from eventual stability issues).

lorenz

Am 24.10.2005 um 17:33 schrieb Frank Barknecht:

...

Hallo, Lorenz Schori hat gesagt: // Lorenz Schori wrote:

...

it is certainly not the goal to make things more complicated nor to include less stuff. what i propose is just to move the externals out of the package into a more accessible, managable and natural (for
osx users) place, plus to modularize externals a bit (standard/gem/pdp/ flext/...). this way it will be easier to upgrade pd and different external packages independantly from each other.

But is there a way to handle dependencies as cleanly as e.g. Debian does it? For example you would need different flext packages for pd-devel and ps-MSP, IIRC. Some externals which use private headers may need to be recompiled for a a new upstream version. With a single package it is easy for Mac users to get matching versions of everything.

I guess it would be the best to get in contact with the Fink team and provide regular Fink packages of Pd and Pd externals?

Ciao

Frank Barknecht _ ______footils.org_ __goto10.org__

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list

"[W]e have invented the technology to eliminate scarcity, but we are
deliberately throwing it away to benefit those who profit from scarcity."

    -John Gilmore

On Nov 1, 2005, at 6:03 PM, james tittle wrote:

On Nov 1, 2005, at 5:19 PM, derek holzer wrote:

...

still no Jack support in this one? Funny thing is, even without Jack
running, and no -jack startup flag, I still get no sound and the
following:

...yup, no jack support in thar, but I'll see about adding it soon...

...

unknown API audio I/O stuck... closing audio

sys_close_audio: unknown API 5

Nothing gets audio running as far as I can see. Let me know if you
need any particulars beyond the fact that I'm running 10.4.

...what kind of audio device are you using? I've noticed that the
audio settings don't necessarily stick between sessions, so have you
tried turning on the audio output via the preferences/audio setup
menu, after startup?

...I also should mention that there are real problems with 0.39-1 and
shutting down: it won't shutdown properly for me, but hangs and I
have to ctrl-c out, which usually leaves a zombie pd process going
(with midiserver), which I've found it's really necessary to kill that
before launching again, because it's otherwise inviting trouble...

...so, maybe tonight I'll be able to scrap together another app pkg
with jack and 0.39-0 (which doesn't exhibit the above probs)...

Check out my patch in the tracker, it fixes the build stuff to include
Jack as an optional dependecy (aka weakly linked). Unfortunately,
Miller declined to include that part of the patch.

.hc

Man has survived hitherto because he was too ignorant to know how to
realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos
Williams