So I finally have some time to work on the next versions of the MacOS X Pd.app and I would like to get all of the video stuff integrated so its easy to use and we don't have constant endless threads about getting Gem/Gem2PDP/GridFlow/PDP/PIDIP working. I number of people expressed interest in helping with this, who all is still interested?
Here's what I think needs to be done: - pick one system to provide necessary libs for all (I think Fink works best for this) - the package needs to be compilable from lines in a Makefile (This makes complete automation possible) - the code should be in the Pd CVS (This also makes automation much easier. It looks like PDP/PIDIP/GEM2PDP are already there, I don't know where GridFlow is and ideally Gem could be moved back to the Pd CVS since it only really works with Pd anyway)
For the long run, it would be ideal if all of the objects in the video libs were compiled as individual files. This makes it much easier for newbies since they you don't have to deal with the .pdrc at all, plus it makes handling name conflicts much easier (there are some in Gem for example).
.hc
________________________________________________________________________ ____
There is no way to peace, peace is the way. -A.J. Muste
On Jun 16, 2004, at 10:39 PM, Hans-Christoph Steiner wrote:
Here's what I think needs to be done:
- pick one system to provide necessary libs for all (I think Fink works best for this)
- the package needs to be compilable from lines in a Makefile (This makes complete automation possible)
- the code should be in the Pd CVS (This also makes automation much easier. It looks like
PDP/PIDIP/GEM2PDP are already there, I don't know where GridFlow is and ideally Gem could be moved back to the Pd CVS since it only really works with Pd anyway)
Is this list for the requirements for the package maintainers or for end users of the package?
For GEM the suggestions break down like this:
Fink - I have never used Fink at any stage of building GEM - it's not necessary.
Makefiles - Anyone is welcome to construct a makefile build system, but the binaries are more than adequate in my view. The projectbuilder project is often out of date, but only three people use it regularly and, to the best of my knowledge, only two others have ever built it (or even inquired about building it) on OSX.
CVS - What would be the reason for moving it? We have a nice little setup as it is and if someone wants to contribute then they just need to contact Johannes.
I would suggest that the people involved in this project focus on producing a very stable and well tested binary release rather than worry about fancy automated builds and continually tracking down the proper libs. To that end I would make the following list:
- Only use libs included with the stock version of the target OS or statically link all non-standard libs. This will help ensure the widest compatibility among potential users. One of the strong points about developing for the Mac is the consistency among software and hardware configurations, so it's best to take advantage of that.
- The end product should be a double click and run binary like just about every other OSX app in existence. There should be no tinkering around in /usr/ or editing of config files required.
- The version issued to the public should be as stable as possible. This means no random builds out of CVS, but rather highly tested point release builds that have had a reasonable degree of feedback and reports from end users.
Ok that's my take.
cgc
hi all!
Makefiles - Anyone is welcome to construct a makefile build system, but the binaries are more than adequate in my view. The projectbuilder project is often out of date, but only three people use it regularly and, to the best of my knowledge, only two others have ever built it (or even inquired about building it) on OSX.
CVS - What would be the reason for moving it? We have a nice little setup as it is and if someone wants to contribute then they just need to contact Johannes.
me too, i do not see any convincing reason to transfer the CVS from pd-gem back to pure-data. we could do some mirroring like thomas grill, though.
as for makefiles, i don't have any objections at all (i even would like it, as i could do remote-builds) but have no time (to gain knowledge) to do it myself.
mfg.asdf.r IOhannes
On Wed, 16 Jun 2004, Hans-Christoph Steiner wrote:
(This also makes automation much easier. It looks likePDP/PIDIP/GEM2PDP are already there, I don't know where GridFlow is and ideally Gem could be moved back to the Pd CVS since it only really works with Pd anyway)
I had to reinstall GridFlow's CVS for some reason and I'm not finished yet. I'll mirror GridFlow to Pd's CVS whenever I release version 0.7.7.
For the long run, it would be ideal if all of the objects in the video libs were compiled as individual files. This makes it much easier for newbies since they you don't have to deal with the .pdrc at all, plus it makes handling name conflicts much easier (there are some in Gem for example).
I reiterate that this is not possible with GridFlow, as it all goes thru something that we could call "rubyext" (that's all gridflow.pd_linux is, after all)
________________________________________________________________ Mathieu Bouchard http://artengine.ca/matju
For the long run, it would be ideal if all of the objects in the video libs were compiled as individual files. This makes it much easier for newbies since they you don't have to deal with the .pdrc at all, plus it makes handling name conflicts much easier (there are some in Gem for example).
I find libraries are also very convenient because otherwise the number of objects becomes unmageable. if you don't want to deal with .pdrc, you can make a startup script like:
for i in `find $LIBS_DIR -name *.pd_darwin` do export LIBS=$(basename $i .pd_darwin):$LIBS done
and later
pd -lib $LIBS
this allows also to organize libraries in subfolders (also usefull for objects and abstractions)
. g
Hallo, 0001 hat gesagt: // 0001 wrote:
I find libraries are also very convenient because otherwise the number of objects becomes unmageable. if you don't want to deal with .pdrc, you can make a startup script like:
for i in `find $LIBS_DIR -name *.pd_darwin` do export LIBS=$(basename $i .pd_darwin):$LIBS done
and later
pd -lib $LIBS
this allows also to organize libraries in subfolders (also usefull for objects and abstractions)
Nice idea, although a similar approach would be possible for external directories. Still you didn't solve the nasty name clash problem. Some libraries like Gem and IEM contain name clashes for a long time now...
Ciao
Still you didn't solve the nasty name clash problem. Some libraries like Gem and IEM contain name clashes for a long time now...
true, this doesn't look easy. it'd be nice to fix the code though, especially if its in the CVS. anyway organizing objects in a directory tree may help
. g
-
0001 -
chris clepper -
Frank Barknecht -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Mathieu Bouchard