[PD-dev] Re: including [dssi~] in Pd-extended

[Hans-Christoph Steiner]

I think others could be interested, so let's keep this on the list...	

On Feb 27, 2006, at 6:22 AM, Jamie Bullock wrote:

> On Mon, 27 Feb 2006 00:08:45 -0500
> Hans-Christoph Steiner <hans at eds.org> wrote:
> <snip>
>>
>> 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.
>>
> I'll have a look at how things are done and try it myself. I let  
> you know if I get stuck.

The easy way is to start with the template.  There are lots of useful  
docs here:

http://puredata.org/docs/developer/

Including "Pd-extended Build System":

http://puredata.org/docs/developer/build



>>> - 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.
>>
> My problem is that if I'm going to give a patch to an ensemble, I  
> don't want to have to say to them "first get PD-extended, then  
> install GTK+OSX, then install x and y plugins, then install......",  
> but I guess this is the precise raison d'etre of what you are doing!

If you really only want to give them one thing, you should give them  
a LiveCD, like pure:dyne.  Adding this stuff to Pd-extended is a step  
in that direction, since there has been some talk of using Pd- 
extended as the basis for pure:dyne's Pd and the Debian packages.

> I guess in terms of meeting our current needs I should probably  
> import plugins into externals/postlude/dssi/plugins, as me or  
> anyone else needs them. Hexter and Fluidsynth-DSSI both use  
> autotools, so I guess it shouldn't be too difficult to incorporate  
> them into the build system. I guess the tricky bit is making sure  
> the overall build process doesn't fall over if one of the plugins  
> doesn't compile - how dow do you usually get around this?

Once its in CVS, then you can check in fixes.  Then others don't have  
to think about it.  And this also makes it easy generate patches to  
submit to the plugin dev.

>
>
>>> - 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).
>>
>
> I'll have a look at all of this, and get back to you when I think  
> I've managed to incorporate one plugin into the build system.
>
>>> - 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
>> Darwinports.
>>
> You mean users are responsible for ensuring these are present?

Yes.  If we start including everything in the Pd.app, then we are  
making a LiveCD.  That's a different, but also very valuable, project.

>>> 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-
>>> extended.....
>>
>> 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.
>>
> Well, I found it a slight struggle just to build the plugins  
> _manually_ on OS X, but I'm happy to give this a go. I think you're  
> working on quite a winning solution here, even though I am not a  
> Mac user!

Pd-extended is no longer just a Mac OS X thing, the Windows build is  
equal to the Mac OS X wherever possible, and the GNU/Linux build is  
usable, tho not quite up to speed with the other two.

.hc
________________________________________________________________________ 
____

"Looking at things from a more basic level, you can come up with a  
more direct solution... It may sound small in theory, but it in  
practice, it can change entire economies."
                                                     - Amy Smith