[PD-dev] including [dssi~] in Pd-extended
Jamie Bullock
jamie at postlude.co.uk
Tue Feb 28 11:04:59 CET 2006
Hi,
On Tue, 28 Feb 2006 08:31:00 +0100
Frank Barknecht <fbar at 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
More information about the Pd-dev
mailing list