J bz said : > "So who packages pd for pure:dyne then? I'd be curious to know the reasons > for not using pd-extended instead of pd... "
Hurray! Ye good ol' vanilla vs extended thread ;) It's true that when Puredyne started, extended was very young (someone would have to check but I also think that it was first introduced for win and macos and was only made available to Linux at a much later stage). Next to that there are some personal choices in using vanilla and a reduced set of externals: - vanilla is the reference -> decreases chances to shoot yourself in the foot by making patches which features relies on a specific distribution of Pd. For example recently hc announced that he would stop maintaining some externals in extended, which I understand perfectly given the insane task it must be to distribute everything related to Pd in a single convenient package for 3 different platforms. http://puredata.info/docs/LibrariesInPdExtended/ - less is more -> we prefer working with fewer sets of externals that have been around for a while and well-tested. It's a choice that influences creativity as it is a constrained process that forces us to really explore what Pd and a few "low level" externals have to offer instead of approaching patching from the "one feature == one external" mindset. It makes maintaining patches easier also, etc. - we package only stuff that we use -> so we have a direct interest in having it working well, which benefits to the user ultimately. Instead of providing everything Pd related and not have time to make sure everything works. - we package everything in a modular way to distribute the workload and maintain components individually (useful if version 2 of [cheeseburger~] is broken but version 1 is bug free which is a more difficult thing to solve in a monolithic distribution such as extended). Of course all of these points are personal choices, we don't hold the truth in that regard, but it is just what works for us, both as artists and Puredyne developers, and it is the type of "philosophy" that made Puredyne a reliable production environment over the past years. YMMV ;) That said, there have been some attempts in the past to coordinate efforts and convince other Pd dev to join Puredyne Pd packaging in a modular approach on Debian based systems. http://lists.puredata.info/pipermail/pd-dev/2009-04/013415.html Sadly enough it did not happen, despite our call. I can't really explain why. We were too early? Both side were a bit territorial in the way things should be led? Does not matter. Everyone moves on. The good news though is that a few Pd dev have very recently started to package externals as part of the Debian multimedia team community in such a modular way and hopefully it will allow the user choose what she/he wants on her/his system while providing higher quality binaries of externals. Everyone will greatly benefit from it and will make our isolated work redundant, which is a good thing as duplicating efforts is just nonsense in such small communities. Concerning the documentation side of Pd extended, I can't really tell as most of the Pd documentation needs of Puredyne were driven by GOTO10 workshops (mostly around 2006-2008) and we had our own tutorials for that. For instance: https://code.goto10.org/hg/index.cgi/canvas/file/ About the interface changes, this is my *own* opinion: I don't care about fancy looking objects, custom fonts and all kind of visual improvements. I remember Frank Barknecht, years ago, saying that it forces you to patch well and not dive into sloppy spaghetti patching, relying on visual feedback to keep track of what is going on. I stand by this argument big time. For those who wanted how to play with the interface it was also covered by checking the different hacks from Carmen. Of course there are some improvements to be made though on the keyboard side, I love what Chun and Matju did on the dd branch, a long time ago, to allow complete keyboard driven patching. I hope that Yvan Volochine can port some of this stuff in his plugin, this is a *real* feature, and would be a shame to have this work lost. Unfortunately it is unlikely that we provide 0.43 for Gazpacho, so no plugin for now (to reply to another mail). > I think it's Claude Heiland-Allen and Chun Lee. Yes, initially it was all of us, but as the development of Puredyne increased in complexity, things got more specialized and at the moment Claude and Chun are doing all the work. a. -- http://su.kuri.mu --- [email protected] http://identi.ca/group/puredyne irc://irc.goto10.org/puredyne
