On 14 Mar 2006, at 10:42, Frank Barknecht wrote:
I don't necessarily agree with that. Perhaps 'imports' isn't the right word, but the fact that a library isn't required to run Pd at all might not be a good enough reason not to include it in an extended build system, especially if it is kept completely apart from the main tree.
But we're not talking about libraries here at all, we're talking about complete applications now! Would you consider packaging Pd with Firefox, just because a browser is needed to read the manual? I guess you wouldn't, and not only because Firefox is a huge application, but also because Firefox has a life outside of Pd and because it is useful on many other occasions as well and there's nothing Pd-specific about Firefox.
Ok point taken.
That is *exactly* the situation with LADSPA, VST or DSSI plugins: They have a seperate life outside of Pd. Pd is just one of a dozen (dssi) or many dozens (LADSPA, VST) host applications for these plugins. If someone wants binary packages of dssi plugin/apps, then instead of putting (and in fact hiding) them in a Pd CVS or in a Pd binary installer package, much more is gained by getting involved with the dssi-team and help them do proper releases for all supported operating systems. But - repeating myself form the umpteenth time - this has nothing to do with Pd.
Fine, but I'd like to see what exactly hc wants to put in there, because while I see your point, I also see that there is a dependency problem which he must solve (and no it's not as big as Firefox), and he's pretty much the only person working full time on it, so while maintaining sanity, we need to ease the road for him, not throw obstacles at him if at all possible.
d
-- David Casal Researcher, Department of Computing Goldsmiths College, University of London Office : +44 020 7078 5151 Mob : +44 07803 173959