Hello all,
I can imagine some of the responses to this question. I have been using Pd 0.43.4 extended for a number of years. Computer crashed which seemed like a good time to consider a new way to work in Pd. Over the past three years I have gotten better at using Pd so I was able to get Vanilla to be closer to what I want.

To the question: Well should I try to go to Vanilla or go to purr data?

Can someone give a brief pros/cons to each?

@raynovich I maintain Purr Data.

Basically, if things like xlet colors, theming, infinite undo, user-friendly built-in preset system, and ease of use matter I'd say use Purr Data.

The drawback is that Purr Data doesn't use the deken system. So if you need access to libraries that don't ship with Purr Data, you have to compile them yourself. Also, the [pd~] object still doesn't work correctly unless you run in "-nogui" mode.

Hope that helps,
Jonathan

@raynovich I'm kind of in the same boat as I've moved from extended to vanilla a few months ago as I was having too many problems with crashes and overheating. Vanilla is fine for me, it's kind of annoying at times due to some externals not available for 64 bit mac, but the only drawbacks I really wish were implemented are the lack of cord inspector, and of course a different colour scheme for the message and audio xlets would help a ton sometimes. As for the rest I don't personally care so much for a fancy gui.

I've downloaded Purr Data a few days ago and it's very nice indeed, I think I'll play with it for a while to see how I like it and I suggest you do the same to make up your mind? I'm not sure how practical it will be though since I don't know how to compile externals.

Another alternative might be the CEAMMC Puredata distribution? it uses deken and have a themed interface close to pd-extended, infinite undo, objects toolbar, grid and more... It's based on pd-vanilla 0.41-1:

https://github.com/uliss/pure-data

I think it should also be mentioned that the Purr Data GUI is more CPU intensive than Vanilla. It probably doesn't matter much on faster machines, but it might be a factor if you're running on a slower machine.

@LiamG said:

I think it should also be mentioned that the Purr Data GUI is more CPU intensive than Vanilla. It probably doesn't matter much on faster machines, but it might be a factor if you're running on a slower machine.

That's true-- you'll definitely notice the difference on a machine with single CPU. On multi-core machines the GUI shouldn't be getting in the way in the course of normal patching operations. (Especially if you run Pd with realtime priorities.)

The actual chatter between the GUI and audio process should be less, though. For example, if you move a selection of objects it's just a single message rather than one message per object. Also, textbox edition doesn't touch the audio process until you re-instantiate the object/message.

But like Pd Vanilla, you can still trigger dropouts by moving the mouse over a patch if there are enough objects on the canvas. Someone started doing work in the direction of fixing that. But it's very tricky to get right without breaking some random Pd ninja's use of Pd's unspecified interface.

However, you can set event callbacks for the new [draw] commands without sending streams of "motion" messages to the canvas. So there's that.

I think there is one thing to take into account : what do you want to do with your projects ?

If you want to keep them on a computer, and run them inside the software itself I would go with Purr Data.

If you want to be able to run your patches with libpd : for instance on mobile devices, run them as vst/vsti plugins, or use them in unity etc. You'll need to stick to vanilla or learn how to compile externals for the platform you target.

Keeping things vanilla is not that hard and sometimes actually forces you to get creative