[PD-dev] including [dssi~] in Pd-extended
hans at eds.org
Mon Feb 27 06:08:45 CET 2006
On Feb 23, 2006, at 4:04 AM, Jamie Bullock wrote:
> Hi Hans,
> On Wed, 22 Feb 2006 14:11:22 -0500
> Hans-Christoph Steiner <hans at eds.org> wrote:
>> First off, I recommend against making an esoteric Pd version. We
>> all be better off if we all work on one distro. If you need to
>> some libs in the main distro, that can be arranged, and is already
>> happening on all platforms.
> I agree about working on one distro, but once you know the details,
> you may not want my changes in PD-extended.
> Firstly, I haven't modified the PD build itself, I just used your
> RC7 build.
> I have stripped out all of the documentation, libs and externals to
> reduce the file size (although this was probably a dubious thing to
> do, and not strictly necessary).
Um, yeah, I wouldn't agree with that ;)
> I then added:
> - my [dssi~] external.
Yay! no problem there. Also, I'd like to help you to move your
makefile to externals/Makefile. I can do the work if you want. Then
it'll be automatically included in Pd-extended, and compile on GNU/
Linux, Mac OS X, and Win32.
> - FluidSynth-DSSI and hexter DSSI plugins to the Plugins folder
Isn't there an existing method of distributing DSSI plugins? It
seems that we should use that instead of starting to manage them
ourselves. The idea of Pd-extended is that its everything in the
pure-data CVS, and all built from source. But if necessary, it
would be possible to include the DSSI plugin sources in the pure-data
CVS and have everything built and included from there. They could be
imported into externals/postlude/dssi/plugins and be managed there.
> - All libraries required by the above: liblo, libfluidsynth,
> libjack, libdssialsacompat and libmx.
On Debian, and other GNU/Linuxes, these should be handled by the
package system whenever possible.
On Mac OS X, the script packages/darwin_app/embed-MacOSX-
dependencies.sh automatically includes library dependencies from /sw/
lib. Its already working quite nicely with PDP, PiDiP, and the ogg
objects, and it could easily look in /usr/local/lib also.
On Windows, I have been manually including the DLLs, but a script
like the one I just mentioned should probably be written. It was
easy on Mac OS X because of "otool -L" and "install_name_tool",
hopefully there are equivalents in Windows (actually, I don't think
an "install_name_tool" is needed for DLLs).
> - All the frameworks required by the above: GLib, GDK, GTK
Those should be installed seperately, like using Debian, Fink,
Windows installers etc. That should be easy to do with Fink or
> If you wanted to (in time), I would be willing to maintain a more
> complete set of DSSI plugins, but you may feel that this bloats PD-
Sounds ok to me, especially if you can get them working on all three
platforms. Just import the sources that you use into the pure-data
CVS, so others can easily build Pd-extended too without having to
download sources from a million different places. I am not worried
about the size of the package. If people want a small package, they
can easily download Miller's. Much more important is having as much
as possible included and _working_ with just a simple install.
>> If you want to see how things are built, check out the source. These
>> files are off interest:
>> There you can see some examples of install_name_tool
> Thanks, I'll have a look at that. So far I've been doing things 'by
> hand' so it would be nice to have some scripts to follow.
> Feel free to forward this to PD-dev if you think it is relevant to
News is what people want to keep hidden and everything else is
- Bill Moyers
More information about the Pd-dev