Purr Data is finally released!
Purr Data inherits the goodness of Pd-l2ork and runs on Gnu/Linux, Windows, and OSX. Infinite undo, enhanced editing and 2d drawing, and most of the the externals from Pd-extended (plus more from Pd-l2ork).

[Edit]
2.2.4:

• fix [wrap~] inconsistency
• port mouse events from [hcs/cursor]
• fix bug with dollarsigns in struct names
• add some "legacy_mouse" classes to support externals that report mouse events: "legacy_mousemotion", "legacy_mouseclick" and "legacy_mousewheel"
• fix bug loading default libs on OSX

2.2.3:

• fixed overallocation bug that made loading soundfiles into arrays take up unnecessary amount of memory (4x-8x overallocation)
• fix some utf8 string handling routines
• port fixes for [soundfiler] from Pd Vanilla
• fix bug with "$@" that could cause invalid reads in some cases
• fix [initbang] functionality
• fix crasher in [pdinfo]

New in 2.2.2:

• fixed usability issues with the dropdown object

New in 2.2.1:

• fix stray GUI bugs
• fix some external libs that weren't building under Windows
• fix some OSX key event bugs

New in 2.2.0:

• fix GOP sizing algo to accommodate small GOP abstractions
• turn off anoying Gnome-keyring popup that appears on some systems
• bump nw.js GUI toolkit to 0.22.1
• fix arrow-key navigation-- use arrow keys for scrollbar navigation in runmode, turn off in editmode
• ignore iemgui label in bbox computation for "-legacy" mode
• fix OSCx library on arm builds
• guard against more out-of-order messages from Pd to GUI
• clean up and simplify build instructions
• leave enough space in GOP abstractions to accommodate all xlets
• fix search path bug
• update some of the documentation, removing old "messageoddness" patches that no longer apply to Purr Data
• update unauthorized library
• clean up and simplify the repository code/structure

New in 2.1.2:

