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.

anyone see any potential pitfalls there?

-ali

On Mon, Oct 2, 2017 at 6:00 AM, José Rafael Subía Valdez < jsubiavaldez@gmail.com> wrote:

Same reason as Alexander Connor, I mainly work with computers of different backgrounds, including different OS and many are older than 5 years. The new GUI, although very nice, does cause increased processing. On top of Purr-Data not being supported for mac 10.8 and lower. On a side note, I did test the CEAMMC Puredata distribution and it works better in older systems although it is also not supported. I believe they use QT.

cheers

On Sun, Oct 1, 2017 at 10:00 PM, Alexander Connor a.connexx@runbox.com wrote:

...

Increased processing overhead with the new GUI -- assuming that matters with a specific computer set-up.

On Sun, 1 Oct 2017 13:48:09 -0400, Ali Momeni batchku@gmail.com wrote:

...

Hello all,

I've been playing around with the latest Purr Data from: https://agraef.github.io/purr-data/

and, well, I love it. The entire experience of working with Pd is much more pleasant.

I'm compelled to ask the group, especially the Pd Vanilla users among

us,

...

the following simple question:

What reason is there NOT to use Purr Data?

Am I missing something? Subtle disadvantages? Missing functionality? Reliability? Performance?

Thanks,

ali _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/li

stinfo/pd-list

---

Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/li stinfo/pd-list

-- José Rafael Subía Valdez www.jrsv.net

---

Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list

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

It is true that even the pure vanilla section of Purr Data is not 100% the same or compatible. I already mentioned how Purr Data doesn't carry yet all of the features from the latest Pd Vanilla (0.48) - though I know it'll get there eventually. Some of these considerations we're bringing here have to do with the Purr Data project being still relatively new. I'm expecting it to be more fully compatible.

But besides Purr Data not integrating all of vanilla yet, it also has some different functionalities of Vanilla's objects. Even regarding syntax, like being able to load $0 in messages (and boy, do I wish that was in Vanilla). So that can be tricky as well.

Anyway, I don't think is that bad to go ahead and use both ;)

cheers

2017-10-02 12:53 GMT-03:00 Jonathan Wilkes via Pd-list <pd-list@lists.iem.at

:

...

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

Typically, "crashers" and "freezers" get fixed pretty quick in Purr Data.

The only freezer I remember with one of your patches was due to a broken object triggering an infinite loop in your patch's [until] object. I'm pretty sure that was an alpha or beta version, and I'm pretty sure I fixed whatever object it was that wouldn't create.

I don't see any other relevant crashers listed on the tracker:

https://git.purrdata.net/jwilkes/purr-data/issues

What am I missing?

-Jonathan

---

Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list

Purr Data looks like a continuity of pd-extended, anyway all pd versions are obsolete since they aren't fully 64bit compatible.

Do most audio devices now require a 64-bit driver under Windows? -Jonathan

Great the Jonathan has joined this thread.

What keeps Purr data from running the latest pd core (0.48) and leaving aside things that Purr can do that vanilla can't (i.e. $0 in message box), are there any concerns going the other way? i.e. basic things that vanilla can do that Purr cant?

On Mon, Oct 2, 2017 at 11:53 AM, Jonathan Wilkes via Pd-list < pd-list@lists.iem.at> wrote:

...

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

Typically, "crashers" and "freezers" get fixed pretty quick in Purr Data.

The only freezer I remember with one of your patches was due to a broken object triggering an infinite loop in your patch's [until] object. I'm pretty sure that was an alpha or beta version, and I'm pretty sure I fixed whatever object it was that wouldn't create.

I don't see any other relevant crashers listed on the tracker:

https://git.purrdata.net/jwilkes/purr-data/issues

What am I missing?

-Jonathan

---

Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list

Great the Jonathan has joined this thread. What keeps Purr data from running the latest pd core (0.48) and leaving aside things that Purr can do that vanilla can't (i.e. $0 in message box), are there any concerns going the other way? i.e. basic things that vanilla can do that Purr cant?

Look at the set of features that were added in Pd Vanilla 0.48. Those features are not yet available in Purr Data. -Jonathan

If supporting pure vanilla patches to their full extent would be a stated goal of the Pure Data project, I'd have some incentive to report stuff, but it seems it isn't.

Supporting Pd Vanilla patches to their fullest extend is a goal of Purr Data. What are the crashers you are experiencing? -Jonathan

Roman

I will let you know as soon as I'm on a machine that I can install a pre-compiled deb package of Purr Data on. Unfortunately, my personal laptop is still running Ubuntu 16.04 i386 because I've been upgrading for a couple of years and I never installed from scratch.

Oh, I see. No rush, then. I thought you were talking about recent crashes. Best,Jonathan

...

On Mon, 2017-10-02 at 18:34 +0000, Jonathan Wilkes wrote:

...

If supporting pure vanilla patches to their full extent would be a stated goal of the Pure Data project, I'd have some incentive to

report

...

stuff, but it seems it isn't.

Supporting Pd Vanilla patches to their fullest extend is a goal of Purr Data.

Up to which version? I'm asking about what you'd like to have reported

as bug and what rather not. The 'set' method to [dac~] was implemented

in Pure Data 0.47 (I guess) and is not yet supported in Purr Data.

Please report it on the issue tracker:

https://git.purrdata.net/jwilkes/purr-data/issues

...

What are the crashers you are experiencing?

Re weird looking patches and unusuable GUIs: the flag -legacy pretty much nails it. Most of the patches I tested look good and work well. Two issues I encountered regarding the GUI part:

1. In Pure Data in a group of overlapping widgets, the lowest one grabs

the mouse commands (which is probably not a design decision, but it

proved helpful for certain hacks). In Purr Data, the most top one grabs

the mouse, which breaks such patches created in Pure Data. I'm not

proposing to change that behavior, as it probably seems more logical to

most users the way Purr Data does it, I'm simply pointing out

differences.

Do you have patches which rely on that?

2. A self-made abstraction (GOP widget) that lets you scroll through a

list of and select an item, doesn't work well in Pure Data. Instead of

showing only the label of the last selected item, all labels stay and

thus end up in a black block after a while. I haven't investigated the

root cause yet.

Hard to tell without looking at it:

https://git.purrdata.net/jwilkes/purr-data/issues

Re crashes. I do experience some crashes, for instance when loading

certain netpd sessions (which does quite a lot of things including but not limited to dynamically creating abstractions). But I haven't

investigated yet why. It may be due to an external I use which comes in

a different version in Purr Data.

I will report back when I more useful data.

Thanks, Jonathan

Roman

Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list