[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