I often use GEM object like [alternate] and [oneshot] in all sorts of patches, but I don't always have GEM installed on all the machines I work on (esp on Debian since pd-gem isn't apt-gettable AFAIK). So I was thinking that it might make sense to move the general objects in GEM (most of the ones in src/MarkEx) to the pure-data.sf.net CVS so that they can be included as part of the pd-externals grand package of all externals than don't have lib dependencies. This would also make sense since the rest of GEM has lots of dependencies.
I'll do the work of putting them in to pure-data CVS, under markex, if people think this is worthwhile. It looks like every object in src/MarkEx except hsvrgb are free of anything but the most basic deps (<math.h>, <stdio.h>, <stdlib.h>)
This would also have the added benefit of dealing with two name conflicts [counter] and [change].
.hc
zen \ \ \[D[D[D[D
This makes a lot of sense to me in the long run.
Mark, why was markEx merged into Gem originally?
Ben
Hans-Christoph Steiner wrote:
I often use GEM object like [alternate] and [oneshot] in all sorts of patches, but I don't always have GEM installed on all the machines I work on (esp on Debian since pd-gem isn't apt-gettable AFAIK). So I was thinking that it might make sense to move the general objects in GEM (most of the ones in src/MarkEx) to the pure-data.sf.net CVS so that they can be included as part of the pd-externals grand package of all externals than don't have lib dependencies. This would also make sense since the rest of GEM has lots of dependencies.
I'll do the work of putting them in to pure-data CVS, under markex, if people think this is worthwhile. It looks like every object in src/MarkEx except hsvrgb are free of anything but the most basic deps (<math.h>, <stdio.h>, <stdlib.h>)
This would also have the added benefit of dealing with two name conflicts [counter] and [change].
.hc
zen \ \ \[D[D[D[D
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
Ben Bogart wrote:
This makes a lot of sense to me in the long run.
Mark, why was markEx merged into Gem originally?
(being not Mark, but i think:) because it was easier: some of the example-patches depend on markEX, and it would have been very complicated if you had to get another library. But of course: markEX is not really Gem, and it certainly makes sense to put it into some separated space (like the CVS, although i don't think, lot's of people will continue development for markEX (?)) But then: should i remove markEX from Gem ? (again the problem with the help-patches)
mfg.ad.r IOhannes
On Mon, 28 Apr 2003, IOhannes zmoelnig wrote:
Ben Bogart wrote:
This makes a lot of sense to me in the long run.
Mark, why was markEx merged into Gem originally?
(being not Mark, but i think:) because it was easier: some of the example-patches depend on markEX, and it would have been very complicated if you had to get another library. But of course: markEX is not really Gem, and it certainly makes sense to put it into some separated space (like the CVS, although i don't think, lot's of people will continue development for markEX (?)) But then: should i remove markEX from Gem ? (again the problem with the help-patches)
There would be a small amount of pain in the move, but I think that the CVS externals collection isn't really a lib anymore, but a standard part of a distro, especially since it now compiles on Linux, MacOS X and Windows. Its also already package-ized for Linux and MacOS X, and Windows shouldn't be too hard to do.
I have a dream of all external objects without lib deps in one easy to install package on all platforms. We are well on the way to this being a reality.
.hc
zen \ \ \[D[D[D[D
-
Ben Bogart -
Hans-Christoph Steiner -
IOhannes zmoelnig