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

Hans-Christoph Steiner hans at eds.org
Tue Feb 28 07:22:34 CET 2006


On Feb 27, 2006, at 3:22 PM, Frank Barknecht wrote:

> Hallo,
> Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
>
>> I do agree with this sentiment for sure, but sometimes it makes sense
>> for us to import other code.  The best example is when there is no
>> release, like portaudio V19,
>
> Portaudio is a crucial library to get Pd running in the first place,
> so I see it as a different case. It also may be necessary to import
> some source code to the CVS, if we need a very very specific version
> of that code. Plugins however by definition are meant to be plugged in
> as an extension, so it's not necessary to have any of them in the CVS,
> IMO. We won't have all of them in our CVS anyway. Maybe we could
> provide one or two simple DSSI/LADSPA plugins as examples, to allow
> users to test the external, but everything else would only lead to
> problems later.
>
>> fluidsynth is another example.  Its in Debian, but there is no easy
>> way to install it on either Mac OS X or Windows, only compiling from
>> source.
>
> Well, then lets compile it from source, but that's doesn't mean, that
> it has to be duplicated into the Pd-CVS, we could use the source from
> fluid's CVS at Savannah. It would complicate things if I would need to
> track two versions of libfluidsynth for possible problems or updates
> while maintaining the [fluid~] external. And no, I wouldn't want to
> require people, who want to use fluid~, to install the special version
> of fluidsynth that would be in Pd's CVS.


The options are currently to build fluid and DSSI plugins from  
source.  That greatly limits the userbase.  If fluidsynth and the  
dssi plugins are indeed very useful to have with Pd, then they should  
be included in Pd-extended.  CVS is a tool for managing source code,  
which is what we would need to do in order to include fluidsynth and  
DSSI plugins.  We don't need to make changes to the fluidsynth  
source, that would indeed complicate things.  We would only import  
stable versions known to work well with Pd.

This is already happening in many places and I think it make good  
sense here.  For example:

externals/grill
GemLibs
externals/hcs/hid/linux/input.h
externals/hcs/hid/HID Utilities Source
externals/gridflow
externals/sc4pd/source
iemlib/src/iem_mp3

.hc

________________________________________________________________________ 
____

Using ReBirth is like trying to play an 808 with a long stick.
                                               -David Zicarelli





More information about the Pd-dev mailing list