Hi,
On Tue, 28 Feb 2006 08:31:00 +0100 Frank Barknecht fbar@footils.org wrote:
<snip>
externals/grill GemLibs externals/hcs/hid/linux/input.h externals/hcs/hid/HID Utilities Source externals/gridflow externals/sc4pd/source iemlib/src/iem_mp3
I cannot find much that is not Pd-related there. flext is not importing sndobj and stk, gridflow is not mirroring Ruby, SC4Pd is not the same as Supercollider and Gem doesn't include Quicktime.
Take for example the Csound repository: To build e.g. the fluidsynth-opcodes, Csound expects to find the fluidsynth sources or a symlink in a certain place. However the fluid-sources are not duplicated into the CVS, no parallel version of fluidsynth is created. Instead the package maker is responsible for doing so and if the sources aren't there, the opcodes will not be built.
I think this approach is fine for PD/Csound 'programmers' (i.e. people who actually use the software to write patches). I don't think it is acceptable for people who are just 'end users' (e.g. musicians, curators) to build these things from source.
I think the answer here is to either urge DSSI(/LADSPA) plugin developers to periodically release binary versions of their plugins, and/or for me to maintain a selection of examples outside of the CVS - perhaps on the puredata site. The latter option can happen straight away since I already have FluidSynth-DSSI and Hexter compiled for OS X. Dependencies could be handled simply by copying the relevant libs to the 'expected' locations if they are not already there. By dependencies, I just mean things like liblo, not GTK+OSX, which is already available in 'easy' binary form.
I am not so bothered about Linux, because there are already integrative solutions(like PlanetCCRMA) available that include these things in a more elegant way.
Jamie