On Mon, 2017-10-02 at 09:29 -0400, Ali Momeni wrote:
thanks everyone, this is really helpful.
in light of your experiences, it seems like the best of all worlds might be to use a modern computer/os with Purr Data for editing, make sure to stick with vanilla only objects, and use vanilla for deploying.
By forking Pure Data and adding incompatible changes, the devs of Purr Data created another ecosystem parallel to the Pure Data ecosystem and I think it's not that easy to make your works/patches cover both ecosystems. There is no guarantee your patches created in Purr Data will work in Pure Data and vice versa. So, yes, I do see potential pitfalls there. I'd say for the sake of your sanity it's probably wiser to stick with one or the other, since both have features that the other hasn't.
Many of my patches that I developed on Pure Data don't run without modification in Purr Data. Some crash at loading, some look graphically weird. Probably it wouldn't take such a big effort to make them work in Purr Data. However, I decided to stick with the Pure Data ecosystem leave Purr Data aside. My feeling is Pure Data still has a larger user base, more developers involved working on it and covers more versatile use cases (assuming libpd is considered part of the Pure Data ecosystem). Pure Data doesn't need a monolithic distribution since it has Deken, which is in my opinion a sensible way of dealing with distribution of externals.
That said, Purr Data is an impressive piece of work, it looks nice, is very easy to install and is also really nice to use. And I can somehow understand why things are how they are now and why it became different from and incompatible with Pure Data. But still, in my ideal world both would be just flavors of the very same core and people wouldn't be forced to decide for one or the other and could switch back and forth as they please.
Just my 2 cents.
Roman