• minor bugfix in the console (duplicate messages weren't printed after clearing)
• some minor fixes in the default startup configuration
• some cosmetic changes in the accompanying README and license information
• various bugfixes in objects and internal API functions (message boxes, dropdown atom, loadbang-related issues)
• updated lyonpotpourri to the latest 3.0 version to fix various 64 bit issues on Linux and macOS
• saving the preferences is much faster on the Mac now
• new animated "About Pd-L2ork" popup; also, the proper version is now shown in the generic "About" box on the Mac

New in 2.1.1:

• normalized range for [bendin] (keep old behavior under legacy flag)
• added "mouseenter" and "mouseleave" events for data structures
• fixed "Recent Files" under Windows
• cleaned up documentation in repo
• fix for [midiclkin] (#255)
• added "l2ork_version" message for [pdinfo]
• make loader search order the same as Pd Vanilla
• fixed cord inspector font size
• silence spurious error when autopatching a signal object
• added a [dropdown] object for choosing a value for an atom box (interface not stable yet)
• made gatom resizable by click-dragging in edit mode
• added "<ctrl-mousewheel>" for zooming
• added solarized and inverted solarized gui presets
• fixed mycanvas stroke color updates
• improvements to mode 4 of intelligent patching
• fixed "<Delete>" not deleting a selected object on some systems

New since rc5:

• fixed display bug with [vu] on graph-on-parent canvas
• fix documentation for timer-help.pd
• fix "open" method for [ggee/image]
• default to the user's home directory on OSX app bundle
• open the help browser file browser in the doc folder
• add a canvas "Print" menu item (under "File" menu)
• allow option to save the zoom level with the canvas
• fix a data structure crasher

please report lots of bugs to

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

Binaries:

https://github.com/jonwwilkes/purr-data/releases

This sounds amazing! Thank you guys for all your work!

HUGE kudos to Jonathan for pulling this off! He worked on this tirelessly for almost two years now to make it happen. He did an amazing job.

There are still a few (very few) rough edges (like the GUI integration features of some of the externals, most notably hammereditor), but we'll get these ironed out in the upcoming releases, now that 2.0 is finally out. If you've been looking for an actively maintained Pd-extended successor with a modern GUI and many improvements, this is it.

We've been using Purr Data at JGU for all computer music courses this semester (which also shook out quite a few of the remaining bugs, so thanks are due to my students as well). Thus I can say with some confidence that this version is really ready for day-to-day use now. In our lab we use desktop PCs equipped with Linux, but the students also have their own Mac and Windows laptops, and Purr Data ran fine on each of those. And if you run into any remaining issues, Jonathan already told you where to report them.

NB: In case you're wondering about the version number: We needed a versioning scheme that would allow us to keep Purr Data apart from upstream Pd-l2ork and vanilla, that's why it's dubbed "Pd-l2ork 2.0 a.k.a. Purr Data". With this release, Ico's original Pd-l2ork version becomes Pd-l2ork 1.0 and goes into maintenance mode, but will of course remain available at least until all the remaining features such as K12 mode and autotips have been ported over to Purr Data or have suitable replacements there.

Finally, a quick note for those running this side-by-side with vanilla Pd (as many will be doing): Purr Data remains almost 100% compatible with vanilla (and is of course 100% compatible with the Pd patch format), but there are a few areas where Pd-l2ork/Purr Data deliberately differs in order to fix long-standing bugs which can't be fixed in vanilla any more due to backwards compatibility concerns. If you want to run a Pd patch which absolutely needs 100% (bug) compatibility with vanilla, you can force Purr Data to that by simply putting -legacy into the startup flags.

One more thing: At JGU we also maintain our own Purr Data and Pd-l2ork Linux packages for Arch and different recent Ubuntu releases, so you may want to look at these if you're running Arch or an Ubuntu version not supported by Jonathan's packages. They also offer the advantage that you can install "classic" Pd-l2ork and Purr Data at the same time. More information including web pointers and installation instructions can be found at https://l2orkaur.bitbucket.io/ and https://l2orkubuntu.bitbucket.io/.

Just wanted to say thanks

Thanks for your work on this.

Just tried it but unfortunately it won't work for my main purpose -- thou that's something I've been meaning to ask about.

I've got a large patch made with vanilla with tons of tightly framed graph on parent abstractions. Of course most of these will not display properly in extended, l2ork v1 or this version. The -legacy flag helps somewhat but doesn't fully correct the problem.. Invoking -legacy does re-align the positional discrepancies outside of the G.O.P.s, which are not as much of a problem, but still an issue as everything is very tightly aligned in the original vanilla layouts.

What methods are there of dealing with this issue? Is there an automated script that could be used to convert the .pd text files to reformat them? Perhaps I'm just dreaming with that last question but the idea of having to redo every G.O.P. in this patch every time I make an update just to make it cross-compatible is pretty daunting.

@NoDSP If the "-legacy" flag doesn't solve the problem then it's a bug.

Can you post a trivial demo patch, either on the issue tracker or here?

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

By trivial, I mean with as few objects in the patch as possible to show the bug. (That makes it easier to narrow down the bug.)

@jancsika Ok, here's one, but I should note that in the course of making this demo I think I may have gotten a bit closer to the source of the problem (as noted in the comments). I'm not sure if this will be an easily solvable bug, as it may be down to a difference in the way the two GUIs work.

It's for that reason, as well as the issue of having to run two separate instances when you want to run legacy/non legacy patches at the same time that I brought up the idea of a patch converter so that -legacy won't be necessary -- though I don't really know if that's doable either based on my limited discovery noted in the patch below.

GOPfailtest.pd

(File Edit: Made a few changes for clarity)

@NoDSP Thanks a lot for the test patch.

Regarding example #4: the reason it is wider is because Pd-l2ork makes sure that the inlets and outlets are properly spaced so that they don't collide. (Based on your comment, Pd-extended does this, too.)

@jancsika I actually haven't been able to test w/extended recently but I remember running into similar problems.

Yes I figured that was an auto spacing issue with #4 but as vanilla lets me do it with no "collisions" that's the way it was set up originally as I was dealing with some very dense, tightly spaced GUI panels. Can the -legacy flag be made to disable this?

Regarding example #1: the toggle doesn't show up because the label appears outside of the GOP bounds. If you remove the label then the tgl will appear on the parent.

@jancsika Yes, this is what I was trying to get at with the comments as I figured that out when I put the file together. It's basically the same problem with the first three examples. Vanilla doesn't handle labels the same way -- you can place the label anywhere inside or outside the GOP border and it works just as if you had placed the GUI object directly on the canvas without the GOP abstraction. Vanilla doesn't see it as part of the object.

It still leaves me (and anyone else with legacy patches set up the like this) with the same problem -- I'd have to redo all of that (I've got lots of those) and then have to replace the object labels with small labelled canvases outside the GOPs just to make the patch compatible.

@NoDSP said:

@jancsika I actually haven't been able to test w/extended recently but I remember running into similar problems.

Yes I figured that was an auto spacing issue with #4 but as vanilla lets me do it with no "collisions" that's the way it was set up originally as I was dealing with some very dense, tightly spaced GUI panels. Can the -legacy flag be made to disable this?

That's certainly possible. I'll add an issue to the tracker about it.

However, the auto-spacing was implemented to solve problems of readability/consistency in normal object boxes. So it's not just a matter of disabling the behavior, but selectively keeping it for objects and disabling it for GOP canvases.

It still leaves me (and anyone else with legacy patches set up the like this) with the same problem -- I'd have to redo all of that (I've got lots of those) and then have to replace the object labels with small labelled canvases outside the GOPs just to make the patch compatible.

