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@eds.org wrote:
First off, I recommend against making an esoteric Pd version. We will all be better off if we all work on one distro. If you need to include 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 Darwinports.
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.
.hc
If you want to see how things are built, check out the source. These files are off interest:
package/darwin_app/Makefile package/darwin_app/embed-MacOSX-dependencies.sh pd/src/makefile.in
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 everyone.
Regards,
Jamie
________________________________________________________________________ ____
News is what people want to keep hidden and everything else is publicity.
- Bill Moyers
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
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'm *very much* against putting sources for DSSI or LADSPA or VST or whatever plugin into the pure-data CVS. To me it feels like trying to put every free audio software there is into a repository, that is intended to only hold Pd related stuff. For example we don't put the sources for the Snd editor in Pd-CVS, even when there is a snd-external, and we don't keep a duplicate copy of Csound just for csoundapi~. Or a Ubuntu-mirror, because some of us ...
Lets try to focus on Pd stuff and not mirror the world.
Ciao
Hans,
I have to say that, having thought about it a bit more, I agree with Frank about not including the plugins in PD-extended. It needlessly creates extra work. I originally put them in my 'bespoke' PD bundle to hide them from the user for the specific piece I am working on, but I could just as easily have included them outside of the bundle.
I'll work on incorporating dssi~ into the build system, and leave it at that.
Regards, Jamie
On Mon, 27 Feb 2006 13:02:03 +0100 Frank Barknecht fbar@footils.org wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
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'm *very much* against putting sources for DSSI or LADSPA or VST or whatever plugin into the pure-data CVS. To me it feels like trying to put every free audio software there is into a repository, that is intended to only hold Pd related stuff. For example we don't put the sources for the Snd editor in Pd-CVS, even when there is a snd-external, and we don't keep a duplicate copy of Csound just for csoundapi~. Or a Ubuntu-mirror, because some of us ...
Lets try to focus on Pd stuff and not mirror the world.
On Feb 27, 2006, at 7:02 AM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
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'm *very much* against putting sources for DSSI or LADSPA or VST or whatever plugin into the pure-data CVS. To me it feels like trying to put every free audio software there is into a repository, that is intended to only hold Pd related stuff. For example we don't put the sources for the Snd editor in Pd-CVS, even when there is a snd-external, and we don't keep a duplicate copy of Csound just for csoundapi~. Or a Ubuntu-mirror, because some of us ...
Lets try to focus on Pd stuff and not mirror the world.
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, or when there is no distribution set up for a package. I don't see a clear and easy distribution of DSSI plugins, so it might make sense to include them in Pd-extended. Many audio programs include some plugins in the default install, like Audacity, and commercial software.
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.
But it'll never make sense to include GTK, Glib, etc. since there are very good distros for those on all platforms.
.hc
________________________________________________________________________ ____
"Information wants to be free." -Stewart Brand
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.
Ciao
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
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
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
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.
For dssi~ and fluid~ it's even easier, as the source code is never necessary to built these externals.
Ciao
Hi,
On Tue, 28 Feb 2006 08:31:00 +0100 Frank Barknecht fbar@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
On Feb 28, 2006, at 2:31 AM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
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
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.
For dssi~ and fluid~ it's even easier, as the source code is never necessary to built these externals.
GemLibs is the perfect example. Its a collection of useful libraries which Gem uses. That code is not pd-specific (FTGL, liborb, particle, etc), but are third-party libraries. But the gem devs found it useful to manage that source code in CVS.
CVS is a useful tool for managing source code, whether its writing code, or importing other people's code. "cvs import" was expressly designed to handle "tracking third-party sources". apt-get, fink, darwinports, etc. are better at managing libraries than CVS. But when such packages are not available, managing the source in CVS is far better option than telling people to download a tarball and compile.
And it comes down to this: what harm is there to importing the sources?
.hc
________________________________________________________________________ ____
"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore
CVS is a useful tool for managing source code, whether its writing code, or importing other people's code. "cvs import" was expressly designed to handle "tracking third-party sources".
SVN has something to offer here
svn propset svn:externals GemLibs libQuicktime http://svn.libquicktime.net/branches/stable
etc. then when the user updates , it grabs from the appropriate remote server.
pretty cool feature if you ask me, def better than manually importing
apt-get, fink, darwinports, etc. are better at managing libraries than CVS. But when such packages are not available, managing the source in CVS is far better option than telling people to download a tarball and compile.
And it comes down to this: what harm is there to importing the sources?
.hc
"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
GemLibs is the perfect example. Its a collection of useful libraries which Gem uses. That code is not pd-specific (FTGL, liborb, particle, etc), but are third-party libraries. But the gem devs found it useful to manage that source code in CVS.
Which I find questionable, too, but at least these aren't plugins as dssi/ladspa, and they aren't whole applications like fluidsynth, and they are used as integral parts of Gem.pd_*. So they are similar to the role Portaudio plays in Pd (and Particle seems to be gone from its old URL anyway, so users cannot download it from somwhere else.)
And it comes down to this: what harm is there to importing the sources?
I see the danger of a maintainance nightmare or at least an additional burden for administrators. We didn't even manage to find a clean organization of the pd-related stuff so far and thus we should not try to carry even more weight.
Ciao
Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
GemLibs is the perfect example. Its a collection of useful libraries
i don't think so.
which Gem uses. That code is not pd-specific (FTGL, liborb, particle, etc), but are third-party libraries. But the gem devs found it useful to manage that source code in CVS.
Which I find questionable, too, but at least these aren't plugins as dssi/ladspa, and they aren't whole applications like fluidsynth, and they are used as integral parts of Gem.pd_*. So they are similar to the role Portaudio plays in Pd (and Particle seems to be gone from its old URL anyway, so users cannot download it from somwhere else.)
wow true, i haven't yet noticed that dave's homepage went to nirvana. last time i checked (fall 2005) it was still there.
GemLibs need a major cleanup anyhow. imo, they are there for historic reasons only. at least on linux, i _never_ use GemLibs.
"particle" has been incorporated into the Gem-sources itself, so the version in GemLibs is not used at all. the same goes for "glm". afaik, the same goes for "darwinStuff". afaik, "liborb" has not been tested for years (most likely nobody has a SpaceOrb); i doubt whether current Gem releases still use it (probably on w32...) and i don't know whether it works at all. as for FTGL/freetype2, i think it would be better to remove them from the GemLibs too (but it is so hard to delete directories in CVS...)
mfg.asd.r IOhannes
On Mar 1, 2006, at 5:59 AM, IOhannes m zmoelnig wrote:
Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
GemLibs is the perfect example. Its a collection of useful libraries
i don't think so.
which Gem uses. That code is not pd-specific (FTGL, liborb, particle, etc), but are third-party libraries. But the gem devs found it useful to manage that source code in CVS.
Which I find questionable, too, but at least these aren't plugins as dssi/ladspa, and they aren't whole applications like fluidsynth, and they are used as integral parts of Gem.pd_*. So they are similar to the role Portaudio plays in Pd (and Particle seems to be gone from its old URL anyway, so users cannot download it from somwhere else.)
wow true, i haven't yet noticed that dave's homepage went to nirvana. last time i checked (fall 2005) it was still there.
GemLibs need a major cleanup anyhow. imo, they are there for historic reasons only. at least on linux, i _never_ use GemLibs.
"particle" has been incorporated into the Gem-sources itself, so the version in GemLibs is not used at all. the same goes for "glm". afaik, the same goes for "darwinStuff". afaik, "liborb" has not been tested for years (most likely nobody has a SpaceOrb); i doubt whether current Gem releases still use it (probably on w32...) and i don't know whether it works at all. as for FTGL/freetype2, i think it would be better to remove them from the GemLibs too (but it is so hard to delete directories in CVS...)
On Debian, which IIRC both Frank and you use, there are tons of deps that are handled by apt-get. That is far from true on Mac OS X, and worse on Windows. Building on all platforms means managing other people's source code. CVS is an excellent tool for groups of people to manage source code. Its far better than not managing it.
Last time I tried to build Gem from source, there were deps which I could not get working on Mac OS X. If those deps had been in CVS, it would have been quite easy since the build system would have known where to find everything, and the right version of the source code would be in place.
Many projects do this, I work some with the EWRT project, where almost the whole codebase is made of imported sources. It would be an absolute nightmare without CVS managing the source code.
.hc
________________________________________________________________________ ____
"I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits." - Martin Luther King, Jr.
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
On Debian, which IIRC both Frank and you use, there are tons of deps that are handled by apt-get. That is far from true on Mac OS X, and worse on Windows. Building on all platforms means managing other people's source code. CVS is an excellent tool for groups of people to manage source code. Its far better than not managing it.
We are talking about two different things: One is dependencies to build Pd and externals, the other is extensions like the dssi, vst, ladspa plugins or even foreign applictions like fluidsynth, Snd and Csound. I think we should currently only discuss the latter, plugins and apps, as the subject is dssi~.
I'm against managing foreign plugins or apps in the Pd CVS. With an open application like Pd, where an external can be made to load *everything*, there just is no stopping point, once we start to do this.
For example as we have pyext, we now might consider to add Python to the CVS, so that people can load python scripts, and we may consider to add 3rd party Python libraries, because some python scripts rely on them, to the CVS which in turn might rely on C-libraries, that will be added etc. Without clear rules and without drawing a line at some point this will never stop.
dssi/ladspa/vst in my view are way beyond that line from the start.
Ciao
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
dssi/ladspa/vst in my view are way beyond that line from the start.
I forgot: Adding "ladspa.h" to the Pd-CVS could be okay however, but it should be added in a different tree of course.
Ciao
I'm against managing foreign plugins or apps in the Pd CVS. With an open application like Pd, where an external can be made to load *everything*, there just is no stopping point, once we start to do this.
Hi all, that is also my point of view. There should be no resources in the CVS that can be aquired elsewhere.
best greetings, Thomas
On Fri, 2006-03-03 at 10:29 +0100, Thomas Grill wrote:
I'm against managing foreign plugins or apps in the Pd CVS. With an open application like Pd, where an external can be made to load *everything*, there just is no stopping point, once we start to do this.
Hi all, that is also my point of view. There should be no resources in the CVS that can be aquired elsewhere.
right ... if one would want to automate a build process, it can easily be done by adding the command to acquire the resources to the build system ... (doing that with scons seems to be trivial)
cheers ... tim
-- TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
All we composers really have to work with is time and sound - and sometimes I'm not even sure about sound. Morton Feldman
On 3 Mar 2006, at 11:56, Tim Blechmann wrote:
There should be no resources in the CVS that can be aquired elsewhere.
right ... if one would want to automate a build process, it can easily be done by adding the command to acquire the resources to the build system ... (doing that with scons seems to be trivial)
Hear, hear.
We should handle dependencies at built time, by pre-empting sources is too scary IMO.
d
-- David Plans Casal Researcher, UEA Studios d.casal at uea dot ac dot uk http://www.davidcasal.com
On Mar 3, 2006, at 6:56 AM, Tim Blechmann wrote:
On Fri, 2006-03-03 at 10:29 +0100, Thomas Grill wrote:
I'm against managing foreign plugins or apps in the Pd CVS. With an open application like Pd, where an external can be made to load *everything*, there just is no stopping point, once we start to do this.
Hi all, that is also my point of view. There should be no resources in the CVS that can be aquired elsewhere.
right ... if one would want to automate a build process, it can easily be done by adding the command to acquire the resources to the build system ... (doing that with scons seems to be trivial)
There is one major caveat to doing that: it will not work at all with the Debian auto-builders. No network access allowed.
I still see no reason why we should not use CVS to manage "foreign" sources. We already are in a lot of places and it works quite well. We need to use a lot of code that is far from released in building Pd. That means we have to manage source code. CVS is a good tool for managing source code, we all know how to use it, (many of us don't use python or scons at all), and even has built-in support for managing foreign sources. Check out the "Tracking Third-Party Sources" section in the CVS manual:
http://ximbiot.com/cvs/manual/cvs-1.12.13/cvs_13.html#SEC106
Really it comes down to this: How are you guys harmed if I choose to manage some "foreign" sources in the Pd CVS?
.hc
cheers ... tim
-- TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
All we composers really have to work with is time and sound - and sometimes I'm not even sure about sound. Morton Feldman
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
________________________________________________________________________ ____
"I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits." - Martin Luther King, Jr.
On Mar 4, 2006, at 8:20 PM, Hans-Christoph Steiner wrote:
On Mar 3, 2006, at 6:56 AM, Tim Blechmann wrote:
On Fri, 2006-03-03 at 10:29 +0100, Thomas Grill wrote:
I'm against managing foreign plugins or apps in the Pd CVS. With an open application like Pd, where an external can be made to load *everything*, there just is no stopping point, once we start to do this.
Hi all, that is also my point of view. There should be no resources in the CVS that can be aquired elsewhere.
right ... if one would want to automate a build process, it can easily be done by adding the command to acquire the resources to the build system ... (doing that with scons seems to be trivial)
There is one major caveat to doing that: it will not work at all with the Debian auto-builders. No network access allowed.
I still see no reason why we should not use CVS to manage "foreign" sources. We already are in a lot of places and it works quite well. We need to use a lot of code that is far from released in building Pd. That means we have to manage source code. CVS is a good tool for managing source code, we all know how to use it, (many of us don't use python or scons at all), and even has built- in support for managing foreign sources. Check out the "Tracking Third-Party Sources" section in the CVS manual:
http://ximbiot.com/cvs/manual/cvs-1.12.13/cvs_13.html#SEC106
Really it comes down to this: How are you guys harmed if I choose to manage some "foreign" sources in the Pd CVS?
I forgot to add two things:
first, I really don't see why this is such a contentious issue. I have no interest in pissing anyone off, so please forgive me if it may come across like that. Its just that I have spend far and away the most time working on making Pd into installer packages, and not using CVS for foreign sources would make it A LOT more work to build and maintain Pd and all the externals.
Second, if we were to remove foreign sources, here are some of the things we would have to remove and track separately:
externals/sc4pd/source (SuperCollider is maintained elsewhere) externals/grill (maintained in a separate repository with separate binary releases) externals/hcs/hid/linux/input.h (Linux header, should Mac OS X and Windows users have to track this one?) externals/hcs/hid/HID Utilities Source (Apple sources) externals/gridflow (maintained and released elsewhere) externals/OSCx/libOSC (library from UC Berkeley) externals/iemlib/src/iem_mp3 (uses source files from lame) pd/portaudio (V19 is still very much under development, no releases, big changes) pd/portmidi
Would we be better off if we removed all these? What I am saying we do is what Thomas currently does with his externals/grill directory: import sources which are known to build and work. No one is saying we should include GTK or something like that. But for things that are under development and/or have no releases, CVS is a good tool to manage those sources. This is standard practice, and indeed, CVS is designed to do this.
Plus with changing sources, we can import sources that we know work with Pd instead of having the whole Pd build system break whenever some developer on portaudio, libOSC, etc. etc. makes a change. This will make bugs much easier to track since we'll know which version of a given library (like portaudio) works well with Pd.
.hc
________________________________________________________________________ ____
"I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits." - Martin Luther King, Jr.
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
There is one major caveat to doing that: it will not work at all with the Debian auto-builders. No network access allowed.
Debian already includes fluidsynth and dssi.
Ciao
On Mar 5, 2006, at 5:57 AM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
There is one major caveat to doing that: it will not work at all with the Debian auto-builders. No network access allowed.
Debian already includes fluidsynth and dssi.
Yes, and Debian is great for that. So the debian packages would not have to include them.
But Pd also runs on Windows and Mac OS X. And there are far more Pd users running Windows and Mac OS X. So I think its also important to consider other platforms when we are talking about such things.
.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
Yes, and Debian is great for that. So the debian packages would not have to include them.
But Pd also runs on Windows and Mac OS X. And there are far more Pd users running Windows and Mac OS X. So I think its also important to consider other platforms when we are talking about such things.
its already very easy to install anything on mac os X: 1 search the web 2 click into site for the software you want 3 click 'download' tab 4 click download link 5 click 'download now' so you dont have to wait 12 seconds 6 minimize all windows 7 find the compressed disk image on your desktop 8 uncompress the disk image 9 mount the disk image 10 open up the folder on disk where you want to put it 11 copy stuff off the disk image 12 unmount the disk image 13 delete disk image and compressed disk image 14 run the app (and hope it works on 10.4.5 or maybe 10.3.1 instead of just 10.4.69) 15 enjoy!
On Sun Mar 05, 2006 at 06:50:25PM +0000, cdr wrote:
Yes, and Debian is great for that. So the debian packages would not have to include them.
But Pd also runs on Windows and Mac OS X. And there are far more Pd users running Windows and Mac OS X. So I think its also important to consider other platforms when we are talking about such things.
its already very easy to install anything on mac os X: 1 search the web 2 click into site for the software you want 3 click 'download' tab 4 click download link 5 click 'download now' so you dont have to wait 12 seconds 6 minimize all windows 7 find the compressed disk image on your desktop 8 uncompress the disk image 9 mount the disk image 10 open up the folder on disk where you want to put it 11 copy stuff off the disk image 12 unmount the disk image 13 delete disk image and compressed disk image 14 run the app (and hope it works on 10.4.5 or maybe 10.3.1 instead of just 10.4.69)
woops, forgot 14.5 foreach dependency {goto 1} 16 Pay $35 for the program that lets you drag stuff from safari to the desktop so it stops popping up shareware warnings
anyways im sure an interesting afternoon project would be to recreate portage's 'SVN/CVS ebuild' feature in pd-extended's autotools scripts. so it could automagicaly download the deps like LADSPA/FluidSynth/PA19 for MacOSX and MinGW users who dont have such capabilities innate in their OS..
15 enjoy!
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Mar 5, 2006, at 2:07 PM, cdr wrote:
On Sun Mar 05, 2006 at 06:50:25PM +0000, cdr wrote:
Yes, and Debian is great for that. So the debian packages would not have to include them.
But Pd also runs on Windows and Mac OS X. And there are far more Pd users running Windows and Mac OS X. So I think its also important to consider other platforms when we are talking about such things.
its already very easy to install anything on mac os X: 1 search the web 2 click into site for the software you want 3 click 'download' tab 4 click download link 5 click 'download now' so you dont have to wait 12 seconds 6 minimize all windows 7 find the compressed disk image on your desktop 8 uncompress the disk image 9 mount the disk image 10 open up the folder on disk where you want to put it 11 copy stuff off the disk image 12 unmount the disk image 13 delete disk image and compressed disk image 14 run the app (and hope it works on 10.4.5 or maybe 10.3.1 instead of just 10.4.69)
woops, forgot 14.5 foreach dependency {goto 1} 16 Pay $35 for the program that lets you drag stuff from safari to the desktop so it stops popping up shareware warnings
anyways im sure an interesting afternoon project would be to recreate portage's 'SVN/CVS ebuild' feature in pd-extended's autotools scripts. so it could automagicaly download the deps like LADSPA/FluidSynth/PA19 for MacOSX and MinGW users who dont have such capabilities innate in their OS..
Don't let me stop you from doing that.
But (unfortunately?), Pd-extended doesn't use autotools, only make. It think it would be really great to have one central externals/ configure which makes a externals/config.h which externals would then use. Then people would not have to figure out autotools to use it, they would just need to #include "../config.h" and use #ifdef HAVE_BLAHBLAH.
.hc
________________________________________________________________________ ____
"Computer science is no more related to the computer than astronomy is related to the telescope." -Edsger Dykstra
On Mar 5, 2006, at 1:50 PM, cdr wrote:
Yes, and Debian is great for that. So the debian packages would not have to include them.
But Pd also runs on Windows and Mac OS X. And there are far more Pd users running Windows and Mac OS X. So I think its also important to consider other platforms when we are talking about such things.
its already very easy to install anything on mac os X: 1 search the web 2 click into site for the software you want 3 click 'download' tab 4 click download link 5 click 'download now' so you dont have to wait 12 seconds 6 minimize all windows 7 find the compressed disk image on your desktop 8 uncompress the disk image 9 mount the disk image 10 open up the folder on disk where you want to put it 11 copy stuff off the disk image 12 unmount the disk image 13 delete disk image and compressed disk image 14 run the app (and hope it works on 10.4.5 or maybe 10.3.1 instead of just 10.4.69) 15 enjoy!
When something is already packaged up like you outline above, then yes, I totally agree we should not be managing the source. We should use the packages. Python, GTK, and Jack are perfect examples of that.
But Fluidsynth and DSSI plugins are only available as source from the original website (I guess you could probably dig up some binaries, but that digging would be part of the problem...). That's when it makes sense to manage the foreign code in CVS.
.hc
________________________________________________________________________ ____
If you are not part of the solution, you are part of the problem. - Eldridge Cleaver
On Sat, 2006-03-04 at 20:20 -0500, Hans-Christoph Steiner wrote:
right ... if one would want to automate a build process, it can
easily
be done by adding the command to acquire the resources to the build system ... (doing that with scons seems to be trivial)
There is one major caveat to doing that: it will not work at all with the Debian auto-builders. No network access allowed.
having no idea about the debian auto-builders (gentoo ebuilds rely on network access), i'd then suggest a simple script in the language of your choice to set up the builder environment
- check out the pd sources from sf - check out the revision controlled sources (e.g. portaudio) by tag, branch or date - download the tarballs of the released sources from the web
this way you can be sure, to have the latest pd sources and the external sources, that you consider as stable, i guess, that's what you want, isn't it? but then the one, who decides, which version/tag/branch/date to use (which would apply to both ways) should check the bug reports with upstream, to avoid duplicate work ...
nevertheless ... from what i understand, you are not working on devel so i guess, we're working on different sources anyway ... so do what you think it's right ... i think the last few monthes have shown, that we won't agree on this topic ...
cheers .... tim
-- TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
You can play a shoestring if you're sincere John Coltrane
On Mar 5, 2006, at 5:42 AM, Tim Blechmann wrote:
On Sat, 2006-03-04 at 20:20 -0500, Hans-Christoph Steiner wrote:
right ... if one would want to automate a build process, it can
easily
be done by adding the command to acquire the resources to the build system ... (doing that with scons seems to be trivial)
There is one major caveat to doing that: it will not work at all with the Debian auto-builders. No network access allowed.
having no idea about the debian auto-builders (gentoo ebuilds rely on network access), i'd then suggest a simple script in the language of your choice to set up the builder environment
- check out the pd sources from sf
- check out the revision controlled sources (e.g. portaudio) by tag,
branch or date
- download the tarballs of the released sources from the web
this way you can be sure, to have the latest pd sources and the external sources, that you consider as stable, i guess, that's what you want, isn't it? but then the one, who decides, which version/tag/branch/date to use (which would apply to both ways) should check the bug reports with upstream, to avoid duplicate work ...
nevertheless ... from what i understand, you are not working on devel so i guess, we're working on different sources anyway ... so do what you think it's right ... i think the last few monthes have shown, that we won't agree on this topic ...
This isn't just about the "pd" part of the repository, but all of it. We all use "externals". I have nothing against pd-devel, but there are so many changes which make it hard to work with in terms of a build system (like moving configure from pd/src/ to pd) that I didn't want to devote the time to a whole other mess of build system issues. Regular pd has enough of those issues for a lifetime. Its sad that we are generating more issues rather than working together to fix them.
As for the simple script to set up the build environment, I choose to use a script called "cvs". It works really well for managing source code, its widely understood and used, and it very stable and mature.
.hc
________________________________________________________________________ ____
There is no way to peace, peace is the way. -A.J. Muste
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Regular pd has enough of those issues for a lifetime. Its sad that we are generating more issues rather than working together to fix them.
That actually is the point why I am not in favour of putting foreign sources in the Pd CVS: They would require additional work in setting up build systems, keeping them up to date etc. Especially when totally separate stuff like plugins in DSSI, LADSPA or VST formats is concerned, I'm still not convinced why we should bother with including them. As I wrote several mails ago: By definition these are meant to be plugged in and not to be included. That's the whole point of a plugin format and the beauty of LADSPA, DSSI.
I'm not so strictly against keeping some libraries to link against in some clearly seperate tree of the Pd CVS. I don't think, it's a good idea, but I can also understand your point that it may make packaging easier on some operating systems in the end and if it's in a totally different tree it may not do any harm.
But plugins IMO should be a no-go area, not only for source code, but also for binary installer packages. The DSSI people may start their own binary packaging system, but that really is none of our business. And including fluidsynth just because we would want to build the fluidsynth-dssi-plugin is even worse. Additionally we would also need to include some more sources, as that are used by fluid-dssi, like the ALSA headers or a compat. library and more. This won't stop.
All this of course is just IMO.
Ciao
On Mar 5, 2006, at 12:21 PM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Regular pd has enough of those issues for a lifetime. Its sad that we are generating more issues rather than working together to fix them.
That actually is the point why I am not in favour of putting foreign sources in the Pd CVS: They would require additional work in setting up build systems, keeping them up to date etc. Especially when totally separate stuff like plugins in DSSI, LADSPA or VST formats is concerned, I'm still not convinced why we should bother with including them. As I wrote several mails ago: By definition these are meant to be plugged in and not to be included. That's the whole point of a plugin format and the beauty of LADSPA, DSSI.
I'm not so strictly against keeping some libraries to link against in some clearly seperate tree of the Pd CVS. I don't think, it's a good idea, but I can also understand your point that it may make packaging easier on some operating systems in the end and if it's in a totally different tree it may not do any harm.
But plugins IMO should be a no-go area, not only for source code, but also for binary installer packages. The DSSI people may start their own binary packaging system, but that really is none of our business. And including fluidsynth just because we would want to build the fluidsynth-dssi-plugin is even worse. Additionally we would also need to include some more sources, as that are used by fluid-dssi, like the ALSA headers or a compat. library and more. This won't stop.
All this of course is just IMO.
On GNU/Linux, I totally agree. But its much more difficult on Windows and Mac OS X. On Debian, for example, its quite easy to setup a build system and install dependencies. On Mac OS X, its not too hard to get the basics going, but Fink isn't dead simple. On Windows its a lot harder.
My goal is to get as much code working in the installer as possible. That's why I want to include these plugins. They sound quite useful, but they would be very difficult to install for most users.
So yes, its painful from the Debian perspective, and its not the way I would prefer to do things, but its a matter of getting things working for people.
.hc
________________________________________________________________________ ____
I spent 33 years and four months in active military service and during that period I spent most of my time as a high class muscle man for Big Business, for Wall Street and the bankers. - General Smedley Butler
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
My goal is to get as much code working in the installer as possible. That's why I want to include these plugins. They sound quite useful, but they would be very difficult to install for most users.
But a DSSI plugin is a totally seperate application from Pd!
DSSI/LADSPA are the same as Firefox or Audacity from a Pd point of view: Firefox or Audacity are useful pieces of software for every Pd user as well, still we would not even think about trying to keep their sources in our CVS or about including them in Pd-installer packages.
Ciao
I think that hc is really just trying to build an awesome package to popularize pd. I know it's a pain in the rear to maintain code and manage source trees and such, but he has a serious drive to make this obscure-as-all-hell program more relevant to laypersons and non-programmers. This saves you guys a TON of work actually, since you won't be badgered by annoying newbie questions on the list re: this stuff, if people can just click an install button.
If more awareness can be made about pd, especially with high-quality plugins like ladspa and dssi, then people will be drawn toward it, and we will eventually gain more users, developers, and maintainers, and possibly more funding! How could that be a bad thing?
My two cents (as a non-programmer).
~Kyle
On 3/5/06, Frank Barknecht fbar@footils.org wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
My goal is to get as much code working in the installer as possible. That's why I want to include these plugins. They sound quite useful, but they would be very difficult to install for most users.
But a DSSI plugin is a totally seperate application from Pd!
DSSI/LADSPA are the same as Firefox or Audacity from a Pd point of view: Firefox or Audacity are useful pieces of software for every Pd user as well, still we would not even think about trying to keep their sources in our CVS or about including them in Pd-installer packages.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
-- http://perhapsidid.blogspot.com (((())))(()()((((((((()())))()(((((((())()()())()))) (())))))(()))))))))))))(((((((((((()()))))))))((()))) ))(((((((((((())))())))))))))))))))__________ _____())))))(((((((((((((()))))))))))_______ ((((((())))))))))))((((((((000)))oOOOOOO
Hallo, Kyle Klipowicz hat gesagt: // Kyle Klipowicz wrote:
I think that hc is really just trying to build an awesome package to popularize pd. I know it's a pain in the rear to maintain code and manage source trees and such, but he has a serious drive to make this obscure-as-all-hell program more relevant to laypersons and non-programmers. This saves you guys a TON of work actually, since you won't be badgered by annoying newbie questions on the list re: this stuff, if people can just click an install button.
If more awareness can be made about pd, especially with high-quality plugins like ladspa and dssi, then people will be drawn toward it, and we will eventually gain more users, developers, and maintainers, and possibly more funding! How could that be a bad thing?
We do need to draw a line somewhere about what to include in a Pd distribution and what to leave out. Every software package has to decide such things, Max has to, Pd has to, Ardour has to, Firefox has to. And I would draw that line when it comes to plugins. DSSI and LADSPA are well defined interfaces that were designed with the main goal in mind, that plugin authors and the authors of plugin host software should be able to work independently. Including plugins in the Pd CVS would defy that underlying idea of DSSI and LADSPA.
Ciao
On Mar 18, 2006, at 7:15 PM, Frank Barknecht wrote:
Hallo, Kyle Klipowicz hat gesagt: // Kyle Klipowicz wrote:
I think that hc is really just trying to build an awesome package to popularize pd. I know it's a pain in the rear to maintain code and manage source trees and such, but he has a serious drive to make this obscure-as-all-hell program more relevant to laypersons and non-programmers. This saves you guys a TON of work actually, since you won't be badgered by annoying newbie questions on the list re: this stuff, if people can just click an install button.
If more awareness can be made about pd, especially with high-quality plugins like ladspa and dssi, then people will be drawn toward it, and we will eventually gain more users, developers, and maintainers, and possibly more funding! How could that be a bad thing?
We do need to draw a line somewhere about what to include in a Pd distribution and what to leave out. Every software package has to decide such things, Max has to, Pd has to, Ardour has to, Firefox has to. And I would draw that line when it comes to plugins. DSSI and LADSPA are well defined interfaces that were designed with the main goal in mind, that plugin authors and the authors of plugin host software should be able to work independently. Including plugins in the Pd CVS would defy that underlying idea of DSSI and LADSPA.
What I don't understand with this whole thread is how is anyone harmed if the plugin source code is included? Ok, in theory, its a plugin and meant to be standalone, but in practice its just a piece of code like any other.
There is a real harm in not including them: people won't use them because of the large hurdle in getting them running. And that to me is sad since most code is written for people to use.
When I include code in Pd-extended, I make sure its works on Mac OS X, GNU/Linux, and Windows. I would do the same for any plugin source that I included. Just look at Pd-0.38.4-extended. I am not saying there aren't problems with it, but look at the situation before.
That's my final two bits, I've spent too much time on this topic...
.hc
________________________________________________________________________ ____
Using ReBirth is like trying to play an 808 with a long stick. -David Zicarelli
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
What I don't understand with this whole thread is how is anyone harmed if the plugin source code is included? Ok, in theory, its a plugin and meant to be standalone, but in practice its just a piece of code like any other.
But if it is so important to have working dssi/ladspa packages on all supported operating systems, then why not give their developers the same support at their respective sites? If these plugins are only available in pd-extended packages, then someone, who wants to run them e.g. in a OS-X Ardour installation has no use for them and surely wouldn't even know, that pd-extended includes a full set of dssi plugins.
OTOH if there were working standalone DSSI packages for OS-X on dssi.sf.net then both Ardour and Pd would profit from them and many other applications as well. With LADSPA on Linux this already is working very well: A lot of applications can use the plugins packages, that are installed distro-wide through a LADSPA package. Bugs in the plugins can be fixed right on site, there are no problems coming from differing versions installed in different direcories, there always is the same central place for the newest version, that even would be a drop-in replacement etc.
Ciao
On Mar 18, 2006, at 7:43 PM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
What I don't understand with this whole thread is how is anyone harmed if the plugin source code is included? Ok, in theory, its a plugin and meant to be standalone, but in practice its just a piece of code like any other.
But if it is so important to have working dssi/ladspa packages on all supported operating systems, then why not give their developers the same support at their respective sites? If these plugins are only available in pd-extended packages, then someone, who wants to run them e.g. in a OS-X Ardour installation has no use for them and surely wouldn't even know, that pd-extended includes a full set of dssi plugins.
OTOH if there were working standalone DSSI packages for OS-X on dssi.sf.net then both Ardour and Pd would profit from them and many other applications as well. With LADSPA on Linux this already is working very well: A lot of applications can use the plugins packages, that are installed distro-wide through a LADSPA package. Bugs in the plugins can be fixed right on site, there are no problems coming from differing versions installed in different direcories, there always is the same central place for the newest version, that even would be a drop-in replacement etc.
That would be the desired outcome. I encourage anyone to take it on.
There are only so many hours in the day. I deal with Pd's build system and releases enough, I really don't want to take on more. Adding this stuff to Pd's build system would be pretty easy. Learning all of the social rules, build system, and coding of another project is a very large undertaking.
On this note, why are there so many versions of Pd released? Why are there so many build systems? Shouldn't we all be working on one system so that we can all benefit from an easier and less buggy build system, and well as Pd releases?
.hc
________________________________________________________________________ ____
News is what people want to keep hidden and everything else is publicity.
- Bill Moyers
On Mar 18, 2006, at 7:23 PM, Hans-Christoph Steiner wrote:
On Mar 18, 2006, at 7:15 PM, Frank Barknecht wrote:
We do need to draw a line somewhere about what to include in a Pd distribution and what to leave out. Every software package has to decide such things, Max has to, Pd has to, Ardour has to, Firefox has to. And I would draw that line when it comes to plugins. DSSI and LADSPA are well defined interfaces that were designed with the main goal in mind, that plugin authors and the authors of plugin host software should be able to work independently. Including plugins in the Pd CVS would defy that underlying idea of DSSI and LADSPA.
What I don't understand with this whole thread is how is anyone harmed if the plugin source code is included? Ok, in theory, its a plugin and meant to be standalone, but in practice its just a piece of code like any other.
...here we're talking about two audio plugins: would you want to include a selection of vst plugins where source is available? How about extending this to freeframe video plugins, which are supported by both GEM and PDP? I think it's enough to have the plugin loader, and then let the user find out about where to get plugins via a helpfile...
There is a real harm in not including them: people won't use them because of the large hurdle in getting them running. And that to me is sad since most code is written for people to use.
...other than the harm of bloat and extended compiles and packagings...I think a better way to get over the "large hurdle" of placing plugins in the correct place for use would be to follow what Iohannes has done with Gem's freeframe and shader/program loading code: make it search the paths that pd already looks into, like loading any other patch...it works very nicely, and would be a good addition to the ladpsa loaders...
When I include code in Pd-extended, I make sure its works on Mac OS X, GNU/Linux, and Windows. I would do the same for any plugin source that I included. Just look at Pd-0.38.4-extended. I am not saying there aren't problems with it, but look at the situation before.
...you have done a great job with pd-extended, but you can't expect to cover all bases on such an open ended system, nor should you want to: it'll just never happen...
That's my final two bits, I've spent too much time on this topic...
...yes, please, move on...
james
An interesting inversion to this topic is the one of using _Pd_ as a plugin within a host device. I know there's jsarlo's pdvst, but that's windows only and is less of a "plug in" solution as it is a "open up the fuse box and rewire your house" kind of solution. This is not an insult, but more of a statement of my own stupidity regarding these things.
Again, I'm not a coder and can't judge or say much on the dev list, but I would love to be able to use Pd inside of other software, and others would too (those of us who are too impatient to build our own state-saving, non-crashing, graphical sequencers).
A preliminary (and un-thorough) search on google shows little documentation of direct vst or audio unit wrappers for dssi and ladspa plugins. Would the best effort be to make a vst wrapper for ladspa/dssi, and then try to make pd available as a ladspa/dssi plugin in its own right? This might appeal more to the hardcore GNU/Linux crowd, since they use these tools anyway, and then some lucky soul (not me unless I magically learn a shitload of coding skills) could simply make ladspa/dssi available to the other OSes.
My only other idea would be to petition someone like Ableton to make an open api based on bsd-liscensed Pd code so that people could program Live extensions with it (which would be _sweet_).
What are your thoughts on this?
~Kyle
On 3/19/06, james tittle tigital@mac.com wrote:
On Mar 18, 2006, at 7:23 PM, Hans-Christoph Steiner wrote:
On Mar 18, 2006, at 7:15 PM, Frank Barknecht wrote:
We do need to draw a line somewhere about what to include in a Pd distribution and what to leave out. Every software package has to decide such things, Max has to, Pd has to, Ardour has to, Firefox has to. And I would draw that line when it comes to plugins. DSSI and LADSPA are well defined interfaces that were designed with the main goal in mind, that plugin authors and the authors of plugin host software should be able to work independently. Including plugins in the Pd CVS would defy that underlying idea of DSSI and LADSPA.
What I don't understand with this whole thread is how is anyone harmed if the plugin source code is included? Ok, in theory, its a plugin and meant to be standalone, but in practice its just a piece of code like any other.
...here we're talking about two audio plugins: would you want to include a selection of vst plugins where source is available? How about extending this to freeframe video plugins, which are supported by both GEM and PDP? I think it's enough to have the plugin loader, and then let the user find out about where to get plugins via a helpfile...
There is a real harm in not including them: people won't use them because of the large hurdle in getting them running. And that to me is sad since most code is written for people to use.
...other than the harm of bloat and extended compiles and packagings...I think a better way to get over the "large hurdle" of placing plugins in the correct place for use would be to follow what Iohannes has done with Gem's freeframe and shader/program loading code: make it search the paths that pd already looks into, like loading any other patch...it works very nicely, and would be a good addition to the ladpsa loaders...
When I include code in Pd-extended, I make sure its works on Mac OS X, GNU/Linux, and Windows. I would do the same for any plugin source that I included. Just look at Pd-0.38.4-extended. I am not saying there aren't problems with it, but look at the situation before.
...you have done a great job with pd-extended, but you can't expect to cover all bases on such an open ended system, nor should you want to: it'll just never happen...
That's my final two bits, I've spent too much time on this topic...
...yes, please, move on...
james
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
-- http://perhapsidid.blogspot.com (((())))(()()((((((((()())))()(((((((())()()())()))) (())))))(()))))))))))))(((((((((((()()))))))))((()))) ))(((((((((((())))())))))))))))))))__________ _____())))))(((((((((((((()))))))))))_______ ((((((())))))))))))((((((((000)))oOOOOOO
-
cdr -
David Plans Casal -
Frank Barknecht -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
james tittle -
Jamie Bullock -
Kyle Klipowicz -
Thomas Grill -
Tim Blechmann