On Thu, Jun 14, 2007 at 11:17:57AM +0200, Roman Haefeli wrote:
the question is: how should they be included? should they be included as they are now, with the gui and their dependency on the netpd-framework? or would it make more sense to strip everything off to get a working subset of abstractions, that can be used in a more flexible way? as far as i understand the concept of pd-extended as a collection of abstractions and externals (read: collection of tools/utility rather than a collection of examples), i'd vote for the latter, though that would involve a lot more work.
i'd rather do not include the abstractions/patches myself and i'd rather do not make the decision on how they should be included. but i'd be willing to deliver stripped off abstractions with helpfiles from my own netpd-patches, so someone else could could include/organize them in pd-extended.
One thing that would be cool for us to come up with is some way to abstract the core, and gui of abstractions separately in such a way that they could be used in multiple different state saving/communication paradigms.
For example, if I could make one abstraction for the s-abstractions collection and then have the user be able to choose whether it:
- saves using sssad, has a GOP gui
- saves using memento, has a GOP gui
- integrates with netpd, has netpd style gui
This could just be a pipe dream, but then again I could never have imagined someone creating something as amazing as netpd or sssad in Pure Data alone.
Best,
Chris.