That behavior should be a bit more straightforward to throw into -legacy mode. But again, with no specification it's just something that I have to implement and test to make sure it doesn't break something somewhere else.

As far as "-legacy" mode-- the idea is to change that to a per-canvas flag that's compatible with Vanilla. So Pd-l2ork could just check the flag to see whether to read/write the canvas in "-legacy" mode. That would solve everything except for reading pd-l2ork patches in Vanilla.

@jancsika I don't know if you know the answer to this question, but just out of curiosity, why was the label behaviour changed to begin with? Was it problematic to work it into the post-vanilla interfaces? Was the change even intentional or was it just implemented that way because it was assumed vanilla worked that way? Would it affect compatibility with L2ork patches to just switch the whole thing back to the vanilla implementation?

The reason I ask is because when I think about it, I can understand the change to the inlet/outlet spacing, but Miller's original label behaviour just seems to make more sense. Take example 2. If I did that in L2ork and wanted to use the internal label function, I would have to extend the GOP border all the way to the end of the label, leaving a ton of dead space. I don't have that space as there are more controls next to it in the patch that I don't want inside the glide GOP and don't really belong there as they have nothing to do with the glide GOP's internal logic (deleted in that example for clarity -- there's quite a lot of it) . I could try pasting them on top of the dead space in the GOP, but I've had problems doing that kind of thing in the past so I generally avoid it. As I mentioned above the other option is to use a labelled canvas, but it seems like this is an unnecessary limitation of the internal labelling function.

@jancsika Also, I just noticed you added this ticket

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

That would address the problem of the label adding to the object's size, but would the label still appear both inside the GOP (when opened) and outside the GOP border (on the parent canvas), the same way as it does in Vanilla?

I could try pasting them on top of the dead space in the GOP, but I've had problems doing that kind of thing in the past so I generally avoid it.

What were the problems?

@NoDSP said:

@jancsika Also, I just noticed you added this ticket

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

That would address the problem of the label adding to the object's size, but would the label still appear both inside the GOP (when opened) and outside the GOP border (on the parent canvas), the same way as it does in Vanilla?

Yes.

@jancsika said:

What were the problems?

Well, I'm not sure how relevant it is now as that was back when I first started experimenting with GOP abstracts and I can't even remember which version or versions of Pd I was using at the time. Basically it was an intermittent problem of the top-pasted objects disappearing behind the GOP under certain conditions, such as when the patch or window was closed and opened again, or when the GOP was opened. Even without those issues it just seemed like a klutzy inelegant way of implementing things so at the time I just decided to move on with a different approach.

@jancsika said:

Yes.

Ok, Thanks.

Basically it was an intermittent problem of the top-pasted objects disappearing behind the GOP under certain conditions, such as when the patch or window was closed and opened again, or when the GOP was opened.

Pd-l2ork maintains consistent z-ordering across copying/pastng/undoing.

As for requiring the label to be within the GOP, I believe Ico did that specifically to deal with some buggy behavior in Pd-l2ork. But I cannot rememeber what the buggy behavior was.